diff options
Diffstat (limited to 'Documentation')
1081 files changed, 34782 insertions, 11418 deletions
diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index e8797cd09aff..cd14ecb3c9a5 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -260,6 +260,15 @@ Description: for discards, and don't read this file. +What: /sys/block/<disk>/queue/dma_alignment +Date: May 2022 +Contact: linux-block@vger.kernel.org +Description: + Reports the alignment that user space addresses must have to be + used for raw block device access with O_DIRECT and other driver + specific passthrough mechanisms. + + What: /sys/block/<disk>/queue/fua Date: May 2018 Contact: linux-block@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index b312242d4f40..af0cbf143c48 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -1,7 +1,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_health Date: June 2018 KernelVersion: 4.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file shows ASIC health status. The possible values are: 0 - health failed, 2 - health OK, 3 - ASIC in booting state. @@ -11,7 +11,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version Date: June 2018 KernelVersion: 4.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show with which CPLD versions have been burned on carrier and switch boards. @@ -20,7 +20,7 @@ Description: These files show with which CPLD versions have been burned What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/fan_dir Date: December 2018 KernelVersion: 5.0 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file shows the system fans direction: forward direction - relevant bit is set 0; reversed direction - relevant bit is set 1. @@ -30,7 +30,7 @@ Description: This file shows the system fans direction: What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version Date: November 2018 KernelVersion: 5.0 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show with which CPLD versions have been burned on LED or Gearbox board. @@ -39,7 +39,7 @@ Description: These files show with which CPLD versions have been burned What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_enable Date: November 2018 KernelVersion: 5.0 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files enable and disable the access to the JTAG domain. By default access to the JTAG domain is disabled. @@ -48,7 +48,7 @@ Description: These files enable and disable the access to the JTAG domain. What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio Date: June 2018 KernelVersion: 4.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file allows iio devices selection. Attribute select_iio can be written with 0 or with 1. It @@ -62,7 +62,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down Date: June 2018 KernelVersion: 4.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files allow asserting system power cycling, switching power supply units on and off and system's main power domain shutdown. @@ -89,7 +89,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_short_pb What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sw_reset Date: June 2018 KernelVersion: 4.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show the system reset cause, as following: power auxiliary outage or power refresh, ASIC thermal shutdown, halt, hotswap, watchdog, firmware reset, long press power button, @@ -106,7 +106,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_system What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_voltmon_upgrade_fail Date: November 2018 KernelVersion: 5.0 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show the system reset cause, as following: ComEx power fail, reset from ComEx, system platform reset, reset due to voltage monitor devices upgrade failure, @@ -119,7 +119,7 @@ Description: These files show the system reset cause, as following: ComEx What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version Date: November 2018 KernelVersion: 5.0 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show with which CPLD versions have been burned on LED board. @@ -133,7 +133,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sff_wd What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_wd Date: June 2019 KernelVersion: 5.3 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show the system reset cause, as following: COMEX thermal shutdown; wathchdog power off or reset was derived by one of the next components: COMEX, switch board or by Small Form @@ -148,7 +148,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config1 What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config2 Date: January 2020 KernelVersion: 5.6 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show system static topology identification like system's static I2C topology, number and type of FPGA devices within the system and so on. @@ -161,7 +161,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_soc What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sw_pwr_off Date: January 2020 KernelVersion: 5.6 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show the system reset causes, as following: reset due to AC power failure, reset invoked from software by assertion reset signal through CPLD. reset caused by signal @@ -173,7 +173,7 @@ Description: These files show the system reset causes, as following: reset What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pcie_asic_reset_dis Date: January 2020 KernelVersion: 5.6 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file allows to retain ASIC up during PCIe root complex reset, when attribute is set 1. @@ -182,7 +182,7 @@ Description: This file allows to retain ASIC up during PCIe root complex What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp Date: January 2020 KernelVersion: 5.6 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file allows to overwrite system VPD hardware write protection when attribute is set 1. @@ -191,7 +191,7 @@ Description: This file allows to overwrite system VPD hardware write What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/voltreg_update_status Date: January 2020 KernelVersion: 5.6 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file exposes the configuration update status of burnable voltage regulator devices. The status values are as following: 0 - OK; 1 - CRC failure; 2 = I2C failure; 3 - in progress. @@ -201,7 +201,7 @@ Description: This file exposes the configuration update status of burnable What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ufm_version Date: January 2020 KernelVersion: 5.6 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file exposes the firmware version of burnable voltage regulator devices. @@ -217,7 +217,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min Date: July 2020 KernelVersion: 5.9 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: These files show with which CPLD part numbers and minor versions have been burned CPLD devices equipped on a system. @@ -471,7 +471,7 @@ Description: These files provide the maximum powered required for line card What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/phy_reset Date: May 2022 KernelVersion: 5.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file allows to reset PHY 88E1548 when attribute is set 0 due to some abnormal PHY behavior. Expected behavior: @@ -483,7 +483,7 @@ Description: This file allows to reset PHY 88E1548 when attribute is set 0 What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/mac_reset Date: May 2022 KernelVersion: 5.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file allows to reset ASIC MT52132 when attribute is set 0 due to some abnormal ASIC behavior. Expected behavior: @@ -495,7 +495,7 @@ Description: This file allows to reset ASIC MT52132 when attribute is set 0 What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/qsfp_pwr_good Date: May 2022 KernelVersion: 5.19 -Contact: Vadim Pasternak <vadimpmellanox.com> +Contact: Vadim Pasternak <vadimp@nvidia.com> Description: This file shows QSFP ports power status. The value is set to 0 when one of any QSFP ports is plugged. The value is set to 1 when there are no any QSFP ports are plugged. @@ -503,3 +503,42 @@ Description: This file shows QSFP ports power status. The value is set to 0 0 - Power good, 1 - Not power good. The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic2_health +Date: July 2022 +KernelVersion: 5.20 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file shows 2-nd ASIC health status. The possible values are: + 0 - health failed, 2 - health OK, 3 - ASIC in booting state. + + The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_reset +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic2_reset +Date: July 2022 +KernelVersion: 5.20 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files allow to each of ASICs by writing 1. + + The files are write only. + + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/comm_chnl_ready +Date: July 2022 +KernelVersion: 5.20 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file is used to indicate remote end (for example BMC) that system + host CPU is ready for sending telemetry data to remote end. + For indication the file should be written 1. + + The file is write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config3 +Date: January 2020 +KernelVersion: 5.6 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: The file indicates COME module hardware configuration. + The value is pushed by hardware through GPIO pins. + The purpose is to expose some minor BOM changes for the same system SKU. + + The file is read only. diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module index 560b4a3278df..41b1f16e8795 100644 --- a/Documentation/ABI/stable/sysfs-module +++ b/Documentation/ABI/stable/sysfs-module @@ -38,7 +38,7 @@ What: /sys/module/<MODULENAME>/srcversion Date: Jun 2005 Description: If the module source has MODULE_VERSION, this file will contain - the checksum of the the source code. + the checksum of the source code. What: /sys/module/<MODULENAME>/version Date: Jun 2005 diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage index c86b63a7bb43..fc0328069267 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage +++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage @@ -19,7 +19,7 @@ KernelVersion: 3.13 Description: The attributes: - =========== ============================================== + ============ ============================================== file The path to the backing file for the LUN. Required if LUN is not marked as removable. ro Flag specifying access to the LUN shall be @@ -32,4 +32,10 @@ Description: being a CD-ROM. nofua Flag specifying that FUA flag in SCSI WRITE(10,12) - =========== ============================================== + forced_eject This write-only file is useful only when + the function is active. It causes the backing + file to be forcibly detached from the LUN, + regardless of whether the host has allowed it. + Any non-zero number of bytes written will + result in ejection. + ============ ============================================== diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 0f8d20fe343f..c915bf17b293 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -101,6 +101,15 @@ Description: Specify the size of the DMA transaction when using DMA to read When the write is finished, the user can read the "data_dma" blob +What: /sys/kernel/debug/habanalabs/hl<n>/dump_razwi_events +Date: Aug 2022 +KernelVersion: 5.20 +Contact: fkassabri@habana.ai +Description: Dumps all razwi events to dmesg if exist. + After reading the status register of an existing event + the routine will clear the status register. + Usage: cat dump_razwi_events + What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations Date: Jan 2021 KernelVersion: 5.12 @@ -121,14 +130,16 @@ Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Sets I2C device address for I2C transaction that is generated - by the device's CPU + by the device's CPU, Not available when device is loaded with secured + firmware What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Sets I2C bus address for I2C transaction that is generated by - the device's CPU + the device's CPU, Not available when device is loaded with secured + firmware What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data Date: Jan 2019 @@ -136,39 +147,45 @@ KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Triggers an I2C transaction that is generated by the device's CPU. Writing to this file generates a write transaction while - reading from the file generates a read transaction + reading from the file generates a read transaction, Not available + when device is loaded with secured firmware What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len Date: Dec 2021 KernelVersion: 5.17 Contact: obitton@habana.ai Description: Sets I2C length in bytes for I2C transaction that is generated by - the device's CPU + the device's CPU, Not available when device is loaded with secured + firmware What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Sets I2C register id for I2C transaction that is generated by - the device's CPU + the device's CPU, Not available when device is loaded with secured + firmware What: /sys/kernel/debug/habanalabs/hl<n>/led0 Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Sets the state of the first S/W led on the device +Description: Sets the state of the first S/W led on the device, Not available + when device is loaded with secured firmware What: /sys/kernel/debug/habanalabs/hl<n>/led1 Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Sets the state of the second S/W led on the device +Description: Sets the state of the second S/W led on the device, Not available + when device is loaded with secured firmware What: /sys/kernel/debug/habanalabs/hl<n>/led2 Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Sets the state of the third S/W led on the device +Description: Sets the state of the third S/W led on the device, Not available + when device is loaded with secured firmware What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub Date: May 2022 @@ -182,7 +199,8 @@ Date: May 2022 KernelVersion: 5.19 Contact: dhirschfeld@habana.ai Description: The value to which the dram will be set to when the user - scrubs the dram using 'memory_scrub' debugfs file + scrubs the dram using 'memory_scrub' debugfs file and + the scrubbing value when using module param 'memory_scrub' What: /sys/kernel/debug/habanalabs/hl<n>/mmu Date: Jan 2019 @@ -277,7 +295,7 @@ Description: Displays a list with information about the currently user to DMA addresses What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup -Date: Aug 2021 +Date: Oct 2021 KernelVersion: 5.15 Contact: ogabbay@kernel.org Description: Allows to search for specific user pointers (user virtual diff --git a/Documentation/ABI/testing/procfs-smaps_rollup b/Documentation/ABI/testing/procfs-smaps_rollup index a4e31c465194..b446a7154a1b 100644 --- a/Documentation/ABI/testing/procfs-smaps_rollup +++ b/Documentation/ABI/testing/procfs-smaps_rollup @@ -22,6 +22,7 @@ Description: MMUPageSize: 4 kB Rss: 884 kB Pss: 385 kB + Pss_Dirty: 68 kB Pss_Anon: 301 kB Pss_File: 80 kB Pss_Shmem: 4 kB diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 7c2b846521f3..8494ef27e8d2 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -7,6 +7,7 @@ Description: all descendant memdevs for unbind. Writing '1' to this attribute flushes that work. + What: /sys/bus/cxl/devices/memX/firmware_version Date: December, 2020 KernelVersion: v5.12 @@ -16,6 +17,7 @@ Description: Memory Device Output Payload in the CXL-2.0 specification. + What: /sys/bus/cxl/devices/memX/ram/size Date: December, 2020 KernelVersion: v5.12 @@ -25,6 +27,7 @@ Description: identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. + What: /sys/bus/cxl/devices/memX/pmem/size Date: December, 2020 KernelVersion: v5.12 @@ -34,6 +37,7 @@ Description: identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. + What: /sys/bus/cxl/devices/memX/serial Date: January, 2022 KernelVersion: v5.18 @@ -43,6 +47,7 @@ Description: capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2 Memory Device PCIe Capabilities and Extended Capabilities. + What: /sys/bus/cxl/devices/memX/numa_node Date: January, 2022 KernelVersion: v5.18 @@ -52,114 +57,334 @@ Description: host PCI device for this memory device, emit the CPU node affinity for this device. + What: /sys/bus/cxl/devices/*/devtype Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - CXL device objects export the devtype attribute which mirrors - the same value communicated in the DEVTYPE environment variable - for uevents for devices on the "cxl" bus. + (RO) CXL device objects export the devtype attribute which + mirrors the same value communicated in the DEVTYPE environment + variable for uevents for devices on the "cxl" bus. + What: /sys/bus/cxl/devices/*/modalias Date: December, 2021 KernelVersion: v5.18 Contact: linux-cxl@vger.kernel.org Description: - CXL device objects export the modalias attribute which mirrors - the same value communicated in the MODALIAS environment variable - for uevents for devices on the "cxl" bus. + (RO) CXL device objects export the modalias attribute which + mirrors the same value communicated in the MODALIAS environment + variable for uevents for devices on the "cxl" bus. + What: /sys/bus/cxl/devices/portX/uport Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - CXL port objects are enumerated from either a platform firmware - device (ACPI0017 and ACPI0016) or PCIe switch upstream port with - CXL component registers. The 'uport' symlink connects the CXL - portX object to the device that published the CXL port + (RO) CXL port objects are enumerated from either a platform + firmware device (ACPI0017 and ACPI0016) or PCIe switch upstream + port with CXL component registers. The 'uport' symlink connects + the CXL portX object to the device that published the CXL port capability. + What: /sys/bus/cxl/devices/portX/dportY Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - CXL port objects are enumerated from either a platform firmware - device (ACPI0017 and ACPI0016) or PCIe switch upstream port with - CXL component registers. The 'dportY' symlink identifies one or - more downstream ports that the upstream port may target in its - decode of CXL memory resources. The 'Y' integer reflects the - hardware port unique-id used in the hardware decoder target - list. + (RO) CXL port objects are enumerated from either a platform + firmware device (ACPI0017 and ACPI0016) or PCIe switch upstream + port with CXL component registers. The 'dportY' symlink + identifies one or more downstream ports that the upstream port + may target in its decode of CXL memory resources. The 'Y' + integer reflects the hardware port unique-id used in the + hardware decoder target list. + What: /sys/bus/cxl/devices/decoderX.Y Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - CXL decoder objects are enumerated from either a platform + (RO) CXL decoder objects are enumerated from either a platform firmware description, or a CXL HDM decoder register set in a PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder Capability Structure). The 'X' in decoderX.Y represents the cxl_port container of this decoder, and 'Y' represents the instance id of a given decoder resource. + What: /sys/bus/cxl/devices/decoderX.Y/{start,size} Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - The 'start' and 'size' attributes together convey the physical - address base and number of bytes mapped in the decoder's decode - window. For decoders of devtype "cxl_decoder_root" the address - range is fixed. For decoders of devtype "cxl_decoder_switch" the - address is bounded by the decode range of the cxl_port ancestor - of the decoder's cxl_port, and dynamically updates based on the - active memory regions in that address space. + (RO) The 'start' and 'size' attributes together convey the + physical address base and number of bytes mapped in the + decoder's decode window. For decoders of devtype + "cxl_decoder_root" the address range is fixed. For decoders of + devtype "cxl_decoder_switch" the address is bounded by the + decode range of the cxl_port ancestor of the decoder's cxl_port, + and dynamically updates based on the active memory regions in + that address space. + What: /sys/bus/cxl/devices/decoderX.Y/locked Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - CXL HDM decoders have the capability to lock the configuration - until the next device reset. For decoders of devtype - "cxl_decoder_root" there is no standard facility to unlock them. - For decoders of devtype "cxl_decoder_switch" a secondary bus - reset, of the PCIe bridge that provides the bus for this - decoders uport, unlocks / resets the decoder. + (RO) CXL HDM decoders have the capability to lock the + configuration until the next device reset. For decoders of + devtype "cxl_decoder_root" there is no standard facility to + unlock them. For decoders of devtype "cxl_decoder_switch" a + secondary bus reset, of the PCIe bridge that provides the bus + for this decoders uport, unlocks / resets the decoder. + What: /sys/bus/cxl/devices/decoderX.Y/target_list Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - Display a comma separated list of the current decoder target - configuration. The list is ordered by the current configured - interleave order of the decoder's dport instances. Each entry in - the list is a dport id. + (RO) Display a comma separated list of the current decoder + target configuration. The list is ordered by the current + configured interleave order of the decoder's dport instances. + Each entry in the list is a dport id. + What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3} Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - When a CXL decoder is of devtype "cxl_decoder_root", it + (RO) When a CXL decoder is of devtype "cxl_decoder_root", it represents a fixed memory window identified by platform firmware. A fixed window may only support a subset of memory types. The 'cap_*' attributes indicate whether persistent memory, volatile memory, accelerator memory, and / or expander memory may be mapped behind this decoder's memory window. + What: /sys/bus/cxl/devices/decoderX.Y/target_type Date: June, 2021 KernelVersion: v5.14 Contact: linux-cxl@vger.kernel.org Description: - When a CXL decoder is of devtype "cxl_decoder_switch", it can - optionally decode either accelerator memory (type-2) or expander - memory (type-3). The 'target_type' attribute indicates the - current setting which may dynamically change based on what + (RO) When a CXL decoder is of devtype "cxl_decoder_switch", it + can optionally decode either accelerator memory (type-2) or + expander memory (type-3). The 'target_type' attribute indicates + the current setting which may dynamically change based on what memory regions are activated in this decode hierarchy. + + +What: /sys/bus/cxl/devices/endpointX/CDAT +Date: July, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) If this sysfs entry is not present no DOE mailbox was + found to support CDAT data. If it is present and the length of + the data is 0 reading the CDAT data failed. Otherwise the CDAT + data is reported. + + +What: /sys/bus/cxl/devices/decoderX.Y/mode +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it + translates from a host physical address range, to a device local + address range. Device-local address ranges are further split + into a 'ram' (volatile memory) range and 'pmem' (persistent + memory) range. The 'mode' attribute emits one of 'ram', 'pmem', + 'mixed', or 'none'. The 'mixed' indication is for error cases + when a decoder straddles the volatile/persistent partition + boundary, and 'none' indicates the decoder is not actively + decoding, or no DPA allocation policy has been set. + + 'mode' can be written, when the decoder is in the 'disabled' + state, with either 'ram' or 'pmem' to set the boundaries for the + next allocation. + + +What: /sys/bus/cxl/devices/decoderX.Y/dpa_resource +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) When a CXL decoder is of devtype "cxl_decoder_endpoint", + and its 'dpa_size' attribute is non-zero, this attribute + indicates the device physical address (DPA) base address of the + allocation. + + +What: /sys/bus/cxl/devices/decoderX.Y/dpa_size +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it + translates from a host physical address range, to a device local + address range. The range, base address plus length in bytes, of + DPA allocated to this decoder is conveyed in these 2 attributes. + Allocations can be mutated as long as the decoder is in the + disabled state. A write to 'dpa_size' releases the previous DPA + allocation and then attempts to allocate from the free capacity + in the device partition referred to by 'decoderX.Y/mode'. + Allocate and free requests can only be performed on the highest + instance number disabled decoder with non-zero size. I.e. + allocations are enforced to occur in increasing 'decoderX.Y/id' + order and frees are enforced to occur in decreasing + 'decoderX.Y/id' order. + + +What: /sys/bus/cxl/devices/decoderX.Y/interleave_ways +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) The number of targets across which this decoder's host + physical address (HPA) memory range is interleaved. The device + maps every Nth block of HPA (of size == + 'interleave_granularity') to consecutive DPA addresses. The + decoder's position in the interleave is determined by the + device's (endpoint or switch) switch ancestry. For root + decoders their interleave is specified by platform firmware and + they only specify a downstream target order for host bridges. + + +What: /sys/bus/cxl/devices/decoderX.Y/interleave_granularity +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) The number of consecutive bytes of host physical address + space this decoder claims at address N before the decode rotates + to the next target in the interleave at address N + + interleave_granularity (assuming N is aligned to + interleave_granularity). + + +What: /sys/bus/cxl/devices/decoderX.Y/create_pmem_region +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write a string in the form 'regionZ' to start the process + of defining a new persistent memory region (interleave-set) + within the decode range bounded by root decoder 'decoderX.Y'. + The value written must match the current value returned from + reading this attribute. An atomic compare exchange operation is + done on write to assign the requested id to a region and + allocate the region-id for the next creation attempt. EBUSY is + returned if the region name written does not match the current + cached value. + + +What: /sys/bus/cxl/devices/decoderX.Y/delete_region +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) Write a string in the form 'regionZ' to delete that region, + provided it is currently idle / not bound to a driver. + + +What: /sys/bus/cxl/devices/regionZ/uuid +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write a unique identifier for the region. This field must + be set for persistent regions and it must not conflict with the + UUID of another region. + + +What: /sys/bus/cxl/devices/regionZ/interleave_granularity +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Set the number of consecutive bytes each device in the + interleave set will claim. The possible interleave granularity + values are determined by the CXL spec and the participating + devices. + + +What: /sys/bus/cxl/devices/regionZ/interleave_ways +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Configures the number of devices participating in the + region is set by writing this value. Each device will provide + 1/interleave_ways of storage for the region. + + +What: /sys/bus/cxl/devices/regionZ/size +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) System physical address space to be consumed by the region. + When written trigger the driver to allocate space out of the + parent root decoder's address space. When read the size of the + address space is reported and should match the span of the + region's resource attribute. Size shall be set after the + interleave configuration parameters. Once set it cannot be + changed, only freed by writing 0. The kernel makes no guarantees + that data is maintained over an address space freeing event, and + there is no guarantee that a free followed by an allocate + results in the same address being allocated. + + +What: /sys/bus/cxl/devices/regionZ/resource +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) A region is a contiguous partition of a CXL root decoder + address space. Region capacity is allocated by writing to the + size attribute, the resulting physical address space determined + by the driver is reflected here. It is therefore not useful to + read this before writing a value to the size attribute. + + +What: /sys/bus/cxl/devices/regionZ/target[0..N] +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write an endpoint decoder object name to 'targetX' where X + is the intended position of the endpoint device in the region + interleave and N is the 'interleave_ways' setting for the + region. ENXIO is returned if the write results in an impossible + to map decode scenario, like the endpoint is unreachable at that + position relative to the root decoder interleave. EBUSY is + returned if the position in the region is already occupied, or + if the region is not in a state to accept interleave + configuration changes. EINVAL is returned if the object name is + not an endpoint decoder. Once all positions have been + successfully written a final validation for decode conflicts is + performed before activating the region. + + +What: /sys/bus/cxl/devices/regionZ/commit +Date: May, 2022 +KernelVersion: v5.20 +Contact: linux-cxl@vger.kernel.org +Description: + (RW) Write a boolean 'true' string value to this attribute to + trigger the region to transition from the software programmed + state to the actively decoding in hardware state. The commit + operation in addition to validating that the region is in proper + configured state, validates that the decoders are being + committed in spec mandated order (last committed decoder id + + 1), and checks that the hardware accepts the commit request. + Reading this value indicates whether the region is committed or + not. diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps b/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps new file mode 100644 index 000000000000..8757dcf41c08 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps @@ -0,0 +1,18 @@ +What: /sys/bus/event_source/devices/<dev>/caps +Date: May 2022 +KernelVersion: 5.19 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + Attribute group to describe the capabilities exposed + for a particular pmu. Each attribute of this group can + expose information specific to a PMU, say pmu_name, so that + userspace can understand some of the feature which the + platform specific PMU supports. + + One of the example available capability in supported platform + like Intel is pmu_name, which exposes underlying CPU name known + to the PMU driver. + + Example output in powerpc: + grep . /sys/bus/event_source/devices/cpu/caps/* + /sys/bus/event_source/devices/cpu/caps/pmu_name:POWER9 diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index d4ccc68fdcf0..e81ba6f5e1c8 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -79,6 +79,11 @@ Description: * "accel-base" * "accel-display" + For devices where an accelerometer is housed in the swivel camera subassembly + (for AR application), the following standardized label is used: + + * "accel-camera" + What: /sys/bus/iio/devices/iio:deviceX/current_timestamp_clock KernelVersion: 4.5 Contact: linux-iio@vger.kernel.org @@ -102,6 +107,9 @@ Description: relevant directories. If it affects all of the above then it is to be found in the base device directory. + The stm32-timer-trigger has the additional characteristic that + a sampling_frequency of 0 is defined to stop sampling. + What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available What: /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency_available What: /sys/bus/iio/devices/iio:deviceX/in_proximity_sampling_frequency_available diff --git a/Documentation/ABI/testing/sysfs-bus-iio-sx9324 b/Documentation/ABI/testing/sysfs-bus-iio-sx9324 index 632e3321f5a3..a8342770e7cb 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-sx9324 +++ b/Documentation/ABI/testing/sysfs-bus-iio-sx9324 @@ -5,6 +5,7 @@ Contact: Gwendal Grignou <gwendal@chromium.org> Description: SX9324 has 3 inputs, CS0, CS1 and CS2. Hardware layout defines if the input is + + not connected (HZ), + grounded (GD), + connected to an antenna where it can act as a base diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856 b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856 deleted file mode 100644 index e5ef6d8e5da1..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856 +++ /dev/null @@ -1,31 +0,0 @@ -What: /sys/bus/iio/devices/iio:deviceX/fault_oc -KernelVersion: 5.1 -Contact: linux-iio@vger.kernel.org -Description: - Open-circuit fault. The detection of open-circuit faults, - such as those caused by broken thermocouple wires. - Reading returns either '1' or '0'. - - === ======================================================= - '1' An open circuit such as broken thermocouple wires - has been detected. - '0' No open circuit or broken thermocouple wires are detected - === ======================================================= - -What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv -KernelVersion: 5.1 -Contact: linux-iio@vger.kernel.org -Description: - Overvoltage or Undervoltage Input Fault. The internal circuitry - is protected from excessive voltages applied to the thermocouple - cables by integrated MOSFETs at the T+ and T- inputs, and the - BIAS output. These MOSFETs turn off when the input voltage is - negative or greater than VDD. - - Reading returns either '1' or '0'. - - === ======================================================= - '1' The input voltage is negative or greater than VDD. - '0' The input voltage is positive and less than VDD (normal - state). - === ======================================================= diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 deleted file mode 100644 index 4b072da92218..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 +++ /dev/null @@ -1,20 +0,0 @@ -What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv -KernelVersion: 5.11 -Contact: linux-iio@vger.kernel.org -Description: - Overvoltage or Undervoltage Input fault. The internal circuitry - is protected from excessive voltages applied to the thermocouple - cables at FORCE+, FORCE2, RTDIN+ & RTDIN-. This circuitry turn - off when the input voltage is negative or greater than VDD. - - Reading returns '1' if input voltage is negative or greater - than VDD, otherwise '0'. - -What: /sys/bus/iio/devices/iio:deviceX/in_filter_notch_center_frequency -KernelVersion: 5.11 -Contact: linux-iio@vger.kernel.org -Description: - Notch frequency in Hz for a noise rejection filter. Used i.e for - line noise rejection. - - Valid notch filter values are 50 Hz and 60 Hz. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-thermocouple b/Documentation/ABI/testing/sysfs-bus-iio-thermocouple new file mode 100644 index 000000000000..01259df297ca --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-thermocouple @@ -0,0 +1,18 @@ +What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv +KernelVersion: 5.1 +Contact: linux-iio@vger.kernel.org +Description: + Overvoltage or Undervoltage Input Fault. The internal circuitry + is protected from excessive voltages applied to the thermocouple + cables. The device can also detect if such a condition occurs. + + Reading returns '1' if input voltage is negative or greater + than VDD, otherwise '0'. + +What: /sys/bus/iio/devices/iio:deviceX/fault_oc +KernelVersion: 5.1 +Contact: linux-iio@vger.kernel.org +Description: + Open-circuit fault. The detection of open-circuit faults, + such as those caused by broken thermocouple wires. + Reading returns '1' if fault, '0' otherwise. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 index c4a4497c249a..05074c4a65e2 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 @@ -90,14 +90,6 @@ Description: Reading returns the current master modes. Writing set the master mode -What: /sys/bus/iio/devices/triggerX/sampling_frequency -KernelVersion: 4.11 -Contact: benjamin.gaignard@st.com -Description: - Reading returns the current sampling frequency. - Writing an value different of 0 set and start sampling. - Writing 0 stop sampling. - What: /sys/bus/iio/devices/iio:deviceX/in_count0_preset KernelVersion: 4.12 Contact: benjamin.gaignard@st.com diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub new file mode 100644 index 000000000000..42deb0552065 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub @@ -0,0 +1,8 @@ +What: /sys/bus/platform/devices/<dev>/always_powered_in_suspend +Date: June 2022 +KernelVersion: 5.20 +Contact: Matthias Kaehlcke <matthias@kaehlcke.net> + linux-usb@vger.kernel.org +Description: + (RW) Controls whether the USB hub remains always powered + during system suspend or not.
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-bus-surface_aggregator-tabletsw b/Documentation/ABI/testing/sysfs-bus-surface_aggregator-tabletsw new file mode 100644 index 000000000000..74cd9d754e60 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-surface_aggregator-tabletsw @@ -0,0 +1,57 @@ +What: /sys/bus/surface_aggregator/devices/01:0e:01:00:01/state +Date: July 2022 +KernelVersion: 5.20 +Contact: Maximilian Luz <luzmaximilian@gmail.com> +Description: + This attribute returns a string with the current type-cover + or device posture, as indicated by the embedded controller. + Currently returned posture states are: + + - "disconnected": The type-cover has been disconnected. + + - "closed": The type-cover has been folded closed and lies on + top of the display. + + - "laptop": The type-cover is open and in laptop-mode, i.e., + ready for normal use. + + - "folded-canvas": The type-cover has been folded back + part-ways, but does not lie flush with the back side of the + device. In general, this means that the kick-stand is used + and extended atop of the cover. + + - "folded-back": The type cover has been fully folded back and + lies flush with the back side of the device. + + - "<unknown>": The current state is unknown to the driver, for + example due to newer as-of-yet unsupported hardware. + + New states may be introduced with new hardware. Users therefore + must not rely on this list of states being exhaustive and + gracefully handle unknown states. + +What: /sys/bus/surface_aggregator/devices/01:26:01:00:01/state +Date: July 2022 +KernelVersion: 5.20 +Contact: Maximilian Luz <luzmaximilian@gmail.com> +Description: + This attribute returns a string with the current device posture, as indicated by the embedded controller. Currently + returned posture states are: + + - "closed": The lid of the device is closed. + + - "laptop": The lid of the device is opened and the device + operates as a normal laptop. + + - "slate": The screen covers the keyboard or has been flipped + back and the device operates mainly based on touch input. + + - "tablet": The device operates as tablet and exclusively + relies on touch input (or external peripherals). + + - "<unknown>": The current state is unknown to the driver, for + example due to newer as-of-yet unsupported hardware. + + New states may be introduced with new hardware. Users therefore + must not rely on this list of states being exhaustive and + gracefully handle unknown states. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 7efe31ed3a25..568103d3376e 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -253,6 +253,17 @@ Description: only if the system firmware is capable of describing the connection between a port and its connector. +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/disable +Date: June 2022 +Contact: Michael Grzeschik <m.grzeschik@pengutronix.de> +Description: + This file controls the state of a USB port, including + Vbus power output (but only on hubs that support + power switching -- most hubs don't support it). If + a port is disabled, the port is unusable: Devices + attached to the port will not be detected, initialized, + or enumerated. + What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout Date: May 2013 Contact: Mathias Nyman <mathias.nyman@linux.intel.com> diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon index 653d4c75eddb..7271781a23b2 100644 --- a/Documentation/ABI/testing/sysfs-class-hwmon +++ b/Documentation/ABI/testing/sysfs-class-hwmon @@ -938,3 +938,12 @@ Description: - 1: enable RW + +What: /sys/class/hwmon/hwmonX/device/pec +Description: + PEC support on I2C devices + + - 0, off, n: disable + - 1, on, y: enable + + RW diff --git a/Documentation/ABI/testing/sysfs-class-pwm b/Documentation/ABI/testing/sysfs-class-pwm index 3d65285bcd5f..0638c94d01ef 100644 --- a/Documentation/ABI/testing/sysfs-class-pwm +++ b/Documentation/ABI/testing/sysfs-class-pwm @@ -81,7 +81,7 @@ Description: What: /sys/class/pwm/pwmchip<N>/pwmX/capture Date: June 2016 KernelVersion: 4.8 -Contact: Lee Jones <lee.jones@linaro.org> +Contact: Lee Jones <lee@kernel.org> Description: Capture information about a PWM signal. The output format is a pair unsigned integers (period and duty cycle), separated by a diff --git a/Documentation/ABI/testing/sysfs-class-rtrs-client b/Documentation/ABI/testing/sysfs-class-rtrs-client index 49a4157c7bf1..fecc59d1b96f 100644 --- a/Documentation/ABI/testing/sysfs-class-rtrs-client +++ b/Documentation/ABI/testing/sysfs-class-rtrs-client @@ -78,7 +78,7 @@ What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_name Date: Feb 2020 KernelVersion: 5.7 Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> -Description: RO, Contains the the name of HCA the connection established on. +Description: RO, Contains the name of HCA the connection established on. What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_port Date: Feb 2020 diff --git a/Documentation/ABI/testing/sysfs-class-rtrs-server b/Documentation/ABI/testing/sysfs-class-rtrs-server index 3b6d5b067df0..b08601d80409 100644 --- a/Documentation/ABI/testing/sysfs-class-rtrs-server +++ b/Documentation/ABI/testing/sysfs-class-rtrs-server @@ -24,7 +24,7 @@ What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_name Date: Feb 2020 KernelVersion: 5.7 Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> -Description: RO, Contains the the name of HCA the connection established on. +Description: RO, Contains the name of HCA the connection established on. What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_port Date: Feb 2020 diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec index 75088ecad202..281b995beb05 100644 --- a/Documentation/ABI/testing/sysfs-class-typec +++ b/Documentation/ABI/testing/sysfs-class-typec @@ -141,6 +141,14 @@ Description: - "reverse": CC2 orientation - "unknown": Orientation cannot be determined. +What: /sys/class/typec/<port>/select_usb_power_delivery +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Lists the USB Power Delivery Capabilities that the port can + advertise to the partner. The currently used capabilities are in + brackets. Selection happens by writing to the file. + USB Type-C partner devices (eg. /sys/class/typec/port0-partner/) What: /sys/class/typec/<port>-partner/accessory_mode diff --git a/Documentation/ABI/testing/sysfs-class-usb_power_delivery b/Documentation/ABI/testing/sysfs-class-usb_power_delivery new file mode 100644 index 000000000000..ce2b1b563cb3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-usb_power_delivery @@ -0,0 +1,240 @@ +What: /sys/class/usb_power_delivery +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Directory for USB Power Delivery devices. + +What: /sys/class/usb_power_delivery/.../revision +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + File showing the USB Power Delivery Specification Revision used + in communication. + +What: /sys/class/usb_power_delivery/.../version +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This is an optional attribute file showing the version of the + specific revision of the USB Power Delivery Specification. In + most cases the specification version is not known and the file + is not available. + +What: /sys/class/usb_power_delivery/.../source-capabilities +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The source capabilities message "Source_Capabilities" contains a + set of Power Data Objects (PDO), each representing a type of + power supply. The order of the PDO objects is defined in the USB + Power Delivery Specification. Each PDO - power supply - will + have its own device, and the PDO device name will start with the + object position number as the first character followed by the + power supply type name (":" as delimiter). + + /sys/class/usb_power_delivery/.../source_capabilities/<position>:<type> + +What: /sys/class/usb_power_delivery/.../sink-capabilities +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The sink capability message "Sink_Capabilities" contains a set + of Power Data Objects (PDO) just like with source capabilities, + but instead of describing the power capabilities, these objects + describe the power requirements. + + The order of the objects in the sink capability message is the + same as with the source capabilities message. + +Fixed Supplies + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Devices containing the attributes (the bit fields) defined for + Fixed Supplies. + + The device "1:fixed_supply" is special. USB Power Delivery + Specification dictates that the first PDO (at object position + 1), and the only mandatory PDO, is always the vSafe5V Fixed + Supply Object. vSafe5V Object has additional fields defined for + it that the other Fixed Supply Objects do not have and that are + related to the USB capabilities rather than power capabilities. + +What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_power +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file contains boolean value that tells does the device + support both source and sink power roles. + +What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_suspend_supported +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file shows the value of the USB Suspend Supported bit in + vSafe5V Fixed Supply Object. If the bit is set then the device + will follow the USB 2.0 and USB 3.2 rules for suspend and + resume. + +What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unconstrained_power +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file shows the value of the Unconstrained Power bit in + vSafe5V Fixed Supply Object. The bit is set when an external + source of power, powerful enough to power the entire system on + its own, is available for the device. + +What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_communication_capable +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file shows the value of the USB Communication Capable bit in + vSafe5V Fixed Supply Object. + +What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_data +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file shows the value of the Dual-Role Data bit in vSafe5V + Fixed Supply Object. Dual role data means ability act as both + USB host and USB device. + +What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unchunked_extended_messages_supported +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file shows the value of the Unchunked Extended Messages + Supported bit in vSafe5V Fixed Supply Object. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply/voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The voltage the supply supports in millivolts. + +What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Maximum current of the fixed source supply in milliamperes. + +What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/operational_current +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Operational current of the sink in milliamperes. + +What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/fast_role_swap_current +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + This file contains the value of the "Fast Role Swap USB Type-C + Current" field that tells the current level the sink requires + after a Fast Role Swap. + 0 - Fast Swap not supported" + 1 - Default USB Power" + 2 - 1.5A@5V" + 3 - 3.0A@5V" + +Variable Supplies + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Variable Power Supply PDO. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/maximum_voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Maximum Voltage in millivolts. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/minimum_voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Minimum Voltage in millivolts. + +What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:variable_supply/maximum_current +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The maximum current in milliamperes that the source can supply + at the given Voltage range. + +What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:variable_supply/operational_current +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The operational current in milliamperes that the sink requires + at the given Voltage range. + +Battery Supplies + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Battery PDO. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery/maximum_voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Maximum Voltage in millivolts. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery/minimum_voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Minimum Voltage in millivolts. + +What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:battery/maximum_power +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Maximum allowable Power in milliwatts. + +What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:battery/operational_power +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The operational power that the sink requires at the given + voltage range. + +Standard Power Range (SPR) Programmable Power Supplies + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Programmable Power Supply (PPS) Augmented PDO (APDO). + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Maximum Voltage in millivolts. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/minimum_voltage +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Minimum Voltage in millivolts. + +What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_current +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Maximum Current in milliamperes. + +What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:programmable_supply/pps_power_limited +Date: May 2022 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The PPS Power Limited bit indicates whether or not the source + supply will exceed the rated output power if requested. diff --git a/Documentation/ABI/testing/sysfs-class-vduse b/Documentation/ABI/testing/sysfs-class-vduse new file mode 100644 index 000000000000..2f2bc5c8fc48 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-vduse @@ -0,0 +1,33 @@ +What: /sys/class/vduse/ +Date: Oct 2021 +KernelVersion: 5.15 +Contact: Yongji Xie <xieyongji@bytedance.com> +Description: + The vduse/ class sub-directory belongs to the VDUSE + framework and provides a sysfs interface for configuring + VDUSE devices. + +What: /sys/class/vduse/control/ +Date: Oct 2021 +KernelVersion: 5.15 +Contact: Yongji Xie <xieyongji@bytedance.com> +Description: + This directory entry is created for the control device + of VDUSE framework. + +What: /sys/class/vduse/<device-name>/ +Date: Oct 2021 +KernelVersion: 5.15 +Contact: Yongji Xie <xieyongji@bytedance.com> +Description: + This directory entry is created when a VDUSE device is + created via the control device. + +What: /sys/class/vduse/<device-name>/msg_timeout +Date: Oct 2021 +KernelVersion: 5.15 +Contact: Yongji Xie <xieyongji@bytedance.com> +Description: + (RW) The timeout (in seconds) for waiting for the control + message's response from userspace. Default value is 30s. + Writing a '0' to the file means to disable the timeout. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD b/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD index f7b360a61b21..bc44bc903bc8 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD +++ b/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD @@ -74,7 +74,7 @@ Description: Reads also cause the AC alarm timer status to be reset. - Another way to reset the the status of the AC alarm timer is to + Another way to reset the status of the AC alarm timer is to write (the number) 0 to this file. If the status return value indicates that the timer has expired, diff --git a/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa index c56dcf15bf29..364b1ba41242 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa +++ b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa @@ -46,33 +46,69 @@ Description: that is supported by the hardware. The possible values are "MAPv4" or "MAPv5". +What: .../XXXXXXX.ipa/endpoint_id/ +Date: July 2022 +KernelVersion: v5.19 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/endpoint_id/ directory contains + attributes that define IDs associated with IPA + endpoints. The "rx" or "tx" in an endpoint name is + from the perspective of the AP. An endpoint ID is a + small unsigned integer. + +What: .../XXXXXXX.ipa/endpoint_id/modem_rx +Date: July 2022 +KernelVersion: v5.19 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/endpoint_id/modem_rx file contains + the ID of the AP endpoint on which packets originating + from the embedded modem are received. + +What: .../XXXXXXX.ipa/endpoint_id/modem_tx +Date: July 2022 +KernelVersion: v5.19 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/endpoint_id/modem_tx file contains + the ID of the AP endpoint on which packets destined + for the embedded modem are sent. + +What: .../XXXXXXX.ipa/endpoint_id/monitor_rx +Date: July 2022 +KernelVersion: v5.19 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/endpoint_id/monitor_rx file contains + the ID of the AP endpoint on which IPA "monitor" data is + received. The monitor endpoint supplies replicas of + packets that enter the IPA hardware for processing. + Each replicated packet is preceded by a fixed-size "ODL" + header (see .../XXXXXXX.ipa/feature/monitor, above). + Large packets are truncated, to reduce the bandwidth + required to provide the monitor function. + What: .../XXXXXXX.ipa/modem/ Date: June 2021 KernelVersion: v5.14 Contact: Alex Elder <elder@kernel.org> Description: - The .../XXXXXXX.ipa/modem/ directory contains a set of - attributes describing properties of the modem execution - environment reachable by the IPA hardware. + The .../XXXXXXX.ipa/modem/ directory contains attributes + describing properties of the modem embedded in the SoC. What: .../XXXXXXX.ipa/modem/rx_endpoint_id Date: June 2021 KernelVersion: v5.14 Contact: Alex Elder <elder@kernel.org> Description: - The .../XXXXXXX.ipa/feature/rx_endpoint_id file contains - the AP endpoint ID that receives packets originating from - the modem execution environment. The "rx" is from the - perspective of the AP; this endpoint is considered an "IPA - producer". An endpoint ID is a small unsigned integer. + The .../XXXXXXX.ipa/modem/rx_endpoint_id file duplicates + the value found in .../XXXXXXX.ipa/endpoint_id/modem_rx. What: .../XXXXXXX.ipa/modem/tx_endpoint_id Date: June 2021 KernelVersion: v5.14 Contact: Alex Elder <elder@kernel.org> Description: - The .../XXXXXXX.ipa/feature/tx_endpoint_id file contains - the AP endpoint ID used to transmit packets destined for - the modem execution environment. The "tx" is from the - perspective of the AP; this endpoint is considered an "IPA - consumer". An endpoint ID is a small unsigned integer. + The .../XXXXXXX.ipa/modem/tx_endpoint_id file duplicates + the value found in .../XXXXXXX.ipa/endpoint_id/modem_tx. diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 1b2a2d41ff80..54195530e97a 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -303,5 +303,5 @@ Date: Apr 2010 Contact: Dominik Brodowski <linux@dominikbrodowski.net> Description: Reports the runtime PM children usage count of a device, or - 0 if the the children will be ignored. + 0 if the children will be ignored. diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc index ea999e292f11..5269808ec35f 100644 --- a/Documentation/ABI/testing/sysfs-devices-soc +++ b/Documentation/ABI/testing/sysfs-devices-soc @@ -1,6 +1,6 @@ What: /sys/devices/socX Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: The /sys/devices/ directory contains a sub-directory for each System-on-Chip (SoC) device on a running platform. Information @@ -14,14 +14,14 @@ Description: What: /sys/devices/socX/machine Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: Read-only attribute common to all SoCs. Contains the SoC machine name (e.g. Ux500). What: /sys/devices/socX/family Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: Read-only attribute common to all SoCs. Contains SoC family name (e.g. DB8500). @@ -59,7 +59,7 @@ Description: What: /sys/devices/socX/soc_id Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: Read-only attribute supported by most SoCs. In the case of ST-Ericsson's chips this contains the SoC serial number. @@ -72,21 +72,21 @@ Description: What: /sys/devices/socX/revision Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: Read-only attribute supported by most SoCs. Contains the SoC's manufacturing revision number. What: /sys/devices/socX/process Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: Read-only attribute supported ST-Ericsson's silicon. Contains the the process by which the silicon chip was manufactured. What: /sys/bus/soc Date: January 2012 -contact: Lee Jones <lee.jones@linaro.org> +contact: Lee Jones <lee@kernel.org> Description: The /sys/bus/soc/ directory contains the usual sub-folders expected under most buses. /sys/bus/soc/devices is of particular diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index bcc974d276dc..760c889b6cd1 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -67,8 +67,7 @@ Description: Discover NUMA node a CPU belongs to /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 -What: /sys/devices/system/cpu/cpuX/topology/core_id - /sys/devices/system/cpu/cpuX/topology/core_siblings +What: /sys/devices/system/cpu/cpuX/topology/core_siblings /sys/devices/system/cpu/cpuX/topology/core_siblings_list /sys/devices/system/cpu/cpuX/topology/physical_package_id /sys/devices/system/cpu/cpuX/topology/thread_siblings @@ -84,10 +83,6 @@ Description: CPU topology files that describe a logical CPU's relationship Briefly, the files above are: - core_id: the CPU core ID of cpuX. Typically it is the - hardware platform's identifier (rather than the kernel's). - The actual value is architecture and platform dependent. - core_siblings: internal kernel map of cpuX's hardware threads within the same physical_package_id. @@ -493,12 +488,13 @@ What: /sys/devices/system/cpu/cpuX/regs/ /sys/devices/system/cpu/cpuX/regs/identification/ /sys/devices/system/cpu/cpuX/regs/identification/midr_el1 /sys/devices/system/cpu/cpuX/regs/identification/revidr_el1 + /sys/devices/system/cpu/cpuX/regs/identification/smidr_el1 Date: June 2016 Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org> Description: AArch64 CPU registers 'identification' directory exposes the CPU ID registers for - identifying model and revision of the CPU. + identifying model and revision of the CPU and SMCU. What: /sys/devices/system/cpu/aarch32_el0 Date: May 2021 @@ -527,6 +523,7 @@ What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit /sys/devices/system/cpu/vulnerabilities/mmio_stale_data + /sys/devices/system/cpu/vulnerabilities/retbleed Date: January 2018 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Information about CPU vulnerabilities diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update new file mode 100644 index 000000000000..0a41afe0ab4c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update @@ -0,0 +1,61 @@ +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_root_entry_hash +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns the root entry hash for the static + region if one is programmed, else it returns the + string: "hash not programmed". This file is only + visible if the underlying device supports it. + Format: string. + +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_root_entry_hash +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns the root entry hash for the partial + reconfiguration region if one is programmed, else it + returns the string: "hash not programmed". This file + is only visible if the underlying device supports it. + Format: string. + +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_root_entry_hash +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns the root entry hash for the BMC image + if one is programmed, else it returns the string: + "hash not programmed". This file is only visible if the + underlying device supports it. + Format: string. + +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_canceled_csks +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns a list of indices for canceled code + signing keys for the static region. The standard bitmap + list format is used (e.g. "1,2-6,9"). + +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_canceled_csks +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns a list of indices for canceled code + signing keys for the partial reconfiguration region. The + standard bitmap list format is used (e.g. "1,2-6,9"). + +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_canceled_csks +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns a list of indices for canceled code + signing keys for the BMC. The standard bitmap list format + is used (e.g. "1,2-6,9"). + +What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count +Date: Sep 2022 +KernelVersion: 5.20 +Contact: Russ Weight <russell.h.weight@intel.com> +Description: Read only. Returns number of times the secure update + staging area has been flashed. + Format: "%u". diff --git a/Documentation/ABI/testing/sysfs-driver-qat b/Documentation/ABI/testing/sysfs-driver-qat new file mode 100644 index 000000000000..185f81a2aab3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-qat @@ -0,0 +1,49 @@ +What: /sys/bus/pci/devices/<BDF>/qat/state +Date: June 2022 +KernelVersion: 5.20 +Contact: qat-linux@intel.com +Description: (RW) Reports the current state of the QAT device. Write to + the file to start or stop the device. + + The values are: + + * up: the device is up and running + * down: the device is down + + + It is possible to transition the device from up to down only + if the device is up and vice versa. + + This attribute is only available for qat_4xxx devices. + +What: /sys/bus/pci/devices/<BDF>/qat/cfg_services +Date: June 2022 +KernelVersion: 5.20 +Contact: qat-linux@intel.com +Description: (RW) Reports the current configuration of the QAT device. + Write to the file to change the configured services. + + The values are: + + * sym;asym: the device is configured for running crypto + services + * dc: the device is configured for running compression services + + It is possible to set the configuration only if the device + is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state) + + The following example shows how to change the configuration of + a device configured for running crypto services in order to + run data compression:: + + # cat /sys/bus/pci/devices/<BDF>/qat/state + up + # cat /sys/bus/pci/devices/<BDF>/qat/cfg_services + sym;asym + # echo down > /sys/bus/pci/devices/<BDF>/qat/state + # echo dc > /sys/bus/pci/devices/<BDF>/qat/cfg_services + # echo up > /sys/bus/pci/devices/<BDF>/qat/state + # cat /sys/bus/pci/devices/<BDF>/qat/cfg_services + dc + + This attribute is only available for qat_4xxx devices. diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkback b/Documentation/ABI/testing/sysfs-driver-xen-blkback index 7faf719af165..fac0f429a869 100644 --- a/Documentation/ABI/testing/sysfs-driver-xen-blkback +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkback @@ -42,5 +42,5 @@ KernelVersion: 5.10 Contact: Maximilian Heyne <mheyne@amazon.de> Description: Whether to enable the persistent grants feature or not. Note - that this option only takes effect on newly created backends. + that this option only takes effect on newly connected backends. The default is Y (enable). diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkfront b/Documentation/ABI/testing/sysfs-driver-xen-blkfront index 7f646c58832e..4d36c5a10546 100644 --- a/Documentation/ABI/testing/sysfs-driver-xen-blkfront +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkfront @@ -15,5 +15,5 @@ KernelVersion: 5.10 Contact: Maximilian Heyne <mheyne@amazon.de> Description: Whether to enable the persistent grants feature or not. Note - that this option only takes effect on newly created frontends. + that this option only takes effect on newly connected frontends. The default is Y (enable). diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg index ee0d6dbc810e..54d1bfd0db12 100644 --- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg @@ -12,8 +12,9 @@ Description: configuration data to the guest userspace. The authoritative guest-side hardware interface documentation - to the fw_cfg device can be found in "docs/specs/fw_cfg.txt" - in the QEMU source tree. + to the fw_cfg device can be found in "docs/specs/fw_cfg.rst" + in the QEMU source tree, or online at: + https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html **SysFS fw_cfg Interface** diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 9b583dd0298b..083ac2d63eef 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -580,3 +580,33 @@ Date: January 2022 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> Description: Controls max # of node block writes to be used for roll forward recovery. This can limit the roll forward recovery time. + +What: /sys/fs/f2fs/<disk>/unusable_blocks_per_sec +Date: June 2022 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: Shows the number of unusable blocks in a section which was defined by + the zone capacity reported by underlying zoned device. + +What: /sys/fs/f2fs/<disk>/current_atomic_write +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the total current atomic write block count, which is not committed yet. + This is a read-only entry. + +What: /sys/fs/f2fs/<disk>/peak_atomic_write +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the peak value of total current atomic write block count after boot. + If you write "0" here, you can initialize to "0". + +What: /sys/fs/f2fs/<disk>/committed_atomic_block +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the accumulated total committed atomic write block count after boot. + If you write "0" here, you can initialize to "0". + +What: /sys/fs/f2fs/<disk>/revoked_atomic_block +Date: July 2022 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show the accumulated total revoked atomic write block count after boot. + If you write "0" here, you can initialize to "0". diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm index 1c9bed5595f5..d244674a9480 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-ksm +++ b/Documentation/ABI/testing/sysfs-kernel-mm-ksm @@ -41,7 +41,7 @@ Description: Kernel Samepage Merging daemon sysfs interface sleep_millisecs: how many milliseconds ksm should sleep between scans. - See Documentation/vm/ksm.rst for more information. + See Documentation/mm/ksm.rst for more information. What: /sys/kernel/mm/ksm/merge_across_nodes Date: January 2013 diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab index c440f4946e12..cd5fb8fa3ddf 100644 --- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab @@ -37,7 +37,7 @@ Description: The alloc_calls file is read-only and lists the kernel code locations from which allocations for this cache were performed. The alloc_calls file only contains information if debugging is - enabled for that cache (see Documentation/vm/slub.rst). + enabled for that cache (see Documentation/mm/slub.rst). What: /sys/kernel/slab/<cache>/alloc_fastpath Date: February 2008 @@ -219,7 +219,7 @@ Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Description: The free_calls file is read-only and lists the locations of object frees if slab debugging is enabled (see - Documentation/vm/slub.rst). + Documentation/mm/slub.rst). What: /sys/kernel/slab/<cache>/free_fastpath Date: February 2008 diff --git a/Documentation/Kconfig b/Documentation/Kconfig index e549a61f4d96..252bfc164dbd 100644 --- a/Documentation/Kconfig +++ b/Documentation/Kconfig @@ -1,23 +1,22 @@ config WARN_MISSING_DOCUMENTS - bool "Warn if there's a missing documentation file" depends on COMPILE_TEST help - It is not uncommon that a document gets renamed. - This option makes the Kernel to check for missing dependencies, - warning when something is missing. Works only if the Kernel - is built from a git tree. + It is not uncommon that a document gets renamed. + This option makes the Kernel to check for missing dependencies, + warning when something is missing. Works only if the Kernel + is built from a git tree. - If unsure, select 'N'. + If unsure, select 'N'. config WARN_ABI_ERRORS bool "Warn if there are errors at ABI files" depends on COMPILE_TEST help - The files under Documentation/ABI should follow what's - described at Documentation/ABI/README. Yet, as they're manually - written, it would be possible that some of those files would - have errors that would break them for being parsed by - scripts/get_abi.pl. Add a check to verify them. + The files under Documentation/ABI should follow what's + described at Documentation/ABI/README. Yet, as they're manually + written, it would be possible that some of those files would + have errors that would break them for being parsed by + scripts/get_abi.pl. Add a check to verify them. - If unsure, select 'N'. + If unsure, select 'N'. diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst index 38ea1f604b6d..4d2333e7ae06 100644 --- a/Documentation/PCI/endpoint/index.rst +++ b/Documentation/PCI/endpoint/index.rst @@ -13,6 +13,8 @@ PCI Endpoint Framework pci-test-howto pci-ntb-function pci-ntb-howto + pci-vntb-function + pci-vntb-howto function/binding/pci-test function/binding/pci-ntb diff --git a/Documentation/PCI/endpoint/pci-vntb-function.rst b/Documentation/PCI/endpoint/pci-vntb-function.rst new file mode 100644 index 000000000000..0c51f53ab972 --- /dev/null +++ b/Documentation/PCI/endpoint/pci-vntb-function.rst @@ -0,0 +1,129 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +PCI vNTB Function +================= + +:Author: Frank Li <Frank.Li@nxp.com> + +The difference between PCI NTB function and PCI vNTB function is + +PCI NTB function need at two endpoint instances and connect HOST1 +and HOST2. + +PCI vNTB function only use one host and one endpoint(EP), use NTB +connect EP and PCI host + +.. code-block:: text + + + +------------+ +---------------------------------------+ + | | | | + +------------+ | +--------------+ + | NTB | | | NTB | + | NetDev | | | NetDev | + +------------+ | +--------------+ + | NTB | | | NTB | + | Transfer | | | Transfer | + +------------+ | +--------------+ + | | | | | + | PCI NTB | | | | + | EPF | | | | + | Driver | | | PCI Virtual | + | | +---------------+ | NTB Driver | + | | | PCI EP NTB |<------>| | + | | | FN Driver | | | + +------------+ +---------------+ +--------------+ + | | | | | | + | PCI BUS | <-----> | PCI EP BUS | | Virtual PCI | + | | PCI | | | BUS | + +------------+ +---------------+--------+--------------+ + PCI RC PCI EP + +Constructs used for Implementing vNTB +===================================== + + 1) Config Region + 2) Self Scratchpad Registers + 3) Peer Scratchpad Registers + 4) Doorbell (DB) Registers + 5) Memory Window (MW) + + +Config Region: +-------------- + +It is same as PCI NTB Function driver + +Scratchpad Registers: +--------------------- + +It is appended after Config region. + +.. code-block:: text + + + +--------------------------------------------------+ Base + | | + | | + | | + | Common Config Register | + | | + | | + | | + +-----------------------+--------------------------+ Base + span_offset + | | | + | Peer Span Space | Span Space | + | | | + | | | + +-----------------------+--------------------------+ Base + span_offset + | | | + span_count * 4 + | | | + | Span Space | Peer Span Space | + | | | + +-----------------------+--------------------------+ + Virtual PCI Pcie Endpoint + NTB Driver NTB Driver + + +Doorbell Registers: +------------------- + + Doorbell Registers are used by the hosts to interrupt each other. + +Memory Window: +-------------- + + Actual transfer of data between the two hosts will happen using the + memory window. + +Modeling Constructs: +==================== + +32-bit BARs. + +====== =============== +BAR NO CONSTRUCTS USED +====== =============== +BAR0 Config Region +BAR1 Doorbell +BAR2 Memory Window 1 +BAR3 Memory Window 2 +BAR4 Memory Window 3 +BAR5 Memory Window 4 +====== =============== + +64-bit BARs. + +====== =============================== +BAR NO CONSTRUCTS USED +====== =============================== +BAR0 Config Region + Scratchpad +BAR1 +BAR2 Doorbell +BAR3 +BAR4 Memory Window 1 +BAR5 +====== =============================== + + diff --git a/Documentation/PCI/endpoint/pci-vntb-howto.rst b/Documentation/PCI/endpoint/pci-vntb-howto.rst new file mode 100644 index 000000000000..4ab8e4a26d4b --- /dev/null +++ b/Documentation/PCI/endpoint/pci-vntb-howto.rst @@ -0,0 +1,167 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================================================== +PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide +=================================================================== + +:Author: Frank Li <Frank.Li@nxp.com> + +This document is a guide to help users use pci-epf-vntb function driver +and ntb_hw_epf host driver for NTB functionality. The list of steps to +be followed in the host side and EP side is given below. For the hardware +configuration and internals of NTB using configurable endpoints see +Documentation/PCI/endpoint/pci-vntb-function.rst + +Endpoint Device +=============== + +Endpoint Controller Devices +--------------------------- + +To find the list of endpoint controller devices in the system:: + + # ls /sys/class/pci_epc/ + 5f010000.pcie_ep + +If PCI_ENDPOINT_CONFIGFS is enabled:: + + # ls /sys/kernel/config/pci_ep/controllers + 5f010000.pcie_ep + +Endpoint Function Drivers +------------------------- + +To find the list of endpoint function drivers in the system:: + + # ls /sys/bus/pci-epf/drivers + pci_epf_ntb pci_epf_test pci_epf_vntb + +If PCI_ENDPOINT_CONFIGFS is enabled:: + + # ls /sys/kernel/config/pci_ep/functions + pci_epf_ntb pci_epf_test pci_epf_vntb + + +Creating pci-epf-vntb Device +---------------------------- + +PCI endpoint function device can be created using the configfs. To create +pci-epf-vntb device, the following commands can be used:: + + # mount -t configfs none /sys/kernel/config + # cd /sys/kernel/config/pci_ep/ + # mkdir functions/pci_epf_vntb/func1 + +The "mkdir func1" above creates the pci-epf-ntb function device that will +be probed by pci_epf_vntb driver. + +The PCI endpoint framework populates the directory with the following +configurable fields:: + + # ls functions/pci_epf_ntb/func1 + baseclass_code deviceid msi_interrupts pci-epf-ntb.0 + progif_code secondary subsys_id vendorid + cache_line_size interrupt_pin msix_interrupts primary + revid subclass_code subsys_vendor_id + +The PCI endpoint function driver populates these entries with default values +when the device is bound to the driver. The pci-epf-vntb driver populates +vendorid with 0xffff and interrupt_pin with 0x0001:: + + # cat functions/pci_epf_vntb/func1/vendorid + 0xffff + # cat functions/pci_epf_vntb/func1/interrupt_pin + 0x0001 + + +Configuring pci-epf-vntb Device +------------------------------- + +The user can configure the pci-epf-vntb device using its configfs entry. In order +to change the vendorid and the deviceid, the following +commands can be used:: + + # echo 0x1957 > functions/pci_epf_vntb/func1/vendorid + # echo 0x0809 > functions/pci_epf_vntb/func1/deviceid + +In order to configure NTB specific attributes, a new sub-directory to func1 +should be created:: + + # mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/ + +The NTB function driver will populate this directory with various attributes +that can be configured by the user:: + + # ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/ + db_count mw1 mw2 mw3 mw4 num_mws + spad_count + +A sample configuration for NTB function is given below:: + + # echo 4 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/db_count + # echo 128 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/spad_count + # echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws + # echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1 + +A sample configuration for virtual NTB driver for virutal PCI bus:: + + # echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid + # echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid + # echo 0x10 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vbus_number + +Binding pci-epf-ntb Device to EP Controller +-------------------------------------------- + +NTB function device should be attached to PCI endpoint controllers +connected to the host. + + # ln -s controllers/5f010000.pcie_ep functions/pci-epf-ntb/func1/primary + +Once the above step is completed, the PCI endpoint controllers are ready to +establish a link with the host. + + +Start the Link +-------------- + +In order for the endpoint device to establish a link with the host, the _start_ +field should be populated with '1'. For NTB, both the PCI endpoint controllers +should establish link with the host (imx8 don't need this steps):: + + # echo 1 > controllers/5f010000.pcie_ep/start + +RootComplex Device +================== + +lspci Output at Host side +------------------------- + +Note that the devices listed here correspond to the values populated in +"Creating pci-epf-ntb Device" section above:: + + # lspci + 00:00.0 PCI bridge: Freescale Semiconductor Inc Device 0000 (rev 01) + 01:00.0 RAM memory: Freescale Semiconductor Inc Device 0809 + +Endpoint Device / Virtual PCI bus +================================= + +lspci Output at EP Side / Virtual PCI bus +----------------------------------------- + +Note that the devices listed here correspond to the values populated in +"Creating pci-epf-ntb Device" section above:: + + # lspci + 10:00.0 Unassigned class [ffff]: Dawicontrol Computersysteme GmbH Device 1234 (rev ff) + +Using ntb_hw_epf Device +----------------------- + +The host side software follows the standard NTB software architecture in Linux. +All the existing client side NTB utilities like NTB Transport Client and NTB +Netdev, NTB Ping Pong Test Client and NTB Tool Test Client can be used with NTB +function device. + +For more information on NTB see +:doc:`Non-Transparent Bridge <../../driver-api/ntb>` diff --git a/Documentation/PCI/pci-iov-howto.rst b/Documentation/PCI/pci-iov-howto.rst index b9fd003206f1..27d35933cea2 100644 --- a/Documentation/PCI/pci-iov-howto.rst +++ b/Documentation/PCI/pci-iov-howto.rst @@ -125,14 +125,14 @@ Following piece of code illustrates the usage of the SR-IOV API. ... } - static int dev_suspend(struct pci_dev *dev, pm_message_t state) + static int dev_suspend(struct device *dev) { ... return 0; } - static int dev_resume(struct pci_dev *dev) + static int dev_resume(struct device *dev) { ... @@ -165,8 +165,7 @@ Following piece of code illustrates the usage of the SR-IOV API. .id_table = dev_id_table, .probe = dev_probe, .remove = dev_remove, - .suspend = dev_suspend, - .resume = dev_resume, + .driver.pm = &dev_pm_ops, .shutdown = dev_shutdown, .sriov_configure = dev_sriov_configure, }; diff --git a/Documentation/PCI/sysfs-pci.rst b/Documentation/PCI/sysfs-pci.rst index 742fbd21dc1f..f495185aa88a 100644 --- a/Documentation/PCI/sysfs-pci.rst +++ b/Documentation/PCI/sysfs-pci.rst @@ -125,7 +125,7 @@ implementation of that functionality. To support the historical interface of mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP. Alternatively, platforms which set HAVE_PCI_MMAP may provide their own -implementation of pci_mmap_page_range() instead of defining +implementation of pci_mmap_resource_range() instead of defining ARCH_GENERIC_PCI_MMAP_RESOURCE. Platforms which support write-combining maps of PCI resources must define diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 04ed8bf27a0e..a0f8164c8513 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -1844,10 +1844,10 @@ that meets this requirement. Furthermore, NMI handlers can be interrupted by what appear to RCU to be normal interrupts. One way that this can happen is for code that -directly invokes rcu_irq_enter() and rcu_irq_exit() to be called +directly invokes ct_irq_enter() and ct_irq_exit() to be called from an NMI handler. This astonishing fact of life prompted the current -code structure, which has rcu_irq_enter() invoking -rcu_nmi_enter() and rcu_irq_exit() invoking rcu_nmi_exit(). +code structure, which has ct_irq_enter() invoking +ct_nmi_enter() and ct_irq_exit() invoking ct_nmi_exit(). And yes, I also learned of this requirement the hard way. Loadable Modules @@ -2195,7 +2195,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be: sections, and RCU believes this CPU to be idle, no problem. This sort of thing is used by some architectures for light-weight exception handlers, which can then avoid the overhead of - rcu_irq_enter() and rcu_irq_exit() at exception entry and + ct_irq_enter() and ct_irq_exit() at exception entry and exit, respectively. Some go further and avoid the entireties of irq_enter() and irq_exit(). Just make very sure you are running some of your tests with @@ -2226,7 +2226,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be: +-----------------------------------------------------------------------+ | **Answer**: | +-----------------------------------------------------------------------+ -| One approach is to do ``rcu_irq_exit();rcu_irq_enter();`` every so | +| One approach is to do ``ct_irq_exit();ct_irq_enter();`` every so | | often. But given that long-running interrupt handlers can cause other | | problems, not least for response time, shouldn't you work to keep | | your interrupt handler's runtime within reasonable bounds? | diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 794837eb519b..e38c587067fc 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -97,12 +97,12 @@ warnings: which will include additional debugging information. - A low-level kernel issue that either fails to invoke one of the - variants of rcu_user_enter(), rcu_user_exit(), rcu_idle_enter(), - rcu_idle_exit(), rcu_irq_enter(), or rcu_irq_exit() on the one + variants of rcu_eqs_enter(true), rcu_eqs_exit(true), ct_idle_enter(), + ct_idle_exit(), ct_irq_enter(), or ct_irq_exit() on the one hand, or that invokes one of them too many times on the other. Historically, the most frequent issue has been an omission of either irq_enter() or irq_exit(), which in turn invoke - rcu_irq_enter() or rcu_irq_exit(), respectively. Building your + ct_irq_enter() or ct_irq_exit(), respectively. Building your kernel with CONFIG_RCU_EQS_DEBUG=y can help track down these types of issues, which sometimes arise in architecture-specific code. diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index caa3c09a5c3f..9eb6b9042f75 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -1,9 +1,9 @@ .. _readme: -Linux kernel release 5.x <http://kernel.org/> +Linux kernel release 6.x <http://kernel.org/> ============================================= -These are the release notes for Linux version 5. Read them carefully, +These are the release notes for Linux version 6. Read them carefully, as they tell you what this is all about, explain how to install the kernel, and what to do if something goes wrong. @@ -63,7 +63,7 @@ Installing the kernel source directory where you have permissions (e.g. your home directory) and unpack it:: - xz -cd linux-5.x.tar.xz | tar xvf - + xz -cd linux-6.x.tar.xz | tar xvf - Replace "X" with the version number of the latest kernel. @@ -72,12 +72,12 @@ Installing the kernel source files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be. - - You can also upgrade between 5.x releases by patching. Patches are + - You can also upgrade between 6.x releases by patching. Patches are distributed in the xz format. To install by patching, get all the newer patch files, enter the top level directory of the kernel source - (linux-5.x) and execute:: + (linux-6.x) and execute:: - xz -cd ../patch-5.x.xz | patch -p1 + xz -cd ../patch-6.x.xz | patch -p1 Replace "x" for all versions bigger than the version "x" of your current source tree, **in_order**, and you should be ok. You may want to remove @@ -85,13 +85,13 @@ Installing the kernel source that there are no failed patches (some-file-name# or some-file-name.rej). If there are, either you or I have made a mistake. - Unlike patches for the 5.x kernels, patches for the 5.x.y kernels + Unlike patches for the 6.x kernels, patches for the 6.x.y kernels (also known as the -stable kernels) are not incremental but instead apply - directly to the base 5.x kernel. For example, if your base kernel is 5.0 - and you want to apply the 5.0.3 patch, you must not first apply the 5.0.1 - and 5.0.2 patches. Similarly, if you are running kernel version 5.0.2 and - want to jump to 5.0.3, you must first reverse the 5.0.2 patch (that is, - patch -R) **before** applying the 5.0.3 patch. You can read more on this in + directly to the base 6.x kernel. For example, if your base kernel is 6.0 + and you want to apply the 6.0.3 patch, you must not first apply the 6.0.1 + and 6.0.2 patches. Similarly, if you are running kernel version 6.0.2 and + want to jump to 6.0.3, you must first reverse the 6.0.2 patch (that is, + patch -R) **before** applying the 6.0.3 patch. You can read more on this in :ref:`Documentation/process/applying-patches.rst <applying_patches>`. Alternatively, the script patch-kernel can be used to automate this @@ -114,7 +114,7 @@ Installing the kernel source Software requirements --------------------- - Compiling and running the 5.x kernels requires up-to-date + Compiling and running the 6.x kernels requires up-to-date versions of various software packages. Consult :ref:`Documentation/process/changes.rst <changes>` for the minimum version numbers required and how to get updates for these packages. Beware that using @@ -132,12 +132,12 @@ Build directory for the kernel place for the output files (including .config). Example:: - kernel source code: /usr/src/linux-5.x + kernel source code: /usr/src/linux-6.x build directory: /home/name/build/kernel To configure and build the kernel, use:: - cd /usr/src/linux-5.x + cd /usr/src/linux-6.x make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst index 45b94f7b3beb..a402359abb99 100644 --- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst +++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst @@ -97,7 +97,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. ============= Page Cache is charged at - - add_to_page_cache_locked(). + - filemap_add_folio(). The logic is very clear. (About migration, see below) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 176298f2f4de..be4a77baf784 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -184,6 +184,14 @@ cgroup v2 currently supports the following mount options. ignored on non-init namespace mounts. Please refer to the Delegation section for details. + favordynmods + Reduce the latencies of dynamic cgroup modifications such as + task migrations and controller on/offs at the cost of making + hot path operations such as forks and exits more expensive. + The static usage pattern of creating a cgroup, enabling + controllers, and then seeding it with CLONE_INTO_CGROUP is + not affected by this option. + memory_localevents Only populate memory.events with data for the current cgroup, and not any subtrees. This is legacy behaviour, the default @@ -1229,6 +1237,13 @@ PAGE_SIZE multiple when read back. the target cgroup. If less bytes are reclaimed than the specified amount, -EAGAIN is returned. + Please note that the proactive reclaim (triggered by this + interface) is not meant to indicate memory pressure on the + memory cgroup. Therefore socket memory balancing triggered by + the memory reclaim normally is not exercised in this case. + This means that the networking layer will not adapt based on + reclaim induced by memory.reclaim. + memory.peak A read-only single value file which exists on non-root cgroups. @@ -1433,6 +1448,24 @@ PAGE_SIZE multiple when read back. workingset_nodereclaim Number of times a shadow node has been reclaimed + pgscan (npn) + Amount of scanned pages (in an inactive LRU list) + + pgsteal (npn) + Amount of reclaimed pages + + pgscan_kswapd (npn) + Amount of scanned pages by kswapd (in an inactive LRU list) + + pgscan_direct (npn) + Amount of scanned pages directly (in an inactive LRU list) + + pgsteal_kswapd (npn) + Amount of reclaimed pages by kswapd + + pgsteal_direct (npn) + Amount of reclaimed pages directly + pgfault (npn) Total number of page faults incurred @@ -1442,12 +1475,6 @@ PAGE_SIZE multiple when read back. pgrefill (npn) Amount of scanned pages (in an active LRU list) - pgscan (npn) - Amount of scanned pages (in an inactive LRU list) - - pgsteal (npn) - Amount of reclaimed pages - pgactivate (npn) Amount of pages moved to the active LRU list diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index 10429779a91a..60c16b7fd5ac 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -20,6 +20,7 @@ Constructor parameters: size) 5. the number of optional parameters (the parameters with an argument count as two) + start_sector n (default: 0) offset from the start of cache device in 512-byte sectors high_watermark n (default: 50) @@ -74,20 +75,21 @@ Constructor parameters: the origin volume in the last n milliseconds Status: + 1. error indicator - 0 if there was no error, otherwise error number 2. the number of blocks 3. the number of free blocks 4. the number of blocks under writeback -5. the number of read requests -6. the number of read requests that hit the cache -7. the number of write requests -8. the number of write requests that hit uncommitted block -9. the number of write requests that hit committed block -10. the number of write requests that bypass the cache -11. the number of write requests that are allocated in the cache +5. the number of read blocks +6. the number of read blocks that hit the cache +7. the number of write blocks +8. the number of write blocks that hit uncommitted block +9. the number of write blocks that hit committed block +10. the number of write blocks that bypass the cache +11. the number of write blocks that are allocated in the cache 12. the number of write requests that are blocked on the freelist 13. the number of flush requests -14. the number of discard requests +14. the number of discarded blocks Messages: flush diff --git a/Documentation/admin-guide/devices.rst b/Documentation/admin-guide/devices.rst index 035275fedbdd..e3776d77374b 100644 --- a/Documentation/admin-guide/devices.rst +++ b/Documentation/admin-guide/devices.rst @@ -7,10 +7,9 @@ This list is the Linux Device List, the official registry of allocated device numbers and ``/dev`` directory nodes for the Linux operating system. -The LaTeX version of this document is no longer maintained, nor is -the document that used to reside at lanana.org. This version in the -mainline Linux kernel is the master document. Updates shall be sent -as patches to the kernel maintainers (see the +The version of this document at lanana.org is no longer maintained. This +version in the mainline Linux kernel is the master document. Updates +shall be sent as patches to the kernel maintainers (see the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` document). Specifically explore the sections titled "CHAR and MISC DRIVERS", and "BLOCK LAYER" in the MAINTAINERS file to find the right maintainers diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst index 833edb0d0bc4..b24e7c40d832 100644 --- a/Documentation/admin-guide/efi-stub.rst +++ b/Documentation/admin-guide/efi-stub.rst @@ -7,10 +7,10 @@ as a PE/COFF image, thereby convincing EFI firmware loaders to load it as an EFI executable. The code that modifies the bzImage header, along with the EFI-specific entry point that the firmware loader jumps to are collectively known as the "EFI boot stub", and live in -arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, +arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c, respectively. For ARM the EFI stub is implemented in arch/arm/boot/compressed/efi-header.S and -arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared +drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared between architectures is in drivers/firmware/efi/libstub. For arm64, there is no compressed kernel support, so the Image itself diff --git a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst index 9393c50b5afc..c98fd11907cc 100644 --- a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst +++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst @@ -230,6 +230,20 @@ The possible values in this file are: * - 'Mitigation: Clear CPU buffers' - The processor is vulnerable and the CPU buffer clearing mitigation is enabled. + * - 'Unknown: No mitigations' + - The processor vulnerability status is unknown because it is + out of Servicing period. Mitigation is not attempted. + +Definitions: +------------ + +Servicing period: The process of providing functional and security updates to +Intel processors or platforms, utilizing the Intel Platform Update (IPU) +process or other similar mechanisms. + +End of Servicing Updates (ESU): ESU is the date at which Intel will no +longer provide Servicing, such as through IPU or other similar update +processes. ESU dates will typically be aligned to end of quarter. If the processor is vulnerable then the following information is appended to the above information: diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index 9e9556826450..2ce2a38cdd55 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -422,6 +422,14 @@ The possible values in this file are: 'RSB filling' Protection of RSB on context switch enabled ============= =========================================== + - EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status: + + =========================== ======================================================= + 'PBRSB-eIBRS: SW sequence' CPU is affected and protection of RSB on VMEXIT enabled + 'PBRSB-eIBRS: Vulnerable' CPU is vulnerable + 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB + =========================== ======================================================= + Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2522b11e593f..426fa892d311 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -400,6 +400,12 @@ arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension support + arm64.nosve [ARM64] Unconditionally disable Scalable Vector + Extension support + + arm64.nosme [ARM64] Unconditionally disable Scalable Matrix + Extension support + ataflop= [HW,M68k] atarimouse= [HW,MOUSE] Atari Mouse @@ -550,7 +556,7 @@ nosocket -- Disable socket memory accounting. nokmem -- Disable kernel memory accounting. - checkreqprot [SELINUX] Set initial checkreqprot flag value. + checkreqprot= [SELINUX] Set initial checkreqprot flag value. Format: { "0" | "1" } See security/selinux/Kconfig help text. 0 -- check protection applied by kernel (includes @@ -1152,8 +1158,12 @@ nopku [X86] Disable Memory Protection Keys CPU feature found in some Intel CPUs. - <module>.async_probe [KNL] - Enable asynchronous probe on this module. + <module>.async_probe[=<bool>] [KNL] + If no <bool> value is specified or if the value + specified is not a valid <bool>, enable asynchronous + probe on this module. Otherwise, enable/disable + asynchronous probe on this module as indicated by the + <bool> value. See also: module.async_probe early_ioremap_debug [KNL] Enable debug messages in early_ioremap support. This @@ -1439,7 +1449,7 @@ (in particular on some ATI chipsets). The kernel tries to set a reasonable default. - enforcing [SELINUX] Set initial enforcing status. + enforcing= [SELINUX] Set initial enforcing status. Format: {"0" | "1"} See security/selinux/Kconfig help text. 0 -- permissive (log only, no denials). @@ -1667,6 +1677,19 @@ hlt [BUGS=ARM,SH] + hostname= [KNL] Set the hostname (aka UTS nodename). + Format: <string> + This allows setting the system's hostname during early + startup. This sets the name returned by gethostname. + Using this parameter to set the hostname makes it + possible to ensure the hostname is correctly set before + any userspace processes run, avoiding the possibility + that a process may call gethostname before the hostname + has been explicitly set, resulting in the calling + process getting an incorrect result. The string must + not exceed the maximum allowed hostname length (usually + 64 characters) and will be truncated otherwise. + hpet= [X86-32,HPET] option to control HPET usage Format: { enable (default) | disable | force | verbose } @@ -1712,19 +1735,22 @@ hugetlb_free_vmemmap= [KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP enabled. + Control if HugeTLB Vmemmap Optimization (HVO) is enabled. Allows heavy hugetlb users to free up some more memory (7 * PAGE_SIZE for each 2MB hugetlb page). - Format: { [oO][Nn]/Y/y/1 | [oO][Ff]/N/n/0 (default) } + Format: { on | off (default) } - [oO][Nn]/Y/y/1: enable the feature - [oO][Ff]/N/n/0: disable the feature + on: enable HVO + off: disable HVO Built with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=y, the default is on. - This is not compatible with memory_hotplug.memmap_on_memory. - If both parameters are enabled, hugetlb_free_vmemmap takes - precedence over memory_hotplug.memmap_on_memory. + Note that the vmemmap pages may be allocated from the added + memory block itself when memory_hotplug.memmap_on_memory is + enabled, those vmemmap pages cannot be optimized even if this + feature is enabled. Other vmemmap pages not allocated from + the added memory block itself do not be affected. hung_task_panic= [KNL] Should the hung task detector generate panics. @@ -2266,23 +2292,39 @@ ivrs_ioapic [HW,X86-64] Provide an override to the IOAPIC-ID<->DEVICE-ID - mapping provided in the IVRS ACPI table. For - example, to map IOAPIC-ID decimal 10 to - PCI device 00:14.0 write the parameter as: + mapping provided in the IVRS ACPI table. + By default, PCI segment is 0, and can be omitted. + For example: + * To map IOAPIC-ID decimal 10 to PCI device 00:14.0 + write the parameter as: ivrs_ioapic[10]=00:14.0 + * To map IOAPIC-ID decimal 10 to PCI segment 0x1 and + PCI device 00:14.0 write the parameter as: + ivrs_ioapic[10]=0001:00:14.0 ivrs_hpet [HW,X86-64] Provide an override to the HPET-ID<->DEVICE-ID - mapping provided in the IVRS ACPI table. For - example, to map HPET-ID decimal 0 to - PCI device 00:14.0 write the parameter as: + mapping provided in the IVRS ACPI table. + By default, PCI segment is 0, and can be omitted. + For example: + * To map HPET-ID decimal 0 to PCI device 00:14.0 + write the parameter as: ivrs_hpet[0]=00:14.0 + * To map HPET-ID decimal 10 to PCI segment 0x1 and + PCI device 00:14.0 write the parameter as: + ivrs_ioapic[10]=0001:00:14.0 ivrs_acpihid [HW,X86-64] Provide an override to the ACPI-HID:UID<->DEVICE-ID - mapping provided in the IVRS ACPI table. For - example, to map UART-HID:UID AMD0020:0 to - PCI device 00:14.5 write the parameter as: + mapping provided in the IVRS ACPI table. + + For example, to map UART-HID:UID AMD0020:0 to + PCI segment 0x1 and PCI device ID 00:14.5, + write the parameter as: + ivrs_acpihid[0001:00:14.5]=AMD0020:0 + + By default, PCI segment is 0, and can be omitted. + For example, PCI device 00:14.5 write the parameter as: ivrs_acpihid[00:14.5]=AMD0020:0 js= [HW,JOY] Analog joystick @@ -2418,8 +2460,7 @@ the KVM_CLEAR_DIRTY ioctl, and only for the pages being cleared. - Eager page splitting currently only supports splitting - huge pages mapped by the TDP MMU. + Eager page splitting is only supported when kvm.tdp_mmu=Y. Default is Y (on). @@ -3068,10 +3109,12 @@ [KNL,X86,ARM] Boolean flag to enable this feature. Format: {on | off (default)} When enabled, runtime hotplugged memory will - allocate its internal metadata (struct pages) - from the hotadded memory which will allow to - hotadd a lot of memory without requiring - additional memory to do so. + allocate its internal metadata (struct pages, + those vmemmap pages cannot be optimized even + if hugetlb_free_vmemmap is enabled) from the + hotadded memory which will allow to hotadd a + lot of memory without requiring additional + memory to do so. This feature is disabled by default because it has some implication on large (e.g. GB) allocations in some configurations (e.g. small @@ -3081,10 +3124,6 @@ Note that even when enabled, there are a few cases where the feature is not effective. - This is not compatible with hugetlb_free_vmemmap. If - both parameters are enabled, hugetlb_free_vmemmap takes - precedence over memory_hotplug.memmap_on_memory. - memtest= [KNL,X86,ARM,M68K,PPC,RISCV] Enable memtest Format: <integer> default : 0 <disable> @@ -3103,7 +3142,7 @@ mem_encrypt=on: Activate SME mem_encrypt=off: Do not activate SME - Refer to Documentation/virt/kvm/amd-memory-encryption.rst + Refer to Documentation/virt/kvm/x86/amd-memory-encryption.rst for details on when memory encryption can be activated. mem_sleep_default= [SUSPEND] Default system suspend mode: @@ -3161,7 +3200,7 @@ improves system performance, but it may also expose users to several CPU vulnerabilities. Equivalent to: nopti [X86,PPC] - kpti=0 [ARM64] + if nokaslr then kpti=0 [ARM64] nospectre_v1 [X86,PPC] nobp=0 [S390] nospectre_v2 [X86,PPC,S390,ARM64] @@ -3176,6 +3215,7 @@ no_entry_flush [PPC] no_uaccess_flush [PPC] mmio_stale_data=off [X86] + retbleed=off [X86] Exceptions: This does not have any effect on @@ -3198,6 +3238,7 @@ mds=full,nosmt [X86] tsx_async_abort=full,nosmt [X86] mmio_stale_data=full,nosmt [X86] + retbleed=auto,nosmt [X86] mminit_loglevel= [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this @@ -3241,6 +3282,15 @@ For details see: Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst + module.async_probe=<bool> + [KNL] When set to true, modules will use async probing + by default. To enable/disable async probing for a + specific module, use the module specific control that + is documented under <module>.async_probe. When both + module.async_probe and <module>.async_probe are + specified, <module>.async_probe takes precedence for + the specific module. + module.sig_enforce [KNL] When CONFIG_MODULE_SIG is set, this means that modules without (valid) signatures will fail to load. @@ -3530,9 +3580,6 @@ noautogroup Disable scheduler automatic task group creation. - nobats [PPC] Do not use BATs for mapping kernel lowmem - on "Classic" PPC cores. - nocache [ARM] nodsp [SH] Disable hardware DSP at boot time. @@ -3659,6 +3706,9 @@ just as if they had also been called out in the rcu_nocbs= boot parameter. + Note that this argument takes precedence over + the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option. + noiotrap [SH] Disables trapped I/O port accesses. noirqdebug [X86-32] Disables the code which attempts to detect and @@ -3699,9 +3749,6 @@ nolapic_timer [X86-32,APIC] Do not use the local APIC timer. - noltlbs [PPC] Do not use large page/tlb entries for kernel - lowmem mapping on PPC40x and PPC8xx - nomca [IA-64] Disable machine check abort handling nomce [X86-32] Disable Machine Check Exception @@ -3733,11 +3780,6 @@ noreplace-smp [X86-32,SMP] Don't replace SMP instructions with UP alternatives - nordrand [X86] Disable kernel use of the RDRAND and - RDSEED instructions even if they are supported - by the processor. RDRAND and RDSEED are still - available to user space applications. - noresume [SWSUSP] Disables resume and restores original swap space. @@ -4557,6 +4599,9 @@ no-callback mode from boot but the mode may be toggled at runtime via cpusets. + Note that this argument takes precedence over + the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option. + rcu_nocb_poll [KNL] Rather than requiring that offloaded CPUs (specified by rcu_nocbs= above) explicitly @@ -4666,6 +4711,34 @@ When RCU_NOCB_CPU is set, also adjust the priority of NOCB callback kthreads. + rcutree.rcu_divisor= [KNL] + Set the shift-right count to use to compute + the callback-invocation batch limit bl from + the number of callbacks queued on this CPU. + The result will be bounded below by the value of + the rcutree.blimit kernel parameter. Every bl + callbacks, the softirq handler will exit in + order to allow the CPU to do other work. + + Please note that this callback-invocation batch + limit applies only to non-offloaded callback + invocation. Offloaded callbacks are instead + invoked in the context of an rcuoc kthread, which + scheduler will preempt as it does any other task. + + rcutree.nocb_nobypass_lim_per_jiffy= [KNL] + On callback-offloaded (rcu_nocbs) CPUs, + RCU reduces the lock contention that would + otherwise be caused by callback floods through + use of the ->nocb_bypass list. However, in the + common non-flooded case, RCU queues directly to + the main ->cblist in order to avoid the extra + overhead of the ->nocb_bypass list and its lock. + But if there are too many callbacks queued during + a single jiffy, RCU pre-queues the callbacks into + the ->nocb_bypass queue. The definition of "too + many" is supplied by this kernel boot parameter. + rcutree.rcu_nocb_gp_stride= [KNL] Set the number of NOCB callback kthreads in each group, which defaults to the square root @@ -5197,6 +5270,43 @@ retain_initrd [RAM] Keep initrd memory after extraction + retbleed= [X86] Control mitigation of RETBleed (Arbitrary + Speculative Code Execution with Return Instructions) + vulnerability. + + AMD-based UNRET and IBPB mitigations alone do not stop + sibling threads from influencing the predictions of other + sibling threads. For that reason, STIBP is used on pro- + cessors that support it, and mitigate SMT on processors + that don't. + + off - no mitigation + auto - automatically select a migitation + auto,nosmt - automatically select a mitigation, + disabling SMT if necessary for + the full mitigation (only on Zen1 + and older without STIBP). + ibpb - On AMD, mitigate short speculation + windows on basic block boundaries too. + Safe, highest perf impact. It also + enables STIBP if present. Not suitable + on Intel. + ibpb,nosmt - Like "ibpb" above but will disable SMT + when STIBP is not available. This is + the alternative for systems which do not + have STIBP. + unret - Force enable untrained return thunks, + only effective on AMD f15h-f17h based + systems. + unret,nosmt - Like unret, but will disable SMT when STIBP + is not available. This is the alternative for + systems which do not have STIBP. + + Selecting 'auto' will choose a mitigation method at run + time according to the CPU. + + Not specifying this option is equivalent to retbleed=auto. + rfkill.default_state= 0 "airplane mode". All wifi, bluetooth, wimax, gps, fm, etc. communication is blocked by default. @@ -5221,6 +5331,8 @@ rodata= [KNL] on Mark read-only kernel memory as read-only (default). off Leave read-only kernel memory writable for debugging. + full Mark read-only kernel memory and aliases as read-only + [arm64] rockchip.usb_uart Enable the uart passthrough on the designated usb port @@ -5442,7 +5554,7 @@ cache (risks via metadata attacks are mostly unchanged). Debug options disable merging on their own. - For more information see Documentation/vm/slub.rst. + For more information see Documentation/mm/slub.rst. slab_max_order= [MM, SLAB] Determines the maximum allowed order for slabs. @@ -5456,13 +5568,13 @@ slub_debug can create guard zones around objects and may poison objects when not in use. Also tracks the last alloc / free. For more information see - Documentation/vm/slub.rst. + Documentation/mm/slub.rst. slub_max_order= [MM, SLUB] Determines the maximum allowed order for slabs. A high setting may cause OOMs due to memory fragmentation. For more information see - Documentation/vm/slub.rst. + Documentation/mm/slub.rst. slub_min_objects= [MM, SLUB] The minimum number of objects per slab. SLUB will @@ -5471,12 +5583,12 @@ the number of objects indicated. The higher the number of objects the smaller the overhead of tracking slabs and the less frequently locks need to be acquired. - For more information see Documentation/vm/slub.rst. + For more information see Documentation/mm/slub.rst. slub_min_order= [MM, SLUB] Determines the minimum page order for slabs. Must be lower than slub_max_order. - For more information see Documentation/vm/slub.rst. + For more information see Documentation/mm/slub.rst. slub_merge [MM, SLUB] Same with slab_merge. @@ -5568,6 +5680,7 @@ eibrs - enhanced IBRS eibrs,retpoline - enhanced IBRS + Retpolines eibrs,lfence - enhanced IBRS + LFENCE + ibrs - use IBRS to protect kernel Not specifying this option is equivalent to spectre_v2=auto. @@ -5771,6 +5884,24 @@ expediting. Set to zero to disable automatic expediting. + srcutree.srcu_max_nodelay [KNL] + Specifies the number of no-delay instances + per jiffy for which the SRCU grace period + worker thread will be rescheduled with zero + delay. Beyond this limit, worker thread will + be rescheduled with a sleep delay of one jiffy. + + srcutree.srcu_max_nodelay_phase [KNL] + Specifies the per-grace-period phase, number of + non-sleeping polls of readers. Beyond this limit, + grace period worker thread will be rescheduled + with a sleep delay of one jiffy, between each + rescan of the readers, for a grace period phase. + + srcutree.srcu_retry_check_delay [KNL] + Specifies number of microseconds of non-sleeping + delay between each non-sleeping poll of readers. + srcutree.small_contention_lim [KNL] Specifies the number of update-side contention events per jiffy will be tolerated before @@ -5904,8 +6035,11 @@ it if 0 is given (See Documentation/admin-guide/cgroup-v1/memory.rst) swiotlb= [ARM,IA-64,PPC,MIPS,X86] - Format: { <int> | force | noforce } + Format: { <int> [,<int>] | force | noforce } <int> -- Number of I/O TLB slabs + <int> -- Second integer after comma. Number of swiotlb + areas with their own lock. Will be rounded up + to a power of 2. force -- force using of bounce buffers even if they wouldn't be automatically used by the kernel noforce -- Never use bounce buffers (for debugging) diff --git a/Documentation/admin-guide/media/vimc.dot b/Documentation/admin-guide/media/vimc.dot index 8e829c164626..92a5bb631235 100644 --- a/Documentation/admin-guide/media/vimc.dot +++ b/Documentation/admin-guide/media/vimc.dot @@ -5,9 +5,13 @@ digraph board { n00000001 [label="{{} | Sensor A\n/dev/v4l-subdev0 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green] n00000001:port0 -> n00000005:port0 [style=bold] n00000001:port0 -> n0000000b [style=bold] + n00000001 -> n00000002 + n00000002 [label="{{} | Lens A\n/dev/v4l-subdev5 | {<port0>}}", shape=Mrecord, style=filled, fillcolor=green] n00000003 [label="{{} | Sensor B\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green] n00000003:port0 -> n00000008:port0 [style=bold] n00000003:port0 -> n0000000f [style=bold] + n00000003 -> n00000004 + n00000004 [label="{{} | Lens B\n/dev/v4l-subdev6 | {<port0>}}", shape=Mrecord, style=filled, fillcolor=green] n00000005 [label="{{<port0> 0} | Debayer A\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] n00000005:port1 -> n00000015:port0 n00000008 [label="{{<port0> 0} | Debayer B\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] diff --git a/Documentation/admin-guide/media/vimc.rst b/Documentation/admin-guide/media/vimc.rst index 0b07f05dde25..3b4d2b36b4f3 100644 --- a/Documentation/admin-guide/media/vimc.rst +++ b/Documentation/admin-guide/media/vimc.rst @@ -53,6 +53,25 @@ vimc-sensor: * 1 Pad source +vimc-lens: + Ancillary lens for a sensor. Supports auto focus control. Linked to + a vimc-sensor using an ancillary link. The lens supports FOCUS_ABSOLUTE + control. + +.. code-block:: bash + + media-ctl -p + ... + - entity 28: Lens A (0 pad, 0 link) + type V4L2 subdev subtype Lens flags 0 + device node name /dev/v4l-subdev6 + - entity 29: Lens B (0 pad, 0 link) + type V4L2 subdev subtype Lens flags 0 + device node name /dev/v4l-subdev7 + v4l2-ctl -d /dev/v4l-subdev7 -C focus_absolute + focus_absolute: 0 + + vimc-debayer: Transforms images in bayer format into a non-bayer format. Exposes: diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst index 6d7175f96f74..4f680dc9661c 100644 --- a/Documentation/admin-guide/media/vivid.rst +++ b/Documentation/admin-guide/media/vivid.rst @@ -714,6 +714,20 @@ The Test Pattern Controls are all specific to video capture. does the same for the EAV (End of Active Video) code. +- Insert Video Guard Band + + adds 4 columns of pixels with the HDMI Video Guard Band code at the + left hand side of the image. This only works with 3 or 4 byte RGB pixel + formats. The RGB pixel value 0xab/0x55/0xab turns out to be equivalent + to the HDMI Video Guard Band code that precedes each active video line + (see section 5.2.2.1 in the HDMI 1.3 Specification). To test if a video + receiver has correct HDMI Video Guard Band processing, enable this + control and then move the image to the left hand side of the screen. + That will result in video lines that start with multiple pixels that + have the same value as the Video Guard Band that precedes them. + Receivers that will just keep skipping Video Guard Band values will + now fail and either loose sync or these video lines will shift. + Capture Feature Selection Controls ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/admin-guide/mm/concepts.rst b/Documentation/admin-guide/mm/concepts.rst index b966fcff993b..c79f1e336222 100644 --- a/Documentation/admin-guide/mm/concepts.rst +++ b/Documentation/admin-guide/mm/concepts.rst @@ -125,7 +125,7 @@ processor. Each bank is referred to as a `node` and for each node Linux constructs an independent memory management subsystem. A node has its own set of zones, lists of free and used pages and various statistics counters. You can find more details about NUMA in -:ref:`Documentation/vm/numa.rst <numa>` and in +:ref:`Documentation/mm/numa.rst <numa>` and in :ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`. Page cache diff --git a/Documentation/admin-guide/mm/damon/index.rst b/Documentation/admin-guide/mm/damon/index.rst index 61aff88347f3..05500042f777 100644 --- a/Documentation/admin-guide/mm/damon/index.rst +++ b/Documentation/admin-guide/mm/damon/index.rst @@ -4,7 +4,7 @@ Monitoring Data Accesses ======================== -:doc:`DAMON </vm/damon/index>` allows light-weight data access monitoring. +:doc:`DAMON </mm/damon/index>` allows light-weight data access monitoring. Using DAMON, users can analyze the memory access patterns of their systems and optimize those. @@ -14,3 +14,4 @@ optimize those. start usage reclaim + lru_sort diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst new file mode 100644 index 000000000000..c09cace80651 --- /dev/null +++ b/Documentation/admin-guide/mm/damon/lru_sort.rst @@ -0,0 +1,294 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +DAMON-based LRU-lists Sorting +============================= + +DAMON-based LRU-lists Sorting (DAMON_LRU_SORT) is a static kernel module that +aimed to be used for proactive and lightweight data access pattern based +(de)prioritization of pages on their LRU-lists for making LRU-lists a more +trusworthy data access pattern source. + +Where Proactive LRU-lists Sorting is Required? +============================================== + +As page-granularity access checking overhead could be significant on huge +systems, LRU lists are normally not proactively sorted but partially and +reactively sorted for special events including specific user requests, system +calls and memory pressure. As a result, LRU lists are sometimes not so +perfectly prepared to be used as a trustworthy access pattern source for some +situations including reclamation target pages selection under sudden memory +pressure. + +Because DAMON can identify access patterns of best-effort accuracy while +inducing only user-specified range of overhead, proactively running +DAMON_LRU_SORT could be helpful for making LRU lists more trustworthy access +pattern source with low and controlled overhead. + +How It Works? +============= + +DAMON_LRU_SORT finds hot pages (pages of memory regions that showing access +rates that higher than a user-specified threshold) and cold pages (pages of +memory regions that showing no access for a time that longer than a +user-specified threshold) using DAMON, and prioritizes hot pages while +deprioritizing cold pages on their LRU-lists. To avoid it consuming too much +CPU for the prioritizations, a CPU time usage limit can be configured. Under +the limit, it prioritizes and deprioritizes more hot and cold pages first, +respectively. System administrators can also configure under what situation +this scheme should automatically activated and deactivated with three memory +pressure watermarks. + +Its default parameters for hotness/coldness thresholds and CPU quota limit are +conservatively chosen. That is, the module under its default parameters could +be widely used without harm for common situations while providing a level of +benefits for systems having clear hot/cold access patterns under memory +pressure while consuming only a limited small portion of CPU time. + +Interface: Module Parameters +============================ + +To use this feature, you should first ensure your system is running on a kernel +that is built with ``CONFIG_DAMON_LRU_SORT=y``. + +To let sysadmins enable or disable it and tune for the given system, +DAMON_LRU_SORT utilizes module parameters. That is, you can put +``damon_lru_sort.<parameter>=<value>`` on the kernel boot command line or write +proper values to ``/sys/modules/damon_lru_sort/parameters/<parameter>`` files. + +Below are the description of each parameter. + +enabled +------- + +Enable or disable DAMON_LRU_SORT. + +You can enable DAMON_LRU_SORT by setting the value of this parameter as ``Y``. +Setting it as ``N`` disables DAMON_LRU_SORT. Note that DAMON_LRU_SORT could do +no real monitoring and LRU-lists sorting due to the watermarks-based activation +condition. Refer to below descriptions for the watermarks parameter for this. + +commit_inputs +------------- + +Make DAMON_LRU_SORT reads the input parameters again, except ``enabled``. + +Input parameters that updated while DAMON_LRU_SORT is running are not applied +by default. Once this parameter is set as ``Y``, DAMON_LRU_SORT 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_LRU_SORT will be disabled. + +hot_thres_access_freq +--------------------- + +Access frequency threshold for hot memory regions identification in permil. + +If a memory region is accessed in frequency of this or higher, DAMON_LRU_SORT +identifies the region as hot, and mark it as accessed on the LRU list, so that +it could not be reclaimed under memory pressure. 50% by default. + +cold_min_age +------------ + +Time threshold for cold memory regions identification in microseconds. + +If a memory region is not accessed for this or longer time, DAMON_LRU_SORT +identifies the region as cold, and mark it as unaccessed on the LRU list, so +that it could be reclaimed first under memory pressure. 120 seconds by +default. + +quota_ms +-------- + +Limit of time for trying the LRU lists sorting in milliseconds. + +DAMON_LRU_SORT tries to use only up to this time within a time window +(quota_reset_interval_ms) for trying LRU lists sorting. This can be used +for limiting CPU consumption of DAMON_LRU_SORT. If the value is zero, the +limit is disabled. + +10 ms by default. + +quota_reset_interval_ms +----------------------- + +The time quota charge reset interval in milliseconds. + +The charge reset interval for the quota of time (quota_ms). That is, +DAMON_LRU_SORT does not try LRU-lists sorting for more than quota_ms +milliseconds or quota_sz bytes within quota_reset_interval_ms milliseconds. + +1 second by default. + +wmarks_interval +--------------- + +The watermarks check time interval in microseconds. + +Minimal time to wait before checking the watermarks, when DAMON_LRU_SORT is +enabled but inactive due to its watermarks rule. 5 seconds by default. + +wmarks_high +----------- + +Free memory rate (per thousand) for the high watermark. + +If free memory of the system in bytes per thousand bytes is higher than this, +DAMON_LRU_SORT becomes inactive, so it does nothing but periodically checks the +watermarks. 200 (20%) by default. + +wmarks_mid +---------- + +Free memory rate (per thousand) for the middle watermark. + +If free memory of the system in bytes per thousand bytes is between this and +the low watermark, DAMON_LRU_SORT becomes active, so starts the monitoring and +the LRU-lists sorting. 150 (15%) by default. + +wmarks_low +---------- + +Free memory rate (per thousand) for the low watermark. + +If free memory of the system in bytes per thousand bytes is lower than this, +DAMON_LRU_SORT becomes inactive, so it does nothing but periodically checks the +watermarks. 50 (5%) by default. + +sample_interval +--------------- + +Sampling interval for the monitoring in microseconds. + +The sampling interval of DAMON for the cold memory monitoring. Please refer to +the DAMON documentation (:doc:`usage`) for more detail. 5ms by default. + +aggr_interval +------------- + +Aggregation interval for the monitoring in microseconds. + +The aggregation interval of DAMON for the cold memory monitoring. Please +refer to the DAMON documentation (:doc:`usage`) for more detail. 100ms by +default. + +min_nr_regions +-------------- + +Minimum number of monitoring regions. + +The minimal number of monitoring regions of DAMON for the cold memory +monitoring. This can be used to set lower-bound of the monitoring quality. +But, setting this too high could result in increased monitoring overhead. +Please refer to the DAMON documentation (:doc:`usage`) for more detail. 10 by +default. + +max_nr_regions +-------------- + +Maximum number of monitoring regions. + +The maximum number of monitoring regions of DAMON for the cold memory +monitoring. This can be used to set upper-bound of the monitoring overhead. +However, setting this too low could result in bad monitoring quality. Please +refer to the DAMON documentation (:doc:`usage`) for more detail. 1000 by +defaults. + +monitor_region_start +-------------------- + +Start of target memory region in physical address. + +The start physical address of memory region that DAMON_LRU_SORT will do work +against. By default, biggest System RAM is used as the region. + +monitor_region_end +------------------ + +End of target memory region in physical address. + +The end physical address of memory region that DAMON_LRU_SORT will do work +against. By default, biggest System RAM is used as the region. + +kdamond_pid +----------- + +PID of the DAMON thread. + +If DAMON_LRU_SORT is enabled, this becomes the PID of the worker thread. Else, +-1. + +nr_lru_sort_tried_hot_regions +----------------------------- + +Number of hot memory regions that tried to be LRU-sorted. + +bytes_lru_sort_tried_hot_regions +-------------------------------- + +Total bytes of hot memory regions that tried to be LRU-sorted. + +nr_lru_sorted_hot_regions +------------------------- + +Number of hot memory regions that successfully be LRU-sorted. + +bytes_lru_sorted_hot_regions +---------------------------- + +Total bytes of hot memory regions that successfully be LRU-sorted. + +nr_hot_quota_exceeds +-------------------- + +Number of times that the time quota limit for hot regions have exceeded. + +nr_lru_sort_tried_cold_regions +------------------------------ + +Number of cold memory regions that tried to be LRU-sorted. + +bytes_lru_sort_tried_cold_regions +--------------------------------- + +Total bytes of cold memory regions that tried to be LRU-sorted. + +nr_lru_sorted_cold_regions +-------------------------- + +Number of cold memory regions that successfully be LRU-sorted. + +bytes_lru_sorted_cold_regions +----------------------------- + +Total bytes of cold memory regions that successfully be LRU-sorted. + +nr_cold_quota_exceeds +--------------------- + +Number of times that the time quota limit for cold regions have exceeded. + +Example +======= + +Below runtime example commands make DAMON_LRU_SORT to find memory regions +having >=50% access frequency and LRU-prioritize while LRU-deprioritizing +memory regions that not accessed for 120 seconds. The prioritization and +deprioritization is limited to be done using only up to 1% CPU time to avoid +DAMON_LRU_SORT consuming too much CPU time for the (de)prioritization. It also +asks DAMON_LRU_SORT to do nothing if the system's free memory rate is more than +50%, but start the real works if it becomes lower than 40%. If DAMON_RECLAIM +doesn't make progress and therefore the free memory rate becomes lower than +20%, it asks DAMON_LRU_SORT to do nothing again, so that we can fall back to +the LRU-list based page granularity reclamation. :: + + # cd /sys/modules/damon_lru_sort/parameters + # echo 500 > hot_thres_access_freq + # echo 120000000 > cold_min_age + # echo 10 > quota_ms + # echo 1000 > quota_reset_interval_ms + # echo 500 > wmarks_high + # echo 400 > wmarks_mid + # echo 200 > wmarks_low + # echo Y > enabled diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst index 46306f1f34b1..4f1479a11e63 100644 --- a/Documentation/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/admin-guide/mm/damon/reclaim.rst @@ -48,12 +48,6 @@ DAMON_RECLAIM utilizes module parameters. That is, you can put ``damon_reclaim.<parameter>=<value>`` on the kernel boot command line or write proper values to ``/sys/modules/damon_reclaim/parameters/<parameter>`` files. -Note that the parameter values except ``enabled`` are applied only when -DAMON_RECLAIM starts. Therefore, if you want to apply new parameter values in -runtime and DAMON_RECLAIM is already enabled, you should disable and re-enable -it via ``enabled`` parameter file. Writing of the new values to proper -parameter values should be done before the re-enablement. - Below are the description of each parameter. enabled @@ -268,4 +262,4 @@ granularity reclamation. :: .. [1] https://research.google/pubs/pub48551/ .. [2] https://lwn.net/Articles/787611/ -.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html +.. [3] https://www.kernel.org/doc/html/latest/mm/free_page_reporting.html diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 1bb7b72414b2..ca91ecc29078 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -30,11 +30,11 @@ DAMON provides below interfaces for different users. <sysfs_interface>`. This will be removed after next LTS kernel is released, so users should move to the :ref:`sysfs interface <sysfs_interface>`. - *Kernel Space Programming Interface.* - :doc:`This </vm/damon/api>` is for kernel space programmers. Using this, + :doc:`This </mm/damon/api>` is for kernel space programmers. Using this, users can utilize every feature of DAMON most flexibly and efficiently by writing kernel space DAMON application programs for you. You can even extend DAMON for various address spaces. For detail, please refer to the interface - :doc:`document </vm/damon/api>`. + :doc:`document </mm/damon/api>`. .. _sysfs_interface: @@ -50,10 +50,10 @@ For a short example, users can monitor the virtual address space of a given workload as below. :: # cd /sys/kernel/mm/damon/admin/ - # echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr + # echo 1 > kdamonds/nr_kdamonds && echo 1 > kdamonds/0/contexts/nr_contexts # echo vaddr > kdamonds/0/contexts/0/operations - # echo 1 > kdamonds/0/contexts/0/targets/nr - # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid + # echo 1 > kdamonds/0/contexts/0/targets/nr_targets + # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid_target # echo on > kdamonds/0/state Files Hierarchy @@ -185,7 +185,7 @@ controls the monitoring overhead, exist. You can set and get the values by writing to and rading from the files. For more details about the intervals and monitoring regions range, please refer -to the Design document (:doc:`/vm/damon/design`). +to the Design document (:doc:`/mm/damon/design`). contexts/<N>/targets/ --------------------- @@ -264,6 +264,8 @@ that can be written to and read from the file and their meaning are as below. - ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - ``lru_prio``: Prioritize the region on its LRU lists. + - ``lru_deprio``: Deprioritize the region on its LRU lists. - ``stat``: Do nothing but count the statistics schemes/<N>/access_pattern/ @@ -364,12 +366,12 @@ memory rate becomes larger than 60%, or lower than 30%". :: # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes # cd kdamonds/0/contexts/0/schemes/0 # # set the basic access pattern and the action - # echo 4096 > access_patterns/sz/min - # echo 8192 > access_patterns/sz/max - # echo 0 > access_patterns/nr_accesses/min - # echo 5 > access_patterns/nr_accesses/max - # echo 10 > access_patterns/age/min - # echo 20 > access_patterns/age/max + # echo 4096 > access_pattern/sz/min + # echo 8192 > access_pattern/sz/max + # echo 0 > access_pattern/nr_accesses/min + # echo 5 > access_pattern/nr_accesses/max + # echo 10 > access_pattern/age/min + # echo 20 > access_pattern/age/max # echo pageout > action # # set quotas # echo 10 > quotas/ms @@ -402,7 +404,7 @@ Attributes Users can get and set the ``sampling interval``, ``aggregation interval``, ``update interval``, and min/max number of monitoring target regions by reading from and writing to the ``attrs`` file. To know about the monitoring -attributes in detail, please refer to the :doc:`/vm/damon/design`. For +attributes in detail, please refer to the :doc:`/mm/damon/design`. For example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and 1000, and then check it again:: diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index a90330d0a837..8e2727dc18d4 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -164,8 +164,8 @@ 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_OPTIMIZE_VMEMMAP is set, this enables optimizing - unused vmemmap pages associated with each HugeTLB page. + When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables HugeTLB + Vmemmap Optimization (HVO). When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` indicates the current number of pre-allocated huge pages of the default size. diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index c21b5823f126..1bd11118dfb1 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -36,6 +36,7 @@ the Linux memory management. numa_memory_policy numaperf pagemap + shrinker_debugfs soft-dirty swap_numa transhuge diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 0f56ecd8ac05..a3c9e8ad8fa0 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -653,8 +653,8 @@ block might fail: - Concurrent activity that operates on the same physical memory area, such as allocating gigantic pages, can result in temporary offlining failures. -- Out of memory when dissolving huge pages, especially when freeing unused - vmemmap pages associated with each hugetlb page is enabled. +- Out of memory when dissolving huge pages, especially when HugeTLB Vmemmap + Optimization (HVO) is enabled. Offlining code may be able to migrate huge page contents, but may not be able to dissolve the source huge page because it fails allocating (unmovable) pages diff --git a/Documentation/admin-guide/mm/shrinker_debugfs.rst b/Documentation/admin-guide/mm/shrinker_debugfs.rst new file mode 100644 index 000000000000..3887f0b294fe --- /dev/null +++ b/Documentation/admin-guide/mm/shrinker_debugfs.rst @@ -0,0 +1,135 @@ +.. _shrinker_debugfs: + +========================== +Shrinker Debugfs Interface +========================== + +Shrinker debugfs interface provides a visibility into the kernel memory +shrinkers subsystem and allows to get information about individual shrinkers +and interact with them. + +For each shrinker registered in the system a directory in **<debugfs>/shrinker/** +is created. The directory's name is composed from the shrinker's name and an +unique id: e.g. *kfree_rcu-0* or *sb-xfs:vda1-36*. + +Each shrinker directory contains **count** and **scan** files, which allow to +trigger *count_objects()* and *scan_objects()* callbacks for each memcg and +numa node (if applicable). + +Usage: +------ + +1. *List registered shrinkers* + + :: + + $ cd /sys/kernel/debug/shrinker/ + $ ls + dquota-cache-16 sb-devpts-28 sb-proc-47 sb-tmpfs-42 + mm-shadow-18 sb-devtmpfs-5 sb-proc-48 sb-tmpfs-43 + mm-zspool:zram0-34 sb-hugetlbfs-17 sb-pstore-31 sb-tmpfs-44 + rcu-kfree-0 sb-hugetlbfs-33 sb-rootfs-2 sb-tmpfs-49 + sb-aio-20 sb-iomem-12 sb-securityfs-6 sb-tracefs-13 + sb-anon_inodefs-15 sb-mqueue-21 sb-selinuxfs-22 sb-xfs:vda1-36 + sb-bdev-3 sb-nsfs-4 sb-sockfs-8 sb-zsmalloc-19 + sb-bpf-32 sb-pipefs-14 sb-sysfs-26 thp-deferred_split-10 + sb-btrfs:vda2-24 sb-proc-25 sb-tmpfs-1 thp-zero-9 + sb-cgroup2-30 sb-proc-39 sb-tmpfs-27 xfs-buf:vda1-37 + sb-configfs-23 sb-proc-41 sb-tmpfs-29 xfs-inodegc:vda1-38 + sb-dax-11 sb-proc-45 sb-tmpfs-35 + sb-debugfs-7 sb-proc-46 sb-tmpfs-40 + +2. *Get information about a specific shrinker* + + :: + + $ cd sb-btrfs\:vda2-24/ + $ ls + count scan + +3. *Count objects* + + Each line in the output has the following format:: + + <cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ... + <cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ... + ... + + If there are no objects on all numa nodes, a line is omitted. If there + are no objects at all, the output might be empty. + + If the shrinker is not memcg-aware or CONFIG_MEMCG is off, 0 is printed + as cgroup inode id. If the shrinker is not numa-aware, 0's are printed + for all nodes except the first one. + :: + + $ cat count + 1 224 2 + 21 98 0 + 55 818 10 + 2367 2 0 + 2401 30 0 + 225 13 0 + 599 35 0 + 939 124 0 + 1041 3 0 + 1075 1 0 + 1109 1 0 + 1279 60 0 + 1313 7 0 + 1347 39 0 + 1381 3 0 + 1449 14 0 + 1483 63 0 + 1517 53 0 + 1551 6 0 + 1585 1 0 + 1619 6 0 + 1653 40 0 + 1687 11 0 + 1721 8 0 + 1755 4 0 + 1789 52 0 + 1823 888 0 + 1857 1 0 + 1925 2 0 + 1959 32 0 + 2027 22 0 + 2061 9 0 + 2469 799 0 + 2537 861 0 + 2639 1 0 + 2707 70 0 + 2775 4 0 + 2877 84 0 + 293 1 0 + 735 8 0 + +4. *Scan objects* + + The expected input format:: + + <cgroup inode id> <numa id> <number of objects to scan> + + For a non-memcg-aware shrinker or on a system with no memory + cgrups **0** should be passed as cgroup id. + :: + + $ cd /sys/kernel/debug/shrinker/ + $ cd sb-btrfs\:vda2-24/ + + $ cat count | head -n 5 + 1 212 0 + 21 97 0 + 55 802 5 + 2367 2 0 + 225 13 0 + + $ echo "55 0 200" > scan + + $ cat count | head -n 5 + 1 212 0 + 21 96 0 + 55 752 5 + 2367 2 0 + 225 13 0 diff --git a/Documentation/admin-guide/perf/hns3-pmu.rst b/Documentation/admin-guide/perf/hns3-pmu.rst new file mode 100644 index 000000000000..578407e487d6 --- /dev/null +++ b/Documentation/admin-guide/perf/hns3-pmu.rst @@ -0,0 +1,136 @@ +====================================== +HNS3 Performance Monitoring Unit (PMU) +====================================== + +HNS3(HiSilicon network system 3) Performance Monitoring Unit (PMU) is an +End Point device to collect performance statistics of HiSilicon SoC NIC. +On Hip09, each SICL(Super I/O cluster) has one PMU device. + +HNS3 PMU supports collection of performance statistics such as bandwidth, +latency, packet rate and interrupt rate. + +Each HNS3 PMU supports 8 hardware events. + +HNS3 PMU driver +=============== + +The HNS3 PMU driver registers a perf PMU with the name of its sicl id.:: + + /sys/devices/hns3_pmu_sicl_<sicl_id> + +PMU driver provides description of available events, filter modes, format, +identifier and cpumask in sysfs. + +The "events" directory describes the event code of all supported events +shown in perf list. + +The "filtermode" directory describes the supported filter modes of each +event. + +The "format" directory describes all formats of the config (events) and +config1 (filter options) fields of the perf_event_attr structure. + +The "identifier" file shows version of PMU hardware device. + +The "bdf_min" and "bdf_max" files show the supported bdf range of each +pmu device. + +The "hw_clk_freq" file shows the hardware clock frequency of each pmu +device. + +Example usage of checking event code and subevent code:: + + $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time + config=0x00204 + $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num + config=0x10204 + +Each performance statistic has a pair of events to get two values to +calculate real performance data in userspace. + +The bits 0~15 of config (here 0x0204) are the true hardware event code. If +two events have same value of bits 0~15 of config, that means they are +event pair. And the bit 16 of config indicates getting counter 0 or +counter 1 of hardware event. + +After getting two values of event pair in usersapce, the formula of +computation to calculate real performance data is::: + + counter 0 / counter 1 + +Example usage of checking supported filter mode:: + + $# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num + filter mode supported: global/port/port-tc/func/func-queue/ + +Example usage of perf:: + + $# perf list + hns3_pmu_sicl_0/bw_ssu_rpu_byte_num/ [kernel PMU event] + hns3_pmu_sicl_0/bw_ssu_rpu_time/ [kernel PMU event] + ------------------------------------------ + + $# perf stat -g -e hns3_pmu_sicl_0/bw_ssu_rpu_byte_num,global=1/ -e hns3_pmu_sicl_0/bw_ssu_rpu_time,global=1/ -I 1000 + or + $# perf stat -g -e hns3_pmu_sicl_0/config=0x00002,global=1/ -e hns3_pmu_sicl_0/config=0x10002,global=1/ -I 1000 + + +Filter modes +-------------- + +1. global mode +PMU collect performance statistics for all HNS3 PCIe functions of IO DIE. +Set the "global" filter option to 1 will enable this mode. +Example usage of perf:: + + $# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,global=1/ -I 1000 + +2. port mode +PMU collect performance statistic of one whole physical port. The port id +is same as mac id. The "tc" filter option must be set to 0xF in this mode, +here tc stands for traffic class. + +Example usage of perf:: + + $# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0xF/ -I 1000 + +3. port-tc mode +PMU collect performance statistic of one tc of physical port. The port id +is same as mac id. The "tc" filter option must be set to 0 ~ 7 in this +mode. +Example usage of perf:: + + $# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0/ -I 1000 + +4. func mode +PMU collect performance statistic of one PF/VF. The function id is BDF of +PF/VF, its conversion formula:: + + func = (bus << 8) + (device << 3) + (function) + +for example: + BDF func + 35:00.0 0x3500 + 35:00.1 0x3501 + 35:01.0 0x3508 + +In this mode, the "queue" filter option must be set to 0xFFFF. +Example usage of perf:: + + $# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0xFFFF/ -I 1000 + +5. func-queue mode +PMU collect performance statistic of one queue of PF/VF. The function id +is BDF of PF/VF, the "queue" filter option must be set to the exact queue +id of function. +Example usage of perf:: + + $# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0/ -I 1000 + +6. func-intr mode +PMU collect performance statistic of one interrupt of PF/VF. The function +id is BDF of PF/VF, the "intr" filter option must be set to the exact +interrupt id of function. +Example usage of perf:: + + $# perf stat -a -e hns3_pmu_sicl_0/config=0x00301,bdf=0x3500,intr=0/ -I 1000 diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst index 69b23f087c05..9c9ece88ce53 100644 --- a/Documentation/admin-guide/perf/index.rst +++ b/Documentation/admin-guide/perf/index.rst @@ -9,6 +9,7 @@ Performance monitor support hisi-pmu hisi-pcie-pmu + hns3-pmu imx-ddr qcom_l2_pmu qcom_l3_pmu diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index aec2cd2aaea7..19754beb5a4e 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -612,8 +612,8 @@ the ``menu`` governor to be used on the systems that use the ``ladder`` governor by default this way, for example. The other kernel command line parameters controlling CPU idle time management -described below are only relevant for the *x86* architecture and some of -them affect Intel processors only. +described below are only relevant for the *x86* architecture and references +to ``intel_idle`` affect Intel processors only. The *x86* architecture support code recognizes three kernel command line options related to CPU idle time management: ``idle=poll``, ``idle=halt``, @@ -635,10 +635,13 @@ idle, so it very well may hurt single-thread computations performance as well as energy-efficiency. Thus using it for performance reasons may not be a good idea at all.] -The ``idle=nomwait`` option disables the ``intel_idle`` driver and causes -``acpi_idle`` to be used (as long as all of the information needed by it is -there in the system's ACPI tables), but it is not allowed to use the -``MWAIT`` instruction of the CPUs to ask the hardware to enter idle states. +The ``idle=nomwait`` option prevents the use of ``MWAIT`` instruction of +the CPU to enter idle states. When this option is used, the ``acpi_idle`` +driver will use the ``HLT`` instruction instead of ``MWAIT``. On systems +running Intel processors, this option disables the ``intel_idle`` driver +and forces the use of the ``acpi_idle`` driver instead. Note that in either +case, ``acpi_idle`` driver will function only if all the information needed +by it is in the system's ACPI tables. In addition to the architecture-level kernel command line options affecting CPU idle time management, there are parameters affecting individual ``CPUIdle`` diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index ddccd1077462..ee6572b1edad 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -38,8 +38,8 @@ acct If BSD-style process accounting is enabled these values control its behaviour. If free space on filesystem where the log lives -goes below ``lowwater``% accounting suspends. If free space gets -above ``highwater``% accounting resumes. ``frequency`` determines +goes below ``lowwater``\ % accounting suspends. If free space gets +above ``highwater``\ % accounting resumes. ``frequency`` determines how often do we check the amount of free space (value is in seconds). Default: @@ -592,6 +592,18 @@ to the guest kernel command line (see Documentation/admin-guide/kernel-parameters.rst). +nmi_wd_lpm_factor (PPC only) +============================ + +Factor to apply to the NMI watchdog timeout (only when ``nmi_watchdog`` is +set to 1). This factor represents the percentage added to +``watchdog_thresh`` when calculating the NMI watchdog timeout during an +LPM. The soft lockup timeout is not impacted. + +A value of 0 means no change. The default value is 200 meaning the NMI +watchdog is set to 30s (based on ``watchdog_thresh`` equal to 10). + + numa_balancing ============== diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index fcd650bdbc7e..60d44165fba7 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -271,7 +271,7 @@ poll cycle or the number of packets processed reaches netdev_budget. netdev_max_backlog ------------------ -Maximum number of packets, queued on the INPUT side, when the interface +Maximum number of packets, queued on the INPUT side, when the interface receives packets faster than kernel can process them. netdev_rss_key @@ -391,6 +391,18 @@ GRO has decided not to coalesce, it is placed on a per-NAPI list. This list is then passed to the stack when the number of segments reaches the gro_normal_batch limit. +high_order_alloc_disable +------------------------ + +By default the allocator for page frags tries to use high order pages (order-3 +on x86). While the default behavior gives good results in most cases, some users +might have hit a contention in page allocations/freeing. This was especially +true on older kernels (< 5.14) when high-order pages were not stored on per-cpu +lists. This allows to opt-in for order-0 allocation instead but is now mostly of +historical importance. + +Default: 0 + 2. /proc/sys/net/unix - Parameters for Unix domain sockets ---------------------------------------------------------- diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 5c9aa171a0d3..9b833e439f09 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -565,13 +565,11 @@ 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 +This knob is not available when 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. +Enable (set to 1) or disable (set to 0) HugeTLB Vmemmap Optimization (HVO). 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 @@ -760,7 +758,7 @@ and don't use much of it. The default value is 0. -See Documentation/vm/overcommit-accounting.rst and +See Documentation/mm/overcommit-accounting.rst and mm/util.c::__vm_enough_memory() for more information. diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index ceeed7b0798d..7d80e8c307d1 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -100,6 +100,7 @@ Bit Log Number Reason that got the kernel tainted 15 _/K 32768 kernel has been live patched 16 _/X 65536 auxiliary taint, defined for and used by distros 17 _/T 131072 kernel was built with the struct randomization plugin + 18 _/N 262144 an in-kernel test has been run === === ====== ======================================================== Note: The character ``_`` is representing a blank in this table to make reading diff --git a/Documentation/arm/google/chromebook-boot-flow.rst b/Documentation/arm/google/chromebook-boot-flow.rst new file mode 100644 index 000000000000..36da77684bba --- /dev/null +++ b/Documentation/arm/google/chromebook-boot-flow.rst @@ -0,0 +1,69 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Chromebook Boot Flow +====================================== + +Most recent Chromebooks that use device tree are using the opensource +depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT +Image`_ which contains an OS image as well as a collection of device trees. It +is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and +provide it to the OS. + +The scheme that depthcharge_ uses to pick the device tree takes into account +three variables: + +- Board name, specified at depthcharge_ compile time. This is $(BOARD) below. +- Board revision number, determined at runtime (perhaps by reading GPIO + strappings, perhaps via some other method). This is $(REV) below. +- SKU number, read from GPIO strappings at boot time. This is $(SKU) below. + +For recent Chromebooks, depthcharge_ creates a match list that looks like this: + +- google,$(BOARD)-rev$(REV)-sku$(SKU) +- google,$(BOARD)-rev$(REV) +- google,$(BOARD)-sku$(SKU) +- google,$(BOARD) + +Note that some older Chromebooks use a slightly different list that may +not include SKU matching or may prioritize SKU/rev differently. + +Note that for some boards there may be extra board-specific logic to inject +extra compatibles into the list, but this is uncommon. + +Depthcharge_ will look through all device trees in the `FIT Image`_ trying to +find one that matches the most specific compatible. It will then look +through all device trees in the `FIT Image`_ trying to find the one that +matches the *second most* specific compatible, etc. + +When searching for a device tree, depthcharge_ doesn't care where the +compatible string falls within a device tree's root compatible string array. +As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device +trees: + +- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180" +- "google,lazor", "qcom,sc7180" + +Then depthcharge_ will pick the first device tree even though +"google,lazor-rev4-sku0" was the second compatible listed in that device tree. +This is because it is a more specific compatible than "google,lazor". + +It should be noted that depthcharge_ does not have any smarts to try to +match board or SKU revisions that are "close by". That is to say that +if depthcharge_ knows it's on "rev4" of a board but there is no "rev4" +device tree then depthcharge_ *won't* look for a "rev3" device tree. + +In general when any significant changes are made to a board the board +revision number is increased even if none of those changes need to +be reflected in the device tree. Thus it's fairly common to see device +trees with multiple revisions. + +It should be noted that, taking into account the above system that +depthcharge_ has, the most flexibility is achieved if the device tree +supporting the newest revision(s) of a board omits the "-rev{REV}" +compatible strings. When this is done then if you get a new board +revision and try to run old software on it then we'll at pick the +newest device tree we know about. + +.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/ +.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst index 2bda5461a80b..495ada7915e1 100644 --- a/Documentation/arm/index.rst +++ b/Documentation/arm/index.rst @@ -31,6 +31,8 @@ SoC-specific documents .. toctree:: :maxdepth: 1 + google/chromebook-boot-flow + ixp4xx marvell diff --git a/Documentation/arm/samsung-s3c24xx/cpufreq.rst b/Documentation/arm/samsung-s3c24xx/cpufreq.rst index 2ddc26c03b1f..cd22697cf606 100644 --- a/Documentation/arm/samsung-s3c24xx/cpufreq.rst +++ b/Documentation/arm/samsung-s3c24xx/cpufreq.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0-only + ======================= S3C24XX CPUfreq support ======================= @@ -73,4 +75,3 @@ Document Author --------------- Ben Dooks, Copyright 2009 Simtec Electronics -Licensed under GPLv2 diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index 3d116fb536c5..311021f2e560 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -171,136 +171,107 @@ HWCAP_PACG Documentation/arm64/pointer-authentication.rst. HWCAP2_DCPODP - Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010. HWCAP2_SVE2 - Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001. HWCAP2_SVEAES - Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001. HWCAP2_SVEPMULL - Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010. HWCAP2_SVEBITPERM - Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001. HWCAP2_SVESHA3 - Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001. HWCAP2_SVESM4 - Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001. HWCAP2_FLAGM2 - Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010. HWCAP2_FRINT - Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001. HWCAP2_SVEI8MM - Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001. HWCAP2_SVEF32MM - Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001. HWCAP2_SVEF64MM - Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001. HWCAP2_SVEBF16 - Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001. HWCAP2_I8MM - Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001. HWCAP2_BF16 - Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001. HWCAP2_DGH - Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001. HWCAP2_RNG - Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001. HWCAP2_BTI - Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001. HWCAP2_MTE - Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described by Documentation/arm64/memory-tagging-extension.rst. HWCAP2_ECV - Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001. HWCAP2_AFP - Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001. HWCAP2_RPRES - Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001. HWCAP2_MTE3 - Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described by Documentation/arm64/memory-tagging-extension.rst. HWCAP2_SME - Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described by Documentation/arm64/sme.rst. HWCAP2_SME_I16I64 - Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111. HWCAP2_SME_F64F64 - Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1. HWCAP2_SME_I8I32 - Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111. HWCAP2_SME_F16F32 - Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1. HWCAP2_SME_B16F32 - Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1. HWCAP2_SME_F32F32 - Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1. HWCAP2_SME_FA64 - Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1. HWCAP2_WFXT - Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010. +HWCAP2_EBF16 + Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index 901cd094f4ec..2a641ba7be3b 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -33,9 +33,8 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: 0000000000000000 0000ffffffffffff 256TB user ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region] - ffff800000000000 ffff800007ffffff 128MB bpf jit region - ffff800008000000 ffff80000fffffff 128MB modules - ffff800010000000 fffffbffefffffff 124TB vmalloc + ffff800000000000 ffff800007ffffff 128MB modules + ffff800008000000 fffffbffefffffff 124TB vmalloc fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space @@ -51,9 +50,8 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support): 0000000000000000 000fffffffffffff 4PB user fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region] - ffff800000000000 ffff800007ffffff 128MB bpf jit region - ffff800008000000 ffff80000fffffff 128MB modules - ffff800010000000 fffffbffefffffff 124TB vmalloc + ffff800000000000 ffff800007ffffff 128MB modules + ffff800008000000 fffffbffefffffff 124TB vmalloc fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index d27db84d585e..fda97b3fcf01 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -52,6 +52,8 @@ stable kernels. | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 | @@ -82,10 +84,14 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A72 | #853709 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 | @@ -102,6 +108,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 | diff --git a/Documentation/atomic_bitops.txt b/Documentation/atomic_bitops.txt index 093cdaefdb37..edea4656c5c0 100644 --- a/Documentation/atomic_bitops.txt +++ b/Documentation/atomic_bitops.txt @@ -58,13 +58,11 @@ Like with atomic_t, the rule of thumb is: - RMW operations that have a return value are fully ordered. - - RMW operations that are conditional are unordered on FAILURE, - otherwise the above rules apply. In the case of test_and_{}_bit() operations, - if the bit in memory is unchanged by the operation then it is deemed to have - failed. + - RMW operations that are conditional are fully ordered. -Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics and -clear_bit_unlock() which has RELEASE semantics. +Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics, +clear_bit_unlock() which has RELEASE semantics and test_bit_acquire which has +ACQUIRE semantics. Since a platform only has a single means of achieving atomic operations the same barriers as for atomic_t are used, see atomic_t.txt. diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst index 68f115f2b1c6..c4c73db748a8 100644 --- a/Documentation/block/index.rst +++ b/Documentation/block/index.rst @@ -23,3 +23,4 @@ Block stat switching-sched writeback_cache_control + ublk diff --git a/Documentation/block/null_blk.rst b/Documentation/block/null_blk.rst index edbbab2f12f8..4dd78f24d10a 100644 --- a/Documentation/block/null_blk.rst +++ b/Documentation/block/null_blk.rst @@ -72,6 +72,28 @@ submit_queues=[1..nr_cpus]: Default: 1 hw_queue_depth=[0..qdepth]: Default: 64 The hardware queue depth of the device. +memory_backed=[0/1]: Default: 0 + Whether or not to use a memory buffer to respond to IO requests + + = ============================================= + 0 Transfer no data in response to IO requests + 1 Use a memory buffer to respond to IO requests + = ============================================= + +discard=[0/1]: Default: 0 + Support discard operations (requires memory-backed null_blk device). + + = ===================================== + 0 Do not support discard operations + 1 Enable support for discard operations + = ===================================== + +cache_size=[Size in MB]: Default: 0 + Cache size in MB for memory-backed device. + +mbps=[Maximum bandwidth in MB/s]: Default: 0 (no limit) + Bandwidth limit for device performance. + Multi-queue specific parameters ------------------------------- diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst new file mode 100644 index 000000000000..2122d1a4a541 --- /dev/null +++ b/Documentation/block/ublk.rst @@ -0,0 +1,253 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================== +Userspace block device driver (ublk driver) +=========================================== + +Overview +======== + +ublk is a generic framework for implementing block device logic from userspace. +The motivation behind it is that moving virtual block drivers into userspace, +such as loop, nbd and similar can be very helpful. It can help to implement +new virtual block device such as ublk-qcow2 (there are several attempts of +implementing qcow2 driver in kernel). + +Userspace block devices are attractive because: + +- They can be written many programming languages. +- They can use libraries that are not available in the kernel. +- They can be debugged with tools familiar to application developers. +- Crashes do not kernel panic the machine. +- Bugs are likely to have a lower security impact than bugs in kernel + code. +- They can be installed and updated independently of the kernel. +- They can be used to simulate block device easily with user specified + parameters/setting for test/debug purpose + +ublk block device (``/dev/ublkb*``) is added by ublk driver. Any IO request +on the device will be forwarded to ublk userspace program. For convenience, +in this document, ``ublk server`` refers to generic ublk userspace +program. ``ublksrv`` [#userspace]_ is one of such implementation. It +provides ``libublksrv`` [#userspace_lib]_ library for developing specific +user block device conveniently, while also generic type block device is +included, such as loop and null. Richard W.M. Jones wrote userspace nbd device +``nbdublk`` [#userspace_nbdublk]_ based on ``libublksrv`` [#userspace_lib]_. + +After the IO is handled by userspace, the result is committed back to the +driver, thus completing the request cycle. This way, any specific IO handling +logic is totally done by userspace, such as loop's IO handling, NBD's IO +communication, or qcow2's IO mapping. + +``/dev/ublkb*`` is driven by blk-mq request-based driver. Each request is +assigned by one queue wide unique tag. ublk server assigns unique tag to each +IO too, which is 1:1 mapped with IO of ``/dev/ublkb*``. + +Both the IO request forward and IO handling result committing are done via +``io_uring`` passthrough command; that is why ublk is also one io_uring based +block driver. It has been observed that using io_uring passthrough command can +give better IOPS than block IO; which is why ublk is one of high performance +implementation of userspace block device: not only IO request communication is +done by io_uring, but also the preferred IO handling in ublk server is io_uring +based approach too. + +ublk provides control interface to set/get ublk block device parameters. +The interface is extendable and kabi compatible: basically any ublk request +queue's parameter or ublk generic feature parameters can be set/get via the +interface. Thus, ublk is generic userspace block device framework. +For example, it is easy to setup a ublk device with specified block +parameters from userspace. + +Using ublk +========== + +ublk requires userspace ublk server to handle real block device logic. + +Below is example of using ``ublksrv`` to provide ublk-based loop device. + +- add a device:: + + ublk add -t loop -f ublk-loop.img + +- format with xfs, then use it:: + + mkfs.xfs /dev/ublkb0 + mount /dev/ublkb0 /mnt + # do anything. all IOs are handled by io_uring + ... + umount /mnt + +- list the devices with their info:: + + ublk list + +- delete the device:: + + ublk del -a + ublk del -n $ublk_dev_id + +See usage details in README of ``ublksrv`` [#userspace_readme]_. + +Design +====== + +Control plane +------------- + +ublk driver provides global misc device node (``/dev/ublk-control``) for +managing and controlling ublk devices with help of several control commands: + +- ``UBLK_CMD_ADD_DEV`` + + Add a ublk char device (``/dev/ublkc*``) which is talked with ublk server + WRT IO command communication. Basic device info is sent together with this + command. It sets UAPI structure of ``ublksrv_ctrl_dev_info``, + such as ``nr_hw_queues``, ``queue_depth``, and max IO request buffer size, + for which the info is negotiated with the driver and sent back to the server. + When this command is completed, the basic device info is immutable. + +- ``UBLK_CMD_SET_PARAMS`` / ``UBLK_CMD_GET_PARAMS`` + + Set or get parameters of the device, which can be either generic feature + related, or request queue limit related, but can't be IO logic specific, + because the driver does not handle any IO logic. This command has to be + sent before sending ``UBLK_CMD_START_DEV``. + +- ``UBLK_CMD_START_DEV`` + + After the server prepares userspace resources (such as creating per-queue + pthread & io_uring for handling ublk IO), this command is sent to the + driver for allocating & exposing ``/dev/ublkb*``. Parameters set via + ``UBLK_CMD_SET_PARAMS`` are applied for creating the device. + +- ``UBLK_CMD_STOP_DEV`` + + Halt IO on ``/dev/ublkb*`` and remove the device. When this command returns, + ublk server will release resources (such as destroying per-queue pthread & + io_uring). + +- ``UBLK_CMD_DEL_DEV`` + + Remove ``/dev/ublkc*``. When this command returns, the allocated ublk device + number can be reused. + +- ``UBLK_CMD_GET_QUEUE_AFFINITY`` + + When ``/dev/ublkc`` is added, the driver creates block layer tagset, so + that each queue's affinity info is available. The server sends + ``UBLK_CMD_GET_QUEUE_AFFINITY`` to retrieve queue affinity info. It can + set up the per-queue context efficiently, such as bind affine CPUs with IO + pthread and try to allocate buffers in IO thread context. + +- ``UBLK_CMD_GET_DEV_INFO`` + + For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's + responsibility to save IO target specific info in userspace. + +Data plane +---------- + +ublk server needs to create per-queue IO pthread & io_uring for handling IO +commands via io_uring passthrough. The per-queue IO pthread +focuses on IO handling and shouldn't handle any control & management +tasks. + +The's IO is assigned by a unique tag, which is 1:1 mapping with IO +request of ``/dev/ublkb*``. + +UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from +the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for +exporting IO info to the server; such as IO offset, length, OP/flags and +buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id +and IO tag directly. + +The following IO commands are communicated via io_uring passthrough command, +and each command is only for forwarding the IO and committing the result +with specified IO tag in the command data: + +- ``UBLK_IO_FETCH_REQ`` + + Sent from the server IO pthread for fetching future incoming IO requests + destined to ``/dev/ublkb*``. This command is sent only once from the server + IO pthread for ublk driver to setup IO forward environment. + +- ``UBLK_IO_COMMIT_AND_FETCH_REQ`` + + When an IO request is destined to ``/dev/ublkb*``, the driver stores + the IO's ``ublksrv_io_desc`` to the specified mapped area; then the + previous received IO command of this IO tag (either ``UBLK_IO_FETCH_REQ`` + or ``UBLK_IO_COMMIT_AND_FETCH_REQ)`` is completed, so the server gets + the IO notification via io_uring. + + After the server handles the IO, its result is committed back to the + driver by sending ``UBLK_IO_COMMIT_AND_FETCH_REQ`` back. Once ublkdrv + received this command, it parses the result and complete the request to + ``/dev/ublkb*``. In the meantime setup environment for fetching future + requests with the same IO tag. That is, ``UBLK_IO_COMMIT_AND_FETCH_REQ`` + is reused for both fetching request and committing back IO result. + +- ``UBLK_IO_NEED_GET_DATA`` + + With ``UBLK_F_NEED_GET_DATA`` enabled, the WRITE request will be firstly + issued to ublk server without data copy. Then, IO backend of ublk server + receives the request and it can allocate data buffer and embed its addr + inside this new io command. After the kernel driver gets the command, + data copy is done from request pages to this backend's buffer. Finally, + backend receives the request again with data to be written and it can + truly handle the request. + + ``UBLK_IO_NEED_GET_DATA`` adds one additional round-trip and one + io_uring_enter() syscall. Any user thinks that it may lower performance + should not enable UBLK_F_NEED_GET_DATA. ublk server pre-allocates IO + buffer for each IO by default. Any new project should try to use this + buffer to communicate with ublk driver. However, existing project may + break or not able to consume the new buffer interface; that's why this + command is added for backwards compatibility so that existing projects + can still consume existing buffers. + +- data copy between ublk server IO buffer and ublk block IO request + + The driver needs to copy the block IO request pages into the server buffer + (pages) first for WRITE before notifying the server of the coming IO, so + that the server can handle WRITE request. + + When the server handles READ request and sends + ``UBLK_IO_COMMIT_AND_FETCH_REQ`` to the server, ublkdrv needs to copy + the server buffer (pages) read to the IO request pages. + +Future development +================== + +Container-aware ublk deivice +---------------------------- + +ublk driver doesn't handle any IO logic. Its function is well defined +for now and very limited userspace interfaces are needed, which is also +well defined too. It is possible to make ublk devices container-aware block +devices in future as Stefan Hajnoczi suggested [#stefan]_, by removing +ADMIN privilege. + +Zero copy +--------- + +Zero copy is a generic requirement for nbd, fuse or similar drivers. A +problem [#xiaoguang]_ Xiaoguang mentioned is that pages mapped to userspace +can't be remapped any more in kernel with existing mm interfaces. This can +occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that +big requests (IO size >= 256 KB) may benefit a lot from zero copy. + + +References +========== + +.. [#userspace] https://github.com/ming1/ubdsrv + +.. [#userspace_lib] https://github.com/ming1/ubdsrv/tree/master/lib + +.. [#userspace_nbdublk] https://gitlab.com/rwmjones/libnbd/-/tree/nbdublk + +.. [#userspace_readme] https://github.com/ming1/ubdsrv/blob/master/README + +.. [#stefan] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/ + +.. [#xiaoguang] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/ diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst index 437de2a7a5de..a210b8a4df00 100644 --- a/Documentation/bpf/bpf_design_QA.rst +++ b/Documentation/bpf/bpf_design_QA.rst @@ -214,6 +214,12 @@ A: NO. Tracepoints are tied to internal implementation details hence they are subject to change and can break with newer kernels. BPF programs need to change accordingly when this happens. +Q: Are places where kprobes can attach part of the stable ABI? +-------------------------------------------------------------- +A: NO. The places to which kprobes can attach are internal implementation +details, which means that they are subject to change and can break with +newer kernels. BPF programs need to change accordingly when this happens. + Q: How much stack space a BPF program uses? ------------------------------------------- A: Currently all program types are limited to 512 bytes of stack @@ -273,3 +279,22 @@ cc (congestion-control) implementations. If any of these kernel functions has changed, both the in-tree and out-of-tree kernel tcp cc implementations have to be changed. The same goes for the bpf programs and they have to be adjusted accordingly. + +Q: Attaching to arbitrary kernel functions is an ABI? +----------------------------------------------------- +Q: BPF programs can be attached to many kernel functions. Do these +kernel functions become part of the ABI? + +A: NO. + +The kernel function prototypes will change, and BPF programs attaching to +them will need to change. The BPF compile-once-run-everywhere (CO-RE) +should be used in order to make it easier to adapt your BPF programs to +different versions of the kernel. + +Q: Marking a function with BTF_ID makes that function an ABI? +------------------------------------------------------------- +A: NO. + +The BTF_ID macro does not cause a function to become part of the ABI +any more than does the EXPORT_SYMBOL_GPL macro. diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 7940da9bc6c1..cf8722f96090 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -74,7 +74,7 @@ sequentially and type id is assigned to each recognized type starting from id #define BTF_KIND_ARRAY 3 /* Array */ #define BTF_KIND_STRUCT 4 /* Struct */ #define BTF_KIND_UNION 5 /* Union */ - #define BTF_KIND_ENUM 6 /* Enumeration */ + #define BTF_KIND_ENUM 6 /* Enumeration up to 32-bit values */ #define BTF_KIND_FWD 7 /* Forward */ #define BTF_KIND_TYPEDEF 8 /* Typedef */ #define BTF_KIND_VOLATILE 9 /* Volatile */ @@ -87,6 +87,7 @@ sequentially and type id is assigned to each recognized type starting from id #define BTF_KIND_FLOAT 16 /* Floating point */ #define BTF_KIND_DECL_TAG 17 /* Decl Tag */ #define BTF_KIND_TYPE_TAG 18 /* Type Tag */ + #define BTF_KIND_ENUM64 19 /* Enumeration up to 64-bit values */ Note that the type section encodes debug info, not just pure types. ``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram. @@ -101,10 +102,10 @@ Each type contains the following common data:: * bits 24-28: kind (e.g. int, ptr, array...etc) * bits 29-30: unused * bit 31: kind_flag, currently used by - * struct, union and fwd + * struct, union, fwd, enum and enum64. */ __u32 info; - /* "size" is used by INT, ENUM, STRUCT and UNION. + /* "size" is used by INT, ENUM, STRUCT, UNION and ENUM64. * "size" tells the size of the type it is describing. * * "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT, @@ -281,10 +282,10 @@ modes exist: ``struct btf_type`` encoding requirement: * ``name_off``: 0 or offset to a valid C identifier - * ``info.kind_flag``: 0 + * ``info.kind_flag``: 0 for unsigned, 1 for signed * ``info.kind``: BTF_KIND_ENUM * ``info.vlen``: number of enum values - * ``size``: 4 + * ``size``: 1/2/4/8 ``btf_type`` is followed by ``info.vlen`` number of ``struct btf_enum``.:: @@ -297,6 +298,10 @@ The ``btf_enum`` encoding: * ``name_off``: offset to a valid C identifier * ``val``: any value +If the original enum value is signed and the size is less than 4, +that value will be sign extended into 4 bytes. If the size is 8, +the value will be truncated into 4 bytes. + 2.2.7 BTF_KIND_FWD ~~~~~~~~~~~~~~~~~~ @@ -364,7 +369,8 @@ No additional type data follow ``btf_type``. * ``name_off``: offset to a valid C identifier * ``info.kind_flag``: 0 * ``info.kind``: BTF_KIND_FUNC - * ``info.vlen``: 0 + * ``info.vlen``: linkage information (BTF_FUNC_STATIC, BTF_FUNC_GLOBAL + or BTF_FUNC_EXTERN) * ``type``: a BTF_KIND_FUNC_PROTO type No additional type data follow ``btf_type``. @@ -375,6 +381,9 @@ type. The BTF_KIND_FUNC may in turn be referenced by a func_info in the :ref:`BTF_Ext_Section` (ELF) or in the arguments to :ref:`BPF_Prog_Load` (ABI). +Currently, only linkage values of BTF_FUNC_STATIC and BTF_FUNC_GLOBAL are +supported in the kernel. + 2.2.13 BTF_KIND_FUNC_PROTO ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -493,7 +502,7 @@ the attribute is applied to a ``struct``/``union`` member or a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a valid index (starting from 0) pointing to a member or an argument. -2.2.17 BTF_KIND_TYPE_TAG +2.2.18 BTF_KIND_TYPE_TAG ~~~~~~~~~~~~~~~~~~~~~~~~ ``struct btf_type`` encoding requirement: @@ -516,6 +525,32 @@ type_tag, then zero or more const/volatile/restrict/typedef and finally the base type. The base type is one of int, ptr, array, struct, union, enum, func_proto and float types. +2.2.19 BTF_KIND_ENUM64 +~~~~~~~~~~~~~~~~~~~~~~ + +``struct btf_type`` encoding requirement: + * ``name_off``: 0 or offset to a valid C identifier + * ``info.kind_flag``: 0 for unsigned, 1 for signed + * ``info.kind``: BTF_KIND_ENUM64 + * ``info.vlen``: number of enum values + * ``size``: 1/2/4/8 + +``btf_type`` is followed by ``info.vlen`` number of ``struct btf_enum64``.:: + + struct btf_enum64 { + __u32 name_off; + __u32 val_lo32; + __u32 val_hi32; + }; + +The ``btf_enum64`` encoding: + * ``name_off``: offset to a valid C identifier + * ``val_lo32``: lower 32-bit value for a 64-bit value + * ``val_hi32``: high 32-bit value for a 64-bit value + +If the original enum value is signed and the size is less than 8, +that value will be sign extended into 8 bytes. + 3. BTF Kernel API ================= diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 96056a7447c7..1bc2c5c58bdb 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -19,6 +19,7 @@ that goes into great technical depth about the BPF Architecture. faq syscall_api helpers + kfuncs programs maps bpf_prog_run diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 1de6a57c7e1e..1b0e6711dec9 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -127,7 +127,7 @@ BPF_XOR | BPF_K | BPF_ALU64 means:: Byte swap instructions ---------------------- -The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit +The byte swap instructions use an instruction class of ``BPF_ALU`` and a 4-bit code field of ``BPF_END``. The byte swap instructions operate on the destination register @@ -351,7 +351,7 @@ These instructions have seven implicit operands: * Register R0 is an implicit output which contains the data fetched from the packet. * Registers R1-R5 are scratch registers that are clobbered after a call to - ``BPF_ABS | BPF_LD`` or ``BPF_IND`` | BPF_LD instructions. + ``BPF_ABS | BPF_LD`` or ``BPF_IND | BPF_LD`` instructions. These instructions have an implicit program exit condition as well. When an eBPF program is trying to access the data beyond the packet boundary, the diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst new file mode 100644 index 000000000000..c0b7dae6dbf5 --- /dev/null +++ b/Documentation/bpf/kfuncs.rst @@ -0,0 +1,170 @@ +============================= +BPF Kernel Functions (kfuncs) +============================= + +1. Introduction +=============== + +BPF Kernel Functions or more commonly known as kfuncs are functions in the Linux +kernel which are exposed for use by BPF programs. Unlike normal BPF helpers, +kfuncs do not have a stable interface and can change from one kernel release to +another. Hence, BPF programs need to be updated in response to changes in the +kernel. + +2. Defining a kfunc +=================== + +There are two ways to expose a kernel function to BPF programs, either make an +existing function in the kernel visible, or add a new wrapper for BPF. In both +cases, care must be taken that BPF program can only call such function in a +valid context. To enforce this, visibility of a kfunc can be per program type. + +If you are not creating a BPF wrapper for existing kernel function, skip ahead +to :ref:`BPF_kfunc_nodef`. + +2.1 Creating a wrapper kfunc +---------------------------- + +When defining a wrapper kfunc, the wrapper function should have extern linkage. +This prevents the compiler from optimizing away dead code, as this wrapper kfunc +is not invoked anywhere in the kernel itself. It is not necessary to provide a +prototype in a header for the wrapper kfunc. + +An example is given below:: + + /* Disables missing prototype warnings */ + __diag_push(); + __diag_ignore_all("-Wmissing-prototypes", + "Global kfuncs as their definitions will be in BTF"); + + struct task_struct *bpf_find_get_task_by_vpid(pid_t nr) + { + return find_get_task_by_vpid(nr); + } + + __diag_pop(); + +A wrapper kfunc is often needed when we need to annotate parameters of the +kfunc. Otherwise one may directly make the kfunc visible to the BPF program by +registering it with the BPF subsystem. See :ref:`BPF_kfunc_nodef`. + +2.2 Annotating kfunc parameters +------------------------------- + +Similar to BPF helpers, there is sometime need for additional context required +by the verifier to make the usage of kernel functions safer and more useful. +Hence, we can annotate a parameter by suffixing the name of the argument of the +kfunc with a __tag, where tag may be one of the supported annotations. + +2.2.1 __sz Annotation +--------------------- + +This annotation is used to indicate a memory and size pair in the argument list. +An example is given below:: + + void bpf_memzero(void *mem, int mem__sz) + { + ... + } + +Here, the verifier will treat first argument as a PTR_TO_MEM, and second +argument as its size. By default, without __sz annotation, the size of the type +of the pointer is used. Without __sz annotation, a kfunc cannot accept a void +pointer. + +.. _BPF_kfunc_nodef: + +2.3 Using an existing kernel function +------------------------------------- + +When an existing function in the kernel is fit for consumption by BPF programs, +it can be directly registered with the BPF subsystem. However, care must still +be taken to review the context in which it will be invoked by the BPF program +and whether it is safe to do so. + +2.4 Annotating kfuncs +--------------------- + +In addition to kfuncs' arguments, verifier may need more information about the +type of kfunc(s) being registered with the BPF subsystem. To do so, we define +flags on a set of kfuncs as follows:: + + BTF_SET8_START(bpf_task_set) + BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL) + BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE) + BTF_SET8_END(bpf_task_set) + +This set encodes the BTF ID of each kfunc listed above, and encodes the flags +along with it. Ofcourse, it is also allowed to specify no flags. + +2.4.1 KF_ACQUIRE flag +--------------------- + +The KF_ACQUIRE flag is used to indicate that the kfunc returns a pointer to a +refcounted object. The verifier will then ensure that the pointer to the object +is eventually released using a release kfunc, or transferred to a map using a +referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the +loading of the BPF program until no lingering references remain in all possible +explored states of the program. + +2.4.2 KF_RET_NULL flag +---------------------- + +The KF_RET_NULL flag is used to indicate that the pointer returned by the kfunc +may be NULL. Hence, it forces the user to do a NULL check on the pointer +returned from the kfunc before making use of it (dereferencing or passing to +another helper). This flag is often used in pairing with KF_ACQUIRE flag, but +both are orthogonal to each other. + +2.4.3 KF_RELEASE flag +--------------------- + +The KF_RELEASE flag is used to indicate that the kfunc releases the pointer +passed in to it. There can be only one referenced pointer that can be passed in. +All copies of the pointer being released are invalidated as a result of invoking +kfunc with this flag. + +2.4.4 KF_KPTR_GET flag +---------------------- + +The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument +as a pointer to kptr, safely increments the refcount of the object it points to, +and returns a reference to the user. The rest of the arguments may be normal +arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with +KF_ACQUIRE and KF_RET_NULL flags. + +2.4.5 KF_TRUSTED_ARGS flag +-------------------------- + +The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It +indicates that the all pointer arguments will always be refcounted, and have +their offset set to 0. It can be used to enforce that a pointer to a refcounted +object acquired from a kfunc or BPF helper is passed as an argument to this +kfunc without any modifications (e.g. pointer arithmetic) such that it is +trusted and points to the original object. This flag is often used for kfuncs +that operate (change some property, perform some operation) on an object that +was obtained using an acquire kfunc. Such kfuncs need an unchanged pointer to +ensure the integrity of the operation being performed on the expected object. + +2.5 Registering the kfuncs +-------------------------- + +Once the kfunc is prepared for use, the final step to making it visible is +registering it with the BPF subsystem. Registration is done per BPF program +type. An example is shown below:: + + BTF_SET8_START(bpf_task_set) + BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL) + BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE) + BTF_SET8_END(bpf_task_set) + + static const struct btf_kfunc_id_set bpf_task_kfunc_set = { + .owner = THIS_MODULE, + .set = &bpf_task_set, + }; + + static int init_subsystem(void) + { + return register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &bpf_task_kfunc_set); + } + late_initcall(init_subsystem); diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst index f86360f734a8..c5ac97f3d4c4 100644 --- a/Documentation/bpf/libbpf/libbpf_naming_convention.rst +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -9,8 +9,8 @@ described here. It's recommended to follow these conventions whenever a new function or type is added to keep libbpf API clean and consistent. All types and functions provided by libbpf API should have one of the -following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``xsk_``, -``btf_dump_``, ``ring_buffer_``, ``perf_buffer_``. +following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``btf_dump_``, +``ring_buffer_``, ``perf_buffer_``. System call wrappers -------------------- @@ -59,15 +59,6 @@ Auxiliary functions and types that don't fit well in any of categories described above should have ``libbpf_`` prefix, e.g. ``libbpf_get_error`` or ``libbpf_prog_type_by_name``. -AF_XDP functions -------------------- - -AF_XDP functions should have an ``xsk_`` prefix, e.g. -``xsk_umem__get_data`` or ``xsk_umem__create``. The interface consists -of both low-level ring access functions and high-level configuration -functions. These can be mixed and matched. Note that these functions -are not reentrant for performance reasons. - ABI --- diff --git a/Documentation/bpf/map_hash.rst b/Documentation/bpf/map_hash.rst new file mode 100644 index 000000000000..e85120878b27 --- /dev/null +++ b/Documentation/bpf/map_hash.rst @@ -0,0 +1,185 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. Copyright (C) 2022 Red Hat, Inc. + +=============================================== +BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants +=============================================== + +.. note:: + - ``BPF_MAP_TYPE_HASH`` was introduced in kernel version 3.19 + - ``BPF_MAP_TYPE_PERCPU_HASH`` was introduced in version 4.6 + - Both ``BPF_MAP_TYPE_LRU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH`` + were introduced in version 4.10 + +``BPF_MAP_TYPE_HASH`` and ``BPF_MAP_TYPE_PERCPU_HASH`` provide general +purpose hash map storage. Both the key and the value can be structs, +allowing for composite keys and values. + +The kernel is responsible for allocating and freeing key/value pairs, up +to the max_entries limit that you specify. Hash maps use pre-allocation +of hash table elements by default. The ``BPF_F_NO_PREALLOC`` flag can be +used to disable pre-allocation when it is too memory expensive. + +``BPF_MAP_TYPE_PERCPU_HASH`` provides a separate value slot per +CPU. The per-cpu values are stored internally in an array. + +The ``BPF_MAP_TYPE_LRU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH`` +variants add LRU semantics to their respective hash tables. An LRU hash +will automatically evict the least recently used entries when the hash +table reaches capacity. An LRU hash maintains an internal LRU list that +is used to select elements for eviction. This internal LRU list is +shared across CPUs but it is possible to request a per CPU LRU list with +the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``. + +Usage +===== + +.. c:function:: + long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags) + +Hash entries can be added or updated using the ``bpf_map_update_elem()`` +helper. This helper replaces existing elements atomically. The ``flags`` +parameter can be used to control the update behaviour: + +- ``BPF_ANY`` will create a new element or update an existing element +- ``BPF_NOEXIST`` will create a new element only if one did not already + exist +- ``BPF_EXIST`` will update an existing element + +``bpf_map_update_elem()`` returns 0 on success, or negative error in +case of failure. + +.. c:function:: + void *bpf_map_lookup_elem(struct bpf_map *map, const void *key) + +Hash entries can be retrieved using the ``bpf_map_lookup_elem()`` +helper. This helper returns a pointer to the value associated with +``key``, or ``NULL`` if no entry was found. + +.. c:function:: + long bpf_map_delete_elem(struct bpf_map *map, const void *key) + +Hash entries can be deleted using the ``bpf_map_delete_elem()`` +helper. This helper will return 0 on success, or negative error in case +of failure. + +Per CPU Hashes +-------------- + +For ``BPF_MAP_TYPE_PERCPU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH`` +the ``bpf_map_update_elem()`` and ``bpf_map_lookup_elem()`` helpers +automatically access the hash slot for the current CPU. + +.. c:function:: + void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu) + +The ``bpf_map_lookup_percpu_elem()`` helper can be used to lookup the +value in the hash slot for a specific CPU. Returns value associated with +``key`` on ``cpu`` , or ``NULL`` if no entry was found or ``cpu`` is +invalid. + +Concurrency +----------- + +Values stored in ``BPF_MAP_TYPE_HASH`` can be accessed concurrently by +programs running on different CPUs. Since Kernel version 5.1, the BPF +infrastructure provides ``struct bpf_spin_lock`` to synchronise access. +See ``tools/testing/selftests/bpf/progs/test_spin_lock.c``. + +Userspace +--------- + +.. c:function:: + int bpf_map_get_next_key(int fd, const void *cur_key, void *next_key) + +In userspace, it is possible to iterate through the keys of a hash using +libbpf's ``bpf_map_get_next_key()`` function. The first key can be fetched by +calling ``bpf_map_get_next_key()`` with ``cur_key`` set to +``NULL``. Subsequent calls will fetch the next key that follows the +current key. ``bpf_map_get_next_key()`` returns 0 on success, -ENOENT if +cur_key is the last key in the hash, or negative error in case of +failure. + +Note that if ``cur_key`` gets deleted then ``bpf_map_get_next_key()`` +will instead return the *first* key in the hash table which is +undesirable. It is recommended to use batched lookup if there is going +to be key deletion intermixed with ``bpf_map_get_next_key()``. + +Examples +======== + +Please see the ``tools/testing/selftests/bpf`` directory for functional +examples. The code snippets below demonstrates API usage. + +This example shows how to declare an LRU Hash with a struct key and a +struct value. + +.. code-block:: c + + #include <linux/bpf.h> + #include <bpf/bpf_helpers.h> + + struct key { + __u32 srcip; + }; + + struct value { + __u64 packets; + __u64 bytes; + }; + + struct { + __uint(type, BPF_MAP_TYPE_LRU_HASH); + __uint(max_entries, 32); + __type(key, struct key); + __type(value, struct value); + } packet_stats SEC(".maps"); + +This example shows how to create or update hash values using atomic +instructions: + +.. code-block:: c + + static void update_stats(__u32 srcip, int bytes) + { + struct key key = { + .srcip = srcip, + }; + struct value *value = bpf_map_lookup_elem(&packet_stats, &key); + + if (value) { + __sync_fetch_and_add(&value->packets, 1); + __sync_fetch_and_add(&value->bytes, bytes); + } else { + struct value newval = { 1, bytes }; + + bpf_map_update_elem(&packet_stats, &key, &newval, BPF_NOEXIST); + } + } + +Userspace walking the map elements from the map declared above: + +.. code-block:: c + + #include <bpf/libbpf.h> + #include <bpf/bpf.h> + + static void walk_hash_elements(int map_fd) + { + struct key *cur_key = NULL; + struct key next_key; + struct value value; + int err; + + for (;;) { + err = bpf_map_get_next_key(map_fd, cur_key, &next_key); + if (err) + break; + + bpf_map_lookup_elem(map_fd, &next_key, &value); + + // Use key and value here + + cur_key = &next_key; + } + } diff --git a/Documentation/conf.py b/Documentation/conf.py index 934727e23e0e..255384d094bf 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -86,6 +86,7 @@ if major >= 3: "__used", "__weak", "noinline", + "__fix_address", # include/linux/memblock.h: "__init_memblock", diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst b/Documentation/core-api/bus-virt-phys-mapping.rst deleted file mode 100644 index c72b24a7d52c..000000000000 --- a/Documentation/core-api/bus-virt-phys-mapping.rst +++ /dev/null @@ -1,220 +0,0 @@ -========================================================== -How to access I/O mapped memory from within device drivers -========================================================== - -:Author: Linus - -.. warning:: - - The virt_to_bus() and bus_to_virt() functions have been - superseded by the functionality provided by the PCI DMA interface - (see Documentation/core-api/dma-api-howto.rst). They continue - to be documented below for historical purposes, but new code - must not use them. --davidm 00/12/12 - -:: - - [ This is a mail message in response to a query on IO mapping, thus the - strange format for a "document" ] - -The AHA-1542 is a bus-master device, and your patch makes the driver give the -controller the physical address of the buffers, which is correct on x86 -(because all bus master devices see the physical memory mappings directly). - -However, on many setups, there are actually **three** different ways of looking -at memory addresses, and in this case we actually want the third, the -so-called "bus address". - -Essentially, the three ways of addressing memory are (this is "real memory", -that is, normal RAM--see later about other details): - - - CPU untranslated. This is the "physical" address. Physical address - 0 is what the CPU sees when it drives zeroes on the memory bus. - - - CPU translated address. This is the "virtual" address, and is - completely internal to the CPU itself with the CPU doing the appropriate - translations into "CPU untranslated". - - - bus address. This is the address of memory as seen by OTHER devices, - not the CPU. Now, in theory there could be many different bus - addresses, with each device seeing memory in some device-specific way, but - happily most hardware designers aren't actually actively trying to make - things any more complex than necessary, so you can assume that all - external hardware sees the memory the same way. - -Now, on normal PCs the bus address is exactly the same as the physical -address, and things are very simple indeed. However, they are that simple -because the memory and the devices share the same address space, and that is -not generally necessarily true on other PCI/ISA setups. - -Now, just as an example, on the PReP (PowerPC Reference Platform), the -CPU sees a memory map something like this (this is from memory):: - - 0-2 GB "real memory" - 2 GB-3 GB "system IO" (inb/out and similar accesses on x86) - 3 GB-4 GB "IO memory" (shared memory over the IO bus) - -Now, that looks simple enough. However, when you look at the same thing from -the viewpoint of the devices, you have the reverse, and the physical memory -address 0 actually shows up as address 2 GB for any IO master. - -So when the CPU wants any bus master to write to physical memory 0, it -has to give the master address 0x80000000 as the memory address. - -So, for example, depending on how the kernel is actually mapped on the -PPC, you can end up with a setup like this:: - - physical address: 0 - virtual address: 0xC0000000 - bus address: 0x80000000 - -where all the addresses actually point to the same thing. It's just seen -through different translations.. - -Similarly, on the Alpha, the normal translation is:: - - physical address: 0 - virtual address: 0xfffffc0000000000 - bus address: 0x40000000 - -(but there are also Alphas where the physical address and the bus address -are the same). - -Anyway, the way to look up all these translations, you do:: - - #include <asm/io.h> - - phys_addr = virt_to_phys(virt_addr); - virt_addr = phys_to_virt(phys_addr); - bus_addr = virt_to_bus(virt_addr); - virt_addr = bus_to_virt(bus_addr); - -Now, when do you need these? - -You want the **virtual** address when you are actually going to access that -pointer from the kernel. So you can have something like this:: - - /* - * this is the hardware "mailbox" we use to communicate with - * the controller. The controller sees this directly. - */ - struct mailbox { - __u32 status; - __u32 bufstart; - __u32 buflen; - .. - } mbox; - - unsigned char * retbuffer; - - /* get the address from the controller */ - retbuffer = bus_to_virt(mbox.bufstart); - switch (retbuffer[0]) { - case STATUS_OK: - ... - -on the other hand, you want the bus address when you have a buffer that -you want to give to the controller:: - - /* ask the controller to read the sense status into "sense_buffer" */ - mbox.bufstart = virt_to_bus(&sense_buffer); - mbox.buflen = sizeof(sense_buffer); - mbox.status = 0; - notify_controller(&mbox); - -And you generally **never** want to use the physical address, because you can't -use that from the CPU (the CPU only uses translated virtual addresses), and -you can't use it from the bus master. - -So why do we care about the physical address at all? We do need the physical -address in some cases, it's just not very often in normal code. The physical -address is needed if you use memory mappings, for example, because the -"remap_pfn_range()" mm function wants the physical address of the memory to -be remapped as measured in units of pages, a.k.a. the pfn (the memory -management layer doesn't know about devices outside the CPU, so it -shouldn't need to know about "bus addresses" etc). - -.. note:: - - The above is only one part of the whole equation. The above - only talks about "real memory", that is, CPU memory (RAM). - -There is a completely different type of memory too, and that's the "shared -memory" on the PCI or ISA bus. That's generally not RAM (although in the case -of a video graphics card it can be normal DRAM that is just used for a frame -buffer), but can be things like a packet buffer in a network card etc. - -This memory is called "PCI memory" or "shared memory" or "IO memory" or -whatever, and there is only one way to access it: the readb/writeb and -related functions. You should never take the address of such memory, because -there is really nothing you can do with such an address: it's not -conceptually in the same memory space as "real memory" at all, so you cannot -just dereference a pointer. (Sadly, on x86 it **is** in the same memory space, -so on x86 it actually works to just deference a pointer, but it's not -portable). - -For such memory, you can do things like: - - - reading:: - - /* - * read first 32 bits from ISA memory at 0xC0000, aka - * C000:0000 in DOS terms - */ - unsigned int signature = isa_readl(0xC0000); - - - remapping and writing:: - - /* - * remap framebuffer PCI memory area at 0xFC000000, - * size 1MB, so that we can access it: We can directly - * access only the 640k-1MB area, so anything else - * has to be remapped. - */ - void __iomem *baseptr = ioremap(0xFC000000, 1024*1024); - - /* write a 'A' to the offset 10 of the area */ - writeb('A',baseptr+10); - - /* unmap when we unload the driver */ - iounmap(baseptr); - - - copying and clearing:: - - /* get the 6-byte Ethernet address at ISA address E000:0040 */ - memcpy_fromio(kernel_buffer, 0xE0040, 6); - /* write a packet to the driver */ - memcpy_toio(0xE1000, skb->data, skb->len); - /* clear the frame buffer */ - memset_io(0xA0000, 0, 0x10000); - -OK, that just about covers the basics of accessing IO portably. Questions? -Comments? You may think that all the above is overly complex, but one day you -might find yourself with a 500 MHz Alpha in front of you, and then you'll be -happy that your driver works ;) - -Note that kernel versions 2.0.x (and earlier) mistakenly called the -ioremap() function "vremap()". ioremap() is the proper name, but I -didn't think straight when I wrote it originally. People who have to -support both can do something like:: - - /* support old naming silliness */ - #if LINUX_VERSION_CODE < 0x020100 - #define ioremap vremap - #define iounmap vfree - #endif - -at the top of their source files, and then they can use the right names -even on 2.0.x systems. - -And the above sounds worse than it really is. Most real drivers really -don't do all that complex things (or rather: the complexity is not so -much in the actual IO accesses as in error handling and timeouts etc). -It's generally not hard to fix drivers, and in many cases the code -actually looks better afterwards:: - - unsigned long signature = *(unsigned int *) 0xC0000; - vs - unsigned long signature = readl(0xC0000); - -I think the second version actually is more readable, no? diff --git a/Documentation/core-api/dma-api-howto.rst b/Documentation/core-api/dma-api-howto.rst index 358d495456d1..828846804e25 100644 --- a/Documentation/core-api/dma-api-howto.rst +++ b/Documentation/core-api/dma-api-howto.rst @@ -707,20 +707,6 @@ to use the dma_sync_*() interfaces:: } } -Drivers converted fully to this interface should not use virt_to_bus() any -longer, nor should they use bus_to_virt(). Some drivers have to be changed a -little bit, because there is no longer an equivalent to bus_to_virt() in the -dynamic DMA mapping scheme - you have to always store the DMA addresses -returned by the dma_alloc_coherent(), dma_pool_alloc(), and dma_map_single() -calls (dma_map_sg() stores them in the scatterlist itself if the platform -supports dynamic DMA mapping in hardware) in your driver structures and/or -in the card registers. - -All drivers should be using these interfaces with no exceptions. It -is planned to completely remove virt_to_bus() and bus_to_virt() as -they are entirely deprecated. Some ports already do not provide these -as it is impossible to correctly support them. - Handling Errors =============== diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index 6d6d0edd2d27..829f20a193ca 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -206,6 +206,20 @@ others should not be larger than the returned value. :: + size_t + dma_opt_mapping_size(struct device *dev); + +Returns the maximum optimal size of a mapping for the device. + +Mapping larger buffers may take much longer in certain scenarios. In +addition, for high-rate short-lived streaming mappings, the upfront time +spent on the mapping may account for an appreciable part of the total +request lifetime. As such, if splitting larger requests incurs no +significant performance penalty, then device drivers are advised to +limit total DMA streaming mappings length to the returned value. + +:: + bool dma_need_sync(struct device *dev, dma_addr_t dma_addr); diff --git a/Documentation/core-api/idr.rst b/Documentation/core-api/idr.rst index 2eb5afdb9931..18d724867064 100644 --- a/Documentation/core-api/idr.rst +++ b/Documentation/core-api/idr.rst @@ -17,6 +17,9 @@ solution to the problem to avoid everybody inventing their own. The IDR provides the ability to map an ID to a pointer, while the IDA provides only ID allocation, and as a result is much more memory-efficient. +The IDR interface is deprecated; please use the :doc:`XArray <xarray>` +instead. + IDR usage ========= diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index dedd4d853329..dc95df462eea 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -41,7 +41,6 @@ Library functionality that is used throughout the kernel. rbtree generic-radix-tree packing - bus-virt-phys-mapping this_cpu_ops timekeeping errseq @@ -87,7 +86,7 @@ Memory management ================= How to allocate and use memory in the kernel. Note that there is a lot -more memory-management documentation in Documentation/vm/index.rst. +more memory-management documentation in Documentation/mm/index.rst. .. toctree:: :maxdepth: 1 diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index d6b3f94b9f1f..0793c400d4b0 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -223,7 +223,7 @@ Module Loading Inter Module support -------------------- -Refer to the file kernel/module.c for more information. +Refer to the files in kernel/module/ for more information. Hardware Interfaces =================== diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index f5b2f92822c8..1ebcc6c3fafe 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -22,16 +22,16 @@ Memory Allocation Controls .. kernel-doc:: include/linux/gfp.h :internal: -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Page mobility and placement hints -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Watermark modifiers -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Reclaim modifiers -.. kernel-doc:: include/linux/gfp.h +.. kernel-doc:: include/linux/gfp_types.h :doc: Useful GFP flag combinations The Slab Cache diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst index ec575e72d0b2..bf28ac0401f3 100644 --- a/Documentation/core-api/protection-keys.rst +++ b/Documentation/core-api/protection-keys.rst @@ -4,31 +4,29 @@ Memory Protection Keys ====================== -Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature -which is found on Intel's Skylake (and later) "Scalable Processor" -Server CPUs. It will be available in future non-server Intel parts -and future AMD processors. - -For anyone wishing to test or use this feature, it is available in -Amazon's EC2 C5 instances and is known to work there using an Ubuntu -17.04 image. - -Memory Protection Keys provides a mechanism for enforcing page-based -protections, but without requiring modification of the page tables -when an application changes protection domains. It works by -dedicating 4 previously ignored bits in each page table entry to a -"protection key", giving 16 possible keys. - -There is also a new user-accessible register (PKRU) with two separate -bits (Access Disable and Write Disable) for each key. Being a CPU -register, PKRU is inherently thread-local, potentially giving each +Memory Protection Keys provide a mechanism for enforcing page-based +protections, but without requiring modification of the page tables when an +application changes protection domains. + +Pkeys Userspace (PKU) is a feature which can be found on: + * Intel server CPUs, Skylake and later + * Intel client CPUs, Tiger Lake (11th Gen Core) and later + * Future AMD CPUs + +Pkeys work by dedicating 4 previously Reserved bits in each page table entry to +a "protection key", giving 16 possible keys. + +Protections for each key are defined with a per-CPU user-accessible register +(PKRU). Each of these is a 32-bit register storing two bits (Access Disable +and Write Disable) for each of 16 keys. + +Being a CPU register, PKRU is inherently thread-local, potentially giving each thread a different set of protections from every other thread. -There are two new instructions (RDPKRU/WRPKRU) for reading and writing -to the new register. The feature is only available in 64-bit mode, -even though there is theoretically space in the PAE PTEs. These -permissions are enforced on data access only and have no effect on -instruction fetches. +There are two instructions (RDPKRU/WRPKRU) for reading and writing to the +register. The feature is only available in 64-bit mode, even though there is +theoretically space in the PAE PTEs. These permissions are enforced on data +access only and have no effect on instruction fetches. Syscalls ======== diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst index 5ad9e0abe42c..12e4aecdae94 100644 --- a/Documentation/core-api/symbol-namespaces.rst +++ b/Documentation/core-api/symbol-namespaces.rst @@ -51,8 +51,8 @@ namespace ``USB_STORAGE``, use:: The corresponding ksymtab entry struct ``kernel_symbol`` will have the member ``namespace`` set accordingly. A symbol that is exported without a namespace will refer to ``NULL``. There is no default namespace if none is defined. ``modpost`` -and kernel/module.c make use the namespace at build time or module load time, -respectively. +and kernel/module/main.c make use the namespace at build time or module load +time, respectively. 2.2 Using the DEFAULT_SYMBOL_NAMESPACE define ============================================= diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 9c454de5a7f7..d9976069ed12 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -66,7 +66,7 @@ The wiki documentation always refers to the linux-next version of the script. For Semantic Patch Language(SmPL) grammar documentation refer to: -http://coccinelle.lip6.fr/documentation.php +https://coccinelle.gitlabpages.inria.fr/website/docs/main_grammar.html Using Coccinelle on the Linux kernel ------------------------------------ diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst index 1c935f41cd3a..5483fd39ef29 100644 --- a/Documentation/dev-tools/kmemleak.rst +++ b/Documentation/dev-tools/kmemleak.rst @@ -174,7 +174,6 @@ mapping: - ``kmemleak_alloc_phys`` - ``kmemleak_free_part_phys`` -- ``kmemleak_not_leak_phys`` - ``kmemleak_ignore_phys`` Dealing with false positives/negatives diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index a833ecf12fbc..e87973763b91 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -208,6 +208,14 @@ In general, the rules for selftests are Contributing new tests (details) ================================ + * In your Makefile, use facilities from lib.mk by including it instead of + reinventing the wheel. Specify flags and binaries generation flags on + need basis before including lib.mk. :: + + CFLAGS = $(KHDR_INCLUDES) + TEST_GEN_PROGS := close_range_test + include ../lib.mk + * Use TEST_GEN_XXX if such binaries or files are generated during compiling. @@ -230,13 +238,30 @@ Contributing new tests (details) * First use the headers inside the kernel source and/or git repo, and then the system headers. Headers for the kernel release as opposed to headers installed by the distro on the system should be the primary focus to be able - to find regressions. + to find regressions. Use KHDR_INCLUDES in Makefile to include headers from + the kernel source. * If a test needs specific kernel config options enabled, add a config file in the test directory to enable them. e.g: tools/testing/selftests/android/config + * Create a .gitignore file inside test directory and add all generated objects + in it. + + * Add new test name in TARGETS in selftests/Makefile:: + + TARGETS += android + + * All changes should pass:: + + kselftest-{all,install,clean,gen_tar} + kselftest-{all,install,clean,gen_tar} O=abo_path + kselftest-{all,install,clean,gen_tar} O=rel_path + make -C tools/testing/selftests {all,install,clean,gen_tar} + make -C tools/testing/selftests {all,install,clean,gen_tar} O=abs_path + make -C tools/testing/selftests {all,install,clean,gen_tar} O=rel_path + Test Module =========== @@ -250,6 +275,14 @@ assist writing kernel modules that are for use with kselftest: - ``tools/testing/selftests/kselftest_module.h`` - ``tools/testing/selftests/kselftest/module.sh`` +Note that test modules should taint the kernel with TAINT_TEST. This will +happen automatically for modules which are in the ``tools/testing/`` +directory, or for modules which use the ``kselftest_module.h`` header above. +Otherwise, you'll need to add ``MODULE_INFO(test, "Y")`` to your module +source. selftests which do not load modules typically should not taint the +kernel, but in cases where a non-test module is loaded, TEST_TAINT can be +applied from userspace by writing to ``/proc/sys/kernel/tainted``. + How to use ---------- @@ -308,6 +341,7 @@ A bare bones test module might look like this: KSTM_MODULE_LOADERS(test_foo); MODULE_AUTHOR("John Developer <jd@fooman.org>"); MODULE_LICENSE("GPL"); + MODULE_INFO(test, "Y"); Example test script ------------------- diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst index 653985ce9cae..cce203138fb7 100644 --- a/Documentation/dev-tools/kunit/run_wrapper.rst +++ b/Documentation/dev-tools/kunit/run_wrapper.rst @@ -192,6 +192,21 @@ via UML. To run tests on qemu, by default it requires two flags: if we have downloaded the microblaze toolchain from the 0-day website to a directory in our home directory called toolchains. +This means that for most architectures, running under qemu is as simple as: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --arch=x86_64 + +When cross-compiling, we'll likely need to specify a different toolchain, for +example: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run \ + --arch=s390 \ + --cross_compile=s390x-linux-gnu- + If we want to run KUnit tests on an architecture not supported by the ``--arch`` flag, or want to run KUnit tests on qemu using a non-default configuration; then we can write our own``QemuConfig``. @@ -214,14 +229,11 @@ as --jobs=12 \ --qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py -To run existing KUnit tests on non-UML architectures, see: -Documentation/dev-tools/kunit/non_uml.rst. - Command-Line Arguments ====================== kunit_tool has a number of other command-line arguments which can -be useful for our test environment. Below the most commonly used +be useful for our test environment. Below are the most commonly used command line arguments: - ``--help``: Lists all available options. To list common options, @@ -245,3 +257,64 @@ command line arguments: added or modified. Instead, enable all tests which have satisfied dependencies by adding ``CONFIG_KUNIT_ALL_TESTS=y`` to your ``.kunitconfig``. + +- ``--kunitconfig``: Specifies the path or the directory of the ``.kunitconfig`` + file. For example: + + - ``lib/kunit/.kunitconfig`` can be the path of the file. + + - ``lib/kunit`` can be the directory in which the file is located. + + This file is used to build and run with a predefined set of tests + and their dependencies. For example, to run tests for a given subsystem. + +- ``--kconfig_add``: Specifies additional configuration options to be + appended to the ``.kunitconfig`` file. For example: + + .. code-block:: + + ./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y + +- ``--arch``: Runs tests on the specified architecture. The architecture + argument is same as the Kbuild ARCH environment variable. + For example, i386, x86_64, arm, um, etc. Non-UML architectures run on qemu. + Default is `um`. + +- ``--cross_compile``: Specifies the Kbuild toolchain. It passes the + same argument as passed to the ``CROSS_COMPILE`` variable used by + Kbuild. This will be the prefix for the toolchain + binaries such as GCC. For example: + + - ``sparc64-linux-gnu-`` if we have the sparc toolchain installed on + our system. + + - ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux`` + if we have downloaded the microblaze toolchain from the 0-day + website to a specified path in our home directory called toolchains. + +- ``--qemu_config``: Specifies the path to a file containing a + custom qemu architecture definition. This should be a python file + containing a `QemuArchParams` object. + +- ``--qemu_args``: Specifies additional qemu arguments, for example, ``-smp 8``. + +- ``--jobs``: Specifies the number of jobs (commands) to run simultaneously. + By default, this is set to the number of cores on your system. + +- ``--timeout``: Specifies the maximum number of seconds allowed for all tests to run. + This does not include the time taken to build the tests. + +- ``--kernel_args``: Specifies additional kernel command-line arguments. May be repeated. + +- ``--run_isolated``: If set, boots the kernel for each individual suite/test. + This is useful for debugging a non-hermetic test, one that + might pass/fail based on what ran before it. + +- ``--raw_output``: If set, generates unformatted output from kernel. Possible options are: + + - ``all``: To view the full kernel output, use ``--raw_output=all``. + + - ``kunit``: This is the default option and filters to KUnit output. Use ``--raw_output`` or ``--raw_output=kunit``. + +- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or + saves to a file if a filename is specified. diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst index c36f6760087d..8e8c493f17d1 100644 --- a/Documentation/dev-tools/kunit/running_tips.rst +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -15,7 +15,7 @@ It can be handy to create a bash function like: .. code-block:: bash function run_kunit() { - ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ ) + ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run "$@" ) } .. note:: @@ -123,8 +123,7 @@ Putting it together into a copy-pastable sequence of commands: .. code-block:: bash # Append coverage options to the current config - $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig - $ ./tools/testing/kunit/kunit.py run + $ ./tools/testing/kunit/kunit.py run --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config # Extract the coverage information from the build dir (.kunit/) $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index d62a04255c2e..44158eecb51e 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -505,7 +505,7 @@ By reusing the same ``cases`` array from above, we can write the test as a const char *str; const char *sha1; }; - struct sha1_test_case cases[] = { + const struct sha1_test_case cases[] = { { .str = "hello world", .sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index c9953f86b19d..1eaccf135b30 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -42,9 +42,7 @@ quiet_cmd_chk_bindings = CHKDT $@ quiet_cmd_mk_schema = SCHEMA $@ cmd_mk_schema = f=$$(mktemp) ; \ - $(if $(DT_MK_SCHEMA_FLAGS), \ - printf '%s\n' $(real-prereqs), \ - $(find_all_cmd)) > $$f ; \ + $(find_all_cmd) > $$f ; \ $(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \ rm -f $$f diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 5e2017c0a051..e6de1d7f516c 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -25,7 +25,14 @@ properties: items: - enum: - altr,socfpga-arria10-socdk - - enclustra,mercury-aa1 + - const: altr,socfpga-arria10 + - const: altr,socfpga + + - description: Mercury+ AA1 boards + items: + - enum: + - google,chameleon-v3 + - const: enclustra,mercury-aa1 - const: altr,socfpga-arria10 - const: altr,socfpga @@ -47,6 +54,7 @@ properties: items: - enum: - altr,socfpga-stratix10-socdk + - altr,socfpga-stratix10-swvp - const: altr,socfpga-stratix10 - description: SoCFPGA VT diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml new file mode 100644 index 000000000000..d783d9276124 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-catu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Coresight Address Translation Unit (CATU) + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The CoreSight Address Translation Unit (CATU) translates addresses between an + AXI master and system memory. The CATU is normally used along with the TMC to + implement scattering of virtual trace buffers in physical memory. The CATU + translates contiguous Virtual Addresses (VAs) from an AXI master into + non-contiguous Physical Addresses (PAs) that are intended for system memory. + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + const: arm,coresight-catu + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-catu + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + interrupts: + maxItems: 1 + description: Address translation error interrupt + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: AXI Slave connected to another Coresight component + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - clocks + - clock-names + - in-ports + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + catu@207e0000 { + compatible = "arm,coresight-catu", "arm,primecell"; + reg = <0x207e0000 0x1000>; + + clocks = <&oscclk6a>; + clock-names = "apb_pclk"; + + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; + in-ports { + port { + catu_in_port: endpoint { + remote-endpoint = <&etr_out_port>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml new file mode 100644 index 000000000000..0a6bc03ebe00 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-cpu-debug.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CoreSight CPU Debug Component + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight CPU debug component are compliant with the ARMv8 architecture + reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The + external debug module is mainly used for two modes: self-hosted debug and + external debug, and it can be accessed from mmio region from Coresight and + eventually the debug module connects with CPU for debugging. And the debug + module provides sample-based profiling extension, which can be used to sample + CPU program counter, secure state and exception level, etc; usually every CPU + has one dedicated debug module to be connected. + +select: + properties: + compatible: + contains: + const: arm,coresight-cpu-debug + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-cpu-debug + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + cpu: + description: + A phandle to the cpu this debug component is bound to. + $ref: /schemas/types.yaml#/definitions/phandle + + power-domains: + maxItems: 1 + description: + A phandle to the debug power domain if the debug logic has its own + dedicated power domain. CPU idle states may also need to be separately + constrained to keep CPU cores powered. + +required: + - compatible + - reg + - clocks + - clock-names + - cpu + +unevaluatedProperties: false + +examples: + - | + debug@f6590000 { + compatible = "arm,coresight-cpu-debug", "arm,primecell"; + reg = <0xf6590000 0x1000>; + clocks = <&sys_ctrl 1>; + clock-names = "apb_pclk"; + cpu = <&cpu0>; + }; +... diff --git a/Documentation/devicetree/bindings/arm/coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml index 21e3515491f4..72ffe4d1e948 100644 --- a/Documentation/devicetree/bindings/arm/coresight-cti.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml @@ -2,7 +2,7 @@ # Copyright 2019 Linaro Ltd. %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/coresight-cti.yaml# +$id: http://devicetree.org/schemas/arm/arm,coresight-cti.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: ARM Coresight Cross Trigger Interface (CTI) device. @@ -12,8 +12,7 @@ description: | to one or more CoreSight components and/or a CPU, with CTIs interconnected in a star topology via the Cross Trigger Matrix (CTM), which is not programmable. The ECT components are not part of the trace generation data path and are thus - not part of the CoreSight graph described in the general CoreSight bindings - file coresight.txt. + not part of the CoreSight graph. The CTI component properties define the connections between the individual CTI and the components it is directly connected to, consisting of input and diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml new file mode 100644 index 000000000000..1eeedc22857c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-dynamic-funnel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Programmable Trace Bus Funnel + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Coresight funnel merges 2-8 trace sources into a single trace + stream with programmable enable and priority of input ports. + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + const: arm,coresight-dynamic-funnel + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-dynamic-funnel + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + '^port(@[0-7])?$': + description: Input connections from CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Output connection to CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - clocks + - clock-names + - in-ports + - out-ports + +unevaluatedProperties: false + +examples: + - | + funnel@20040000 { + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; + reg = <0x20040000 0x1000>; + + clocks = <&oscclk6a>; + clock-names = "apb_pclk"; + out-ports { + port { + funnel_out_port0: endpoint { + remote-endpoint = <&replicator_in_port0>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + funnel_in_port0: endpoint { + remote-endpoint = <&ptm0_out_port>; + }; + }; + + port@1 { + reg = <1>; + funnel_in_port1: endpoint { + remote-endpoint = <&ptm1_out_port>; + }; + }; + + port@2 { + reg = <2>; + funnel_in_port2: endpoint { + remote-endpoint = <&etm0_out_port>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml new file mode 100644 index 000000000000..a26ed9214e00 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-dynamic-replicator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Coresight Programmable Trace Bus Replicator + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Coresight replicator splits a single trace stream into two trace streams + for systems that have more than one trace sink component. + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + const: arm,coresight-dynamic-replicator + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-dynamic-replicator + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + qcom,replicator-loses-context: + type: boolean + description: + Indicates that the replicator will lose register context when AMBA clock + is removed which is observed in some replicator designs. + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Input connection from CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + '^port(@[01])?$': + description: Output connections to CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - clocks + - clock-names + - in-ports + - out-ports + +unevaluatedProperties: false + +examples: + - | + replicator@20120000 { + compatible = "arm,coresight-dynamic-replicator", "arm,primecell"; + reg = <0x20120000 0x1000>; + + clocks = <&soc_smc50mhz>; + clock-names = "apb_pclk"; + + out-ports { + #address-cells = <1>; + #size-cells = <0>; + + /* replicator output ports */ + port@0 { + reg = <0>; + replicator_out_port0: endpoint { + remote-endpoint = <&tpiu_in_port>; + }; + }; + + port@1 { + reg = <1>; + replicator_out_port1: endpoint { + remote-endpoint = <&etr_in_port>; + }; + }; + }; + in-ports { + port { + replicator_in_port0: endpoint { + remote-endpoint = <&csys2_funnel_out_port>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml new file mode 100644 index 000000000000..fd06ede26ceb --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-etb10.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Embedded Trace Buffer + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The CoreSight Embedded Trace Buffer stores traces in a dedicated SRAM that is + used as a circular buffer. + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + const: arm,coresight-etb10 + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-etb10 + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Input connection from CoreSight Trace bus. + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - clocks + - clock-names + - in-ports + +unevaluatedProperties: false + +examples: + - | + etb@20010000 { + compatible = "arm,coresight-etb10", "arm,primecell"; + reg = <0x20010000 0x1000>; + + clocks = <&oscclk6a>; + clock-names = "apb_pclk"; + in-ports { + port { + etb_in_port: endpoint { + remote-endpoint = <&replicator_out_port0>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml new file mode 100644 index 000000000000..e0377ce48537 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml @@ -0,0 +1,156 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-etm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Embedded Trace MacroCell + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Embedded Trace Macrocell (ETM) is a real-time trace module providing + instruction and data tracing of a processor. + +select: + properties: + compatible: + contains: + enum: + - arm,coresight-etm3x + - arm,coresight-etm4x + - arm,coresight-etm4x-sysreg + required: + - compatible + +allOf: + - if: + not: + properties: + compatible: + contains: + const: arm,coresight-etm4x-sysreg + then: + $ref: /schemas/arm/primecell.yaml# + required: + - reg + +properties: + compatible: + oneOf: + - description: + Embedded Trace Macrocell with memory mapped access. + items: + - enum: + - arm,coresight-etm3x + - arm,coresight-etm4x + - const: arm,primecell + - description: + Embedded Trace Macrocell (version 4.x), with system register access only + const: arm,coresight-etm4x-sysreg + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + arm,coresight-loses-context-with-cpu: + type: boolean + description: + Indicates that the hardware will lose register context on CPU power down + (e.g. CPUIdle). An example of where this may be needed are systems which + contain a coresight component and CPU in the same power domain. When the + CPU powers down the coresight component also powers down and loses its + context. + + arm,cp14: + type: boolean + description: + Must be present if the system accesses ETM/PTM management registers via + co-processor 14. + + qcom,skip-power-up: + type: boolean + description: + Indicates that an implementation can skip powering up the trace unit. + TRCPDCR.PU does not have to be set on Qualcomm Technologies Inc. systems + since ETMs are in the same power domain as their CPU cores. This property + is required to identify such systems with hardware errata where the CPU + watchdog counter is stopped when TRCPDCR.PU is set. + + cpu: + description: + phandle to the cpu this ETM is bound to. + $ref: /schemas/types.yaml#/definitions/phandle + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Output connection from the ETM to CoreSight Trace bus. + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - clocks + - clock-names + - cpu + - out-ports + +unevaluatedProperties: false + +examples: + - | + ptm@2201c000 { + compatible = "arm,coresight-etm3x", "arm,primecell"; + reg = <0x2201c000 0x1000>; + + cpu = <&cpu0>; + clocks = <&oscclk6a>; + clock-names = "apb_pclk"; + out-ports { + port { + ptm0_out_port: endpoint { + remote-endpoint = <&funnel_in_port0>; + }; + }; + }; + }; + + ptm@2201d000 { + compatible = "arm,coresight-etm3x", "arm,primecell"; + reg = <0x2201d000 0x1000>; + + cpu = <&cpu1>; + clocks = <&oscclk6a>; + clock-names = "apb_pclk"; + out-ports { + port { + ptm1_out_port: endpoint { + remote-endpoint = <&funnel_in_port1>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml new file mode 100644 index 000000000000..374083956b20 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-static-funnel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Static Trace Bus Funnel + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Coresight static funnel merges 2-8 trace sources into a single trace + stream. + +properties: + compatible: + const: arm,coresight-static-funnel + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + '^port@[0-7]$': + description: Input connections from CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Output connection to CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - in-ports + - out-ports + +additionalProperties: false + +examples: + - | + funnel { + /* + * non-configurable replicators don't show up on the + * AMBA bus. As such no need to add "arm,primecell". + */ + compatible = "arm,coresight-static-funnel"; + + out-ports { + port { + combo_funnel_out: endpoint { + remote-endpoint = <&top_funnel_in>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + combo_funnel_in0: endpoint { + remote-endpoint = <&cluster0_etf_out>; + }; + }; + + port@1 { + reg = <1>; + combo_funnel_in1: endpoint { + remote-endpoint = <&cluster1_etf_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml new file mode 100644 index 000000000000..a34d8583830c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-static-replicator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Static Trace Bus Replicator + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The Coresight replicator splits a single trace stream into two trace streams + for systems that have more than one trace sink component. + +properties: + compatible: + const: arm,coresight-static-replicator + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Input connection from CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + '^port@[01]$': + description: Output connections to CoreSight Trace bus + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - in-ports + - out-ports + +additionalProperties: false + +examples: + - | + replicator { + /* + * non-configurable replicators don't show up on the + * AMBA bus. As such no need to add "arm,primecell". + */ + compatible = "arm,coresight-static-replicator"; + + out-ports { + #address-cells = <1>; + #size-cells = <0>; + + /* replicator output ports */ + port@0 { + reg = <0>; + replicator_out_port0: endpoint { + remote-endpoint = <&etb_in_port>; + }; + }; + + port@1 { + reg = <1>; + replicator_out_port1: endpoint { + remote-endpoint = <&tpiu_in_port>; + }; + }; + }; + + in-ports { + port { + replicator_in_port0: endpoint { + remote-endpoint = <&funnel_out_port0>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml new file mode 100644 index 000000000000..905008faa012 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-stm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight System Trace MacroCell + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The STM is a trace source that is integrated into a CoreSight system, designed + primarily for high-bandwidth trace of instrumentation embedded into software. + This instrumentation is made up of memory-mapped writes to the STM Advanced + eXtensible Interface (AXI) slave, which carry information about the behavior + of the software. + +select: + properties: + compatible: + contains: + const: arm,coresight-stm + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-stm + - const: arm,primecell + + reg: + maxItems: 2 + + reg-names: + items: + - const: stm-base + - const: stm-stimulus-base + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Output connection to the CoreSight Trace bus. + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - out-ports + +unevaluatedProperties: false + +examples: + - | + stm@20100000 { + compatible = "arm,coresight-stm", "arm,primecell"; + reg = <0x20100000 0x1000>, + <0x28000000 0x180000>; + reg-names = "stm-base", "stm-stimulus-base"; + + clocks = <&soc_smc50mhz>; + clock-names = "apb_pclk"; + out-ports { + port { + stm_out_port: endpoint { + remote-endpoint = <&main_funnel_in_port2>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml new file mode 100644 index 000000000000..3463b6e53aef --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-tmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Trace Memory Controller + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + Trace Memory Controller is used for Embedded Trace Buffer(ETB), Embedded Trace + FIFO(ETF) and Embedded Trace Router(ETR) configurations. The configuration + mode (ETB, ETF, ETR) is discovered at boot time when the device is probed. + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + const: arm,coresight-tmc + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-tmc + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + arm,buffer-size: + $ref: /schemas/types.yaml#/definitions/uint32 + deprecated: true + description: + Size of contiguous buffer space for TMC ETR (embedded trace router). The + buffer size can be configured dynamically via buffer_size property in + sysfs instead. + + arm,scatter-gather: + type: boolean + description: + Indicates that the TMC-ETR can safely use the SG mode on this system. + + arm,max-burst-size: + description: + The maximum burst size initiated by TMC on the AXI master interface. The + burst size can be in the range [0..15], the setting supports one data + transfer per burst up to a maximum of 16 data transfers per burst. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Input connection from the CoreSight Trace bus. + $ref: /schemas/graph.yaml#/properties/port + + out-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: AXI or ATB Master output connection. Used for ETR + and ETF configurations. + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - clocks + - clock-names + - in-ports + +unevaluatedProperties: false + +examples: + - | + etr@20070000 { + compatible = "arm,coresight-tmc", "arm,primecell"; + reg = <0x20070000 0x1000>; + + clocks = <&oscclk6a>; + clock-names = "apb_pclk"; + in-ports { + port { + etr_in_port: endpoint { + remote-endpoint = <&replicator2_out_port0>; + }; + }; + }; + + out-ports { + port { + etr_out_port: endpoint { + remote-endpoint = <&catu_in_port>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml new file mode 100644 index 000000000000..e80d48200c37 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,coresight-tpiu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm CoreSight Trace Port Interface Unit + +maintainers: + - Mathieu Poirier <mathieu.poirier@linaro.org> + - Mike Leach <mike.leach@linaro.org> + - Leo Yan <leo.yan@linaro.org> + - Suzuki K Poulose <suzuki.poulose@arm.com> + +description: | + CoreSight components are compliant with the ARM CoreSight architecture + specification and can be connected in various topologies to suit a particular + SoCs tracing needs. These trace components can generally be classified as + sinks, links and sources. Trace data produced by one or more sources flows + through the intermediate links connecting the source to the currently selected + sink. + + The CoreSight Trace Port Interface Unit captures trace data from the trace bus + and outputs it to an external trace port. + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + const: arm,coresight-tpiu + required: + - compatible + +allOf: + - $ref: /schemas/arm/primecell.yaml# + +properties: + compatible: + items: + - const: arm,coresight-tpiu + - const: arm,primecell + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: apb_pclk + - const: atclk + + in-ports: + $ref: /schemas/graph.yaml#/properties/ports + additionalProperties: false + + properties: + port: + description: Input connection from the CoreSight Trace bus. + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - clocks + - clock-names + - in-ports + +unevaluatedProperties: false + +examples: + - | + tpiu@e3c05000 { + compatible = "arm,coresight-tpiu", "arm,primecell"; + reg = <0xe3c05000 0x1000>; + + clocks = <&clk_375m>; + clock-names = "apb_pclk"; + in-ports { + port { + tpiu_in_port: endpoint { + remote-endpoint = <&funnel4_out_port0>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/ete.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml index 7f9b2d1e1147..5f07fb166c56 100644 --- a/Documentation/devicetree/bindings/arm/ete.yaml +++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml @@ -2,7 +2,7 @@ # Copyright 2021, Arm Ltd %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/ete.yaml#" +$id: "http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: ARM Embedded Trace Extensions @@ -20,7 +20,6 @@ description: | Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to legacy CoreSight components, a node must be listed per instance, along with any optional connection graph as per the coresight bindings. - See bindings/arm/coresight.txt. properties: $nodename: diff --git a/Documentation/devicetree/bindings/arm/trbe.yaml b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml index 4402d7bfd1fc..b1322658063a 100644 --- a/Documentation/devicetree/bindings/arm/trbe.yaml +++ b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml @@ -2,7 +2,7 @@ # Copyright 2021, Arm Ltd %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/trbe.yaml#" +$id: "http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: ARM Trace Buffer Extensions diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml new file mode 100644 index 000000000000..1895ce9de461 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/aspeed/aspeed.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aspeed SoC based boards + +maintainers: + - Joel Stanley <joel@jms.id.au> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: AST2400 based boards + items: + - enum: + - facebook,galaxy100-bmc + - facebook,wedge100-bmc + - facebook,wedge40-bmc + - microsoft,olympus-bmc + - quanta,q71l-bmc + - tyan,palmetto-bmc + - yadro,vesnin-bmc + - const: aspeed,ast2400 + + - description: AST2500 based boards + items: + - enum: + - amd,ethanolx-bmc + - ampere,mtjade-bmc + - aspeed,ast2500-evb + - asrock,e3c246d4i-bmc + - asrock,romed8hm3-bmc + - bytedance,g220a-bmc + - facebook,cmm-bmc + - facebook,minipack-bmc + - facebook,tiogapass-bmc + - facebook,yamp-bmc + - facebook,yosemitev2-bmc + - facebook,wedge400-bmc + - hxt,stardragon4800-rep2-bmc + - ibm,mihawk-bmc + - ibm,mowgli-bmc + - ibm,romulus-bmc + - ibm,swift-bmc + - ibm,witherspoon-bmc + - ingrasys,zaius-bmc + - inspur,fp5280g2-bmc + - inspur,nf5280m6-bmc + - inspur,on5263m5-bmc + - intel,s2600wf-bmc + - inventec,lanyang-bmc + - lenovo,hr630-bmc + - lenovo,hr855xg2-bmc + - portwell,neptune-bmc + - qcom,centriq2400-rep-bmc + - supermicro,x11spi-bmc + - tyan,s7106-bmc + - tyan,s8036-bmc + - yadro,nicole-bmc + - yadro,vegman-n110-bmc + - yadro,vegman-rx20-bmc + - yadro,vegman-sx20-bmc + - const: aspeed,ast2500 + + - description: AST2600 based boards + items: + - enum: + - aspeed,ast2600-evb + - aspeed,ast2600-evb-a1 + - facebook,bletchley-bmc + - facebook,cloudripper-bmc + - facebook,elbert-bmc + - facebook,fuji-bmc + - ibm,everest-bmc + - ibm,rainier-bmc + - ibm,tacoma-bmc + - inventec,transformer-bmc + - jabil,rbp-bmc + - nuvia,dc-scm-bmc + - quanta,s6q-bmc + - const: aspeed,ast2600 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 4e495e03264b..2b7848bb7769 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -163,9 +163,11 @@ properties: - const: microchip,sama7g5 - const: microchip,sama7 - - description: Microchip LAN9662 PCB8291 Evaluation Board. + - description: Microchip LAN9662 Evaluation Boards. items: - - const: microchip,lan9662-pcb8291 + - enum: + - microchip,lan9662-pcb8291 + - microchip,lan9662-pcb8309 - const: microchip,lan9662 - const: microchip,lan966 diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 16eef600d599..ab1b352344ae 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -25,21 +25,6 @@ System Timer (ST) required properties: Its subnodes can be: - watchdog: compatible should be "atmel,at91rm9200-wdt" -RSTC Reset Controller required properties: -- compatible: Should be "atmel,<chip>-rstc". - <chip> can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7" - it also can be "microchip,sam9x60-rstc" -- reg: Should contain registers location and length -- clocks: phandle to input clock. - -Example: - - rstc@fffffd00 { - compatible = "atmel,at91sam9260-rstc"; - reg = <0xfffffd00 0x10>; - clocks = <&clk32k>; - }; - RAMC SDRAM/DDR Controller required properties: - compatible: Should be "atmel,at91rm9200-sdramc", "syscon" "atmel,at91sam9260-sdramc", diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml index 8b7e87fb6c34..958df32b4899 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml @@ -87,6 +87,13 @@ properties: - const: brcm,bcm53012 - const: brcm,bcm4708 + - description: BCM53015 based boards + items: + - enum: + - meraki,mr26 + - const: brcm,bcm53015 + - const: brcm,bcm4708 + - description: BCM53016 based boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml index 5fb455840417..324e59104360 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml @@ -28,6 +28,99 @@ properties: - const: brcm,bcm47622 - const: brcm,bcmbca + - description: BCM4912 based boards + items: + - enum: + - asus,gt-ax6000 + - brcm,bcm94912 + - const: brcm,bcm4912 + - const: brcm,bcmbca + + - description: BCM63138 based boards + items: + - enum: + - brcm,bcm963138 + - brcm,BCM963138DVT + - const: brcm,bcm63138 + - const: brcm,bcmbca + + - description: BCM63146 based boards + items: + - enum: + - brcm,bcm963146 + - const: brcm,bcm63146 + - const: brcm,bcmbca + + - description: BCM63148 based boards + items: + - enum: + - brcm,bcm963148 + - const: brcm,bcm63148 + - const: brcm,bcmbca + + - description: BCM63158 based boards + items: + - enum: + - brcm,bcm963158 + - const: brcm,bcm63158 + - const: brcm,bcmbca + + - description: BCM63178 based boards + items: + - enum: + - brcm,bcm963178 + - const: brcm,bcm63178 + - const: brcm,bcmbca + + - description: BCM6756 based boards + items: + - enum: + - brcm,bcm96756 + - const: brcm,bcm6756 + - const: brcm,bcmbca + + - description: BCM6813 based boards + items: + - enum: + - brcm,bcm96813 + - const: brcm,bcm6813 + - const: brcm,bcmbca + + - description: BCM6846 based boards + items: + - enum: + - brcm,bcm96846 + - const: brcm,bcm6846 + - const: brcm,bcmbca + + - description: BCM6855 based boards + items: + - enum: + - brcm,bcm96855 + - const: brcm,bcm6855 + - const: brcm,bcmbca + + - description: BCM6856 based boards + items: + - enum: + - brcm,bcm96856 + - const: brcm,bcm6856 + - const: brcm,bcmbca + + - description: BCM6858 based boards + items: + - enum: + - brcm,bcm96858 + - const: brcm,bcm6858 + - const: brcm,bcmbca + + - description: BCM6878 based boards + items: + - enum: + - brcm,bcm96878 + - const: brcm,bcm6878 + - const: brcm,bcmbca + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt b/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt deleted file mode 100644 index f1de3247c1b7..000000000000 --- a/Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt +++ /dev/null @@ -1,49 +0,0 @@ -* CoreSight CPU Debug Component: - -CoreSight CPU debug component are compliant with the ARMv8 architecture -reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The -external debug module is mainly used for two modes: self-hosted debug and -external debug, and it can be accessed from mmio region from Coresight -and eventually the debug module connects with CPU for debugging. And the -debug module provides sample-based profiling extension, which can be used -to sample CPU program counter, secure state and exception level, etc; -usually every CPU has one dedicated debug module to be connected. - -Required properties: - -- compatible : should be "arm,coresight-cpu-debug"; supplemented with - "arm,primecell" since this driver is using the AMBA bus - interface. - -- reg : physical base address and length of the register set. - -- clocks : the clock associated to this component. - -- clock-names : the name of the clock referenced by the code. Since we are - using the AMBA framework, the name of the clock providing - the interconnect should be "apb_pclk" and the clock is - mandatory. The interface between the debug logic and the - processor core is clocked by the internal CPU clock, so it - is enabled with CPU clock by default. - -- cpu : the CPU phandle the debug module is affined to. Do not assume it - to default to CPU0 if omitted. - -Optional properties: - -- power-domains: a phandle to the debug power domain. We use "power-domains" - binding to turn on the debug logic if it has own dedicated - power domain and if necessary to use "cpuidle.off=1" or - "nohlt" in the kernel command line or sysfs node to - constrain idle states to ensure registers in the CPU power - domain are accessible. - -Example: - - debug@f6590000 { - compatible = "arm,coresight-cpu-debug","arm,primecell"; - reg = <0 0xf6590000 0 0x1000>; - clocks = <&sys_ctrl HI6220_DAPB_CLK>; - clock-names = "apb_pclk"; - cpu = <&cpu0>; - }; diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt deleted file mode 100644 index c68d93a35b6c..000000000000 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ /dev/null @@ -1,402 +0,0 @@ -* CoreSight Components: - -CoreSight components are compliant with the ARM CoreSight architecture -specification and can be connected in various topologies to suit a particular -SoCs tracing needs. These trace components can generally be classified as -sinks, links and sources. Trace data produced by one or more sources flows -through the intermediate links connecting the source to the currently selected -sink. Each CoreSight component device should use these properties to describe -its hardware characteristcs. - -* Required properties for all components *except* non-configurable replicators - and non-configurable funnels: - - * compatible: These have to be supplemented with "arm,primecell" as - drivers are using the AMBA bus interface. Possible values include: - - Embedded Trace Buffer (version 1.0): - "arm,coresight-etb10", "arm,primecell"; - - - Trace Port Interface Unit: - "arm,coresight-tpiu", "arm,primecell"; - - - Trace Memory Controller, used for Embedded Trace Buffer(ETB), - Embedded Trace FIFO(ETF) and Embedded Trace Router(ETR) - configuration. The configuration mode (ETB, ETF, ETR) is - discovered at boot time when the device is probed. - "arm,coresight-tmc", "arm,primecell"; - - - Trace Programmable Funnel: - "arm,coresight-dynamic-funnel", "arm,primecell"; - "arm,coresight-funnel", "arm,primecell"; (OBSOLETE. For - backward compatibility and will be removed) - - - Embedded Trace Macrocell (version 3.x) and - Program Flow Trace Macrocell: - "arm,coresight-etm3x", "arm,primecell"; - - - Embedded Trace Macrocell (version 4.x), with memory mapped access. - "arm,coresight-etm4x", "arm,primecell"; - - - Embedded Trace Macrocell (version 4.x), with system register access only. - "arm,coresight-etm4x-sysreg"; - - - Coresight programmable Replicator : - "arm,coresight-dynamic-replicator", "arm,primecell"; - - - System Trace Macrocell: - "arm,coresight-stm", "arm,primecell"; [1] - - Coresight Address Translation Unit (CATU) - "arm,coresight-catu", "arm,primecell"; - - - Coresight Cross Trigger Interface (CTI): - "arm,coresight-cti", "arm,primecell"; - See coresight-cti.yaml for full CTI definitions. - - * reg: physical base address and length of the register - set(s) of the component. - - * clocks: the clocks associated to this component. - - * clock-names: the name of the clocks referenced by the code. - Since we are using the AMBA framework, the name of the clock - providing the interconnect should be "apb_pclk", and some - coresight blocks also have an additional clock "atclk", which - clocks the core of that coresight component. The latter clock - is optional. - - * port or ports: see "Graph bindings for Coresight" below. - -* Additional required property for Embedded Trace Macrocell (version 3.x and - version 4.x): - * cpu: the cpu phandle this ETM/PTM is affined to. Do not - assume it to default to CPU0 if omitted. - -* Additional required properties for System Trace Macrocells (STM): - * reg: along with the physical base address and length of the register - set as described above, another entry is required to describe the - mapping of the extended stimulus port area. - - * reg-names: the only acceptable values are "stm-base" and - "stm-stimulus-base", each corresponding to the areas defined in "reg". - -* Required properties for Coresight Cross Trigger Interface (CTI) - See coresight-cti.yaml for full CTI definitions. - -* Required properties for devices that don't show up on the AMBA bus, such as - non-configurable replicators and non-configurable funnels: - - * compatible: Currently supported value is (note the absence of the - AMBA markee): - - Coresight Non-configurable Replicator: - "arm,coresight-static-replicator"; - "arm,coresight-replicator"; (OBSOLETE. For backward - compatibility and will be removed) - - - Coresight Non-configurable Funnel: - "arm,coresight-static-funnel"; - - * port or ports: see "Graph bindings for Coresight" below. - -* Optional properties for all components: - - * arm,coresight-loses-context-with-cpu : boolean. Indicates that the - hardware will lose register context on CPU power down (e.g. CPUIdle). - An example of where this may be needed are systems which contain a - coresight component and CPU in the same power domain. When the CPU - powers down the coresight component also powers down and loses its - context. This property is currently only used for the ETM 4.x driver. - -* Optional properties for ETM/PTMs: - - * arm,cp14: must be present if the system accesses ETM/PTM management - registers via co-processor 14. - - * qcom,skip-power-up: boolean. Indicates that an implementation can - skip powering up the trace unit. TRCPDCR.PU does not have to be set - on Qualcomm Technologies Inc. systems since ETMs are in the same power - domain as their CPU cores. This property is required to identify such - systems with hardware errata where the CPU watchdog counter is stopped - when TRCPDCR.PU is set. - -* Optional property for TMC: - - * arm,buffer-size: size of contiguous buffer space for TMC ETR - (embedded trace router). This property is obsolete. The buffer size - can be configured dynamically via buffer_size property in sysfs. - - * arm,scatter-gather: boolean. Indicates that the TMC-ETR can safely - use the SG mode on this system. - - * arm,max-burst-size: The maximum burst size initiated by TMC on the - AXI master interface. The burst size can be in the range [0..15], - the setting supports one data transfer per burst up to a maximum of - 16 data transfers per burst. - -* Optional property for CATU : - * interrupts : Exactly one SPI may be listed for reporting the address - error - -* Optional property for configurable replicators: - - * qcom,replicator-loses-context: boolean. Indicates that the replicator - will lose register context when AMBA clock is removed which is observed - in some replicator designs. - -Graph bindings for Coresight -------------------------------- - -Coresight components are interconnected to create a data path for the flow of -trace data generated from the "sources" to their collection points "sink". -Each coresight component must describe the "input" and "output" connections. -The connections must be described via generic DT graph bindings as described -by the "bindings/graph.txt", where each "port" along with an "endpoint" -component represents a hardware port and the connection. - - * All output ports must be listed inside a child node named "out-ports" - * All input ports must be listed inside a child node named "in-ports". - * Port address must match the hardware port number. - -Example: - -1. Sinks - etb@20010000 { - compatible = "arm,coresight-etb10", "arm,primecell"; - reg = <0 0x20010000 0 0x1000>; - - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - in-ports { - port { - etb_in_port: endpoint@0 { - remote-endpoint = <&replicator_out_port0>; - }; - }; - }; - }; - - tpiu@20030000 { - compatible = "arm,coresight-tpiu", "arm,primecell"; - reg = <0 0x20030000 0 0x1000>; - - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - in-ports { - port { - tpiu_in_port: endpoint@0 { - remote-endpoint = <&replicator_out_port1>; - }; - }; - }; - }; - - etr@20070000 { - compatible = "arm,coresight-tmc", "arm,primecell"; - reg = <0 0x20070000 0 0x1000>; - - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - in-ports { - port { - etr_in_port: endpoint { - remote-endpoint = <&replicator2_out_port0>; - }; - }; - }; - - out-ports { - port { - etr_out_port: endpoint { - remote-endpoint = <&catu_in_port>; - }; - }; - }; - }; - -2. Links - replicator { - /* non-configurable replicators don't show up on the - * AMBA bus. As such no need to add "arm,primecell". - */ - compatible = "arm,coresight-static-replicator"; - - out-ports { - #address-cells = <1>; - #size-cells = <0>; - - /* replicator output ports */ - port@0 { - reg = <0>; - replicator_out_port0: endpoint { - remote-endpoint = <&etb_in_port>; - }; - }; - - port@1 { - reg = <1>; - replicator_out_port1: endpoint { - remote-endpoint = <&tpiu_in_port>; - }; - }; - }; - - in-ports { - port { - replicator_in_port0: endpoint { - remote-endpoint = <&funnel_out_port0>; - }; - }; - }; - }; - - funnel { - /* - * non-configurable funnel don't show up on the AMBA - * bus. As such no need to add "arm,primecell". - */ - compatible = "arm,coresight-static-funnel"; - clocks = <&crg_ctrl HI3660_PCLK>; - clock-names = "apb_pclk"; - - out-ports { - port { - combo_funnel_out: endpoint { - remote-endpoint = <&top_funnel_in>; - }; - }; - }; - - in-ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - combo_funnel_in0: endpoint { - remote-endpoint = <&cluster0_etf_out>; - }; - }; - - port@1 { - reg = <1>; - combo_funnel_in1: endpoint { - remote-endpoint = <&cluster1_etf_out>; - }; - }; - }; - }; - - funnel@20040000 { - compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; - reg = <0 0x20040000 0 0x1000>; - - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - out-ports { - port { - funnel_out_port0: endpoint { - remote-endpoint = - <&replicator_in_port0>; - }; - }; - }; - - in-ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - funnel_in_port0: endpoint { - remote-endpoint = <&ptm0_out_port>; - }; - }; - - port@1 { - reg = <1>; - funnel_in_port1: endpoint { - remote-endpoint = <&ptm1_out_port>; - }; - }; - - port@2 { - reg = <2>; - funnel_in_port2: endpoint { - remote-endpoint = <&etm0_out_port>; - }; - }; - - }; - }; - -3. Sources - ptm@2201c000 { - compatible = "arm,coresight-etm3x", "arm,primecell"; - reg = <0 0x2201c000 0 0x1000>; - - cpu = <&cpu0>; - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - out-ports { - port { - ptm0_out_port: endpoint { - remote-endpoint = <&funnel_in_port0>; - }; - }; - }; - }; - - ptm@2201d000 { - compatible = "arm,coresight-etm3x", "arm,primecell"; - reg = <0 0x2201d000 0 0x1000>; - - cpu = <&cpu1>; - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - out-ports { - port { - ptm1_out_port: endpoint { - remote-endpoint = <&funnel_in_port1>; - }; - }; - }; - }; - -4. STM - stm@20100000 { - compatible = "arm,coresight-stm", "arm,primecell"; - reg = <0 0x20100000 0 0x1000>, - <0 0x28000000 0 0x180000>; - reg-names = "stm-base", "stm-stimulus-base"; - - clocks = <&soc_smc50mhz>; - clock-names = "apb_pclk"; - out-ports { - port { - stm_out_port: endpoint { - remote-endpoint = <&main_funnel_in_port2>; - }; - }; - }; - }; - -5. CATU - - catu@207e0000 { - compatible = "arm,coresight-catu", "arm,primecell"; - reg = <0 0x207e0000 0 0x1000>; - - clocks = <&oscclk6a>; - clock-names = "apb_pclk"; - - interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; - in-ports { - port { - catu_in_port: endpoint { - remote-endpoint = <&etr_out_port>; - }; - }; - }; - }; - -[1]. There is currently two version of STM: STM32 and STM500. Both -have the same HW interface and as such don't need an explicit binding name. diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index ed04650291a8..a07c5bac7c46 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -138,6 +138,7 @@ properties: - arm,cortex-a76 - arm,cortex-a77 - arm,cortex-a78 + - arm,cortex-a78ae - arm,cortex-a510 - arm,cortex-a710 - arm,cortex-m0 @@ -221,6 +222,7 @@ properties: - qcom,kpss-acc-v1 - qcom,kpss-acc-v2 - qcom,msm8226-smp + - qcom,msm8909-smp # Only valid on ARM 32-bit, see above for ARM v8 64-bit - qcom,msm8916-smp - renesas,apmu diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt deleted file mode 100644 index a87ec15e28d2..000000000000 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ /dev/null @@ -1,271 +0,0 @@ -NXP i.MX System Controller Firmware (SCFW) --------------------------------------------------------------------- - -The System Controller Firmware (SCFW) is a low-level system function -which runs on a dedicated Cortex-M core to provide power, clock, and -resource management. It exists on some i.MX8 processors. e.g. i.MX8QM -(QM, QP), and i.MX8QX (QXP, DX). - -The AP communicates with the SC using a multi-ported MU module found -in the LSIO subsystem. The current definition of this MU module provides -5 remote AP connections to the SC to support up to 5 execution environments -(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces -with the LSIO DSC IP bus. The SC firmware will communicate with this MU -using the MSI bus. - -System Controller Device Node: -============================================================ - -The scu node with the following properties shall be under the /firmware/ node. - -Required properties: -------------------- -- compatible: should be "fsl,imx-scu". -- mbox-names: should include "tx0", "tx1", "tx2", "tx3", - "rx0", "rx1", "rx2", "rx3"; - include "gip3" if want to support general MU interrupt. -- mboxes: List of phandle of 4 MU channels for tx, 4 MU channels for - rx, and 1 optional MU channel for general interrupt. - All MU channels must be in the same MU instance. - Cross instances are not allowed. The MU instance can only - be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need - to make sure use the one which is not conflict with other - execution environments. e.g. ATF. - Note: - Channel 0 must be "tx0" or "rx0". - Channel 1 must be "tx1" or "rx1". - Channel 2 must be "tx2" or "rx2". - Channel 3 must be "tx3" or "rx3". - General interrupt rx channel must be "gip3". - e.g. - mboxes = <&lsio_mu1 0 0 - &lsio_mu1 0 1 - &lsio_mu1 0 2 - &lsio_mu1 0 3 - &lsio_mu1 1 0 - &lsio_mu1 1 1 - &lsio_mu1 1 2 - &lsio_mu1 1 3 - &lsio_mu1 3 3>; - See Documentation/devicetree/bindings/mailbox/fsl,mu.yaml - for detailed mailbox binding. - -Note: Each mu which supports general interrupt should have an alias correctly -numbered in "aliases" node. -e.g. -aliases { - mu1 = &lsio_mu1; -}; - -i.MX SCU Client Device Node: -============================================================ - -Client nodes are maintained as children of the relevant IMX-SCU device node. - -Power domain bindings based on SCU Message Protocol ------------------------------------------------------------- - -This binding for the SCU power domain providers uses the generic power -domain binding[2]. - -Required properties: -- compatible: Should be one of: - "fsl,imx8qm-scu-pd", - "fsl,imx8qxp-scu-pd" - followed by "fsl,scu-pd" - -- #power-domain-cells: Must be 1. Contains the Resource ID used by - SCU commands. - See detailed Resource ID list from: - include/dt-bindings/firmware/imx/rsrc.h - -Clock bindings based on SCU Message Protocol ------------------------------------------------------------- - -This binding uses the common clock binding[1]. - -Required properties: -- compatible: Should be one of: - "fsl,imx8dxl-clk" - "fsl,imx8qm-clk" - "fsl,imx8qxp-clk" - followed by "fsl,scu-clk" -- #clock-cells: Should be 2. - Contains the Resource and Clock ID value. -- clocks: List of clock specifiers, must contain an entry for - each required entry in clock-names -- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz" - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. - -See the full list of clock IDs from: -include/dt-bindings/clock/imx8qxp-clock.h - -Pinctrl bindings based on SCU Message Protocol ------------------------------------------------------------- - -This binding uses the i.MX common pinctrl binding[3]. - -Required properties: -- compatible: Should be one of: - "fsl,imx8qm-iomuxc", - "fsl,imx8qxp-iomuxc", - "fsl,imx8dxl-iomuxc". - -Required properties for Pinctrl sub nodes: -- fsl,pins: Each entry consists of 3 integers which represents - the mux and config setting for one pin. The first 2 - integers <pin_id mux_mode> are specified using a - PIN_FUNC_ID macro, which can be found in - <dt-bindings/pinctrl/pads-imx8qm.h>, - <dt-bindings/pinctrl/pads-imx8qxp.h>, - <dt-bindings/pinctrl/pads-imx8dxl.h>. - The last integer CONFIG is the pad setting value like - pull-up on this pin. - - Please refer to i.MX8QXP Reference Manual for detailed - CONFIG settings. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt - -RTC bindings based on SCU Message Protocol ------------------------------------------------------------- - -Required properties: -- compatible: should be "fsl,imx8qxp-sc-rtc"; - -OCOTP bindings based on SCU Message Protocol ------------------------------------------------------------- -Required properties: -- compatible: Should be one of: - "fsl,imx8qm-scu-ocotp", - "fsl,imx8qxp-scu-ocotp". -- #address-cells: Must be 1. Contains byte index -- #size-cells: Must be 1. Contains byte length - -Optional Child nodes: - -- Data cells of ocotp: - Detailed bindings are described in bindings/nvmem/nvmem.txt - -Watchdog bindings based on SCU Message Protocol ------------------------------------------------------------- - -Required properties: -- compatible: should be: - "fsl,imx8qxp-sc-wdt" - followed by "fsl,imx-sc-wdt"; -Optional properties: -- timeout-sec: contains the watchdog timeout in seconds. - -SCU key bindings based on SCU Message Protocol ------------------------------------------------------------- - -Required properties: -- compatible: should be: - "fsl,imx8qxp-sc-key" - followed by "fsl,imx-sc-key"; -- linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml - -Thermal bindings based on SCU Message Protocol ------------------------------------------------------------- - -Required properties: -- compatible: Should be : - "fsl,imx8qxp-sc-thermal" - followed by "fsl,imx-sc-thermal"; - -- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml - for a description. - -Example (imx8qxp): -------------- -aliases { - mu1 = &lsio_mu1; -}; - -lsio_mu1: mailbox@5d1c0000 { - ... - #mbox-cells = <2>; -}; - -firmware { - scu { - compatible = "fsl,imx-scu"; - mbox-names = "tx0", "tx1", "tx2", "tx3", - "rx0", "rx1", "rx2", "rx3", - "gip3"; - mboxes = <&lsio_mu1 0 0 - &lsio_mu1 0 1 - &lsio_mu1 0 2 - &lsio_mu1 0 3 - &lsio_mu1 1 0 - &lsio_mu1 1 1 - &lsio_mu1 1 2 - &lsio_mu1 1 3 - &lsio_mu1 3 3>; - - clk: clk { - compatible = "fsl,imx8qxp-clk", "fsl,scu-clk"; - #clock-cells = <2>; - }; - - iomuxc { - compatible = "fsl,imx8qxp-iomuxc"; - - pinctrl_lpuart0: lpuart0grp { - fsl,pins = < - SC_P_UART0_RX_ADMA_UART0_RX 0x06000020 - SC_P_UART0_TX_ADMA_UART0_TX 0x06000020 - >; - }; - ... - }; - - ocotp: imx8qx-ocotp { - compatible = "fsl,imx8qxp-scu-ocotp"; - #address-cells = <1>; - #size-cells = <1>; - - fec_mac0: mac@2c4 { - reg = <0x2c4 8>; - }; - }; - - pd: imx8qx-pd { - compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; - #power-domain-cells = <1>; - }; - - rtc: rtc { - compatible = "fsl,imx8qxp-sc-rtc"; - }; - - scu_key: scu-key { - compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key"; - linux,keycodes = <KEY_POWER>; - }; - - watchdog { - compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt"; - timeout-sec = <60>; - }; - - tsens: thermal-sensor { - compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal"; - #thermal-sensor-cells = <1>; - }; - }; -}; - -serial@5a060000 { - ... - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_lpuart0>; - clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>; - clock-names = "ipg"; - power-domains = <&pd IMX_SC_R_UART_0>; -}; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index ef524378d449..7431579ab0e8 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -321,6 +321,7 @@ properties: - enum: - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board - toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6Q/D Module on Ixora V1.1 Carrier Board + - toradex,apalis_imx6q-ixora-v1.2 # Apalis iMX6Q/D Module on Ixora V1.2 Carrier Board - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board - const: toradex,apalis_imx6q - const: fsl,imx6q @@ -670,30 +671,30 @@ properties: - description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Modules items: - enum: - - toradex,colibri-imx6ull-aster # Colibri iMX6ULL Module on Aster Carrier Board - - toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board V3 - - toradex,colibri-imx6ull-iris # Colibri iMX6ULL Module on Iris Carrier Board - - toradex,colibri-imx6ull-iris-v2 # Colibri iMX6ULL Module on Iris V2 Carrier Board + - toradex,colibri-imx6ull-aster # Aster Carrier Board + - toradex,colibri-imx6ull-eval # Colibri Evaluation Board V3 + - toradex,colibri-imx6ull-iris # Iris Carrier Board + - toradex,colibri-imx6ull-iris-v2 # Iris V2 Carrier Board - const: toradex,colibri-imx6ull # Colibri iMX6ULL Module - const: fsl,imx6ull - description: i.MX6ULL Boards with Toradex Colibri iMX6ULL 1GB (eMMC) Module items: - enum: - - toradex,colibri-imx6ull-emmc-aster # Colibri iMX6ULL 1G (eMMC) on Aster Carrier Board - - toradex,colibri-imx6ull-emmc-eval # Colibri iMX6ULL 1G (eMMC) on Colibri Evaluation B. V3 - - toradex,colibri-imx6ull-emmc-iris # Colibri iMX6ULL 1G (eMMC) on Iris Carrier Board - - toradex,colibri-imx6ull-emmc-iris-v2 # Colibri iMX6ULL 1G (eMMC) on Iris V2 Carrier Board + - toradex,colibri-imx6ull-emmc-aster # Aster Carrier Board + - toradex,colibri-imx6ull-emmc-eval # Colibri Evaluation B. V3 + - toradex,colibri-imx6ull-emmc-iris # Iris Carrier Board + - toradex,colibri-imx6ull-emmc-iris-v2 # Iris V2 Carrier Board - const: toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module - const: fsl,imx6ull - description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Wi-Fi / BT Modules items: - enum: - - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT M. on Colibri Eval. B. V3 - - toradex,colibri-imx6ull-wifi-aster # Colibri iMX6ULL Wi-Fi / BT M. on Aster Carrier Board - - toradex,colibri-imx6ull-wifi-iris # Colibri iMX6ULL Wi-Fi / BT M. on Iris Carrier Board - - toradex,colibri-imx6ull-wifi-iris-v2 # Colibri iMX6ULL Wi-Fi / BT M. on Iris V2 Carrier Board + - toradex,colibri-imx6ull-wifi-eval # Colibri Eval. B. V3 + - toradex,colibri-imx6ull-wifi-aster # Aster Carrier Board + - toradex,colibri-imx6ull-wifi-iris # Iris Carrier Board + - toradex,colibri-imx6ull-wifi-iris-v2 # Iris V2 Carrier Board - const: toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Module - const: fsl,imx6ull @@ -738,6 +739,8 @@ properties: - enum: - toradex,colibri-imx7s-aster # Module on Aster Carrier Board - toradex,colibri-imx7s-eval-v3 # Module on Colibri Evaluation Board V3 + - toradex,colibri-imx7s-iris # Module on Iris Carrier Board + - toradex,colibri-imx7s-iris-v2 # Module on Iris Carrier Board V2 - const: toradex,colibri-imx7s - const: fsl,imx7s @@ -789,8 +792,10 @@ properties: - description: i.MX7D Boards with Toradex Colibri i.MX7D Module items: - enum: - - toradex,colibri-imx7d-aster # Colibri iMX7D Module on Aster Carrier Board - - toradex,colibri-imx7d-eval-v3 # Colibri iMX7D Module on Colibri Evaluation Board V3 + - toradex,colibri-imx7d-aster # Aster Carrier Board + - toradex,colibri-imx7d-eval-v3 # Colibri Evaluation Board V3 + - toradex,colibri-imx7d-iris # Iris Carrier Board + - toradex,colibri-imx7d-iris-v2 # Iris Carrier Board V2 - const: toradex,colibri-imx7d - const: fsl,imx7d @@ -799,6 +804,8 @@ properties: - enum: - toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board - toradex,colibri-imx7d-emmc-eval-v3 # Module on Colibri Evaluation Board V3 + - toradex,colibri-imx7d-emmc-iris # Module on Iris Carrier Board + - toradex,colibri-imx7d-emmc-iris-v2 # Module on Iris Carrier Board V2 - const: toradex,colibri-imx7d-emmc - const: fsl,imx7d @@ -865,6 +872,12 @@ properties: - const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module - const: fsl,imx8mm + - description: PHYTEC phyCORE-i.MX8MM SoM based boards + items: + - const: phytec,imx8mm-phyboard-polis-rdk # phyBOARD-Polis RDK + - const: phytec,imx8mm-phycore-som # phyCORE-i.MX8MM SoM + - const: fsl,imx8mm + - description: Variscite VAR-SOM-MX8MM based boards items: - const: variscite,var-som-mx8mm-symphony @@ -914,6 +927,8 @@ properties: - description: i.MX8MP based Boards items: - enum: + - dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM + - dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board - fsl,imx8mp-evk # i.MX8MP EVK Board - gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board - toradex,verdin-imx8mp # Verdin iMX8M Plus Modules @@ -952,6 +967,18 @@ properties: - const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module - const: fsl,imx8mp + - description: + TQMa8MPxL is a series of LGA SOM featuring NXP i.MX8MP system-on-chip + variants. It is designed to be soldered on different carrier boards. + All CPU variants use the same device tree hence only one compatible + is needed. MBa8MPxL mainboard can be used as starterkit or in a boxed + version as an industrial computing device. + items: + - enum: + - tq,imx8mp-tqma8mpql-mba8mpxl # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM on MBa8MPxL + - const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM + - const: fsl,imx8mp + - description: i.MX8MQ based Boards items: - enum: @@ -1020,6 +1047,12 @@ properties: - fsl,imx8ulp-evk # i.MX8ULP EVK Board - const: fsl,imx8ulp + - description: i.MX93 based Boards + items: + - enum: + - fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board + - const: fsl,imx93 + - description: Freescale Vybrid Platform Device Tree Bindings diff --git a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt index 052a967c1f28..c83245065d44 100644 --- a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt @@ -72,7 +72,7 @@ mpp19 19 gpio, uart0(rxd), sdio(pw_off) GPIO: ----- For common binding part and usage, refer to -Documentation/devicetree/bindings/gpio/gpio-mvebu.txt. +Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml. Required properties: diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt index 0705e765f432..d84105c7c935 100644 --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt @@ -156,7 +156,7 @@ GPIO: ----- For common binding part and usage, refer to -Documentation/devicetree/bindings/gpio/gpio-mvebu.txt. +Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml. Required properties: diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,ac5.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,ac5.yaml new file mode 100644 index 000000000000..8960fb8b2b2f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/marvell/marvell,ac5.yaml @@ -0,0 +1,32 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/marvell/marvell,ac5.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Alleycat5/5X Platforms + +maintainers: + - Chris Packham <chris.packham@alliedtelesis.co.nz> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Alleycat5 (98DX25xx) Reference Design + items: + - enum: + - marvell,rd-ac5 + - const: marvell,ac5 + + - description: Alleycat5X (98DX35xx) Reference Design + items: + - enum: + - marvell,rd-ac5x + - const: marvell,ac5x + - const: marvell,ac5 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 4a2bd9759c47..07c0ea94e850 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -131,6 +131,36 @@ properties: - enum: - mediatek,mt8183-evb - const: mediatek,mt8183 + - description: Google Hayato + items: + - const: google,hayato-rev1 + - const: google,hayato + - const: mediatek,mt8192 + - description: Google Spherion (Acer Chromebook 514) + items: + - const: google,spherion-rev3 + - const: google,spherion-rev2 + - const: google,spherion-rev1 + - const: google,spherion-rev0 + - const: google,spherion + - const: mediatek,mt8192 + - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H) + items: + - enum: + - google,tomato-rev2 + - google,tomato-rev1 + - const: google,tomato + - const: mediatek,mt8195 + - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H) + items: + - const: google,tomato-rev4 + - const: google,tomato-rev3 + - const: google,tomato + - const: mediatek,mt8195 + - items: + - enum: + - mediatek,mt8186-evb + - const: mediatek,mt8186 - items: - enum: - mediatek,mt8192-evb diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml index 0886e2e335bb..661047d26e11 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml @@ -39,6 +39,9 @@ properties: '#clock-cells': const: 1 + '#reset-cells': + const: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml index c8c67c033f8c..b57cc2e69efb 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml @@ -24,7 +24,6 @@ properties: - mediatek,mt8192-imp_iic_wrap_w - mediatek,mt8192-imp_iic_wrap_n - mediatek,mt8192-msdc_top - - mediatek,mt8192-msdc - mediatek,mt8192-mfgcfg - mediatek,mt8192-imgsys - mediatek,mt8192-imgsys2 @@ -108,13 +107,6 @@ examples: }; - | - msdc: clock-controller@11f60000 { - compatible = "mediatek,mt8192-msdc"; - reg = <0x11f60000 0x1000>; - #clock-cells = <1>; - }; - - - | mfgcfg: clock-controller@13fbf000 { compatible = "mediatek,mt8192-mfgcfg"; reg = <0x13fbf000 0x1000>; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml index 5705bcf1fe47..27f79175c678 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml @@ -29,6 +29,9 @@ properties: '#clock-cells': const: 1 + '#reset-cells': + const: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml index 57a1503d95fe..95b6bdf99936 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml @@ -37,6 +37,9 @@ properties: '#clock-cells': const: 1 + '#reset-cells': + const: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml index 611f666f359d..8585f6f18f69 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8135-pericfg - mediatek,mt8173-pericfg - mediatek,mt8183-pericfg + - mediatek,mt8186-pericfg - mediatek,mt8195-pericfg - mediatek,mt8516-pericfg - const: syscon diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt index 94d50a949be1..c0e3c3a42bea 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt @@ -10,7 +10,7 @@ system, notifying them when a low power state is entered or exited. Multiple revisions of the SAW hardware are supported using these Device Nodes. SAW2 revisions differ in the register offset and configuration data. Also, the same revision of the SAW in different SoCs may have different configuration -data due the the differences in hardware capabilities. Hence the SoC name, the +data due the differences in hardware capabilities. Hence the SoC name, the version of the SAW hardware in that SoC and the distinction between cpu (big or Little) or cache, may be needed to uniquely identify the SAW register configuration and initialization data. The compatible string is used to diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml index 95e51378089c..43409e5721d5 100644 --- a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml +++ b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml @@ -8,6 +8,7 @@ title: NPCM Platforms Device Tree Bindings maintainers: - Jonathan Neuschäfer <j.neuschaefer@gmx.net> + - Tomer Maimon <tmaimon77@gmail.com> properties: $nodename: @@ -26,4 +27,10 @@ properties: - nuvoton,npcm750-evb # NPCM750 evaluation board - const: nuvoton,npcm750 + - description: NPCM845 based boards + items: + - enum: + - nuvoton,npcm845-evb # NPCM845 evaluation board + - const: nuvoton,npcm845 + additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml index fcb211add7d3..94e72f25b331 100644 --- a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml +++ b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml @@ -8,6 +8,7 @@ title: Global Control Registers block in Nuvoton SoCs maintainers: - Jonathan Neuschäfer <j.neuschaefer@gmx.net> + - Tomer Maimon <tmaimon77@gmail.com> description: The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs @@ -20,6 +21,7 @@ properties: - enum: - nuvoton,wpcm450-gcr - nuvoton,npcm750-gcr + - nuvoton,npcm845-gcr - const: syscon - const: simple-mfd diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 5c06d1bfc046..fb1d00bcc847 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: QCOM device tree bindings maintainers: - - Stephen Boyd <sboyd@codeaurora.org> + - Bjorn Andersson <bjorn.andersson@linaro.org> description: | Some qcom based bootloaders identify the dtb blob based on a set of @@ -38,18 +38,24 @@ description: | msm8992 msm8994 msm8996 + msm8998 + qcs404 sa8155p sa8540p sc7180 sc7280 sc8180x sc8280xp + sda660 sdm630 sdm632 + sdm636 sdm660 sdm845 sdx55 sdx65 + sm6125 + sm6350 sm7225 sm8150 sm8250 @@ -90,6 +96,11 @@ description: | A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in foundry 2. + There are many devices in the list below that run the standard ChromeOS + bootloader setup and use the open source depthcharge bootloader to boot the + OS. These devices do not use the scheme described above. For details, see: + https://docs.kernel.org/arm/google/chromebook-boot-flow.html + properties: $nodename: const: "/" @@ -153,28 +164,50 @@ properties: - const: qcom,msm8974 - items: - - enum: - - alcatel,idol347 - - const: qcom,msm8916-mtp/1 - const: qcom,msm8916-mtp + - const: qcom,msm8916-mtp/1 - const: qcom,msm8916 - items: - enum: - - longcheer,l8150 + - alcatel,idol347 + - asus,z00l + - huawei,g7 + - longcheer,l8910 - samsung,a3u-eur - samsung,a5u-eur + - samsung,j5 + - samsung,serranove + - wingtech,wt88047 + - const: qcom,msm8916 + + - items: + - const: longcheer,l8150 + - const: qcom,msm8916-v1-qrd/9-v1 - const: qcom,msm8916 - items: - enum: + - lg,bullhead + - microsoft,talkman + - xiaomi,libra + - const: qcom,msm8992 + + - items: + - enum: - sony,karin_windy + - const: qcom,apq8094 + + - items: + - enum: + - huawei,angler + - microsoft,cityman + - sony,ivy-row - sony,karin-row - sony,satsuki-row - sony,sumire-row - sony,suzuran-row - - qcom,msm8994 - - const: qcom,apq8094 + - const: qcom,msm8994 - items: - enum: @@ -190,11 +223,26 @@ properties: - sony,kagura-row - sony,keyaki-row - xiaomi,gemini + - xiaomi,natrium - xiaomi,scorpio - const: qcom,msm8996 - items: - enum: + - asus,novago-tp370ql + - fxtec,pro1 + - hp,envy-x2 + - lenovo,miix-630 + - oneplus,cheeseburger + - oneplus,dumpling + - qcom,msm8998-mtp + - sony,xperia-lilac + - sony,xperia-maple + - sony,xperia-poplar + - const: qcom,msm8998 + + - items: + - enum: - qcom,ipq4019-ap-dk01.1-c1 - qcom,ipq4019-ap-dk04.1-c3 - qcom,ipq4019-ap-dk07.1-c1 @@ -214,19 +262,317 @@ properties: - qcom,ipq8074-hk10-c2 - const: qcom,ipq8074 - - items: + - description: Qualcomm Technologies, Inc. SC7180 IDP + items: - enum: - qcom,sc7180-idp - const: qcom,sc7180 - - items: - - enum: - - qcom,sc7280-crd - - qcom,sc7280-idp - - qcom,sc7280-idp2 - - google,hoglin - - google,piglin - - google,senor + - description: HP Chromebook x2 11c (rev1 - 2) + items: + - const: google,coachz-rev1 + - const: google,coachz-rev2 + - const: qcom,sc7180 + + - description: HP Chromebook x2 11c (newest rev) + items: + - const: google,coachz + - const: qcom,sc7180 + + - description: HP Chromebook x2 11c with LTE (rev1 - 2) + items: + - const: google,coachz-rev1-sku0 + - const: google,coachz-rev2-sku0 + - const: qcom,sc7180 + + - description: HP Chromebook x2 11c with LTE (newest rev) + items: + - const: google,coachz-sku0 + - const: qcom,sc7180 + + - description: Lenovo Chromebook Duet 5 13 (rev2) + items: + - const: google,homestar-rev2 + - const: google,homestar-rev23 + - const: qcom,sc7180 + + - description: Lenovo Chromebook Duet 5 13 (rev3) + items: + - const: google,homestar-rev3 + - const: qcom,sc7180 + + - description: Lenovo Chromebook Duet 5 13 (newest rev) + items: + - const: google,homestar + - const: qcom,sc7180 + + - description: Google Kingoftown (rev0) + items: + - const: google,kingoftown-rev0 + - const: qcom,sc7180 + + - description: Google Kingoftown (newest rev) + items: + - const: google,kingoftown + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 (rev0) + items: + - const: google,lazor-rev0 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 (rev1 - 2) + items: + - const: google,lazor-rev1 + - const: google,lazor-rev2 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 (rev3 - 8) + items: + - const: google,lazor-rev3 + - const: google,lazor-rev4 + - const: google,lazor-rev5 + - const: google,lazor-rev6 + - const: google,lazor-rev7 + - const: google,lazor-rev8 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 (newest rev) + items: + - const: google,lazor + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 with KB Backlight (rev1 - 2) + items: + - const: google,lazor-rev1-sku2 + - const: google,lazor-rev2-sku2 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 with KB Backlight (rev3 - 8) + items: + - const: google,lazor-rev3-sku2 + - const: google,lazor-rev4-sku2 + - const: google,lazor-rev5-sku2 + - const: google,lazor-rev6-sku2 + - const: google,lazor-rev7-sku2 + - const: google,lazor-rev8-sku2 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 with KB Backlight (newest rev) + items: + - const: google,lazor-sku2 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 with LTE (rev1 - 2) + items: + - const: google,lazor-rev1-sku0 + - const: google,lazor-rev2-sku0 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 with LTE (rev3 - 8) + items: + - const: google,lazor-rev3-sku0 + - const: google,lazor-rev4-sku0 + - const: google,lazor-rev5-sku0 + - const: google,lazor-rev6-sku0 + - const: google,lazor-rev7-sku0 + - const: google,lazor-rev8-sku0 + - const: qcom,sc7180 + + - description: Acer Chromebook Spin 513 with LTE (newest rev) + items: + - const: google,lazor-sku0 + - const: qcom,sc7180 + + - description: Acer Chromebook 511 (rev4 - rev8) + items: + - const: google,lazor-rev4-sku4 + - const: google,lazor-rev5-sku4 + - const: google,lazor-rev6-sku4 + - const: google,lazor-rev7-sku4 + - const: google,lazor-rev8-sku4 + - const: qcom,sc7180 + + - description: Acer Chromebook 511 (newest rev) + items: + - const: google,lazor-sku4 + - const: qcom,sc7180 + + - description: Acer Chromebook 511 without Touchscreen (rev4) + items: + - const: google,lazor-rev4-sku5 + - const: qcom,sc7180 + + - description: Acer Chromebook 511 without Touchscreen (rev5 - rev8) + items: + - const: google,lazor-rev5-sku5 + - const: google,lazor-rev5-sku6 + - const: google,lazor-rev6-sku6 + - const: google,lazor-rev7-sku6 + - const: google,lazor-rev8-sku6 + - const: qcom,sc7180 + + - description: Acer Chromebook 511 without Touchscreen (newest rev) + items: + - const: google,lazor-sku6 + - const: qcom,sc7180 + + - description: Google Mrbland with AUO panel (rev0) + items: + - const: google,mrbland-rev0-sku0 + - const: qcom,sc7180 + + - description: Google Mrbland with AUO panel (newest rev) + items: + - const: google,mrbland-sku1536 + - const: qcom,sc7180 + + - description: Google Mrbland with BOE panel (rev0) + items: + - const: google,mrbland-rev0-sku16 + - const: qcom,sc7180 + + - description: Google Mrbland with BOE panel (newest rev) + items: + - const: google,mrbland-sku1024 + - const: google,mrbland-sku768 + - const: qcom,sc7180 + + - description: Google Pazquel with Parade (newest rev) + items: + - const: google,pazquel-sku5 + - const: qcom,sc7180 + + - description: Google Pazquel with TI (newest rev) + items: + - const: google,pazquel-sku1 + - const: qcom,sc7180 + + - description: Google Pazquel with LTE and Parade (newest rev) + items: + - const: google,pazquel-sku4 + - const: qcom,sc7180 + + - description: Google Pazquel with LTE and TI (newest rev) + items: + - const: google,pazquel-sku0 + - const: google,pazquel-sku2 + - const: qcom,sc7180 + + - description: Sharp Dynabook Chromebook C1 (rev1) + items: + - const: google,pompom-rev1 + - const: qcom,sc7180 + + - description: Sharp Dynabook Chromebook C1 (rev2) + items: + - const: google,pompom-rev2 + - const: qcom,sc7180 + + - description: Sharp Dynabook Chromebook C1 (newest rev) + items: + - const: google,pompom + - const: qcom,sc7180 + + - description: Sharp Dynabook Chromebook C1 with LTE (rev1) + items: + - const: google,pompom-rev1-sku0 + - const: qcom,sc7180 + + - description: Sharp Dynabook Chromebook C1 with LTE (rev2) + items: + - const: google,pompom-rev2-sku0 + - const: qcom,sc7180 + + - description: Sharp Dynabook Chromebook C1 with LTE (newest rev) + items: + - const: google,pompom-sku0 + - const: qcom,sc7180 + + - description: Google Quackingstick (newest rev) + items: + - const: google,quackingstick-sku1537 + - const: qcom,sc7180 + + - description: Google Quackingstick with LTE (newest rev) + items: + - const: google,quackingstick-sku1536 + - const: qcom,sc7180 + + - description: Google Trogdor (newest rev) + items: + - const: google,trogdor + - const: qcom,sc7180 + + - description: Google Trogdor with LTE (newest rev) + items: + - const: google,trogdor-sku0 + - const: qcom,sc7180 + + - description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel (rev0) + items: + - const: google,wormdingler-rev0-sku16 + - const: qcom,sc7180 + + - description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel (newest rev) + items: + - const: google,wormdingler-sku1024 + - const: qcom,sc7180 + + - description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel and rt5682s (newest rev) + items: + - const: google,wormdingler-sku1025 + - const: qcom,sc7180 + + - description: Lenovo IdeaPad Chromebook Duet 3 with INX panel (rev0) + items: + - const: google,wormdingler-rev0-sku0 + - const: qcom,sc7180 + + - description: Lenovo IdeaPad Chromebook Duet 3 with INX panel (newest rev) + items: + - const: google,wormdingler-sku0 + - const: qcom,sc7180 + + - description: Lenovo IdeaPad Chromebook Duet 3 with INX panel and rt5682s (newest rev) + items: + - const: google,wormdingler-sku1 + - const: qcom,sc7180 + + - description: Qualcomm Technologies, Inc. sc7280 CRD platform (rev3 - 4) + items: + - const: qcom,sc7280-crd + - const: google,hoglin-rev3 + - const: google,hoglin-rev4 + - const: google,piglin-rev3 + - const: google,piglin-rev4 + - const: qcom,sc7280 + + - description: Qualcomm Technologies, Inc. sc7280 CRD platform (newest rev) + items: + - const: google,hoglin + - const: qcom,sc7280 + + - description: Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform + items: + - const: qcom,sc7280-idp + - const: google,senor + - const: qcom,sc7280 + + - description: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform + items: + - const: qcom,sc7280-idp2 + - const: google,piglin + - const: qcom,sc7280 + + - description: Google Herobrine (newest rev) + items: + - const: google,herobrine + - const: qcom,sc7280 + + - description: Google Villager (newest rev) + items: + - const: google,villager - const: qcom,sc7280 - items: @@ -238,16 +584,36 @@ properties: - items: - enum: + - lenovo,thinkpad-x13s + - qcom,sc8280xp-crd - qcom,sc8280xp-qrd - const: qcom,sc8280xp - items: - enum: + - sony,discovery-row + - sony,kirin-row + - sony,pioneer-row + - sony,voyager-row + - const: qcom,sdm630 + + - items: + - enum: + - inforce,ifc6560 + - const: qcom,sda660 + + - items: + - enum: - fairphone,fp3 - const: qcom,sdm632 - items: - enum: + - sony,mermaid-row + - const: qcom,sdm636 + + - items: + - enum: - xiaomi,lavender - const: qcom,sdm660 @@ -271,6 +637,13 @@ properties: - items: - enum: + - qcom,qcs404-evb-1000 + - qcom,qcs404-evb-4000 + - const: qcom,qcs404-evb + - const: qcom,qcs404 + + - items: + - enum: - qcom,sa8155p-adp - const: qcom,sa8155p @@ -281,24 +654,62 @@ properties: - items: - enum: + - lenovo,yoga-c630 + - lg,judyln + - lg,judyp + - oneplus,enchilada + - oneplus,fajita + - qcom,sdm845-mtp + - shift,axolotl + - samsung,w737 + - sony,akari-row + - sony,akatsuki-row + - sony,apollo-row + - thundercomm,db845c + - xiaomi,beryllium + - xiaomi,polaris + - const: qcom,sdm845 + + - items: + - enum: + - sony,pdx201 + - const: qcom,sm6125 + + - items: + - enum: + - sony,pdx213 + - const: qcom,sm6350 + + - items: + - enum: - fairphone,fp4 - const: qcom,sm7225 - items: - enum: + - microsoft,surface-duo + - qcom,sm8150-hdk - qcom,sm8150-mtp + - sony,bahamut-generic + - sony,griffin-generic - const: qcom,sm8150 - items: - enum: - qcom,qrb5165-rb5 + - qcom,sm8250-hdk - qcom,sm8250-mtp + - sony,pdx203-generic + - sony,pdx206-generic - const: qcom,sm8250 - items: - enum: + - microsoft,surface-duo2 - qcom,sm8350-hdk - qcom,sm8350-mtp + - sony,pdx214-generic + - sony,pdx215-generic - const: qcom,sm8350 - items: diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index cf9eb1e8326a..7811ba64149c 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -554,6 +554,11 @@ properties: - const: vamrs,rk3399pro-vmarc-som - const: rockchip,rk3399pro + - description: Radxa ROCK Pi S + items: + - const: radxa,rockpis + - const: rockchip,rk3308 + - description: Radxa Rock2 Square items: - const: radxa,rock2-square diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml new file mode 100644 index 000000000000..653f85997643 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/samsung/samsung-soc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C, S5P and Exynos SoC compatibles naming convention + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +description: | + Guidelines for new compatibles for SoC blocks/components. + When adding new compatibles in new bindings, use the format:: + samsung,SoC-IP + + For example:: + samsung,exynos5433-cmu-isp + +select: + properties: + compatible: + pattern: "^samsung,.*(s3c|s5pv|exynos)[0-9a-z]+.*$" + required: + - compatible + +properties: + compatible: + oneOf: + - description: Preferred naming style for compatibles of SoC components + pattern: "^samsung,(s3c|s5pv|exynos|exynosautov)[0-9]+-.*$" + + # Legacy compatibles with wild-cards - list cannot grow with new bindings: + - enum: + - samsung,exynos4x12-pinctrl + - samsung,exynos4x12-usb2-phy + - samsung,s3c64xx-pinctrl + - samsung,s3c64xx-wakeup-eint + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 8b31565fee59..4c605bccc474 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -59,12 +59,18 @@ properties: - prt,prtt1s # Protonic PRTT1S - const: st,stm32mp151 - - description: DH STM32MP153 SoM based Boards + - description: DH STM32MP153 DHCOM SoM based Boards items: - const: dh,stm32mp153c-dhcom-drc02 - const: dh,stm32mp153c-dhcom-som - const: st,stm32mp153 + - description: DH STM32MP153 DHCOR SoM based Boards + items: + - const: dh,stm32mp153c-dhcor-drc-compact + - const: dh,stm32mp153c-dhcor-som + - const: st,stm32mp153 + - items: - enum: - shiratech,stm32mp157a-iot-box # IoT Box diff --git a/Documentation/devicetree/bindings/arm/sunplus,sp7021.yaml b/Documentation/devicetree/bindings/arm/sunplus,sp7021.yaml new file mode 100644 index 000000000000..def7d0cfeb31 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sunplus,sp7021.yaml @@ -0,0 +1,29 @@ +# 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/arm/sunplus,sp7021.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SP7021 Boards + +maintainers: + - qinjian <qinjian@cqplus1.com> + +description: | + ARM platforms using Sunplus SP7021, an ARM Cortex A7 (4-cores) based SoC. + Wiki: https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview + +properties: + $nodename: + const: '/' + compatible: + items: + - enum: + - sunplus,sp7021-achip + - sunplus,sp7021-demo-v3 + - const: sunplus,sp7021 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 95278a6a9a8e..0c2356778208 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -863,6 +863,11 @@ properties: - const: yones-toptech,bs1078-v2 - const: allwinner,sun6i-a31s + - description: X96 Mate TV box + items: + - const: hechuang,x96-mate + - const: allwinner,sun50i-h616 + - description: Xunlong OrangePi items: - const: xunlong,orangepi @@ -963,4 +968,9 @@ properties: - const: xunlong,orangepi-zero-plus2-h3 - const: allwinner,sun8i-h3 + - description: Xunlong OrangePi Zero 2 + items: + - const: xunlong,orangepi-zero2 + - const: allwinner,sun50i-h616 + additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml index 8eee312c2e6f..99566688d033 100644 --- a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml @@ -29,10 +29,20 @@ properties: compatible: enum: - allwinner,sun5i-a13-mbus + - allwinner,sun8i-a33-mbus + - allwinner,sun8i-a50-mbus + - allwinner,sun8i-a83t-mbus - allwinner,sun8i-h3-mbus - allwinner,sun8i-r40-mbus + - allwinner,sun8i-v3s-mbus + - allwinner,sun8i-v536-mbus + - allwinner,sun20i-d1-mbus - allwinner,sun50i-a64-mbus + - allwinner,sun50i-a100-mbus - allwinner,sun50i-h5-mbus + - allwinner,sun50i-h6-mbus + - allwinner,sun50i-h616-mbus + - allwinner,sun50i-r329-mbus reg: minItems: 1 @@ -81,13 +91,13 @@ required: - dma-ranges if: - properties: - compatible: - contains: - enum: - - allwinner,sun8i-h3-mbus - - allwinner,sun50i-a64-mbus - - allwinner,sun50i-h5-mbus + not: + properties: + compatible: + contains: + enum: + - allwinner,sun5i-a13-mbus + - allwinner,sun8i-r40-mbus then: properties: diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml index 8c6543b5c0dc..711bb4d08c60 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -40,7 +40,6 @@ required: - compatible - reg - nvidia,bpmp - - status examples: - | diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml new file mode 100644 index 000000000000..788a13f8aa93 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra194 AXI2APB bridge + +maintainers: + - Sumit Gupta <sumitg@nvidia.com> + +properties: + $nodename: + pattern: "^axi2apb@([0-9a-f]+)$" + + compatible: + enum: + - nvidia,tegra194-axi2apb + + reg: + maxItems: 6 + description: Physical base address and length of registers for all bridges + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + axi2apb: axi2apb@2390000 { + compatible = "nvidia,tegra194-axi2apb"; + reg = <0x02390000 0x1000>, + <0x023a0000 0x1000>, + <0x023b0000 0x1000>, + <0x023c0000 0x1000>, + <0x023d0000 0x1000>, + <0x023e0000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml new file mode 100644 index 000000000000..debb2b0c8013 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra194 CBB 1.0 bindings + +maintainers: + - Sumit Gupta <sumitg@nvidia.com> + +description: |+ + The Control Backbone (CBB) is comprised of the physical path from an + initiator to a target's register configuration space. CBB 1.0 has + multiple hierarchical sub-NOCs (Network-on-Chip) and connects various + initiators and targets using different bridges like AXIP2P, AXI2APB. + + This driver handles errors due to illegal register accesses reported + by the NOCs inside the CBB. NOCs reporting errors are cluster NOCs + "AON-NOC, SCE-NOC, RCE-NOC, BPMP-NOC, CV-NOC" and "CBB Central NOC" + which is the main NOC. + + By default, the access issuing initiator is informed about the error + using SError or Data Abort exception unless the ERD (Error Response + Disable) is enabled/set for that initiator. If the ERD is enabled, then + SError or Data Abort is masked and the error is reported with interrupt. + + - For CCPLEX (CPU Complex) initiator, the driver sets ERD bit. So, the + errors due to illegal accesses from CCPLEX are reported by interrupts. + If ERD is not set, then error is reported by SError. + - For other initiators, the ERD is disabled. So, the access issuing + initiator is informed about the illegal access by Data Abort exception. + In addition, an interrupt is also generated to CCPLEX. These initiators + include all engines using Cortex-R5 (which is ARMv7 CPU cluster) and + engines like TSEC (Security co-processor), NVDEC (NVIDIA Video Decoder + engine) etc which can initiate transactions. + + The driver prints relevant debug information like Error Code, Error + Description, Master, Address, AXI ID, Cache, Protection, Security Group + etc on receiving error notification. + +properties: + $nodename: + pattern: "^[a-z]+-noc@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra194-cbb-noc + - nvidia,tegra194-aon-noc + - nvidia,tegra194-bpmp-noc + - nvidia,tegra194-rce-noc + - nvidia,tegra194-sce-noc + + reg: + maxItems: 1 + + interrupts: + description: + CCPLEX receives secure or nonsecure interrupt depending on error type. + A secure interrupt is received for SEC(firewall) & SLV errors and a + non-secure interrupt is received for TMO & DEC errors. + items: + - description: non-secure interrupt + - description: secure interrupt + + nvidia,axi2apb: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: + Specifies the node having all axi2apb bridges which need to be checked + for any error logged in their status register. + + nvidia,apbmisc: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: + Specifies the apbmisc node which need to be used for reading the ERD + register. + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - nvidia,apbmisc + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + cbb-noc@2300000 { + compatible = "nvidia,tegra194-cbb-noc"; + reg = <0x02300000 0x1000>; + interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>; + nvidia,axi2apb = <&axi2apb>; + nvidia,apbmisc = <&apbmisc>; + }; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index 564ae6aaccf7..7fd8d47b1be4 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml @@ -208,7 +208,7 @@ properties: "^[a-z0-9]+$": type: object - patternProperties: + properties: clocks: minItems: 1 maxItems: 8 diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml new file mode 100644 index 000000000000..7b1fe50ffbe0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra CBB 2.0 bindings + +maintainers: + - Sumit Gupta <sumitg@nvidia.com> + +description: |+ + The Control Backbone (CBB) is comprised of the physical path from an + initiator to a target's register configuration space. CBB 2.0 consists + of multiple sub-blocks connected to each other to create a topology. + The Tegra234 SoC has different fabrics based on CBB 2.0 architecture + which include cluster fabrics BPMP, AON, PSC, SCE, RCE, DCE, FSI and + "CBB central fabric". + + In CBB 2.0, each initiator which can issue transactions connects to a + Root Master Node (MN) before it connects to any other element of the + fabric. Each Root MN contains a Error Monitor (EM) which detects and + logs error. Interrupts from various EM blocks are collated by Error + Notifier (EN) which is per fabric and presents a single interrupt from + fabric to the SoC interrupt controller. + + The driver handles errors from CBB due to illegal register accesses + and prints debug information about failed transaction on receiving + the interrupt from EN. Debug information includes Error Code, Error + Description, MasterID, Fabric, SlaveID, Address, Cache, Protection, + Security Group etc on receiving error notification. + + If the Error Response Disable (ERD) is set/enabled for an initiator, + then SError or Data abort exception error response is masked and an + interrupt is used for reporting errors due to illegal accesses from + that initiator. The value returned on read failures is '0xFFFFFFFF' + for compatibility with PCIE. + +properties: + $nodename: + pattern: "^[a-z]+-fabric@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra234-aon-fabric + - nvidia,tegra234-bpmp-fabric + - nvidia,tegra234-cbb-fabric + - nvidia,tegra234-dce-fabric + - nvidia,tegra234-rce-fabric + - nvidia,tegra234-sce-fabric + + reg: + maxItems: 1 + + interrupts: + items: + - description: secure interrupt from error notifier + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + cbb-fabric@1300000 { + compatible = "nvidia,tegra234-cbb-fabric"; + reg = <0x13a00000 0x400000>; + interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml b/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml index b5e26e41f88c..f04db802a732 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml @@ -29,6 +29,13 @@ properties: ranges: true + gpio-controller: + deprecated: true + + "#gpio-cells": + deprecated: true + const: 2 + additionalProperties: false patternProperties: @@ -67,8 +74,7 @@ patternProperties: required: - compatible - - "#address-cells" - - "#size-cells" + - reg examples: - | diff --git a/Documentation/devicetree/bindings/ata/ahci-ceva.txt b/Documentation/devicetree/bindings/ata/ahci-ceva.txt deleted file mode 100644 index bfb6da0281ec..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-ceva.txt +++ /dev/null @@ -1,63 +0,0 @@ -Binding for CEVA AHCI SATA Controller - -Required properties: - - reg: Physical base address and size of the controller's register area. - - compatible: Compatibility string. Must be 'ceva,ahci-1v84'. - - clocks: Input clock specifier. Refer to common clock bindings. - - interrupts: Interrupt specifier. Refer to interrupt binding. - - ceva,p0-cominit-params: OOB timing value for COMINIT parameter for port 0. - - ceva,p1-cominit-params: OOB timing value for COMINIT parameter for port 1. - The fields for the above parameter must be as shown below: - ceva,pN-cominit-params = /bits/ 8 <CIBGMN CIBGMX CIBGN CINMP>; - CINMP : COMINIT Negate Minimum Period. - CIBGN : COMINIT Burst Gap Nominal. - CIBGMX: COMINIT Burst Gap Maximum. - CIBGMN: COMINIT Burst Gap Minimum. - - ceva,p0-comwake-params: OOB timing value for COMWAKE parameter for port 0. - - ceva,p1-comwake-params: OOB timing value for COMWAKE parameter for port 1. - The fields for the above parameter must be as shown below: - ceva,pN-comwake-params = /bits/ 8 <CWBGMN CWBGMX CWBGN CWNMP>; - CWBGMN: COMWAKE Burst Gap Minimum. - CWBGMX: COMWAKE Burst Gap Maximum. - CWBGN: COMWAKE Burst Gap Nominal. - CWNMP: COMWAKE Negate Minimum Period. - - ceva,p0-burst-params: Burst timing value for COM parameter for port 0. - - ceva,p1-burst-params: Burst timing value for COM parameter for port 1. - The fields for the above parameter must be as shown below: - ceva,pN-burst-params = /bits/ 8 <BMX BNM SFD PTST>; - BMX: COM Burst Maximum. - BNM: COM Burst Nominal. - SFD: Signal Failure Detection value. - PTST: Partial to Slumber timer value. - - ceva,p0-retry-params: Retry interval timing value for port 0. - - ceva,p1-retry-params: Retry interval timing value for port 1. - The fields for the above parameter must be as shown below: - ceva,pN-retry-params = /bits/ 16 <RIT RCT>; - RIT: Retry Interval Timer. - RCT: Rate Change Timer. - -Optional properties: - - ceva,broken-gen2: limit to gen1 speed instead of gen2. - - phys: phandle for the PHY device - - resets: phandle to the reset controller for the SATA IP - -Examples: - ahci@fd0c0000 { - compatible = "ceva,ahci-1v84"; - reg = <0xfd0c0000 0x200>; - interrupt-parent = <&gic>; - interrupts = <0 133 4>; - clocks = <&clkc SATA_CLK_ID>; - ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; - ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; - ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; - ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>; - - ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; - ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; - ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; - ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>; - ceva,broken-gen2; - phys = <&psgtr 1 PHY_TYPE_SATA 1 1>; - resets = <&zynqmp_reset ZYNQMP_RESET_SATA>; - }; diff --git a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml new file mode 100644 index 000000000000..9b31f864e071 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml @@ -0,0 +1,189 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/ceva,ahci-1v84.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ceva AHCI SATA Controller + +maintainers: + - Piyush Mehta <piyush.mehta@xilinx.com> + +description: | + The Ceva SATA controller mostly conforms to the AHCI interface with some + special extensions to add functionality, is a high-performance dual-port + SATA host controller with an AHCI compliant command layer which supports + advanced features such as native command queuing and frame information + structure (FIS) based switching for systems employing port multipliers. + +properties: + compatible: + const: ceva,ahci-1v84 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + dma-coherent: true + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + ceva,p0-cominit-params: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: | + OOB timing value for COMINIT parameter for port 0. + The fields for the above parameter must be as shown below:- + ceva,p0-cominit-params = /bits/ 8 <CIBGMN CIBGMX CIBGN CINMP>; + items: + - description: CINMP - COMINIT Negate Minimum Period. + - description: CIBGN - COMINIT Burst Gap Nominal. + - description: CIBGMX - COMINIT Burst Gap Maximum. + - description: CIBGMN - COMINIT Burst Gap Minimum. + + ceva,p0-comwake-params: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: | + OOB timing value for COMWAKE parameter for port 0. + The fields for the above parameter must be as shown below:- + ceva,p0-comwake-params = /bits/ 8 <CWBGMN CWBGMX CWBGN CWNMP>; + items: + - description: CWBGMN - COMWAKE Burst Gap Minimum. + - description: CWBGMX - COMWAKE Burst Gap Maximum. + - description: CWBGN - COMWAKE Burst Gap Nominal. + - description: CWNMP - COMWAKE Negate Minimum Period. + + ceva,p0-burst-params: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: | + Burst timing value for COM parameter for port 0. + The fields for the above parameter must be as shown below:- + ceva,p0-burst-params = /bits/ 8 <BMX BNM SFD PTST>; + items: + - description: BMX - COM Burst Maximum. + - description: BNM - COM Burst Nominal. + - description: SFD - Signal Failure Detection value. + - description: PTST - Partial to Slumber timer value. + + ceva,p0-retry-params: + $ref: /schemas/types.yaml#/definitions/uint16-array + description: | + Retry interval timing value for port 0. + The fields for the above parameter must be as shown below:- + ceva,p0-retry-params = /bits/ 16 <RIT RCT>; + items: + - description: RIT - Retry Interval Timer. + - description: RCT - Rate Change Timer. + + ceva,p1-cominit-params: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: | + OOB timing value for COMINIT parameter for port 1. + The fields for the above parameter must be as shown below:- + ceva,p1-cominit-params = /bits/ 8 <CIBGMN CIBGMX CIBGN CINMP>; + items: + - description: CINMP - COMINIT Negate Minimum Period. + - description: CIBGN - COMINIT Burst Gap Nominal. + - description: CIBGMX - COMINIT Burst Gap Maximum. + - description: CIBGMN - COMINIT Burst Gap Minimum. + + ceva,p1-comwake-params: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: | + OOB timing value for COMWAKE parameter for port 1. + The fields for the above parameter must be as shown below:- + ceva,p1-comwake-params = /bits/ 8 <CWBGMN CWBGMX CWBGN CWNMP>; + items: + - description: CWBGMN - COMWAKE Burst Gap Minimum. + - description: CWBGMX - COMWAKE Burst Gap Maximum. + - description: CWBGN - COMWAKE Burst Gap Nominal. + - description: CWNMP - COMWAKE Negate Minimum Period. + + ceva,p1-burst-params: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: | + Burst timing value for COM parameter for port 1. + The fields for the above parameter must be as shown below:- + ceva,p1-burst-params = /bits/ 8 <BMX BNM SFD PTST>; + items: + - description: BMX - COM Burst Maximum. + - description: BNM - COM Burst Nominal. + - description: SFD - Signal Failure Detection value. + - description: PTST - Partial to Slumber timer value. + + ceva,p1-retry-params: + $ref: /schemas/types.yaml#/definitions/uint16-array + description: | + Retry interval timing value for port 1. + The fields for the above parameter must be as shown below:- + ceva,pN-retry-params = /bits/ 16 <RIT RCT>; + items: + - description: RIT - Retry Interval Timer. + - description: RCT - Rate Change Timer. + + ceva,broken-gen2: + $ref: /schemas/types.yaml#/definitions/flag + description: | + limit to gen1 speed instead of gen2. + + phys: + maxItems: 1 + + phy-names: + items: + - const: sata-phy + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + - ceva,p0-cominit-params + - ceva,p0-comwake-params + - ceva,p0-burst-params + - ceva,p0-retry-params + - ceva,p1-cominit-params + - ceva,p1-comwake-params + - ceva,p1-burst-params + - ceva,p1-retry-params + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/xlnx-zynqmp-power.h> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h> + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + #include <dt-bindings/phy/phy.h> + + sata: ahci@fd0c0000 { + compatible = "ceva,ahci-1v84"; + reg = <0xfd0c0000 0x200>; + interrupt-parent = <&gic>; + interrupts = <0 133 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zynqmp_clk SATA_REF>; + ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; + ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; + ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; + ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>; + ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; + ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; + ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; + ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>; + ceva,broken-gen2; + phys = <&psgtr 1 PHY_TYPE_SATA 1 1>; + resets = <&zynqmp_reset ZYNQMP_RESET_SATA>; + }; diff --git a/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml index 5b9705079015..8e9e6ff35d7d 100644 --- a/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml +++ b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml @@ -28,11 +28,9 @@ properties: - const: qcom,ssc-block-bus reg: - description: | - Shall contain the addresses of the SSCAON_CONFIG0 and SSCAON_CONFIG1 - registers - minItems: 2 - maxItems: 2 + items: + - description: SSCAON_CONFIG0 registers + - description: SSCAON_CONFIG1 registers reg-names: items: @@ -48,7 +46,6 @@ properties: ranges: true clocks: - minItems: 6 maxItems: 6 clock-names: @@ -61,9 +58,9 @@ properties: - const: ssc_ahbs power-domains: - description: Power domain phandles for the ssc_cx and ssc_mx power domains - minItems: 2 - maxItems: 2 + items: + - description: CX power domain + - description: MX power domain power-domain-names: items: @@ -71,11 +68,11 @@ properties: - const: ssc_mx resets: - description: | - Reset phandles for the ssc_reset and ssc_bcr resets (note: ssc_bcr is the - branch control register associated with the ssc_xo and ssc_ahbs clocks) - minItems: 2 - maxItems: 2 + items: + - description: Main reset + - description: + SSC Branch Control Register reset (associated with the ssc_xo and + ssc_ahbs clocks) reset-names: items: diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt deleted file mode 100644 index 1cc3aa10dcb1..000000000000 --- a/Documentation/devicetree/bindings/chosen.txt +++ /dev/null @@ -1,137 +0,0 @@ -The chosen node ---------------- - -The chosen node does not represent a real device, but serves as a place -for passing data between firmware and the operating system, like boot -arguments. Data in the chosen node does not represent the hardware. - -The following properties are recognized: - - -kaslr-seed ------------ - -This property is used when booting with CONFIG_RANDOMIZE_BASE as the -entropy used to randomize the kernel image base address location. Since -it is used directly, this value is intended only for KASLR, and should -not be used for other purposes (as it may leak information about KASLR -offsets). It is parsed as a u64 value, e.g. - -/ { - chosen { - kaslr-seed = <0xfeedbeef 0xc0def00d>; - }; -}; - -Note that if this property is set from UEFI (or a bootloader in EFI -mode) when EFI_RNG_PROTOCOL is supported, it will be overwritten by -the Linux EFI stub (which will populate the property itself, using -EFI_RNG_PROTOCOL). - -stdout-path ------------ - -Device trees may specify the device to be used for boot console output -with a stdout-path property under /chosen, as described in the Devicetree -Specification, e.g. - -/ { - chosen { - stdout-path = "/serial@f00:115200"; - }; - - serial@f00 { - compatible = "vendor,some-uart"; - reg = <0xf00 0x10>; - }; -}; - -If the character ":" is present in the value, this terminates the path. -The meaning of any characters following the ":" is device-specific, and -must be specified in the relevant binding documentation. - -For UART devices, the preferred binding is a string in the form: - - <baud>{<parity>{<bits>{<flow>}}} - -where - - baud - baud rate in decimal - parity - 'n' (none), 'o', (odd) or 'e' (even) - bits - number of data bits - flow - 'r' (rts) - -For example: 115200n8r - -Implementation note: Linux will look for the property "linux,stdout-path" or -on PowerPC "stdout" if "stdout-path" is not found. However, the -"linux,stdout-path" and "stdout" properties are deprecated. New platforms -should only use the "stdout-path" property. - -linux,booted-from-kexec ------------------------ - -This property is set (currently only on PowerPC, and only needed on -book3e) by some versions of kexec-tools to tell the new kernel that it -is being booted by kexec, as the booting environment may differ (e.g. -a different secondary CPU release mechanism) - -linux,usable-memory-range -------------------------- - -This property holds a base address and size, describing a limited region in -which memory may be considered available for use by the kernel. Memory outside -of this range is not available for use. - -This property describes a limitation: memory within this range is only -valid when also described through another mechanism that the kernel -would otherwise use to determine available memory (e.g. memory nodes -or the EFI memory map). Valid memory may be sparse within the range. -e.g. - -/ { - chosen { - linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>; - }; -}; - -The main usage is for crash dump kernel to identify its own usable -memory and exclude, at its boot time, any other memory areas that are -part of the panicked kernel's memory. - -While this property does not represent a real hardware, the address -and the size are expressed in #address-cells and #size-cells, -respectively, of the root node. - -linux,elfcorehdr ----------------- - -This property holds the memory range, the address and the size, of the elf -core header which mainly describes the panicked kernel's memory layout as -PT_LOAD segments of elf format. -e.g. - -/ { - chosen { - linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>; - }; -}; - -While this property does not represent a real hardware, the address -and the size are expressed in #address-cells and #size-cells, -respectively, of the root node. - -linux,initrd-start and linux,initrd-end ---------------------------------------- - -These properties hold the physical start and end address of an initrd that's -loaded by the bootloader. Note that linux,initrd-start is inclusive, but -linux,initrd-end is exclusive. -e.g. - -/ { - chosen { - linux,initrd-start = <0x82000000>; - linux,initrd-end = <0x82800000>; - }; -}; diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml index 2d98f7c4d3bc..50ebd8c57795 100644 --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml @@ -20,13 +20,24 @@ properties: compatible: const: google,cros-ec-typec - connector: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^connector@[0-9a-f]+$': $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + properties: + reg: + maxItems: 1 required: - compatible -additionalProperties: true #fixme +additionalProperties: false examples: - |+ diff --git a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml b/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml new file mode 100644 index 000000000000..5b875af6a95a --- /dev/null +++ b/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/chrome/google,cros-kbd-led-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ChromeOS keyboard backlight LED driver. + +maintainers: + - Tzung-Bi Shih <tzungbi@kernel.org> + +properties: + compatible: + const: google,cros-kbd-led-backlight + +required: + - compatible + +additionalProperties: false + +examples: + - | + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + cros_ec: ec@0 { + compatible = "google,cros-ec-spi"; + reg = <0>; + + kbd-led-backlight { + compatible = "google,cros-kbd-led-backlight"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml index e79eeac5f086..17caf78f0ccf 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml @@ -28,6 +28,9 @@ properties: - items: - const: allwinner,sun8i-r40-de2-clk - const: allwinner,sun8i-h3-de2-clk + - items: + - const: allwinner,sun20i-d1-de2-clk + - const: allwinner,sun50i-h5-de2-clk reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/efm32-clock.txt b/Documentation/devicetree/bindings/clock/efm32-clock.txt deleted file mode 100644 index 263d293f6a10..000000000000 --- a/Documentation/devicetree/bindings/clock/efm32-clock.txt +++ /dev/null @@ -1,11 +0,0 @@ -* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit - -Required properties: -- compatible: Should be "efm32gg,cmu" -- reg: Base address and length of the register set -- interrupts: Interrupt used by the CMU -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock ID in -its "clocks" phandle cell. The header efm32-clk.h contains a list of available -IDs. diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml index f415845b38dd..0b02378a3a0c 100644 --- a/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml @@ -13,7 +13,6 @@ maintainers: properties: compatible: enum: - - allwinner,sun4i-a10-pll3-2x-clk - fixed-factor-clock "#clock-cells": diff --git a/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml b/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml new file mode 100644 index 000000000000..f2c48460a399 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/fsl,scu-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - Clock bindings based on SCU Message Protocol + +maintainers: + - Abel Vesa <abel.vesa@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + This binding uses the common clock binding. + (Documentation/devicetree/bindings/clock/clock-bindings.txt) + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See the full list of clock IDs from + include/dt-bindings/clock/imx8qxp-clock.h + +properties: + compatible: + items: + - enum: + - fsl,imx8dxl-clk + - fsl,imx8qm-clk + - fsl,imx8qxp-clk + - const: fsl,scu-clk + + '#clock-cells': + const: 2 + +required: + - compatible + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller { + compatible = "fsl,imx8qxp-clk", "fsl,scu-clk"; + #clock-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml new file mode 100644 index 000000000000..771db2ddf026 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/nuvoton,npcm845-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NPCM8XX Clock Controller Binding + +maintainers: + - Tomer Maimon <tmaimon77@gmail.com> + +description: | + Nuvoton Arbel BMC NPCM8XX contains an integrated clock controller, which + generates and supplies clocks to all modules within the BMC. + +properties: + compatible: + enum: + - nuvoton,npcm845-clk + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + description: + See include/dt-bindings/clock/nuvoton,npcm8xx-clock.h for the full + list of NPCM8XX clock IDs. + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + ahb { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@f0801000 { + compatible = "nuvoton,npcm845-clk"; + reg = <0x0 0xf0801000 0x0 0x1000>; + #clock-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml index 31497677e8de..7a8d375e055e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml @@ -4,18 +4,19 @@ $id: http://devicetree.org/schemas/clock/qcom,dispcc-sm8x50.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250 +title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250/SM8350 maintainers: - Jonathan Marek <jonathan@marek.ca> description: | Qualcomm display clock control module which supports the clocks, resets and - power domains on SM8150 and SM8250. + power domains on SM8150/SM8250/SM8350. See also: dt-bindings/clock/qcom,dispcc-sm8150.h dt-bindings/clock/qcom,dispcc-sm8250.h + dt-bindings/clock/qcom,dispcc-sm8350.h properties: compatible: @@ -23,6 +24,7 @@ properties: - qcom,sc8180x-dispcc - qcom,sm8150-dispcc - qcom,sm8250-dispcc + - qcom,sm8350-dispcc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index 9fafcb080069..3cf404c9325a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/clock/qcom,gcc-apq8064.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Global Clock & Reset Controller Binding for APQ8064 +title: Qualcomm Global Clock & Reset Controller Binding for APQ8064/MSM8960 allOf: - $ref: qcom,gcc.yaml# @@ -23,11 +23,25 @@ description: | properties: compatible: - const: qcom,gcc-apq8064 + oneOf: + - items: + - enum: + - qcom,gcc-apq8064 + - qcom,gcc-msm8960 + - const: syscon + - enum: + - qcom,gcc-apq8064 + - qcom,gcc-msm8960 + deprecated: true + + thermal-sensor: + description: child tsens device + $ref: /schemas/thermal/qcom-tsens.yaml# nvmem-cells: minItems: 1 maxItems: 2 + deprecated: true description: Qualcomm TSENS (thermal sensor device) on some devices can be part of GCC and hence the TSENS properties can also be part @@ -37,31 +51,39 @@ properties: nvmem-cell-names: minItems: 1 + deprecated: true items: - const: calib - const: calib_backup '#thermal-sensor-cells': const: 1 + deprecated: true required: - compatible - - nvmem-cells - - nvmem-cell-names - - '#thermal-sensor-cells' unevaluatedProperties: false examples: - | clock-controller@900000 { - compatible = "qcom,gcc-apq8064"; + compatible = "qcom,gcc-apq8064", "syscon"; reg = <0x00900000 0x4000>; - nvmem-cells = <&tsens_calib>, <&tsens_backup>; - nvmem-cell-names = "calib", "calib_backup"; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; - #thermal-sensor-cells = <1>; + + thermal-sensor { + compatible = "qcom,msm8960-tsens"; + + nvmem-cells = <&tsens_calib>, <&tsens_backup>; + nvmem-cell-names = "calib", "calib_backup"; + interrupts = <0 178 4>; + interrupt-names = "uplow"; + + #qcom,sensors = <11>; + #thermal-sensor-cells = <1>; + }; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml index 98572b4a9b60..21470f52ce36 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml @@ -24,6 +24,9 @@ properties: '#clock-cells': const: 1 + '#power-domain-cells': + const: 1 + '#reset-cells': const: 1 @@ -38,6 +41,7 @@ required: - compatible - reg - '#clock-cells' + - '#power-domain-cells' - '#reset-cells' additionalProperties: false @@ -48,6 +52,7 @@ examples: compatible = "qcom,gcc-ipq8074"; reg = <0x01800000 0x80000>; #clock-cells = <1>; + #power-domain-cells = <1>; #reset-cells = <1>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml index 5a5b2214f0ca..005e0edd4609 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml @@ -22,16 +22,32 @@ properties: const: qcom,gcc-msm8996 clocks: + minItems: 3 items: - description: XO source - description: Second XO source - description: Sleep clock source + - description: PCIe 0 PIPE clock (optional) + - description: PCIe 1 PIPE clock (optional) + - description: PCIe 2 PIPE clock (optional) + - description: USB3 PIPE clock (optional) + - description: UFS RX symbol 0 clock (optional) + - description: UFS RX symbol 1 clock (optional) + - description: UFS TX symbol 0 clock (optional) clock-names: + minItems: 3 items: - const: cxo - const: cxo2 - const: sleep_clk + - const: pcie_0_pipe_clk_src + - const: pcie_1_pipe_clk_src + - const: pcie_2_pipe_clk_src + - const: usb3_phy_pipe_clk_src + - const: ufs_rx_symbol_0_clk_src + - const: ufs_rx_symbol_1_clk_src + - const: ufs_tx_symbol_0_clk_src '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml index 6c45e0f85494..6c78df0c46a9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -44,7 +44,6 @@ properties: - qcom,gcc-msm8916 - qcom,gcc-msm8939 - qcom,gcc-msm8953 - - qcom,gcc-msm8960 - qcom,gcc-msm8974 - qcom,gcc-msm8974pro - qcom,gcc-msm8974pro-ac @@ -58,10 +57,10 @@ required: unevaluatedProperties: false examples: - # Example for GCC for MSM8960: + # Example for GCC for MSM8974: - | clock-controller@900000 { - compatible = "qcom,gcc-msm8960"; + compatible = "qcom,gcc-msm8974"; reg = <0x900000 0x4000>; #clock-cells = <1>; #reset-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml index d902f137ab17..daf7906ebc40 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml @@ -43,6 +43,9 @@ properties: '#reset-cells': const: 1 + power-domains: + maxItems: 1 + '#power-domain-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml new file mode 100644 index 000000000000..0a0546c079a9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gpucc-sm8350.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller Binding + +maintainers: + - Robert Foss <robert.foss@linaro.org> + +description: | + Qualcomm graphics clock control module which supports the clocks, resets and + power domains on Qualcomm SoCs. + + See also: + dt-bindings/clock/qcom,gpucc-sm8350.h + +properties: + compatible: + enum: + - qcom,sm8350-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + - description: GPLL0 div branch source + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm8350.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@3d90000 { + compatible = "qcom,sm8350-gpucc"; + reg = <0 0x03d90000 0 0x9000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml index 9d296b89a8d0..d63b45ad06e8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -49,15 +49,86 @@ properties: const: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 2 clock-names: - const: xo + minItems: 1 + maxItems: 2 required: - compatible - '#clock-cells' +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,rpmcc-apq8060 + - qcom,rpmcc-ipq806x + - qcom,rpmcc-msm8660 + + then: + properties: + clocks: + items: + - description: pxo clock + + clock-names: + items: + - const: pxo + + - if: + properties: + compatible: + contains: + const: qcom,rpmcc-apq8064 + then: + properties: + clocks: + items: + - description: pxo clock + - description: cxo clock + + clock-names: + items: + - const: pxo + - const: cxo + + - if: + properties: + compatible: + contains: + enum: + - qcom,rpmcc-mdm9607 + - qcom,rpmcc-msm8226 + - 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 + + then: + properties: + clocks: + items: + - description: xo clock + + clock-names: + items: + - const: xo + additionalProperties: false examples: @@ -73,3 +144,13 @@ examples: }; }; }; + + - | + rpm { + clock-controller { + compatible = "qcom,rpmcc-ipq806x", "qcom,rpmcc"; + #clock-cells = <1>; + clocks = <&pxo_board>; + clock-names = "pxo"; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml new file mode 100644 index 000000000000..268f4c6ae0ee --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SM8450 + +maintainers: + - Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SM8450. + + See also include/dt-bindings/clock/qcom,sm8450-camcc.h + +properties: + compatible: + const: qcom,sm8450-camcc + + clocks: + items: + - description: Camera AHB clock from GCC + - description: Board XO source + - description: Board active XO source + - description: Sleep clock source + + power-domains: + maxItems: 1 + description: + A phandle and PM domain specifier for the MMCX power domain. + + required-opps: + description: + A phandle to an OPP node describing required MMCX performance point. + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - power-domains + - required-opps + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm8450.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + clock-controller@ade0000 { + compatible = "qcom,sm8450-camcc"; + reg = <0xade0000 0x20000>; + clocks = <&gcc GCC_CAMERA_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + power-domains = <&rpmhpd SM8450_MMCX>; + required-opps = <&rpmhpd_opp_low_svs>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index 8880b834f264..d036675e0779 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -45,10 +45,9 @@ 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/r9a0*-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> or - <dt-bindings/clock/r9a09g011-cpg.h>. + a module number, as defined in <dt-bindings/clock/r9a0*-cpg.h>. const: 2 '#power-domain-cells': @@ -62,7 +61,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> or <dt-bindings/clock/r9a09g011-cpg.h>. + <dt-bindings/clock/r9a0*-cpg.h>. const: 1 required: diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml index 5073e569a47f..006d33a9e0f1 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml @@ -33,6 +33,7 @@ properties: enum: - samsung,exynos7885-cmu-top - samsung,exynos7885-cmu-core + - samsung,exynos7885-cmu-fsys - samsung,exynos7885-cmu-peri clocks: @@ -92,6 +93,32 @@ allOf: properties: compatible: contains: + const: samsung,exynos7885-cmu-fsys + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_FSYS bus clock (from CMU_TOP) + - description: MMC_CARD clock (from CMU_TOP) + - description: MMC_EMBD clock (from CMU_TOP) + - description: MMC_SDIO clock (from CMU_TOP) + - description: USB30DRD clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dout_fsys_bus + - const: dout_fsys_mmc_card + - const: dout_fsys_mmc_embd + - const: dout_fsys_mmc_sdio + - const: dout_fsys_usb30drd + + - if: + properties: + compatible: + contains: const: samsung,exynos7885-cmu-peri then: diff --git a/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml new file mode 100644 index 000000000000..5f747b0471cf --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2022 Unisoc Inc. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: UMS512 Soc clock controller + +maintainers: + - Orson Zhai <orsonzhai@gmail.com> + - Baolin Wang <baolin.wang7@gmail.com> + - Chunyan Zhang <zhang.lyra@gmail.com> + +properties: + compatible: + enum: + - sprd,ums512-apahb-gate + - sprd,ums512-ap-clk + - sprd,ums512-aonapb-clk + - sprd,ums512-pmu-gate + - sprd,ums512-g0-pll + - sprd,ums512-g2-pll + - sprd,ums512-g3-pll + - sprd,ums512-gc-pll + - sprd,ums512-aon-gate + - sprd,ums512-audcpapb-gate + - sprd,ums512-audcpahb-gate + - sprd,ums512-gpu-clk + - sprd,ums512-mm-clk + - sprd,ums512-mm-gate-clk + - sprd,ums512-apapb-gate + + "#clock-cells": + const: 1 + + clocks: + minItems: 1 + maxItems: 4 + description: | + The input parent clock(s) phandle for the clock, only list + fixed clocks which are declared in devicetree. + + clock-names: + minItems: 1 + items: + - const: ext-26m + - const: ext-32k + - const: ext-4m + - const: rco-100m + + reg: + maxItems: 1 + +required: + - compatible + - '#clock-cells' + - reg + +additionalProperties: false + +examples: + - | + ap_clk: clock-controller@20200000 { + compatible = "sprd,ums512-ap-clk"; + reg = <0x20200000 0x1000>; + clocks = <&ext_26m>; + clock-names = "ext-26m"; + #clock-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index f8c474227807..242fe922b035 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -78,6 +78,7 @@ if: contains: enum: - st,stm32mp1-rcc-secure + - st,stm32mp13-rcc then: properties: clocks: diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt index 55a18939bddd..c918075405ba 100644 --- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt @@ -78,7 +78,7 @@ Required properties: - #clock-cells : from common clock binding; shall be set to 1 (multiple clock outputs). -- clocks : must be set to the parent's phandle. it's could be output clocks of +- clocks : must be set to the parent's phandle. it could be output clocks of a quadsfs or/and a pll or/and clk_sysin (up to 7 clocks) - clock-output-names : List of strings used to name the clock outputs. diff --git a/Documentation/devicetree/bindings/clock/sunplus,sp7021-clkc.yaml b/Documentation/devicetree/bindings/clock/sunplus,sp7021-clkc.yaml new file mode 100644 index 000000000000..bcc14088220a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sunplus,sp7021-clkc.yaml @@ -0,0 +1,52 @@ +# 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/clock/sunplus,sp7021-clkc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SP7021 SoC Clock Controller + +maintainers: + - Qin Jian <qinjian@cqplus1.com> + +properties: + compatible: + const: sunplus,sp7021-clkc + + reg: + maxItems: 3 + + clocks: + maxItems: 1 + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - "#clock-cells" + +additionalProperties: false + +examples: + - | + extclk: osc0 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <27000000>; + clock-output-names = "extclk"; + }; + + clkc: clock-controller@9c000004 { + compatible = "sunplus,sp7021-clkc"; + reg = <0x9c000004 0x28>, + <0x9c000200 0x44>, + <0x9c000268 0x08>; + clocks = <&extclk>; + #clock-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt b/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt index 36998e184821..c9894538315b 100644 --- a/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt +++ b/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt @@ -15,7 +15,7 @@ Required properties: - for "ti,da850-pll1", shall be "clksrc" Optional properties: -- ti,clkmode-square-wave: Indicates that the the board is supplying a square +- ti,clkmode-square-wave: Indicates that the board is supplying a square wave input on the OSCIN pin instead of using a crystal oscillator. This property is only valid when compatible = "ti,da850-pll0". diff --git a/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt index 21c002d28b9b..68504079f99f 100644 --- a/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt +++ b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt @@ -6,7 +6,7 @@ functional clock but can be configured to provide different clocks. ATL can maintain a clock averages to some desired frequency based on the bws/aws signals - can compensate the drift between the two ws signal. -In order to provide the support for ATL and it's output clocks (which can be used +In order to provide the support for ATL and its output clocks (which can be used internally within the SoC or external components) two sets of bindings is needed: Clock tree binding: diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 0420fa563532..ae515651fc6b 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -263,11 +263,11 @@ examples: # Micro-USB connector with HS lines routed via controller (MUIC). - | muic-max77843 { - usb_con1: connector { - compatible = "usb-b-connector"; - label = "micro-USB"; - type = "micro"; - }; + usb_con1: connector { + compatible = "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + }; }; # USB-C connector attached to CC controller (s2mm005), HS lines routed @@ -275,34 +275,34 @@ examples: # DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. - | ccic: s2mm005 { - usb_con2: connector { - compatible = "usb-c-connector"; - label = "USB-C"; + usb_con2: connector { + compatible = "usb-c-connector"; + label = "USB-C"; - ports { - #address-cells = <1>; - #size-cells = <0>; + ports { + #address-cells = <1>; + #size-cells = <0>; - port@0 { - reg = <0>; - usb_con_hs: endpoint { - remote-endpoint = <&max77865_usbc_hs>; - }; - }; - port@1 { - reg = <1>; - usb_con_ss: endpoint { - remote-endpoint = <&usbdrd_phy_ss>; - }; - }; - port@2 { - reg = <2>; - usb_con_sbu: endpoint { - remote-endpoint = <&dp_aux>; + port@0 { + reg = <0>; + usb_con_hs: endpoint { + remote-endpoint = <&max77865_usbc_hs>; + }; + }; + port@1 { + reg = <1>; + usb_con_ss: endpoint { + remote-endpoint = <&usbdrd_phy_ss>; + }; + }; + port@2 { + reg = <2>; + usb_con_sbu: endpoint { + remote-endpoint = <&dp_aux>; + }; + }; }; - }; }; - }; }; # USB-C connector attached to a typec port controller(ptn5110), which has @@ -310,16 +310,16 @@ examples: - | #include <dt-bindings/usb/pd.h> typec: ptn5110 { - usb_con3: connector { - compatible = "usb-c-connector"; - label = "USB-C"; - power-role = "dual"; - try-power-role = "sink"; - source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>; - sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) - PDO_VAR(5000, 12000, 2000)>; - op-sink-microwatt = <10000000>; - }; + usb_con3: connector { + compatible = "usb-c-connector"; + label = "USB-C"; + power-role = "dual"; + try-power-role = "sink"; + source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>; + sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) + PDO_VAR(5000, 12000, 2000)>; + op-sink-microwatt = <10000000>; + }; }; # USB-C connector attached to SoC and USB3 typec port controller(hd3ss3220) @@ -332,20 +332,20 @@ examples: data-role = "dual"; ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - hs_ep: endpoint { - remote-endpoint = <&usb3_hs_ep>; - }; + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + hs_ep: endpoint { + remote-endpoint = <&usb3_hs_ep>; }; - port@1 { - reg = <1>; - ss_ep: endpoint { - remote-endpoint = <&hd3ss3220_in_ep>; - }; + }; + port@1 { + reg = <1>; + ss_ep: endpoint { + remote-endpoint = <&hd3ss3220_in_ep>; }; + }; }; }; @@ -354,12 +354,12 @@ examples: #include <dt-bindings/gpio/gpio.h> usb { - connector { - compatible = "gpio-usb-b-connector", "usb-b-connector"; - type = "micro"; - id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; - vbus-supply = <&usb_p0_vbus>; - }; + connector { + compatible = "gpio-usb-b-connector", "usb-b-connector"; + type = "micro"; + id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; + vbus-supply = <&usb_p0_vbus>; + }; }; # Micro-USB connector with HS lines routed via controller (MUIC) and MHL @@ -367,27 +367,27 @@ examples: # mobile phone - | muic-max77843 { - usb_con4: connector { - compatible = "samsung,usb-connector-11pin", "usb-b-connector"; - label = "micro-USB"; - type = "micro"; + usb_con4: connector { + compatible = "samsung,usb-connector-11pin", "usb-b-connector"; + label = "micro-USB"; + type = "micro"; - ports { - #address-cells = <1>; - #size-cells = <0>; + ports { + #address-cells = <1>; + #size-cells = <0>; - port@0 { - reg = <0>; - muic_to_usb: endpoint { - remote-endpoint = <&usb_to_muic>; - }; - }; - port@3 { - reg = <3>; - usb_con_mhl: endpoint { - remote-endpoint = <&sii8620_mhl>; + port@0 { + reg = <0>; + muic_to_usb: endpoint { + remote-endpoint = <&usb_to_muic>; + }; + }; + port@3 { + reg = <3>; + usb_con_mhl: endpoint { + remote-endpoint = <&sii8620_mhl>; + }; + }; }; - }; }; - }; }; diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index 2f1b8b6852a0..24fa3d87a40b 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -25,6 +25,7 @@ properties: - description: v2 of CPUFREQ HW (EPSS) items: - enum: + - qcom,sm6375-cpufreq-epss - qcom,sm8250-cpufreq-epss - const: qcom,cpufreq-epss diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml index a9a776da5505..a11e1b867379 100644 --- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml +++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml @@ -22,6 +22,13 @@ select: compatible: contains: enum: + - qcom,apq8064 + - qcom,apq8096 + - qcom,ipq8064 + - qcom,msm8939 + - qcom,msm8960 + - qcom,msm8974 + - qcom,msm8996 - qcom,qcs404 required: - compatible @@ -63,8 +70,8 @@ additionalProperties: true examples: - | / { - model = "Qualcomm Technologies, Inc. QCS404"; - compatible = "qcom,qcs404"; + model = "Qualcomm Technologies, Inc. QCS404 EVB 1000"; + compatible = "qcom,qcs404-evb-1000", "qcom,qcs404-evb", "qcom,qcs404"; #address-cells = <2>; #size-cells = <2>; diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt deleted file mode 100644 index bcaa2c08ac11..000000000000 --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt +++ /dev/null @@ -1,488 +0,0 @@ -* Generic Exynos Bus frequency device - -The Samsung Exynos SoC has many buses for data transfer between DRAM -and sub-blocks in SoC. Most Exynos SoCs share the common architecture -for buses. Generally, each bus of Exynos SoC includes a source clock -and a power line, which are able to change the clock frequency -of the bus in runtime. To monitor the usage of each bus in runtime, -the driver uses the PPMU (Platform Performance Monitoring Unit), which -is able to measure the current load of sub-blocks. - -The Exynos SoC includes the various sub-blocks which have the each AXI bus. -The each AXI bus has the owned source clock but, has not the only owned -power line. The power line might be shared among one more sub-blocks. -So, we can divide into two type of device as the role of each sub-block. -There are two type of bus devices as following: -- parent bus device -- passive bus device - -Basically, parent and passive bus device share the same power line. -The parent bus device can only change the voltage of shared power line -and the rest bus devices (passive bus device) depend on the decision of -the parent bus device. If there are three blocks which share the VDD_xxx -power line, Only one block should be parent device and then the rest blocks -should depend on the parent device as passive device. - - VDD_xxx |--- A block (parent) - |--- B block (passive) - |--- C block (passive) - -There are a little different composition among Exynos SoC because each Exynos -SoC has different sub-blocks. Therefore, such difference should be specified -in devicetree file instead of each device driver. In result, this driver -is able to support the bus frequency for all Exynos SoCs. - -Required properties for all bus devices: -- compatible: Should be "samsung,exynos-bus". -- clock-names : the name of clock used by the bus, "bus". -- clocks : phandles for clock specified in "clock-names" property. -- operating-points-v2: the OPP table including frequency/voltage information - to support DVFS (Dynamic Voltage/Frequency Scaling) feature. - -Required properties only for parent bus device: -- vdd-supply: the regulator to provide the buses with the voltage. -- devfreq-events: the devfreq-event device to monitor the current utilization - of buses. - -Required properties only for passive bus device: -- devfreq: the parent bus device. - -Optional properties only for parent bus device: -- exynos,saturation-ratio: the percentage value which is used to calibrate - the performance count against total cycle count. - -Optional properties for the interconnect functionality (QoS frequency -constraints): -- #interconnect-cells: should be 0. -- interconnects: as documented in ../interconnect.txt, describes a path at the - higher level interconnects used by this interconnect provider. - If this interconnect provider is directly linked to a top level interconnect - provider the property contains only one phandle. The provider extends - the interconnect graph by linking its node to a node registered by provider - pointed to by first phandle in the 'interconnects' property. - -- samsung,data-clock-ratio: ratio of the data throughput in B/s to minimum data - clock frequency in Hz, default value is 8 when this property is missing. - -Detailed correlation between sub-blocks and power line according to Exynos SoC: -- In case of Exynos3250, there are two power line as following: - VDD_MIF |--- DMC - - VDD_INT |--- LEFTBUS (parent device) - |--- PERIL - |--- MFC - |--- G3D - |--- RIGHTBUS - |--- PERIR - |--- FSYS - |--- LCD0 - |--- PERIR - |--- ISP - |--- CAM - -- In case of Exynos4210, there is one power line as following: - VDD_INT |--- DMC (parent device) - |--- LEFTBUS - |--- PERIL - |--- MFC(L) - |--- G3D - |--- TV - |--- LCD0 - |--- RIGHTBUS - |--- PERIR - |--- MFC(R) - |--- CAM - |--- FSYS - |--- GPS - |--- LCD0 - |--- LCD1 - -- In case of Exynos4x12, there are two power line as following: - VDD_MIF |--- DMC - - VDD_INT |--- LEFTBUS (parent device) - |--- PERIL - |--- MFC(L) - |--- G3D - |--- TV - |--- IMAGE - |--- RIGHTBUS - |--- PERIR - |--- MFC(R) - |--- CAM - |--- FSYS - |--- GPS - |--- LCD0 - |--- ISP - -- In case of Exynos5422, there are two power line as following: - VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller) - |--- DREX 1 - - VDD_INT |--- NoC_Core (parent device) - |--- G2D - |--- G3D - |--- DISP1 - |--- NoC_WCORE - |--- GSCL - |--- MSCL - |--- ISP - |--- MFC - |--- GEN - |--- PERIS - |--- PERIC - |--- FSYS - |--- FSYS2 - -- In case of Exynos5433, there is VDD_INT power line as following: - VDD_INT |--- G2D (parent device) - |--- MSCL - |--- GSCL - |--- JPEG - |--- MFC - |--- HEVC - |--- BUS0 - |--- BUS1 - |--- BUS2 - |--- PERIS (Fixed clock rate) - |--- PERIC (Fixed clock rate) - |--- FSYS (Fixed clock rate) - -Example 1: - Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to - power line (regulator). The MIF (Memory Interface) AXI bus is used to - transfer data between DRAM and CPU and uses the VDD_MIF regulator. - - - MIF (Memory Interface) block - : VDD_MIF |--- DMC (Dynamic Memory Controller) - - - INT (Internal) block - : VDD_INT |--- LEFTBUS (parent device) - |--- PERIL - |--- MFC - |--- G3D - |--- RIGHTBUS - |--- FSYS - |--- LCD0 - |--- PERIR - |--- ISP - |--- CAM - - - MIF bus's frequency/voltage table - ----------------------- - |Lv| Freq | Voltage | - ----------------------- - |L1| 50000 |800000 | - |L2| 100000 |800000 | - |L3| 134000 |800000 | - |L4| 200000 |825000 | - |L5| 400000 |875000 | - ----------------------- - - - INT bus's frequency/voltage table - ---------------------------------------------------------- - |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP |PERIL ||VDD_INT | - | name| |LCD0 | | | || | - | | |FSYS | | | || | - | | |MFC | | | || | - ---------------------------------------------------------- - |Mode |*parent|passive |passive|passive|passive|| | - ---------------------------------------------------------- - |Lv |Frequency ||Voltage | - ---------------------------------------------------------- - |L1 |50000 |50000 |50000 |50000 |50000 ||900000 | - |L2 |80000 |80000 |80000 |80000 |80000 ||900000 | - |L3 |100000 |100000 |100000 |100000 |100000 ||1000000 | - |L4 |134000 |134000 |200000 |200000 | ||1000000 | - |L5 |200000 |200000 |400000 |300000 | ||1000000 | - ---------------------------------------------------------- - -Example 2: - The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi - is listed below: - - bus_dmc: bus_dmc { - compatible = "samsung,exynos-bus"; - clocks = <&cmu_dmc CLK_DIV_DMC>; - clock-names = "bus"; - operating-points-v2 = <&bus_dmc_opp_table>; - status = "disabled"; - }; - - bus_dmc_opp_table: opp_table1 { - compatible = "operating-points-v2"; - opp-shared; - - opp-50000000 { - opp-hz = /bits/ 64 <50000000>; - opp-microvolt = <800000>; - }; - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - opp-microvolt = <800000>; - }; - opp-134000000 { - opp-hz = /bits/ 64 <134000000>; - opp-microvolt = <800000>; - }; - opp-200000000 { - opp-hz = /bits/ 64 <200000000>; - opp-microvolt = <825000>; - }; - opp-400000000 { - opp-hz = /bits/ 64 <400000000>; - opp-microvolt = <875000>; - }; - }; - - bus_leftbus: bus_leftbus { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_GDL>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_rightbus: bus_rightbus { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_GDR>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_lcd0: bus_lcd0 { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_ACLK_160>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_fsys: bus_fsys { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_ACLK_200>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_mcuisp: bus_mcuisp { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>; - clock-names = "bus"; - operating-points-v2 = <&bus_mcuisp_opp_table>; - status = "disabled"; - }; - - bus_isp: bus_isp { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_ACLK_266>; - clock-names = "bus"; - operating-points-v2 = <&bus_isp_opp_table>; - status = "disabled"; - }; - - bus_peril: bus_peril { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_DIV_ACLK_100>; - clock-names = "bus"; - operating-points-v2 = <&bus_peril_opp_table>; - status = "disabled"; - }; - - bus_mfc: bus_mfc { - compatible = "samsung,exynos-bus"; - clocks = <&cmu CLK_SCLK_MFC>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_leftbus_opp_table: opp_table1 { - compatible = "operating-points-v2"; - opp-shared; - - opp-50000000 { - opp-hz = /bits/ 64 <50000000>; - opp-microvolt = <900000>; - }; - opp-80000000 { - opp-hz = /bits/ 64 <80000000>; - opp-microvolt = <900000>; - }; - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - opp-microvolt = <1000000>; - }; - opp-134000000 { - opp-hz = /bits/ 64 <134000000>; - opp-microvolt = <1000000>; - }; - opp-200000000 { - opp-hz = /bits/ 64 <200000000>; - opp-microvolt = <1000000>; - }; - }; - - bus_mcuisp_opp_table: opp_table2 { - compatible = "operating-points-v2"; - opp-shared; - - opp-50000000 { - opp-hz = /bits/ 64 <50000000>; - }; - opp-80000000 { - opp-hz = /bits/ 64 <80000000>; - }; - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - }; - opp-200000000 { - opp-hz = /bits/ 64 <200000000>; - }; - opp-400000000 { - opp-hz = /bits/ 64 <400000000>; - }; - }; - - bus_isp_opp_table: opp_table3 { - compatible = "operating-points-v2"; - opp-shared; - - opp-50000000 { - opp-hz = /bits/ 64 <50000000>; - }; - opp-80000000 { - opp-hz = /bits/ 64 <80000000>; - }; - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - }; - opp-200000000 { - opp-hz = /bits/ 64 <200000000>; - }; - opp-300000000 { - opp-hz = /bits/ 64 <300000000>; - }; - }; - - bus_peril_opp_table: opp_table4 { - compatible = "operating-points-v2"; - opp-shared; - - opp-50000000 { - opp-hz = /bits/ 64 <50000000>; - }; - opp-80000000 { - opp-hz = /bits/ 64 <80000000>; - }; - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - }; - }; - - - Usage case to handle the frequency and voltage of bus on runtime - in exynos3250-rinato.dts is listed below: - - &bus_dmc { - devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>; - vdd-supply = <&buck1_reg>; /* VDD_MIF */ - status = "okay"; - }; - - &bus_leftbus { - devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>; - vdd-supply = <&buck3_reg>; - status = "okay"; - }; - - &bus_rightbus { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - - &bus_lcd0 { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - - &bus_fsys { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - - &bus_mcuisp { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - - &bus_isp { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - - &bus_peril { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - - &bus_mfc { - devfreq = <&bus_leftbus>; - status = "okay"; - }; - -Example 3: - An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on - Exynos4412 SoC with video mixer as an interconnect consumer device. - - soc { - bus_dmc: bus_dmc { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_DMC>; - clock-names = "bus"; - operating-points-v2 = <&bus_dmc_opp_table>; - samsung,data-clock-ratio = <4>; - #interconnect-cells = <0>; - }; - - bus_leftbus: bus_leftbus { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_GDL>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - #interconnect-cells = <0>; - interconnects = <&bus_dmc>; - }; - - bus_display: bus_display { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_ACLK160>; - clock-names = "bus"; - operating-points-v2 = <&bus_display_opp_table>; - #interconnect-cells = <0>; - interconnects = <&bus_leftbus &bus_dmc>; - }; - - bus_dmc_opp_table: opp_table1 { - compatible = "operating-points-v2"; - /* ... */ - } - - bus_leftbus_opp_table: opp_table3 { - compatible = "operating-points-v2"; - /* ... */ - }; - - bus_display_opp_table: opp_table4 { - compatible = "operating-points-v2"; - /* .. */ - }; - - &mixer { - compatible = "samsung,exynos4212-mixer"; - interconnects = <&bus_display &bus_dmc>; - /* ... */ - }; - }; diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml index c388ae5da1e4..c9c346e6228e 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml @@ -94,6 +94,7 @@ if: - allwinner,sun8i-a83t-display-engine - allwinner,sun8i-r40-display-engine - allwinner,sun9i-a80-display-engine + - allwinner,sun20i-d1-display-engine - allwinner,sun50i-a64-display-engine then: diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml index 4a92a4c7dcd7..f8168986a0a9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml @@ -233,6 +233,7 @@ allOf: - allwinner,sun8i-a83t-tcon-lcd - allwinner,sun8i-v3s-tcon - allwinner,sun9i-a80-tcon-lcd + - allwinner,sun20i-d1-tcon-lcd then: properties: @@ -252,6 +253,7 @@ allOf: - allwinner,sun8i-a83t-tcon-tv - allwinner,sun8i-r40-tcon-tv - allwinner,sun9i-a80-tcon-tv + - allwinner,sun20i-d1-tcon-tv then: properties: @@ -278,6 +280,7 @@ allOf: - allwinner,sun9i-a80-tcon-lcd - allwinner,sun4i-a10-tcon - allwinner,sun8i-a83t-tcon-lcd + - allwinner,sun20i-d1-tcon-lcd then: required: @@ -294,6 +297,7 @@ allOf: - allwinner,sun8i-a23-tcon - allwinner,sun8i-a33-tcon - allwinner,sun8i-a83t-tcon-lcd + - allwinner,sun20i-d1-tcon-lcd then: properties: diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.yaml b/Documentation/devicetree/bindings/display/arm,pl11x.yaml index b545c6d20325..6cc9045e5c68 100644 --- a/Documentation/devicetree/bindings/display/arm,pl11x.yaml +++ b/Documentation/devicetree/bindings/display/arm,pl11x.yaml @@ -159,25 +159,12 @@ examples: }; panel { - compatible = "arm,rtsm-display", "panel-dpi"; - power-supply = <&vcc_supply>; + compatible = "arm,rtsm-display"; port { clcd_panel: endpoint { remote-endpoint = <&clcd_pads>; }; }; - - panel-timing { - clock-frequency = <25175000>; - hactive = <640>; - hback-porch = <40>; - hfront-porch = <24>; - hsync-len = <96>; - vactive = <480>; - vback-porch = <32>; - vfront-porch = <11>; - vsync-len = <2>; - }; }; ... diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.txt b/Documentation/devicetree/bindings/display/atmel,lcdc.txt index acb5a0132127..b5e355ada2fa 100644 --- a/Documentation/devicetree/bindings/display/atmel,lcdc.txt +++ b/Documentation/devicetree/bindings/display/atmel,lcdc.txt @@ -9,7 +9,6 @@ Required properties: "atmel,at91sam9g45-lcdc" , "atmel,at91sam9g45es-lcdc" , "atmel,at91sam9rl-lcdc" , - "atmel,at32ap-lcdc" - reg : Should contain 1 register ranges(address and length). Can contain an additional register range(address and length) for fixed framebuffer memory. Useful for dedicated memories. diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 35a48515836e..4590186c4a0b 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -94,7 +94,22 @@ properties: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: - Video port for MIPI DSI input. + MIPI DSI/DPI input. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + type: object + additionalProperties: false + + properties: + remote-endpoint: true + + bus-type: + enum: [7] + default: 1 + + data-lanes: true port@1: $ref: /schemas/graph.yaml#/properties/port @@ -143,6 +158,8 @@ examples: reg = <0>; anx7625_in: endpoint { remote-endpoint = <&mipi_dsi>; + bus-type = <7>; + data-lanes = <0 1 2 3>; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml new file mode 100644 index 000000000000..94543006f5de --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-ldb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp LVDS Display Bridge + +maintainers: + - Liu Ying <victor.liu@nxp.com> + +description: | + The Freescale i.MX8qm/qxp LVDS Display Bridge(LDB) has two channels. + + The i.MX8qm/qxp LDB is controlled by Control and Status Registers(CSR) module. + The CSR module, as a system controller, contains the LDB's configuration + registers. + + For i.MX8qxp LDB, each channel supports up to 24bpp parallel input color + format and can map the input to VESA or JEIDA standards. The two channels + cannot be used simultaneously, that is to say, the user should pick one of + them to use. Two LDB channels from two LDB instances can work together in + LDB split mode to support a dual link LVDS display. The channel indexes + have to be different. Channel0 outputs odd pixels and channel1 outputs + even pixels. + + For i.MX8qm LDB, each channel additionally supports up to 30bpp parallel + input color format. The two channels can be used simultaneously, either + in dual mode or split mode. In dual mode, the two channels output identical + data. In split mode, channel0 outputs odd pixels and channel1 outputs even + pixels. + + A side note is that i.MX8qm/qxp LDB is officially called pixel mapper in + the SoC reference manuals. The pixel mapper uses logic of LDBs embedded in + i.MX6qdl/sx SoCs, i.e., it is essentially based on them. To keep the naming + consistency, this binding calls it LDB. + +properties: + compatible: + enum: + - fsl,imx8qm-ldb + - fsl,imx8qxp-ldb + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + clocks: + items: + - description: pixel clock + - description: bypass clock + + clock-names: + items: + - const: pixel + - const: bypass + + power-domains: + maxItems: 1 + + fsl,companion-ldb: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + A phandle which points to companion LDB which is used in LDB split mode. + +patternProperties: + "^channel@[0-1]$": + type: object + description: Represents a channel of LDB. + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + description: The channel index. + enum: [ 0, 1 ] + + phys: + description: A phandle to the phy module representing the LVDS PHY. + maxItems: 1 + + phy-names: + const: lvds_phy + + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input port of the channel. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output port of the channel. + + required: + - "#address-cells" + - "#size-cells" + - reg + - phys + - phy-names + + additionalProperties: false + +required: + - compatible + - "#address-cells" + - "#size-cells" + - clocks + - clock-names + - power-domains + - channel@0 + - channel@1 + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx8qm-ldb + then: + properties: + fsl,companion-ldb: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/firmware/imx/rsrc.h> + ldb { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx8qxp-ldb"; + clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>, + <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>; + clock-names = "pixel", "bypass"; + power-domains = <&pd IMX_SC_R_LVDS_0>; + + channel@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + phys = <&mipi_lvds_0_phy>; + phy-names = "lvds_phy"; + + port@0 { + reg = <0>; + + mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint { + remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0>; + }; + }; + }; + + channel@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + phys = <&mipi_lvds_0_phy>; + phy-names = "lvds_phy"; + + port@0 { + reg = <0>; + + mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi: endpoint { + remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml new file mode 100644 index 000000000000..50bae2122183 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Pixel Combiner + +maintainers: + - Liu Ying <victor.liu@nxp.com> + +description: | + The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a + single display controller and manipulates the two streams to support a number + of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as + either one screen, two screens, or virtual screens. The pixel combiner is + also responsible for generating some of the control signals for the pixel link + output channel. + +properties: + compatible: + enum: + - fsl,imx8qm-pixel-combiner + - fsl,imx8qxp-pixel-combiner + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: apb + + power-domains: + maxItems: 1 + +patternProperties: + "^channel@[0-1]$": + type: object + description: Represents a display stream of pixel combiner. + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + description: The display stream index. + enum: [ 0, 1 ] + + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input endpoint of the display stream. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the display stream. + + required: + - "#address-cells" + - "#size-cells" + - reg + - port@0 + - port@1 + + additionalProperties: false + +required: + - compatible + - "#address-cells" + - "#size-cells" + - reg + - clocks + - clock-names + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8-lpcg.h> + #include <dt-bindings/firmware/imx/rsrc.h> + pixel-combiner@56020000 { + compatible = "fsl,imx8qxp-pixel-combiner"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x56020000 0x10000>; + clocks = <&dc0_pixel_combiner_lpcg IMX_LPCG_CLK_4>; + clock-names = "apb"; + power-domains = <&pd IMX_SC_R_DC_0>; + + channel@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + port@0 { + reg = <0>; + + dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint { + remote-endpoint = <&dc0_dpu_disp0_dc0_pixel_combiner_ch0>; + }; + }; + + port@1 { + reg = <1>; + + dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint { + remote-endpoint = <&dc0_pixel_link0_dc0_pixel_combiner_ch0>; + }; + }; + }; + + channel@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + port@0 { + reg = <0>; + + dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint { + remote-endpoint = <&dc0_dpu_disp1_dc0_pixel_combiner_ch1>; + }; + }; + + port@1 { + reg = <1>; + + dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint { + remote-endpoint = <&dc0_pixel_link1_dc0_pixel_combiner_ch1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml new file mode 100644 index 000000000000..38ecc7926fad --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-link.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Display Pixel Link + +maintainers: + - Liu Ying <victor.liu@nxp.com> + +description: | + The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard + asynchronous linkage between pixel sources(display controller or + camera module) and pixel consumers(imaging or displays). + It consists of two distinct functions, a pixel transfer function and a + control interface. Multiple pixel channels can exist per one control channel. + This binding documentation is only for pixel links whose pixel sources are + display controllers. + + The i.MX8qm/qxp Display Pixel Link is accessed via System Controller Unit(SCU) + firmware. + +properties: + compatible: + enum: + - fsl,imx8qm-dc-pixel-link + - fsl,imx8qxp-dc-pixel-link + + fsl,dc-id: + $ref: /schemas/types.yaml#/definitions/uint8 + description: | + u8 value representing the display controller index that the pixel link + connects to. + + fsl,dc-stream-id: + $ref: /schemas/types.yaml#/definitions/uint8 + description: | + u8 value representing the display controller stream index that the pixel + link connects to. + enum: [0, 1] + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: The pixel link input port node from upstream video source. + + patternProperties: + "^port@[1-4]$": + $ref: /schemas/graph.yaml#/properties/port + description: The pixel link output port node to downstream bridge. + + required: + - port@0 + - port@1 + - port@2 + - port@3 + - port@4 + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx8qxp-dc-pixel-link + then: + properties: + fsl,dc-id: + const: 0 + + - if: + properties: + compatible: + contains: + const: fsl,imx8qm-dc-pixel-link + then: + properties: + fsl,dc-id: + enum: [0, 1] + +required: + - compatible + - fsl,dc-id + - fsl,dc-stream-id + - ports + +additionalProperties: false + +examples: + - | + dc0-pixel-link0 { + compatible = "fsl,imx8qxp-dc-pixel-link"; + fsl,dc-id = /bits/ 8 <0>; + fsl,dc-stream-id = /bits/ 8 <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* from dc0 pixel combiner channel0 */ + port@0 { + reg = <0>; + + dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint { + remote-endpoint = <&dc0_pixel_combiner_ch0_dc0_pixel_link0>; + }; + }; + + /* to PXL2DPIs in MIPI/LVDS combo subsystems */ + port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 { + reg = <0>; + remote-endpoint = <&mipi_lvds_0_pxl2dpi_dc0_pixel_link0>; + }; + + dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 { + reg = <1>; + remote-endpoint = <&mipi_lvds_1_pxl2dpi_dc0_pixel_link0>; + }; + }; + + /* unused */ + port@2 { + reg = <2>; + }; + + /* unused */ + port@3 { + reg = <3>; + }; + + /* to imaging subsystem */ + port@4 { + reg = <4>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml new file mode 100644 index 000000000000..e4e77fad05f1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface + +maintainers: + - Liu Ying <victor.liu@nxp.com> + +description: | + The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI) + interfaces the pixel link 36-bit data output and the DSI controller’s + MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module + used in LVDS mode, to remap the pixel color codings between those modules. + This module is purely combinatorial. + + The i.MX8qxp PXL2DPI is controlled by Control and Status Registers(CSR) module. + The CSR module, as a system controller, contains the PXL2DPI's configuration + register. + +properties: + compatible: + const: fsl,imx8qxp-pxl2dpi + + fsl,sc-resource: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The SCU resource ID associated with this PXL2DPI instance. + + power-domains: + maxItems: 1 + + fsl,companion-pxl2dpi: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + A phandle which points to companion PXL2DPI which is used by downstream + LVDS Display Bridge(LDB) in split mode. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: The PXL2DPI input port node from pixel link. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: The PXL2DPI output port node to downstream bridge. + + required: + - port@0 + - port@1 + +required: + - compatible + - fsl,sc-resource + - power-domains + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/firmware/imx/rsrc.h> + pxl2dpi { + compatible = "fsl,imx8qxp-pxl2dpi"; + fsl,sc-resource = <IMX_SC_R_MIPI_0>; + power-domains = <&pd IMX_SC_R_MIPI_0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 { + reg = <0>; + remote-endpoint = <&dc_pixel_link0_mipi_lvds_0_pxl2dpi>; + }; + + mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 { + reg = <1>; + remote-endpoint = <&dc_pixel_link1_mipi_lvds_0_pxl2dpi>; + }; + }; + + port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 { + reg = <0>; + remote-endpoint = <&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>; + }; + + mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 { + reg = <1>; + remote-endpoint = <&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml index 77f174eee424..2ebaa43eb62e 100644 --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml @@ -24,6 +24,15 @@ properties: clock-names: const: ldb + reg: + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: ldb + - const: lvds + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -56,10 +65,15 @@ examples: #include <dt-bindings/clock/imx8mp-clock.h> blk-ctrl { - bridge { + #address-cells = <1>; + #size-cells = <1>; + + bridge@5c { compatible = "fsl,imx8mp-ldb"; clocks = <&clk IMX8MP_CLK_MEDIA_LDB>; clock-names = "ldb"; + reg = <0x5c 0x4>, <0x128 0x4>; + reg-names = "ldb", "lvds"; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml index b8219eab4475..89490fdffeb0 100644 --- a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml @@ -55,7 +55,6 @@ examples: compatible = "ingenic,jz4780-dw-hdmi"; reg = <0x10180000 0x8000>; reg-io-width = <4>; - ddc-i2c-bus = <&i2c4>; interrupt-parent = <&intc>; interrupts = <3>; clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>; diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt deleted file mode 100644 index 3bc760cc31cb..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ /dev/null @@ -1,78 +0,0 @@ -sii902x HDMI bridge bindings - -Required properties: - - compatible: "sil,sii9022" - - reg: i2c address of the bridge - -Optional properties: - - interrupts: describe the interrupt line used to inform the host - about hotplug events. - - reset-gpios: OF device-tree gpio specification for RST_N pin. - - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V) - - cvcc12-supply: Digital Core Supply Voltage (1.2V) - - HDMI audio properties: - - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin - is wired, <1> if the both are wired. HDMI audio is - configured only if this property is found. - - sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3 - Each integer indicates which i2s pin is connected to which - audio fifo. The first integer selects i2s audio pin for the - first audio fifo#0 (HDMI channels 1&2), second for fifo#1 - (HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s - pins (SD0 - SD3). Any i2s pin can be connected to any fifo, - but there can be no gaps. E.g. an i2s pin must be mapped to - fifo#0 and fifo#1 before mapping a channel to fifo#2. Default - value is <0>, describing SD0 pin beiging routed to hdmi audio - fifo #0. - - clocks: phandle and clock specifier for each clock listed in - the clock-names property - - clock-names: "mclk" - Describes SII902x MCLK input. MCLK can be used to produce - HDMI audio CTS values. This property follows - Documentation/devicetree/bindings/clock/clock-bindings.txt - consumer binding. - - If HDMI audio is configured the sii902x device becomes an I2S - and/or spdif audio codec component (e.g a digital audio sink), - that can be used in configuring a full audio devices with - simple-card or audio-graph-card binding. See their binding - documents on how to describe the way the sii902x device is - connected to the rest of the audio system: - Documentation/devicetree/bindings/sound/simple-card.yaml - Documentation/devicetree/bindings/sound/audio-graph-card.yaml - Note: In case of the audio-graph-card binding the used port - index should be 3. - -Optional subnodes: - - video input: this subnode can contain a video input port node - to connect the bridge to a display controller output (See this - documentation [1]). - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - hdmi-bridge@39 { - compatible = "sil,sii9022"; - reg = <0x39>; - reset-gpios = <&pioA 1 0>; - iovcc-supply = <&v3v3_hdmi>; - cvcc12-supply = <&v1v2_hdmi>; - - #sound-dai-cells = <0>; - sil,i2s-data-lanes = < 0 1 2 >; - clocks = <&mclk>; - clock-names = "mclk"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - bridge_in: endpoint { - remote-endpoint = <&dc_out>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml new file mode 100644 index 000000000000..5a69547ad3d7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/sil,sii9022.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Image sii902x HDMI bridge + +maintainers: + - Boris Brezillon <bbrezillon@kernel.org> + +properties: + compatible: + oneOf: + - items: + - enum: + - sil,sii9022-cpi # CEC Programming Interface + - sil,sii9022-tpi # Transmitter Programming Interface + - const: sil,sii9022 + - const: sil,sii9022 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Interrupt line used to inform the host about hotplug events. + + reset-gpios: + maxItems: 1 + + iovcc-supply: + description: I/O Supply Voltage (1.8V or 3.3V) + + cvcc12-supply: + description: Digital Core Supply Voltage (1.2V) + + '#sound-dai-cells': + enum: [ 0, 1 ] + description: | + <0> if only I2S or S/PDIF pin is wired, + <1> if both are wired. + HDMI audio is configured only if this property is found. + If HDMI audio is configured, the sii902x device becomes an I2S and/or + S/PDIF audio codec component (e.g. a digital audio sink), that can be + used in configuring full audio devices with simple-card or + audio-graph-card bindings. See their binding documents on how to describe + the way the + sii902x device is connected to the rest of the audio system: + Documentation/devicetree/bindings/sound/simple-card.yaml + Documentation/devicetree/bindings/sound/audio-graph-card.yaml + Note: In case of the audio-graph-card binding the used port index should + be 3. + + sil,i2s-data-lanes: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + uniqueItems: true + items: + enum: [ 0, 1, 2, 3 ] + description: + Each integer indicates which I2S pin is connected to which audio FIFO. + The first integer selects the I2S audio pin for the first audio FIFO#0 + (HDMI channels 1&2), the second for FIFO#1 (HDMI channels 3&4), and so + on. There are 4 FIFOs and 4 I2S pins (SD0 - SD3). Any I2S pin can be + connected to any FIFO, but there can be no gaps. E.g. an I2S pin must be + mapped to FIFO#0 and FIFO#1 before mapping a channel to FIFO#2. The + default value is <0>, describing SD0 pin being routed to HDMI audio + FIFO#0. + + clocks: + maxItems: 1 + description: MCLK input. MCLK can be used to produce HDMI audio CTS values. + + clock-names: + const: mclk + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Parallel RGB input port + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: HDMI output port + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Sound input port + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hdmi-bridge@39 { + compatible = "sil,sii9022"; + reg = <0x39>; + reset-gpios = <&pioA 1 0>; + iovcc-supply = <&v3v3_hdmi>; + cvcc12-supply = <&v1v2_hdmi>; + + #sound-dai-cells = <0>; + sil,i2s-data-lanes = < 0 1 2 >; + clocks = <&mclk>; + clock-names = "mclk"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + bridge_in: endpoint { + remote-endpoint = <&dc_out>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml b/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml new file mode 100644 index 000000000000..542193d77cdf --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,dlpc3433.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI DLPC3433 MIPI DSI to DMD bridge + +maintainers: + - Jagan Teki <jagan@amarulasolutions.com> + - Christopher Vollo <chris@renewoutreach.org> + +description: | + TI DLPC3433 is a MIPI DSI based display controller bridge + for processing high resolution DMD based projectors. + + It has a flexible configuration of MIPI DSI and DPI signal + input that produces a DMD output in RGB565, RGB666, RGB888 + formats. + + It supports upto 720p resolution with 60 and 120 Hz refresh + rates. + +properties: + compatible: + const: ti,dlpc3433 + + reg: + enum: + - 0x1b + - 0x1d + + enable-gpios: + description: PROJ_ON pin, chip powers up PROJ_ON is high. + + vcc_intf-supply: + description: A 1.8V/3.3V supply that power the Host I/O. + + vcc_flsh-supply: + description: A 1.8V/3.3V supply that power the Flash I/O. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: Video port for MIPI DSI input. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for DMD output. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c1 { + #address-cells = <1>; + #size-cells = <0>; + + bridge@1b { + compatible = "ti,dlpc3433"; + reg = <0x1b>; + enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + bridge_in_dsi: endpoint { + remote-endpoint = <&dsi_out_bridge>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + + bridge_out_panel: endpoint { + remote-endpoint = <&panel_out_bridge>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 900a56cae80e..876015a44a1e 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx23-lcdif - fsl,imx28-lcdif - fsl,imx6sx-lcdif + - fsl,imx8mp-lcdif - items: - enum: - fsl,imx6sl-lcdif diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt deleted file mode 100644 index 169b32e4ee4e..000000000000 --- a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt +++ /dev/null @@ -1,27 +0,0 @@ -Ilitek ILI9341 display panels - -This binding is for display panels using an Ilitek ILI9341 controller in SPI -mode. - -Required properties: -- compatible: "adafruit,yx240qv29", "ilitek,ili9341" -- dc-gpios: D/C pin -- reset-gpios: Reset pin - -The node for this driver must be a child node of a SPI controller, hence -all mandatory properties described in ../spi/spi-bus.txt must be specified. - -Optional properties: -- rotation: panel rotation in degrees counter clockwise (0,90,180,270) -- backlight: phandle of the backlight device attached to the panel - -Example: - display@0{ - compatible = "adafruit,yx240qv29", "ilitek,ili9341"; - reg = <0>; - spi-max-frequency = <32000000>; - dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>; - rotation = <270>; - backlight = <&backlight>; - }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index 77ee1b923991..5bb23e97cf33 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -4,16 +4,16 @@ $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: mediatek DPI Controller Device Tree Bindings +title: MediaTek DPI and DP_INTF Controller maintainers: - CK Hu <ck.hu@mediatek.com> - Jitao shi <jitao.shi@mediatek.com> description: | - The Mediatek DPI function block is a sink of the display subsystem and - provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel - output bus. + The MediaTek DPI and DP_INTF function blocks are a sink of the display + subsystem and provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a + parallel output bus. properties: compatible: @@ -24,6 +24,7 @@ properties: - mediatek,mt8183-dpi - mediatek,mt8186-dpi - mediatek,mt8192-dpi + - mediatek,mt8195-dp-intf reg: maxItems: 1 @@ -55,7 +56,7 @@ properties: $ref: /schemas/graph.yaml#/properties/port description: Output port node. This port should be connected to the input port of an - attached HDMI or LVDS encoder chip. + attached HDMI, LVDS or DisplayPort encoder chip. required: - compatible diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt deleted file mode 100644 index 36b01458f45c..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ /dev/null @@ -1,62 +0,0 @@ -Mediatek DSI Device -=================== - -The Mediatek DSI function block is a sink of the display subsystem and can -drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual- -channel output. - -Required properties: -- compatible: "mediatek,<chip>-dsi" -- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183. -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "engine", "digital", and "hs" -- phys: phandle link to the MIPI D-PHY controller. -- phy-names: must contain "dphy" -- port: Output port node with endpoint definitions as described in - Documentation/devicetree/bindings/graph.txt. This port should be connected - to the input port of an attached DSI panel or DSI-to-eDP encoder chip. - -Optional properties: -- resets: list of phandle + reset specifier pair, as described in [1]. - -[1] Documentation/devicetree/bindings/reset/reset.txt - -MIPI TX Configuration Module -============================ - -See phy/mediatek,dsi-phy.yaml - -Example: - -mipi_tx0: mipi-dphy@10215000 { - compatible = "mediatek,mt8173-mipi-tx"; - reg = <0 0x10215000 0 0x1000>; - clocks = <&clk26m>; - clock-output-names = "mipi_tx0_pll"; - #clock-cells = <0>; - #phy-cells = <0>; - drive-strength-microamp = <4600>; - nvmem-cells= <&mipi_tx_calibration>; - nvmem-cell-names = "calibration-data"; -}; - -dsi0: dsi@1401b000 { - compatible = "mediatek,mt8173-dsi"; - reg = <0 0x1401b000 0 0x1000>; - interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_LOW>; - clocks = <&mmsys MM_DSI0_ENGINE>, <&mmsys MM_DSI0_DIGITAL>, - <&mipi_tx0>; - clock-names = "engine", "digital", "hs"; - resets = <&mmsys MT8173_MMSYS_SW0_RST_B_DISP_DSI0>; - phys = <&mipi_tx0>; - phy-names = "dphy"; - - port { - dsi0_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml new file mode 100644 index 000000000000..b18d6a57c6e1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek DSI Controller Device Tree Bindings + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + - Jitao Shi <jitao.shi@mediatek.com> + - Xinlei Lee <xinlei.lee@mediatek.com> + +description: | + The MediaTek DSI function block is a sink of the display subsystem and can + drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual- + channel output. + +allOf: + - $ref: /schemas/display/dsi-controller.yaml# + +properties: + compatible: + enum: + - mediatek,mt2701-dsi + - mediatek,mt7623-dsi + - mediatek,mt8167-dsi + - mediatek,mt8173-dsi + - mediatek,mt8183-dsi + - mediatek,mt8186-dsi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Engine Clock + - description: Digital Clock + - description: HS Clock + + clock-names: + items: + - const: engine + - const: digital + - const: hs + + resets: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + items: + - const: dphy + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Output port node. This port should be connected to the input + port of an attached DSI panel or DSI-to-eDP encoder chip. + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - clock-names + - phys + - phy-names + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/mt8183-power.h> + #include <dt-bindings/phy/phy.h> + #include <dt-bindings/reset/mt8183-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + dsi0: dsi@14014000 { + compatible = "mediatek,mt8183-dsi"; + reg = <0 0x14014000 0 0x1000>; + interrupts = <GIC_SPI 236 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DSI0_MM>, + <&mmsys CLK_MM_DSI0_IF>, + <&mipi_tx0>; + clock-names = "engine", "digital", "hs"; + resets = <&mmsys MT8183_MMSYS_SW0_RST_B_DISP_DSI0>; + phys = <&mipi_tx0>; + phy-names = "dphy"; + port { + dsi0_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml new file mode 100644 index 000000000000..dd12e2ff685c --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MDP RDMA + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + The MediaTek MDP RDMA stands for Read Direct Memory Access. + It provides real time data to the back-end panel driver, such as DSI, + DPI and DP_INTF. + It contains one line buffer to store the sufficient pixel data. + RDMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for details. + +properties: + compatible: + const: mediatek,mt8195-vdo1-rdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + clocks: + items: + - description: RDMA Clock + + iommus: + maxItems: 1 + + mediatek,gce-client-reg: + description: + The register of display function block to be set by gce. There are 4 arguments, + such as gce node, subsys id, offset and register size. The subsys id that is + mapping to the register of display function blocks is defined in the gce header + include/dt-bindings/gce/<chip>-gce.h of each chips. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + maxItems: 1 + +required: + - compatible + - reg + - power-domains + - clocks + - iommus + - mediatek,gce-client-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8195-clk.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + rdma@1c104000 { + compatible = "mediatek,mt8195-vdo1-rdma"; + reg = <0 0x1c104000 0 0x1000>; + interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index cd05cfd76536..94bc6e1b6451 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: MSM Display Port Controller maintainers: - - Kuogee Hsieh <khsieh@codeaurora.org> + - Kuogee Hsieh <quic_khsieh@quicinc.com> description: | Device tree bindings for DisplayPort host controller for MSM targets @@ -76,6 +76,9 @@ properties: "#sound-dai-cells": const: 0 + vdda-0p9-supply: true + vdda-1p2-supply: true + ports: $ref: /schemas/graph.yaml#/properties/ports properties: @@ -137,6 +140,9 @@ examples: power-domains = <&rpmhpd SC7180_CX>; + vdda-0p9-supply = <&vdda_usb_ss_dp_core>; + vdda-1p2-supply = <&vdda_usb_ss_dp_1p2>; + ports { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt b/Documentation/devicetree/bindings/display/msm/hdmi.txt deleted file mode 100644 index 5f90a40da51b..000000000000 --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt +++ /dev/null @@ -1,99 +0,0 @@ -Qualcomm adreno/snapdragon hdmi output - -Required properties: -- compatible: one of the following - * "qcom,hdmi-tx-8996" - * "qcom,hdmi-tx-8994" - * "qcom,hdmi-tx-8084" - * "qcom,hdmi-tx-8974" - * "qcom,hdmi-tx-8660" - * "qcom,hdmi-tx-8960" -- reg: Physical base address and length of the controller's registers -- reg-names: "core_physical" -- interrupts: The interrupt signal from the hdmi block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: device clocks - See ../clocks/clock-bindings.txt for details. -- core-vdda-supply: phandle to supply regulator -- hdmi-mux-supply: phandle to mux regulator -- phys: the phandle for the HDMI PHY device -- phy-names: the name of the corresponding PHY device - -Optional properties: -- hpd-gpios: hpd pin -- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin -- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin -- qcom,hdmi-tx-mux-lpm-gpios: hdmi mux lpm pin -- power-domains: reference to the power domain(s), if available. -- pinctrl-names: the pin control state names; should contain "default" -- pinctrl-0: the default pinctrl state (active) -- pinctrl-1: the "sleep" pinctrl state - -HDMI PHY: -Required properties: -- compatible: Could be the following - * "qcom,hdmi-phy-8660" - * "qcom,hdmi-phy-8960" - * "qcom,hdmi-phy-8974" - * "qcom,hdmi-phy-8084" - * "qcom,hdmi-phy-8996" -- #phy-cells: Number of cells in a PHY specifier; Should be 0. -- reg: Physical base address and length of the registers of the PHY sub blocks. -- reg-names: The names of register regions. The following regions are required: - * "hdmi_phy" - * "hdmi_pll" - For HDMI PHY on msm8996, these additional register regions are required: - * "hdmi_tx_l0" - * "hdmi_tx_l1" - * "hdmi_tx_l3" - * "hdmi_tx_l4" -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- core-vdda-supply: phandle to vdda regulator device node - -Example: - -/ { - ... - - hdmi: hdmi@4a00000 { - compatible = "qcom,hdmi-tx-8960"; - reg-names = "core_physical"; - reg = <0x04a00000 0x2f0>; - interrupts = <GIC_SPI 79 0>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "core", - "master_iface", - "slave_iface"; - clocks = - <&mmcc HDMI_APP_CLK>, - <&mmcc HDMI_M_AHB_CLK>, - <&mmcc HDMI_S_AHB_CLK>; - qcom,hdmi-tx-ddc-clk = <&msmgpio 70 GPIO_ACTIVE_HIGH>; - qcom,hdmi-tx-ddc-data = <&msmgpio 71 GPIO_ACTIVE_HIGH>; - qcom,hdmi-tx-hpd = <&msmgpio 72 GPIO_ACTIVE_HIGH>; - core-vdda-supply = <&pm8921_hdmi_mvs>; - hdmi-mux-supply = <&ext_3p3v>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&hpd_active &ddc_active &cec_active>; - pinctrl-1 = <&hpd_suspend &ddc_suspend &cec_suspend>; - - phys = <&hdmi_phy>; - phy-names = "hdmi_phy"; - }; - - hdmi_phy: phy@4a00400 { - compatible = "qcom,hdmi-phy-8960"; - reg-names = "hdmi_phy", - "hdmi_pll"; - reg = <0x4a00400 0x60>, - <0x4a00500 0x100>; - #phy-cells = <0>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = "slave_iface"; - clocks = <&mmcc HDMI_S_AHB_CLK>; - core-vdda-supply = <&pm8921_hdmi_mvs>; - }; -}; diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.yaml b/Documentation/devicetree/bindings/display/msm/hdmi.yaml new file mode 100644 index 000000000000..47e97669821c --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/hdmi.yaml @@ -0,0 +1,232 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/display/msm/hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Adreno/Snapdragon HDMI output + +maintainers: + - Rob Clark <robdclark@gmail.com> + +properties: + compatible: + enum: + - qcom,hdmi-tx-8084 + - qcom,hdmi-tx-8660 + - qcom,hdmi-tx-8960 + - qcom,hdmi-tx-8974 + - qcom,hdmi-tx-8994 + - qcom,hdmi-tx-8996 + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + reg: + minItems: 1 + maxItems: 3 + + reg-names: + minItems: 1 + items: + - const: core_physical + - const: qfprom_physical + - const: hdcp_physical + + interrupts: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + enum: + - hdmi_phy + - hdmi-phy + deprecated: true + + core-vdda-supply: + description: phandle to VDDA supply regulator + + hdmi-mux-supply: + description: phandle to mux regulator + deprecated: true + + core-vcc-supply: + description: phandle to VCC supply regulator + + hpd-gpios: + maxItems: 1 + description: hpd pin + + qcom,hdmi-tx-mux-en-gpios: + maxItems: 1 + deprecated: true + description: HDMI mux enable pin + + qcom,hdmi-tx-mux-sel-gpios: + maxItems: 1 + deprecated: true + description: HDMI mux select pin + + qcom,hdmi-tx-mux-lpm-gpios: + maxItems: 1 + deprecated: true + description: HDMI mux lpm pin + + '#sound-dai-cells': + const: 1 + + ports: + type: object + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + description: | + Input endpoints of the controller. + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: | + Output endpoints of the controller. + + required: + - port@0 + +required: + - compatible + - clocks + - clock-names + - reg + - reg-names + - interrupts + - phys + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,hdmi-tx-8960 + - qcom,hdmi-tx-8660 + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: core + - const: master_iface + - const: slave_iface + core-vcc-supplies: false + + - if: + properties: + compatible: + contains: + enum: + - qcom,hdmi-tx-8974 + - qcom,hdmi-tx-8084 + - qcom,hdmi-tx-8994 + - qcom,hdmi-tx-8996 + then: + properties: + clocks: + minItems: 5 + clock-names: + items: + - const: mdp_core + - const: iface + - const: core + - const: alt_iface + - const: extp + hdmi-mux-supplies: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + hdmi: hdmi@4a00000 { + compatible = "qcom,hdmi-tx-8960"; + reg-names = "core_physical"; + reg = <0x04a00000 0x2f0>; + interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "core", + "master_iface", + "slave_iface"; + clocks = <&clk 61>, + <&clk 72>, + <&clk 98>; + hpd-gpios = <&msmgpio 72 GPIO_ACTIVE_HIGH>; + core-vdda-supply = <&pm8921_hdmi_mvs>; + hdmi-mux-supply = <&ext_3p3v>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&hpd_active &ddc_active &cec_active>; + pinctrl-1 = <&hpd_suspend &ddc_suspend &cec_suspend>; + + phys = <&hdmi_phy>; + }; + - | + #include <dt-bindings/clock/qcom,gcc-msm8996.h> + #include <dt-bindings/clock/qcom,mmcc-msm8996.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + hdmi@9a0000 { + compatible = "qcom,hdmi-tx-8996"; + reg = <0x009a0000 0x50c>, + <0x00070000 0x6158>, + <0x009e0000 0xfff>; + reg-names = "core_physical", + "qfprom_physical", + "hdcp_physical"; + + interrupt-parent = <&mdss>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_HDMI_CLK>, + <&mmcc MDSS_HDMI_AHB_CLK>, + <&mmcc MDSS_EXTPCLK_CLK>; + clock-names = "mdp_core", + "iface", + "core", + "alt_iface", + "extp"; + + phys = <&hdmi_phy>; + #sound-dai-cells = <1>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&hdmi_hpd_active &hdmi_ddc_active>; + pinctrl-1 = <&hdmi_hpd_suspend &hdmi_ddc_suspend>; + + core-vdda-supply = <&vreg_l12a_1p8>; + core-vcc-supply = <&vreg_s4a_1p8>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&mdp5_intf3_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/arm,rtsm-display.yaml b/Documentation/devicetree/bindings/display/panel/arm,rtsm-display.yaml new file mode 100644 index 000000000000..4ad484f09ba3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/arm,rtsm-display.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/arm,rtsm-display.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm RTSM Virtual Platforms Display + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: arm,rtsm-display + + port: true + +required: + - compatible + - port + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml b/Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml new file mode 100644 index 000000000000..80deedc01c7c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ebbg,ft8719.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EBBG FT8719 MIPI-DSI LCD panel + +maintainers: + - Joel Selvaraj <jo@jsfamily.in> + +description: | + The FT8719 panel from EBBG is a FHD+ LCD display panel with a resolution + of 1080x2246. It is a video mode DSI panel. The backlight is managed + through the QCOM WLED driver. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: ebbg,ft8719 + + reg: + maxItems: 1 + description: DSI virtual channel of the peripheral + + vddio-supply: + description: power IC supply regulator + + vddpos-supply: + description: positive boost supply regulator + + vddneg-supply: + description: negative boost supply regulator + +required: + - compatible + - reg + - vddio-supply + - vddpos-supply + - vddneg-supply + - reset-gpios + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "ebbg,ft8719"; + reg = <0>; + + vddio-supply = <&vreg_l14a_1p88>; + vddpos-supply = <&lab>; + vddneg-supply = <&ibb>; + + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>; + + backlight = <&pmi8998_wled>; + + port { + ebbg_ft8719_in_0: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml index 95acf9e96f1c..1cf84c8dd85e 100644 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml @@ -35,7 +35,6 @@ required: - reg - avdd-supply - dvdd-supply - - reset-gpios additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 6058948a9764..99e0cb9440cf 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -21,8 +21,10 @@ properties: compatible: items: - enum: + - adafruit,yx240qv29 # ili9341 240*320 Color on stm32f429-disco board - st,sf-tc240t-9370-t + - canaan,kd233-tft - const: ilitek,ili9341 reg: true @@ -47,31 +49,50 @@ properties: vddi-led-supply: description: Voltage supply for the LED driver (1.65 .. 3.3 V) -additionalProperties: false +unevaluatedProperties: false required: - compatible - reg - dc-gpios - - port + +if: + properties: + compatible: + contains: + enum: + - st,sf-tc240t-9370-t +then: + required: + - port examples: - |+ + #include <dt-bindings/gpio/gpio.h> spi { #address-cells = <1>; #size-cells = <0>; panel: display@0 { - compatible = "st,sf-tc240t-9370-t", - "ilitek,ili9341"; - reg = <0>; - spi-3wire; - spi-max-frequency = <10000000>; - dc-gpios = <&gpiod 13 0>; - port { - panel_in: endpoint { - remote-endpoint = <&display_out>; - }; - }; - }; + compatible = "st,sf-tc240t-9370-t", + "ilitek,ili9341"; + reg = <0>; + spi-3wire; + spi-max-frequency = <10000000>; + dc-gpios = <&gpiod 13 0>; + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + display@1{ + compatible = "adafruit,yx240qv29", "ilitek,ili9341"; + reg = <1>; + spi-max-frequency = <10000000>; + dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>; + rotation = <270>; + backlight = <&backlight>; }; + }; ... diff --git a/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml b/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml index b4314ce7b411..ee357e139ac0 100644 --- a/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml +++ b/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml @@ -15,13 +15,13 @@ maintainers: allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: const: lg,lg4573 reg: true - spi-max-frequency: true required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml index 5e4e0e552c2f..628c4b898111 100644 --- a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml +++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml @@ -21,6 +21,9 @@ properties: enable-gpios: true port: true + spi-cpha: true + spi-cpol: true + required: - compatible - enable-gpios diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index 563766d283f6..41ee3157a1cd 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -46,6 +46,7 @@ properties: reg: true port: true + backlight: true required: - compatible @@ -73,6 +74,7 @@ examples: vddpos-supply = <&lab>; vddneg-supply = <&ibb>; + backlight = <&pmi8998_wled>; reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>; port { diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 21ba90c9fe33..bc8e9c0c1dc3 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -35,6 +35,8 @@ properties: - ampire,am-480272h3tmqw-t01h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - ampire,am800480r3tmqwa1h + # Ampire AM-800600P5TMQW-TB8H 8.0" SVGA TFT LCD panel + - ampire,am800600p5tmqw-tb8h # AU Optronics Corporation 10.1" WSVGA TFT LCD panel - auo,b101aw03 # AU Optronics Corporation 10.1" WSVGA TFT LCD panel @@ -107,6 +109,8 @@ properties: - chunghwa,claa101wb03 # DataImage, Inc. 4.3" WQVGA (480x272) TFT LCD panel with 24-bit parallel interface. - dataimage,fg040346dsswbg04 + # DataImage, Inc. 10.1" WXGA (1280×800) TFT LCD panel + - dataimage,fg1001l0dsswmg01 # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface. - dataimage,scf0700c48ggu18 # DLC Display Co. DLC1010GIG 10.1" WXGA TFT LCD Panel @@ -137,6 +141,8 @@ properties: # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - edt,etm0700g0dh6 - edt,etm0700g0edh6 + # Emerging Display Technology Corp. LVDS WSVGA TFT Display with capacitive touch + - edt,etml0700y5dha # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with # capacitive touch - edt,etmv570g2dhu @@ -158,6 +164,8 @@ properties: - hannstar,hsd070pww1 # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel - hannstar,hsd100pxn1 + # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel + - hannstar,hsd101pww2 # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel - hit,tx23d38vm0caa # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml index 617aa8c8c03a..d62fd692bf10 100644 --- a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml @@ -38,6 +38,7 @@ properties: 0 - burst-mode 1 - non-burst with sync event 2 - non-burst with sync pulse + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1, 2] required: diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml index d525165d6d63..c0fabeb38628 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml @@ -42,6 +42,9 @@ properties: panel-height-mm: description: physical panel height [mm] + spi-cpha: true + spi-cpol: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml index a679d3647dbd..9ec0e8aae4c6 100644 --- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml @@ -30,7 +30,12 @@ allOf: properties: compatible: - const: sharp,lq101r1sx01 + oneOf: + - items: + - const: sharp,lq101r1sx03 + - const: sharp,lq101r1sx01 + - items: + - const: sharp,lq101r1sx01 reg: true power-supply: true diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index 9e1d707c2ace..d984b59daa4a 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -23,6 +23,9 @@ properties: backlight: true port: true + spi-cpha: true + spi-cpol: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml index f902a9d74141..e8c8ee8d7c88 100644 --- a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml +++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml @@ -28,6 +28,9 @@ properties: backlight: true port: true + spi-cpha: true + spi-cpol: true + required: - compatible - port diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml index 919734c05c0b..458d399cb025 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos SoC HDMI DDC maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml index 63379fae3636..e4a68c5a1a09 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos SoC HDMI maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml index 00e325a19cb1..25d53fde92e1 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos SoC Mixer maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml index 7c37470bd329..921bfe925cd6 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos5433 SoC Display and Enhancement Controller (DECON) maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml index c5c6239c28d0..7d405f2febcd 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos5433 SoC Mobile Image Compressor (MIC) maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml index 320eedc61a5b..969bd8c563a5 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos7 SoC Display and Enhancement Controller (DECON) maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml index c62ea9d22843..5d5cc220f78a 100644 --- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml @@ -8,7 +8,6 @@ title: Samsung S3C/S5P/Exynos SoC Fully Interactive Mobile Display (FIMD) maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 27ba4323d221..1f905d85dd9c 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Simple Framebuffer Device Tree Bindings maintainers: - - Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - Hans de Goede <hdegoede@redhat.com> description: |+ diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml index 157b1a7b18f9..53f181ef3670 100644 --- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml @@ -15,6 +15,7 @@ description: allOf: - $ref: panel/panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 3fbd87c2c120..669f70b1b4c4 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -49,9 +49,6 @@ properties: vbat-supply: description: The supply for VBAT - # Only required for SPI - spi-max-frequency: true - solomon,height: $ref: /schemas/types.yaml#/definitions/uint32 default: 16 @@ -153,6 +150,8 @@ required: - reg allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: properties: compatible: @@ -223,7 +222,7 @@ allOf: solomon,dclk-frq: default: 10 -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt deleted file mode 100644 index e4a25cedc5cf..000000000000 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt +++ /dev/null @@ -1,41 +0,0 @@ -NVIDIA Tegra MIPI pad calibration controller - -Required properties: -- compatible: "nvidia,tegra<chip>-mipi" -- reg: Physical base address and length of the controller's registers. -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - mipi-cal -- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads - that need to be calibrated for a given device. - -User nodes need to contain an nvidia,mipi-calibrate property that has a -phandle to refer to the calibration controller node and a bitmask of the pads -that need to be calibrated. - -Example: - - mipi: mipi@700e3000 { - compatible = "nvidia,tegra114-mipi"; - reg = <0x700e3000 0x100>; - clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>; - clock-names = "mipi-cal"; - #nvidia,mipi-calibrate-cells = <1>; - }; - - ... - - host1x@50000000 { - ... - - dsi@54300000 { - ... - - nvidia,mipi-calibrate = <&mipi 0x060>; - - ... - }; - - ... - }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml new file mode 100644 index 000000000000..d5ca8cf86e8e --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra114-mipi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra MIPI pad calibration controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^mipi@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra114-mipi + - nvidia,tegra210-mipi + - nvidia,tegra186-mipi + + reg: + maxItems: 1 + + clocks: + items: + - description: module clock + + clock-names: + items: + - const: mipi-cal + + power-domains: + maxItems: 1 + + "#nvidia,mipi-calibrate-cells": + description: The number of cells in a MIPI calibration specifier. + Should be 1. The single cell specifies a bitmask of the pads that + need to be calibrated for a given device. + $ref: "/schemas/types.yaml#/definitions/uint32" + const: 1 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - "#nvidia,mipi-calibrate-cells" + +examples: + - | + #include <dt-bindings/clock/tegra114-car.h> + + mipi@700e3000 { + compatible = "nvidia,tegra114-mipi"; + reg = <0x700e3000 0x100>; + clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>; + clock-names = "mipi-cal"; + #nvidia,mipi-calibrate-cells = <1>; + }; + + dsia: dsi@54300000 { + compatible = "nvidia,tegra114-dsi"; + reg = <0x54300000 0x00040000>; + clocks = <&tegra_car TEGRA114_CLK_DSIA>, + <&tegra_car TEGRA114_CLK_DSIALP>, + <&tegra_car TEGRA114_CLK_PLL_D_OUT0>; + clock-names = "dsi", "lp", "parent"; + resets = <&tegra_car 48>; + reset-names = "dsi"; + nvidia,mipi-calibrate = <&mipi 0x060>; /* DSIA & DSIB pads */ + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml new file mode 100644 index 000000000000..9ab123cd2325 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml @@ -0,0 +1,152 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-dpaux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra DisplayPort AUX Interface + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The Tegra Display Port Auxiliary (DPAUX) pad controller manages two + pins which can be assigned to either the DPAUX channel or to an I2C + controller. + + When configured for DisplayPort AUX operation, the DPAUX controller + can also be used to communicate with a DisplayPort device using the + AUX channel. + +properties: + $nodename: + pattern: "^dpaux@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - nvidia,tegra124-dpaux + - nvidia,tegra210-dpaux + - nvidia,tegra186-dpaux + - nvidia,tegra194-dpaux + + - items: + - const: nvidia,tegra132-dpaux + - const: nvidia,tegra124-dpaux + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: clock input for the DPAUX hardware + - description: reference clock + + clock-names: + items: + - const: dpaux + - const: parent + + resets: + items: + - description: module reset + + reset-names: + items: + - const: dpaux + + power-domains: + maxItems: 1 + + i2c-bus: + description: Subnode where I2C slave devices are listed. This + subnode must be always present. If there are no I2C slave + devices, an empty node should be added. See ../../i2c/i2c.yaml + for more information. + type: object + + aux-bus: + $ref: /schemas/display/dp-aux-bus.yaml# + + vdd-supply: + description: phandle of a supply that powers the DisplayPort + link + +patternProperties: + "^pinmux-[a-z0-9]+$": + description: + Since only three configurations are possible, only three child + nodes are needed to describe the pin mux'ing options for the + DPAUX pads. Furthermore, given that the pad functions are only + applicable to a single set of pads, the child nodes only need + to describe the pad group the functions are being applied to + rather than the individual pads. + type: object + properties: + groups: + const: dpaux-io + + function: + enum: + - aux + - i2c + - off + + additionalProperties: false + + required: + - groups + - function + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dpaux: dpaux@545c0000 { + compatible = "nvidia,tegra210-dpaux"; + reg = <0x545c0000 0x00040000>; + interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_DPAUX>, + <&tegra_car TEGRA210_CLK_PLL_DP>; + clock-names = "dpaux", "parent"; + resets = <&tegra_car 181>; + reset-names = "dpaux"; + power-domains = <&pd_sor>; + status = "disabled"; + + state_dpaux_aux: pinmux-aux { + groups = "dpaux-io"; + function = "aux"; + }; + + state_dpaux_i2c: pinmux-i2c { + groups = "dpaux-io"; + function = "i2c"; + }; + + state_dpaux_off: pinmux-off { + groups = "dpaux-io"; + function = "off"; + }; + + i2c-bus { + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml new file mode 100644 index 000000000000..907fb0baccae --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml @@ -0,0 +1,197 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-sor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra SOR Output Encoder + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS, eDP + and DP outputs. + +properties: + $nodename: + pattern: "^sor@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - nvidia,tegra124-sor + - nvidia,tegra210-sor + - nvidia,tegra210-sor1 + - nvidia,tegra186-sor + - nvidia,tegra186-sor1 + - nvidia,tegra194-sor + + - items: + - const: nvidia,tegra132-sor + - const: nvidia,tegra124-sor + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 5 + maxItems: 6 + + clock-names: + minItems: 5 + maxItems: 6 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: sor + + power-domains: + maxItems: 1 + + avdd-io-hdmi-dp-supply: + description: I/O supply for HDMI/DP + + vdd-hdmi-dp-pll-supply: + description: PLL supply for HDMI/DP + + hdmi-supply: + description: +5.0V HDMI connector supply, required for HDMI + + # Tegra186 and later + nvidia,interface: + description: index of the SOR interface + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,ddc-i2c-bus: + description: phandle of an I2C controller used for DDC EDID + probing + $ref: "/schemas/types.yaml#/definitions/phandle" + + nvidia,hpd-gpio: + description: specifies a GPIO used for hotplug detection + maxItems: 1 + + nvidia,edid: + description: supplies a binary EDID blob + $ref: "/schemas/types.yaml#/definitions/uint8-array" + + nvidia,panel: + description: phandle of a display panel, required for eDP + $ref: "/schemas/types.yaml#/definitions/phandle" + + nvidia,xbar-cfg: + description: 5 cells containing the crossbar configuration. + Each lane of the SOR, identified by the cell's index, is + mapped via the crossbar to the pad specified by the cell's + value. + $ref: "/schemas/types.yaml#/definitions/uint32-array" + + # optional when driving an eDP output + nvidia,dpaux: + description: phandle to a DispayPort AUX interface + $ref: "/schemas/types.yaml#/definitions/phandle" + +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra186-sor + - nvidia,tegra194-sor + then: + properties: + clocks: + items: + - description: clock input for the SOR hardware + - description: SOR output clock + - description: input for the pixel clock + - description: reference clock for the SOR clock + - description: safe reference clock for the SOR clock + during power up + - description: SOR pad output clock + + clock-names: + items: + - const: sor + - enum: + - source # deprecated + - out + - const: parent + - const: dp + - const: safe + - const: pad + else: + properties: + clocks: + items: + - description: clock input for the SOR hardware + - description: SOR output clock + - description: input for the pixel clock + - description: reference clock for the SOR clock + - description: safe reference clock for the SOR clock + during power up + + clock-names: + items: + - const: sor + - enum: + - source # deprecated + - out + - const: parent + - const: dp + - const: safe + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - avdd-io-hdmi-dp-supply + - vdd-hdmi-dp-pll-supply + +examples: + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + sor0: sor@54540000 { + compatible = "nvidia,tegra210-sor"; + reg = <0x54540000 0x00040000>; + interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_SOR0>, + <&tegra_car TEGRA210_CLK_SOR0_OUT>, + <&tegra_car TEGRA210_CLK_PLL_D_OUT0>, + <&tegra_car TEGRA210_CLK_PLL_DP>, + <&tegra_car TEGRA210_CLK_SOR_SAFE>; + clock-names = "sor", "out", "parent", "dp", "safe"; + resets = <&tegra_car 182>; + reset-names = "sor"; + pinctrl-0 = <&state_dpaux_aux>; + pinctrl-1 = <&state_dpaux_i2c>; + pinctrl-2 = <&state_dpaux_off>; + pinctrl-names = "aux", "i2c", "off"; + power-domains = <&pd_sor>; + + avdd-io-hdmi-dp-supply = <&avdd_1v05>; + vdd-hdmi-dp-pll-supply = <&vdd_1v8>; + hdmi-supply = <&vdd_hdmi>; + + nvidia,ddc-i2c-bus = <&hdmi_ddc>; + nvidia,hpd-gpio = <&gpio TEGRA_GPIO(CC, 1) GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml new file mode 100644 index 000000000000..7200095ef19e --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra124-vic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Video Image Composer + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^vic@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - nvidia,tegra124-vic + - nvidia,tegra210-vic + - nvidia,tegra186-vic + - nvidia,tegra194-vic + - nvidia,tegra234-vic + + - items: + - const: nvidia,tegra132-vic + - const: nvidia,tegra124-vic + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: clock input for the VIC hardware + + clock-names: + items: + - const: vic + + resets: + items: + - description: module reset + + reset-names: + items: + - const: vic + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + interconnects: + description: Description of the interconnect paths for the VIC; + see ../interconnect/interconnect.txt for details. + items: + - description: memory read client for VIC + - description: memory write client for VIC + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + dma-coherent: true + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml new file mode 100644 index 000000000000..265a60d79d89 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra186-dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 (and later) Display Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^display@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra186-dc + - nvidia,tegra194-dc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: display controller pixel clock + + clock-names: + items: + - const: dc + + resets: + items: + - description: display controller reset + + reset-names: + items: + - const: dc + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + interconnects: + description: Description of the interconnect paths for the + display controller; see ../interconnect/interconnect.txt + for details. + + interconnect-names: + items: + - const: dma-mem # read-0 + - const: read-1 + + nvidia,outputs: + description: A list of phandles of outputs that this display + controller can drive. + $ref: "/schemas/types.yaml#/definitions/phandle-array" + + nvidia,head: + description: The number of the display controller head. This + is used to setup the various types of output to receive + video data from the given head. + $ref: "/schemas/types.yaml#/definitions/uint32" + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - power-domains + - nvidia,outputs + - nvidia,head + +# see nvidia,tegra186-display.yaml for examples diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml new file mode 100644 index 000000000000..8c0231345529 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml @@ -0,0 +1,310 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra186-display.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 (and later) Display Hub + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^display-hub@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra186-display + - nvidia,tegra194-display + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + resets: + items: + - description: display hub reset + - description: window group 0 reset + - description: window group 1 reset + - description: window group 2 reset + - description: window group 3 reset + - description: window group 4 reset + - description: window group 5 reset + + reset-names: + items: + - const: misc + - const: wgrp0 + - const: wgrp1 + - const: wgrp2 + - const: wgrp3 + - const: wgrp4 + - const: wgrp5 + + power-domains: + maxItems: 1 + + ranges: + maxItems: 1 + +patternProperties: + "^display@[0-9a-f]+$": + type: object + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra186-display + then: + properties: + clocks: + items: + - description: display core clock + - description: display stream compression clock + - description: display hub clock + + clock-names: + items: + - const: disp + - const: dsc + - const: hub + else: + properties: + clocks: + items: + - description: display core clock + - description: display hub clock + + clock-names: + items: + - const: disp + - const: hub + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - power-domains + - "#address-cells" + - "#size-cells" + - ranges + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + display-hub@15200000 { + compatible = "nvidia,tegra186-display"; + reg = <0x15200000 0x00040000>; + resets = <&bpmp TEGRA186_RESET_NVDISPLAY0_MISC>, + <&bpmp TEGRA186_RESET_NVDISPLAY0_WGRP0>, + <&bpmp TEGRA186_RESET_NVDISPLAY0_WGRP1>, + <&bpmp TEGRA186_RESET_NVDISPLAY0_WGRP2>, + <&bpmp TEGRA186_RESET_NVDISPLAY0_WGRP3>, + <&bpmp TEGRA186_RESET_NVDISPLAY0_WGRP4>, + <&bpmp TEGRA186_RESET_NVDISPLAY0_WGRP5>; + reset-names = "misc", "wgrp0", "wgrp1", "wgrp2", + "wgrp3", "wgrp4", "wgrp5"; + clocks = <&bpmp TEGRA186_CLK_NVDISPLAY_DISP>, + <&bpmp TEGRA186_CLK_NVDISPLAY_DSC>, + <&bpmp TEGRA186_CLK_NVDISPLAYHUB>; + clock-names = "disp", "dsc", "hub"; + status = "disabled"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x15200000 0x15200000 0x40000>; + + display@15200000 { + compatible = "nvidia,tegra186-dc"; + reg = <0x15200000 0x10000>; + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA186_CLK_NVDISPLAY_P0>; + clock-names = "dc"; + resets = <&bpmp TEGRA186_RESET_NVDISPLAY0_HEAD0>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + iommus = <&smmu TEGRA186_SID_NVDISPLAY>; + + nvidia,outputs = <&dsia &dsib &sor0 &sor1>; + nvidia,head = <0>; + }; + + display@15210000 { + compatible = "nvidia,tegra186-dc"; + reg = <0x15210000 0x10000>; + interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA186_CLK_NVDISPLAY_P1>; + clock-names = "dc"; + resets = <&bpmp TEGRA186_RESET_NVDISPLAY0_HEAD1>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPB>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + iommus = <&smmu TEGRA186_SID_NVDISPLAY>; + + nvidia,outputs = <&dsia &dsib &sor0 &sor1>; + nvidia,head = <1>; + }; + + display@15220000 { + compatible = "nvidia,tegra186-dc"; + reg = <0x15220000 0x10000>; + interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA186_CLK_NVDISPLAY_P2>; + clock-names = "dc"; + resets = <&bpmp TEGRA186_RESET_NVDISPLAY0_HEAD2>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPC>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + iommus = <&smmu TEGRA186_SID_NVDISPLAY>; + + nvidia,outputs = <&sor0 &sor1>; + nvidia,head = <2>; + }; + }; + + - | + #include <dt-bindings/clock/tegra194-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra194-mc.h> + #include <dt-bindings/power/tegra194-powergate.h> + #include <dt-bindings/reset/tegra194-reset.h> + + display-hub@15200000 { + compatible = "nvidia,tegra194-display"; + reg = <0x15200000 0x00040000>; + resets = <&bpmp TEGRA194_RESET_NVDISPLAY0_MISC>, + <&bpmp TEGRA194_RESET_NVDISPLAY0_WGRP0>, + <&bpmp TEGRA194_RESET_NVDISPLAY0_WGRP1>, + <&bpmp TEGRA194_RESET_NVDISPLAY0_WGRP2>, + <&bpmp TEGRA194_RESET_NVDISPLAY0_WGRP3>, + <&bpmp TEGRA194_RESET_NVDISPLAY0_WGRP4>, + <&bpmp TEGRA194_RESET_NVDISPLAY0_WGRP5>; + reset-names = "misc", "wgrp0", "wgrp1", "wgrp2", + "wgrp3", "wgrp4", "wgrp5"; + clocks = <&bpmp TEGRA194_CLK_NVDISPLAY_DISP>, + <&bpmp TEGRA194_CLK_NVDISPLAYHUB>; + clock-names = "disp", "hub"; + status = "disabled"; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISP>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x15200000 0x15200000 0x40000>; + + display@15200000 { + compatible = "nvidia,tegra194-dc"; + reg = <0x15200000 0x10000>; + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA194_CLK_NVDISPLAY_P0>; + clock-names = "dc"; + resets = <&bpmp TEGRA194_RESET_NVDISPLAY0_HEAD0>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISP>; + interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + + nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>; + nvidia,head = <0>; + }; + + display@15210000 { + compatible = "nvidia,tegra194-dc"; + reg = <0x15210000 0x10000>; + interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA194_CLK_NVDISPLAY_P1>; + clock-names = "dc"; + resets = <&bpmp TEGRA194_RESET_NVDISPLAY0_HEAD1>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISPB>; + interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + + nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>; + nvidia,head = <1>; + }; + + display@15220000 { + compatible = "nvidia,tegra194-dc"; + reg = <0x15220000 0x10000>; + interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA194_CLK_NVDISPLAY_P2>; + clock-names = "dc"; + resets = <&bpmp TEGRA194_RESET_NVDISPLAY0_HEAD2>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISPC>; + interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + + nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>; + nvidia,head = <2>; + }; + + display@15230000 { + compatible = "nvidia,tegra194-dc"; + reg = <0x15230000 0x10000>; + interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA194_CLK_NVDISPLAY_P3>; + clock-names = "dc"; + resets = <&bpmp TEGRA194_RESET_NVDISPLAY0_HEAD3>; + reset-names = "dc"; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISPC>; + interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>, + <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>; + interconnect-names = "dma-mem", "read-1"; + + nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>; + nvidia,head = <3>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml new file mode 100644 index 000000000000..e5a6145c8c53 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra186-dsi-padctl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra MIPI DSI pad controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^padctl@[0-9a-f]+$" + + compatible: + const: nvidia,tegra186-dsi-padctl + + reg: + maxItems: 1 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: dsi + +allOf: + - $ref: "/schemas/reset/reset.yaml" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/reset/tegra186-reset.h> + + padctl@15880000 { + compatible = "nvidia,tegra186-dsi-padctl"; + reg = <0x15880000 0x10000>; + resets = <&bpmp TEGRA186_RESET_DSI>; + reset-names = "dsi"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml new file mode 100644 index 000000000000..6eedee503aa0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml @@ -0,0 +1,183 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Display Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^dc@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - nvidia,tegra20-dc + - nvidia,tegra30-dc + - nvidia,tegra114-dc + - nvidia,tegra124-dc + - nvidia,tegra210-dc + + - items: + - const: nvidia,tegra124-dc + - const: nvidia,tegra132-dc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: display controller pixel clock + - description: parent clock # optional + + clock-names: + minItems: 1 + items: + - const: dc + - const: parent # optional + + resets: + items: + - description: module reset + + reset-names: + items: + - const: dc + + interconnect-names: true + interconnects: true + + iommus: + maxItems: 1 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the core power domain + + memory-region: true + + nvidia,head: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of the display controller head. This is used to setup the various + types of output to receive video data from the given head. + + nvidia,outputs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A list of phandles of outputs that this display controller can drive. + + rgb: + type: object + +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-dc + - nvidia,tegra30-dc + - nvidia,tegra114-dc + then: + properties: + interconnects: + items: + - description: window A memory client + - description: window B memory client + - description: window B memory client (vertical filter) + - description: window C memory client + - description: cursor memory client + + interconnect-names: + items: + - const: wina + - const: winb + - const: winb-vfilter + - const: winc + - const: cursor + + rgb: + description: Each display controller node has a child node, named "rgb", that represents + the RGB output associated with the controller. + type: object + properties: + nvidia,ddc-i2c-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle of an I2C controller used for DDC EDID probing + + nvidia,hpd-gpio: + description: specifies a GPIO used for hotplug detection + maxItems: 1 + + nvidia,edid: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: supplies a binary EDID blob + + nvidia,panel: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle of a display panel + + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra124-dc + then: + properties: + interconnects: + minItems: 4 + items: + - description: window A memory client + - description: window B memory client + - description: window C memory client + - description: cursor memory client + - description: window D memory client + - description: window T memory client + + interconnect-names: + minItems: 4 + items: + - const: wina + - const: winb + - const: winc + - const: cursor + - const: wind + - const: wint + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_DISP1>; + clock-names = "dc"; + resets = <&tegra_car 27>; + reset-names = "dc"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml new file mode 100644 index 000000000000..75546f250ad7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Display Serial Interface + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-dsi + - nvidia,tegra30-dsi + - nvidia,tegra114-dsi + - nvidia,tegra124-dsi + - nvidia,tegra210-dsi + - nvidia,tegra186-dsi + + - items: + - const: nvidia,tegra132-dsi + - const: nvidia,tegra124-dsi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: dsi + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + maxItems: 1 + + avdd-dsi-csi-supply: + description: phandle of a supply that powers the DSI controller + + nvidia,mipi-calibrate: + description: Should contain a phandle and a specifier specifying + which pads are used by this DSI output and need to be + calibrated. See nvidia,tegra114-mipi.yaml for details. + $ref: "/schemas/types.yaml#/definitions/phandle-array" + + nvidia,ddc-i2c-bus: + description: phandle of an I2C controller used for DDC EDID + probing + $ref: "/schemas/types.yaml#/definitions/phandle" + + nvidia,hpd-gpio: + description: specifies a GPIO used for hotplug detection + maxItems: 1 + + nvidia,edid: + description: supplies a binary EDID blob + $ref: "/schemas/types.yaml#/definitions/uint8-array" + + nvidia,panel: + description: phandle of a display panel + $ref: "/schemas/types.yaml#/definitions/phandle" + + nvidia,ganged-mode: + description: contains a phandle to a second DSI controller to + gang up with in order to support up to 8 data lanes + $ref: "/schemas/types.yaml#/definitions/phandle" + +allOf: + - $ref: "../dsi-controller.yaml#" + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-dsi + - nvidia,tegra30-dsi + then: + properties: + clocks: + items: + - description: DSI module clock + - description: input for the pixel clock + + clock-names: + items: + - const: dsi + - const: parent + else: + properties: + clocks: + items: + - description: DSI module clock + - description: low-power module clock + - description: input for the pixel clock + + clock-names: + items: + - const: dsi + - const: lp + - const: parent + + - if: + properties: + compatible: + contains: + const: nvidia,tegra186-dsi + then: + required: + - interrupts + +unevaluatedProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + dsi@15300000 { + compatible = "nvidia,tegra186-dsi"; + reg = <0x15300000 0x10000>; + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA186_CLK_DSI>, + <&bpmp TEGRA186_CLK_DSIA_LP>, + <&bpmp TEGRA186_CLK_PLLD>; + clock-names = "dsi", "lp", "parent"; + resets = <&bpmp TEGRA186_RESET_DSI>; + reset-names = "dsi"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml new file mode 100644 index 000000000000..0d55e6206b5e --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-epp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Encoder Pre-Processor + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^epp@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra20-epp + - nvidia,tegra30-epp + - nvidia,tegra114-epp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: epp + + iommus: + maxItems: 1 + + interconnects: + maxItems: 4 + + interconnect-names: + maxItems: 4 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the core power domain + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + epp@540c0000 { + compatible = "nvidia,tegra20-epp"; + reg = <0x540c0000 0x00040000>; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_EPP>; + resets = <&tegra_car 19>; + reset-names = "epp"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml new file mode 100644 index 000000000000..bf38accd98eb --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-gr2d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA 2D graphics engine + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^gr2d@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra20-gr2d + - nvidia,tegra30-gr2d + - nvidia,tegra114-gr2d + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + resets: + items: + - description: module reset + - description: memory client hotflush reset + + reset-names: + items: + - const: 2d + - const: mc + + iommus: + maxItems: 1 + + interconnects: + maxItems: 4 + + interconnect-names: + maxItems: 4 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the HEG or core power domain + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra20-mc.h> + + gr2d@54140000 { + compatible = "nvidia,tegra20-gr2d"; + reg = <0x54140000 0x00040000>; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_GR2D>; + resets = <&tegra_car 21>, <&mc TEGRA20_MC_RESET_2D>; + reset-names = "2d", "mc"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml new file mode 100644 index 000000000000..dbdf0229d9f6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-gr3d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA 3D graphics engine + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^gr3d@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra20-gr3d + - nvidia,tegra30-gr3d + - nvidia,tegra114-gr3d + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + + resets: + minItems: 2 + maxItems: 4 + + reset-names: + minItems: 2 + maxItems: 4 + + iommus: + minItems: 1 + maxItems: 2 + + interconnects: + minItems: 4 + maxItems: 10 + + interconnect-names: + minItems: 4 + maxItems: 10 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + minItems: 1 + maxItems: 2 + + power-domain-names: + minItems: 2 + maxItems: 2 + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra20-gr2d + then: + properties: + clocks: + items: + - description: module clock + + clock-names: + items: + - const: 3d + + resets: + items: + - description: module reset + - description: memory client hotflush reset + + reset-names: + items: + - const: 3d + - const: mc + + iommus: + maxItems: 1 + + interconnects: + minItems: 4 + maxItems: 4 + + interconnect-names: + minItems: 4 + maxItems: 4 + + power-domains: + items: + - description: phandle to the TD power domain + + - if: + properties: + compatible: + contains: + const: nvidia,tegra30-gr3d + then: + properties: + clocks: + items: + - description: primary module clock + - description: secondary module clock + + clock-names: + items: + - const: 3d + - const: 3d2 + + resets: + items: + - description: primary module reset + - description: secondary module reset + - description: primary memory client hotflush reset + - description: secondary memory client hotflush reset + + reset-names: + items: + - const: 3d + - const: 3d2 + - const: mc + - const: mc2 + + iommus: + minItems: 2 + maxItems: 2 + + interconnects: + minItems: 8 + maxItems: 8 + + interconnect-names: + minItems: 8 + maxItems: 8 + + power-domains: + items: + - description: phandle to the TD power domain + - description: phandle to the TD2 power domain + + power-domain-names: + items: + - const: 3d0 + - const: 3d1 + + dependencies: + power-domains: [ power-domain-names ] + + - if: + properties: + compatible: + contains: + const: nvidia,tegra114-gr2d + then: + properties: + clocks: + items: + - description: module clock + + clock-names: + items: + - const: 3d + + resets: + items: + - description: module reset + - description: memory client hotflush reset + + reset-names: + items: + - const: 3d + - const: mc + + iommus: + maxItems: 1 + + interconnects: + minItems: 10 + maxItems: 10 + + interconnect-names: + minItems: 10 + maxItems: 10 + + power-domains: + items: + - description: phandle to the TD power domain + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/memory/tegra20-mc.h> + + gr3d@54180000 { + compatible = "nvidia,tegra20-gr3d"; + reg = <0x54180000 0x00040000>; + clocks = <&tegra_car TEGRA20_CLK_GR3D>; + resets = <&tegra_car 24>, <&mc TEGRA20_MC_RESET_3D>; + reset-names = "3d", "mc"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml new file mode 100644 index 000000000000..035b9f1f2eb5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra HDMI Output Encoder + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^hdmi@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - nvidia,tegra20-hdmi + - nvidia,tegra30-hdmi + - nvidia,tegra114-hdmi + - nvidia,tegra124-hdmi + + - items: + - const: nvidia,tegra132-hdmi + - const: nvidia,tegra124-hdmi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + - description: parent clock + + clock-names: + items: + - const: hdmi + - const: parent + + resets: + items: + - description: module reset + + reset-names: + items: + - const: hdmi + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the core power domain + + hdmi-supply: + description: supply for the +5V HDMI connector pin + + vdd-supply: + description: regulator for supply voltage + + pll-supply: + description: regulator for PLL + + nvidia,ddc-i2c-bus: + description: phandle of an I2C controller used for DDC EDID + probing + $ref: "/schemas/types.yaml#/definitions/phandle" + + nvidia,hpd-gpio: + description: specifies a GPIO used for hotplug detection + maxItems: 1 + + nvidia,edid: + description: supplies a binary EDID blob + $ref: "/schemas/types.yaml#/definitions/uint8-array" + + nvidia,panel: + description: phandle of a display panel + $ref: "/schemas/types.yaml#/definitions/phandle" + + "#sound-dai-cells": + const: 0 + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - pll-supply + - vdd-supply + - nvidia,ddc-i2c-bus + - nvidia,hpd-gpio + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/gpio/tegra-gpio.h> + + hdmi@54280000 { + compatible = "nvidia,tegra124-hdmi"; + reg = <0x54280000 0x00040000>; + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA124_CLK_HDMI>, + <&tegra_car TEGRA124_CLK_PLL_D2_OUT0>; + clock-names = "hdmi", "parent"; + resets = <&tegra_car 51>; + reset-names = "hdmi"; + + hdmi-supply = <&vdd_5v0_hdmi>; + pll-supply = <&vdd_hdmi_pll>; + vdd-supply = <&vdd_3v3_hdmi>; + + nvidia,ddc-i2c-bus = <&hdmi_ddc>; + nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt deleted file mode 100644 index e61999ce54e9..000000000000 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ /dev/null @@ -1,675 +0,0 @@ -NVIDIA Tegra host1x - -Required properties: -- compatible: "nvidia,tegra<chip>-host1x" -- reg: Physical base address and length of the controller's registers. - For pre-Tegra186, one entry describing the whole register area. - For Tegra186, one entry for each entry in reg-names: - "vm" - VM region assigned to Linux - "hypervisor" - Hypervisor region (only if Linux acts as hypervisor) -- interrupts: The interrupt outputs from the controller. -- #address-cells: The number of cells used to represent physical base addresses - in the host1x address space. Should be 1. -- #size-cells: The number of cells used to represent the size of an address - range in the host1x address space. Should be 1. -- ranges: The mapping of the host1x address space to the CPU address space. -- clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - host1x - - mc - -Optional properties: -- operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to HEG or core power domain. - -For each opp entry in 'operating-points-v2' table of host1x and its modules: -- opp-supported-hw: One bitfield indicating: - On Tegra20: SoC process ID mask - On Tegra30+: SoC speedo ID mask - - A bitwise AND is performed against the value and if any bit - matches, the OPP gets enabled. - -Each host1x client module having to perform DMA through the Memory Controller -should have the interconnect endpoints set to the Memory Client and External -Memory respectively. - -The host1x top-level node defines a number of children, each representing one -of the following host1x client modules: - -- mpe: video encoder - - Required properties: - - compatible: "nvidia,tegra<chip>-mpe" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - mpe - - Optional properties: - - interconnects: Must contain entry for the MPE memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to MPE power domain. - -- vi: video input - - Required properties: - - compatible: "nvidia,tegra<chip>-vi" - - reg: Physical base address and length of the controller registers. - - interrupts: The interrupt outputs from the controller. - - clocks: clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - Tegra20/Tegra30/Tegra114/Tegra124: - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - vi - - Tegra210: - - power-domains: Must include venc powergate node as vi is in VE partition. - - ports (optional node) - vi can have optional ports node and max 6 ports are supported. Each port - should have single 'endpoint' child node. All port nodes are grouped under - ports node. Please refer to the bindings defined in - Documentation/devicetree/bindings/media/video-interfaces.txt - - csi (required node) - Tegra210 has CSI part of VI sharing same host interface and register space. - So, VI device node should have CSI child node. - - - csi: mipi csi interface to vi - - Required properties: - - compatible: "nvidia,tegra210-csi" - - reg: Physical base address offset to parent and length of the controller - registers. - - clocks: Must contain entries csi, cilab, cilcd, cile, csi_tpg clocks. - See ../clocks/clock-bindings.txt for details. - - power-domains: Must include sor powergate node as csicil is in - SOR partition. - - channel (optional nodes) - Maximum 6 channels are supported with each csi brick as either x4 or x2 - based on hw connectivity to sensor. - - Required properties: - - reg: csi port number. Valid port numbers are 0 through 5. - - nvidia,mipi-calibrate: Should contain a phandle and a specifier - specifying which pads are used by this CSI port and need to be - calibrated. See also ../display/tegra/nvidia,tegra114-mipi.txt. - - Each channel node must contain 2 port nodes which can be grouped - under 'ports' node and each port should have a single child 'endpoint' - node. - - ports node - Please refer to the bindings defined in - Documentation/devicetree/bindings/media/video-interfaces.txt - - ports node must contain below 2 port nodes. - port@0 with single child 'endpoint' node always a sink. - port@1 with single child 'endpoint' node always a source. - - port@0 (required node) - Required properties: - - reg: 0 - - endpoint (required node) - Required properties: - - data-lanes: an array of data lane from 1 to 8. Valid array - lengths are 1/2/4/8. - - remote-endpoint: phandle to sensor 'endpoint' node. - - port@1 (required node) - Required properties: - - reg: 1 - - endpoint (required node) - Required properties: - - remote-endpoint: phandle to vi port 'endpoint' node. - - Optional properties: - - interconnects: Must contain entry for the VI memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to VENC power domain. - -- epp: encoder pre-processor - - Required properties: - - compatible: "nvidia,tegra<chip>-epp" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - epp - - Optional properties: - - interconnects: Must contain entry for the EPP memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to HEG or core power domain. - -- isp: image signal processor - - Required properties: - - compatible: "nvidia,tegra<chip>-isp" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - isp - - Optional properties: - - interconnects: Must contain entry for the ISP memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - power-domains: Phandle to VENC or core power domain. - -- gr2d: 2D graphics engine - - Required properties: - - compatible: "nvidia,tegra<chip>-gr2d" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - 2d - - mc - - Optional properties: - - interconnects: Must contain entry for the GR2D memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to HEG or core power domain. - -- gr3d: 3D graphics engine - - Required properties: - - compatible: "nvidia,tegra<chip>-gr3d" - - reg: Physical base address and length of the controller's registers. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - (This property may be omitted if the only clock in the list is "3d") - - 3d - This MUST be the first entry. - - 3d2 (Only required on SoCs with two 3D clocks) - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - 3d - - 3d2 (Only required on SoCs with two 3D clocks) - - mc - - mc2 (Only required on SoCs with two 3D clocks) - - Optional properties: - - interconnects: Must contain entry for the GR3D memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandles to 3D or core power domain. - -- dc: display controller - - Required properties: - - compatible: "nvidia,tegra<chip>-dc" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - dc - This MUST be the first entry. - - parent - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - dc - - nvidia,head: The number of the display controller head. This is used to - setup the various types of output to receive video data from the given - head. - - Each display controller node has a child node, named "rgb", that represents - the RGB output associated with the controller. It can take the following - optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - - interconnects: Must contain entry for the DC memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to core power domain. - -- hdmi: High Definition Multimedia Interface - - Required properties: - - compatible: "nvidia,tegra<chip>-hdmi" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - hdmi-supply: supply for the +5V HDMI connector pin - - vdd-supply: regulator for supply voltage - - pll-supply: regulator for PLL - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - hdmi - This MUST be the first entry. - - parent - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - hdmi - - Optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - - operating-points-v2: See ../bindings/opp/opp.txt for details. - -- tvo: TV encoder output - - Required properties: - - compatible: "nvidia,tegra<chip>-tvo" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - Optional properties: - - operating-points-v2: See ../bindings/opp/opp.txt for details. - - power-domains: Phandle to core power domain. - -- dsi: display serial interface - - Required properties: - - compatible: "nvidia,tegra<chip>-dsi" - - reg: Physical base address and length of the controller's registers. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - dsi - This MUST be the first entry. - - lp - - parent - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - dsi - - avdd-dsi-supply: phandle of a supply that powers the DSI controller - - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying - which pads are used by this DSI output and need to be calibrated. See also - ../display/tegra/nvidia,tegra114-mipi.txt. - - Optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - - nvidia,ganged-mode: contains a phandle to a second DSI controller to gang - up with in order to support up to 8 data lanes - - operating-points-v2: See ../bindings/opp/opp.txt for details. - -- sor: serial output resource - - Required properties: - - compatible: Should be: - - "nvidia,tegra124-sor": for Tegra124 and Tegra132 - - "nvidia,tegra132-sor": for Tegra132 - - "nvidia,tegra210-sor": for Tegra210 - - "nvidia,tegra210-sor1": for Tegra210 - - "nvidia,tegra186-sor": for Tegra186 - - "nvidia,tegra186-sor1": for Tegra186 - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - sor: clock input for the SOR hardware - - out: SOR output clock - - parent: input for the pixel clock - - dp: reference clock for the SOR clock - - safe: safe reference for the SOR clock during power up - - For Tegra186 and later: - - pad: SOR pad output clock (on Tegra186 and later) - - Obsolete: - - source: source clock for the SOR clock (obsolete, use "out" instead) - - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - sor - - Required properties on Tegra186 and later: - - nvidia,interface: index of the SOR interface - - Optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - - nvidia,xbar-cfg: 5 cells containing the crossbar configuration. Each lane - of the SOR, identified by the cell's index, is mapped via the crossbar to - the pad specified by the cell's value. - - Optional properties when driving an eDP output: - - nvidia,dpaux: phandle to a DispayPort AUX interface - -- dpaux: DisplayPort AUX interface - - compatible : Should contain one of the following: - - "nvidia,tegra124-dpaux": for Tegra124 and Tegra132 - - "nvidia,tegra210-dpaux": for Tegra210 - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - dpaux: clock input for the DPAUX hardware - - parent: reference clock - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - dpaux - - vdd-supply: phandle of a supply that powers the DisplayPort link - - i2c-bus: Subnode where I2C slave devices are listed. This subnode - must be always present. If there are no I2C slave devices, an empty - node should be added. See ../../i2c/i2c.txt for more information. - - See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information - regarding the DPAUX pad controller bindings. - -- vic: Video Image Compositor - - compatible : "nvidia,tegra<chip>-vic" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - vic: clock input for the VIC hardware - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - vic - - Optional properties: - - interconnects: Must contain entry for the VIC memory clients. - - interconnect-names: Must include name of the interconnect path for each - interconnect entry. Consult TRM documentation for information about - available memory clients, see MEMORY CONTROLLER section. - -Example: - -/ { - ... - - host1x { - compatible = "nvidia,tegra20-host1x", "simple-bus"; - reg = <0x50000000 0x00024000>; - interrupts = <0 65 0x04 /* mpcore syncpt */ - 0 67 0x04>; /* mpcore general */ - clocks = <&tegra_car TEGRA20_CLK_HOST1X>; - resets = <&tegra_car 28>; - reset-names = "host1x"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - - #address-cells = <1>; - #size-cells = <1>; - - ranges = <0x54000000 0x54000000 0x04000000>; - - mpe { - compatible = "nvidia,tegra20-mpe"; - reg = <0x54040000 0x00040000>; - interrupts = <0 68 0x04>; - clocks = <&tegra_car TEGRA20_CLK_MPE>; - resets = <&tegra_car 60>; - reset-names = "mpe"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - }; - - vi@54080000 { - compatible = "nvidia,tegra210-vi"; - reg = <0x0 0x54080000 0x0 0x700>; - interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; - assigned-clocks = <&tegra_car TEGRA210_CLK_VI>; - assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>; - operating-points-v2 = <&dvfs_opp_table>; - - clocks = <&tegra_car TEGRA210_CLK_VI>; - power-domains = <&pd_venc>; - - #address-cells = <1>; - #size-cells = <1>; - - ranges = <0x0 0x0 0x54080000 0x2000>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - imx219_vi_in0: endpoint { - remote-endpoint = <&imx219_csi_out0>; - }; - }; - }; - - csi@838 { - compatible = "nvidia,tegra210-csi"; - reg = <0x838 0x1300>; - assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>, - <&tegra_car TEGRA210_CLK_CILCD>, - <&tegra_car TEGRA210_CLK_CILE>, - <&tegra_car TEGRA210_CLK_CSI_TPG>; - assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>, - <&tegra_car TEGRA210_CLK_PLL_P>, - <&tegra_car TEGRA210_CLK_PLL_P>; - assigned-clock-rates = <102000000>, - <102000000>, - <102000000>, - <972000000>; - - clocks = <&tegra_car TEGRA210_CLK_CSI>, - <&tegra_car TEGRA210_CLK_CILAB>, - <&tegra_car TEGRA210_CLK_CILCD>, - <&tegra_car TEGRA210_CLK_CILE>, - <&tegra_car TEGRA210_CLK_CSI_TPG>; - clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg"; - power-domains = <&pd_sor>; - - #address-cells = <1>; - #size-cells = <0>; - - channel@0 { - reg = <0>; - nvidia,mipi-calibrate = <&mipi 0x001>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - imx219_csi_in0: endpoint { - data-lanes = <1 2>; - remote-endpoint = <&imx219_out0>; - }; - }; - - port@1 { - reg = <1>; - imx219_csi_out0: endpoint { - remote-endpoint = <&imx219_vi_in0>; - }; - }; - }; - }; - }; - }; - - epp { - compatible = "nvidia,tegra20-epp"; - reg = <0x540c0000 0x00040000>; - interrupts = <0 70 0x04>; - clocks = <&tegra_car TEGRA20_CLK_EPP>; - resets = <&tegra_car 19>; - reset-names = "epp"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - }; - - isp { - compatible = "nvidia,tegra20-isp"; - reg = <0x54100000 0x00040000>; - interrupts = <0 71 0x04>; - clocks = <&tegra_car TEGRA20_CLK_ISP>; - resets = <&tegra_car 23>; - reset-names = "isp"; - }; - - gr2d { - compatible = "nvidia,tegra20-gr2d"; - reg = <0x54140000 0x00040000>; - interrupts = <0 72 0x04>; - clocks = <&tegra_car TEGRA20_CLK_GR2D>; - resets = <&tegra_car 21>; - reset-names = "2d"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - }; - - gr3d { - compatible = "nvidia,tegra20-gr3d"; - reg = <0x54180000 0x00040000>; - clocks = <&tegra_car TEGRA20_CLK_GR3D>; - resets = <&tegra_car 24>; - reset-names = "3d"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - }; - - dc@54200000 { - compatible = "nvidia,tegra20-dc"; - reg = <0x54200000 0x00040000>; - interrupts = <0 73 0x04>; - clocks = <&tegra_car TEGRA20_CLK_DISP1>, - <&tegra_car TEGRA20_CLK_PLL_P>; - clock-names = "dc", "parent"; - resets = <&tegra_car 27>; - reset-names = "dc"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - - interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>, - <&mc TEGRA20_MC_DISPLAY0B &emc>, - <&mc TEGRA20_MC_DISPLAY0C &emc>, - <&mc TEGRA20_MC_DISPLAYHC &emc>; - interconnect-names = "wina", - "winb", - "winc", - "cursor"; - - rgb { - status = "disabled"; - }; - }; - - dc@54240000 { - compatible = "nvidia,tegra20-dc"; - reg = <0x54240000 0x00040000>; - interrupts = <0 74 0x04>; - clocks = <&tegra_car TEGRA20_CLK_DISP2>, - <&tegra_car TEGRA20_CLK_PLL_P>; - clock-names = "dc", "parent"; - resets = <&tegra_car 26>; - reset-names = "dc"; - operating-points-v2 = <&dvfs_opp_table>; - power-domains = <&domain>; - - interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>, - <&mc TEGRA20_MC_DISPLAY0BB &emc>, - <&mc TEGRA20_MC_DISPLAY0CB &emc>, - <&mc TEGRA20_MC_DISPLAYHCB &emc>; - interconnect-names = "wina", - "winb", - "winc", - "cursor"; - - rgb { - status = "disabled"; - }; - }; - - hdmi { - compatible = "nvidia,tegra20-hdmi"; - reg = <0x54280000 0x00040000>; - interrupts = <0 75 0x04>; - clocks = <&tegra_car TEGRA20_CLK_HDMI>, - <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; - clock-names = "hdmi", "parent"; - resets = <&tegra_car 51>; - reset-names = "hdmi"; - status = "disabled"; - operating-points-v2 = <&dvfs_opp_table>; - }; - - tvo { - compatible = "nvidia,tegra20-tvo"; - reg = <0x542c0000 0x00040000>; - interrupts = <0 76 0x04>; - clocks = <&tegra_car TEGRA20_CLK_TVO>; - status = "disabled"; - operating-points-v2 = <&dvfs_opp_table>; - }; - - dsi { - compatible = "nvidia,tegra20-dsi"; - reg = <0x54300000 0x00040000>; - clocks = <&tegra_car TEGRA20_CLK_DSI>, - <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; - clock-names = "dsi", "parent"; - resets = <&tegra_car 48>; - reset-names = "dsi"; - status = "disabled"; - operating-points-v2 = <&dvfs_opp_table>; - }; - }; - - ... -}; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml new file mode 100644 index 000000000000..913ca104c871 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml @@ -0,0 +1,431 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-host1x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra host1x controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The host1x top-level node defines a number of children, each + representing one of the host1x client modules defined in this binding. + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-host1x + - nvidia,tegra30-host1x + - nvidia,tegra114-host1x + - nvidia,tegra124-host1x + - nvidia,tegra210-host1x + - nvidia,tegra186-host1x + - nvidia,tegra194-host1x + - nvidia,tegra234-host1x + + - items: + - const: nvidia,tegra132-host1x + - const: nvidia,tegra124-host1x + + reg: + minItems: 1 + maxItems: 3 + + reg-names: + minItems: 1 + maxItems: 3 + + interrupts: + minItems: 1 + maxItems: 9 + + interrupt-names: + minItems: 1 + maxItems: 9 + + '#address-cells': + description: The number of cells used to represent physical base addresses + in the host1x address space. + enum: [1, 2] + + '#size-cells': + description: The number of cells used to represent the size of an address + range in the host1x address space. + enum: [1, 2] + + ranges: + maxItems: 1 + + clocks: + description: Must contain one entry, for the module clock. See + ../clocks/clock-bindings.txt for details. + + clock-names: + items: + - const: host1x + + resets: + minItems: 1 # MC reset is optional on Tegra186 and later + items: + - description: module reset + - description: memory client hotflush reset + + reset-names: + minItems: 1 # MC reset is optional on Tegra186 and later + items: + - const: host1x + - const: mc + + iommus: + maxItems: 1 + + interconnects: + items: + - description: memory read client for host1x + + interconnect-names: + items: + - const: dma-mem # read + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the HEG or core power domain + +required: + - compatible + - interrupts + - interrupt-names + - '#address-cells' + - '#size-cells' + - ranges + - reg + - clocks + - clock-names + +unevaluatedProperties: + type: object + +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-host1x + - nvidia,tegra30-host1x + - nvidia,tegra114-host1x + - nvidia,tegra124-host1x + - nvidia,tegra210-host1x + then: + properties: + interrupts: + items: + - description: host1x syncpoint interrupt + - description: host1x general interrupt + + interrupt-names: + items: + - const: syncpt + - const: host1x + required: + - resets + - reset-names + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra186-host1x + - nvidia,tegra194-host1x + then: + properties: + reg-names: + items: + - const: hypervisor + - const: vm + + reg: + items: + - description: region used by the hypervisor + - description: region assigned to the virtual machine + + resets: + maxItems: 1 + + reset-names: + maxItems: 1 + + interrupts: + items: + - description: host1x syncpoint interrupt + - description: host1x general interrupt + + interrupt-names: + items: + - const: syncpt + - const: host1x + + iommu-map: + description: Specification of stream IDs available for memory context device + use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to + usable stream IDs. + + required: + - reg-names + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra234-host1x + then: + properties: + reg-names: + items: + - const: common + - const: hypervisor + - const: vm + + reg: + items: + - description: region used by host1x server + - description: region used by the hypervisor + - description: region assigned to the virtual machine + + interrupts: + items: + - description: host1x syncpoint interrupt 0 + - description: host1x syncpoint interrupt 1 + - description: host1x syncpoint interrupt 2 + - description: host1x syncpoint interrupt 3 + - description: host1x syncpoint interrupt 4 + - description: host1x syncpoint interrupt 5 + - description: host1x syncpoint interrupt 6 + - description: host1x syncpoint interrupt 7 + - description: host1x general interrupt + + interrupt-names: + items: + - const: syncpt0 + - const: syncpt1 + - const: syncpt2 + - const: syncpt3 + - const: syncpt4 + - const: syncpt5 + - const: syncpt6 + - const: syncpt7 + - const: host1x + + iommu-map: + description: Specification of stream IDs available for memory context device + use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to + usable stream IDs. + + required: + - reg-names + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/memory/tegra20-mc.h> + + host1x@50000000 { + compatible = "nvidia,tegra20-host1x"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04>, /* mpcore syncpt */ + <0 67 0x04>; /* mpcore general */ + interrupt-names = "syncpt", "host1x"; + clocks = <&tegra_car TEGRA20_CLK_HOST1X>; + clock-names = "host1x"; + resets = <&tegra_car 28>, <&mc TEGRA20_MC_RESET_HC>; + reset-names = "host1x", "mc"; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + mpe@54040000 { + compatible = "nvidia,tegra20-mpe"; + reg = <0x54040000 0x00040000>; + interrupts = <0 68 0x04>; + clocks = <&tegra_car TEGRA20_CLK_MPE>; + resets = <&tegra_car 60>; + reset-names = "mpe"; + }; + + vi@54080000 { + compatible = "nvidia,tegra20-vi"; + reg = <0x54080000 0x00040000>; + interrupts = <0 69 0x04>; + clocks = <&tegra_car TEGRA20_CLK_VI>; + resets = <&tegra_car 100>; + reset-names = "vi"; + }; + + epp@540c0000 { + compatible = "nvidia,tegra20-epp"; + reg = <0x540c0000 0x00040000>; + interrupts = <0 70 0x04>; + clocks = <&tegra_car TEGRA20_CLK_EPP>; + resets = <&tegra_car 19>; + reset-names = "epp"; + }; + + isp@54100000 { + compatible = "nvidia,tegra20-isp"; + reg = <0x54100000 0x00040000>; + interrupts = <0 71 0x04>; + clocks = <&tegra_car TEGRA20_CLK_ISP>; + resets = <&tegra_car 23>; + reset-names = "isp"; + }; + + gr2d@54140000 { + compatible = "nvidia,tegra20-gr2d"; + reg = <0x54140000 0x00040000>; + interrupts = <0 72 0x04>; + clocks = <&tegra_car TEGRA20_CLK_GR2D>; + resets = <&tegra_car 21>, <&mc TEGRA20_MC_RESET_2D>; + reset-names = "2d", "mc"; + }; + + gr3d@54180000 { + compatible = "nvidia,tegra20-gr3d"; + reg = <0x54180000 0x00040000>; + clocks = <&tegra_car TEGRA20_CLK_GR3D>; + resets = <&tegra_car 24>, <&mc TEGRA20_MC_RESET_3D>; + reset-names = "3d", "mc"; + }; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + clocks = <&tegra_car TEGRA20_CLK_DISP1>; + clock-names = "dc"; + resets = <&tegra_car 27>; + reset-names = "dc"; + + rgb { + }; + }; + + dc@54240000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54240000 0x00040000>; + interrupts = <0 74 0x04>; + clocks = <&tegra_car TEGRA20_CLK_DISP2>; + clock-names = "dc"; + resets = <&tegra_car 26>; + reset-names = "dc"; + + rgb { + }; + }; + + hdmi@54280000 { + compatible = "nvidia,tegra20-hdmi"; + reg = <0x54280000 0x00040000>; + interrupts = <0 75 0x04>; + clocks = <&tegra_car TEGRA20_CLK_HDMI>, + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; + clock-names = "hdmi", "parent"; + resets = <&tegra_car 51>; + reset-names = "hdmi"; + + hdmi-supply = <&vdd_5v0_hdmi>; + pll-supply = <&vdd_hdmi_pll>; + vdd-supply = <&vdd_3v3_hdmi>; + + nvidia,ddc-i2c-bus = <&hdmi_ddc>; + nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>; + }; + + tvo@542c0000 { + compatible = "nvidia,tegra20-tvo"; + reg = <0x542c0000 0x00040000>; + interrupts = <0 76 0x04>; + clocks = <&tegra_car TEGRA20_CLK_TVO>; + }; + + dsi@54300000 { + compatible = "nvidia,tegra20-dsi"; + reg = <0x54300000 0x00040000>; + clocks = <&tegra_car TEGRA20_CLK_DSI>, + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; + clock-names = "dsi", "parent"; + resets = <&tegra_car 48>; + reset-names = "dsi"; + }; + }; + + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra210-mc.h> + + host1x@50000000 { + compatible = "nvidia,tegra210-host1x"; + reg = <0x50000000 0x00024000>; + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, /* mpcore syncpt */ + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; /* mpcore general */ + interrupt-names = "syncpt", "host1x"; + clocks = <&tegra_car TEGRA210_CLK_HOST1X>; + clock-names = "host1x"; + resets = <&tegra_car 28>; + reset-names = "host1x"; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x01000000>; + iommus = <&mc TEGRA_SWGROUP_HC>; + + vi@54080000 { + compatible = "nvidia,tegra210-vi"; + reg = <0x54080000 0x00000700>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&tegra_car TEGRA210_CLK_VI>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>; + + clocks = <&tegra_car TEGRA210_CLK_VI>; + power-domains = <&pd_venc>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x0 0x54080000 0x2000>; + + csi@838 { + compatible = "nvidia,tegra210-csi"; + reg = <0x838 0x1300>; + assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>, + <&tegra_car TEGRA210_CLK_CILCD>, + <&tegra_car TEGRA210_CLK_CILE>, + <&tegra_car TEGRA210_CLK_CSI_TPG>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>, + <&tegra_car TEGRA210_CLK_PLL_P>, + <&tegra_car TEGRA210_CLK_PLL_P>; + assigned-clock-rates = <102000000>, + <102000000>, + <102000000>, + <972000000>; + + clocks = <&tegra_car TEGRA210_CLK_CSI>, + <&tegra_car TEGRA210_CLK_CILAB>, + <&tegra_car TEGRA210_CLK_CILCD>, + <&tegra_car TEGRA210_CLK_CILE>, + <&tegra_car TEGRA210_CLK_CSI_TPG>; + clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg"; + power-domains = <&pd_sor>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml new file mode 100644 index 000000000000..3bc3b22e98e1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-isp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra ISP processor + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + enum: + - nvidia,tegra20-isp + - nvidia,tegra30-isp + - nvidia,tegra210-isp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + resets: + items: + - description: module reset + + reset-names: + items: + - const: isp + + iommus: + maxItems: 1 + + interconnects: + items: + - description: memory write client + + interconnect-names: + items: + - const: dma-mem # write + + power-domains: + items: + - description: phandle to the VENC or core power domain + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + isp@54100000 { + compatible = "nvidia,tegra20-isp"; + reg = <0x54100000 0x00040000>; + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_ISP>; + resets = <&tegra_car 23>; + reset-names = "isp"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml new file mode 100644 index 000000000000..4154ae01ad13 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-mpe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Video Encoder + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^mpe@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra20-mpe + - nvidia,tegra30-mpe + - nvidia,tegra114-mpe + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + resets: + items: + - description: module reset + + reset-names: + items: + - const: mpe + + iommus: + maxItems: 1 + + interconnects: + minItems: 6 + maxItems: 6 + + interconnect-names: + minItems: 6 + maxItems: 6 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the MPE power domain + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mpe@54040000 { + compatible = "nvidia,tegra20-mpe"; + reg = <0x54040000 0x00040000>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_MPE>; + resets = <&tegra_car 60>; + reset-names = "mpe"; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml new file mode 100644 index 000000000000..467b015e5700 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-tvo.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra TV Encoder Output + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^tvo@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra20-tvo + - nvidia,tegra30-tvo + - nvidia,tegra114-tvo + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the core power domain + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tvo@542c0000 { + compatible = "nvidia,tegra20-tvo"; + reg = <0x542c0000 0x00040000>; + interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_TVO>; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml new file mode 100644 index 000000000000..782a4b10150a --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml @@ -0,0 +1,163 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-vi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Video Input controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^vi@[0-9a-f]+$" + + compatible: + oneOf: + - const: nvidia,tegra20-vi + - const: nvidia,tegra30-vi + - const: nvidia,tegra114-vi + - const: nvidia,tegra124-vi + - items: + - const: nvidia,tegra132-vi + - const: nvidia,tegra124-vi + - const: nvidia,tegra210-vi + - const: nvidia,tegra186-vi + - const: nvidia,tegra194-vi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: vi + + iommus: + maxItems: 1 + + interconnects: + minItems: 4 + maxItems: 5 + + interconnect-names: + minItems: 4 + maxItems: 5 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the VENC power domain + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: + maxItems: 1 + + avdd-dsi-csi-supply: + description: DSI/CSI power supply. Must supply 1.2 V. + +patternProperties: + "^csi@[0-9a-f]+$": + type: object + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-vi + - nvidia,tegra30-vi + - nvidia,tegra114-vi + - nvidia,tegra124-vi + then: + required: + - resets + - reset-names + else: + required: + - power-domains + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + vi@54080000 { + compatible = "nvidia,tegra20-vi"; + reg = <0x54080000 0x00040000>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA20_CLK_VI>; + resets = <&tegra_car 100>; + reset-names = "vi"; + }; + + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + vi@54080000 { + compatible = "nvidia,tegra210-vi"; + reg = <0x54080000 0x00000700>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&tegra_car TEGRA210_CLK_VI>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>; + + clocks = <&tegra_car TEGRA210_CLK_VI>; + power-domains = <&pd_venc>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x0 0x54080000 0x2000>; + + csi@838 { + compatible = "nvidia,tegra210-csi"; + reg = <0x838 0x1300>; + assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>, + <&tegra_car TEGRA210_CLK_CILCD>, + <&tegra_car TEGRA210_CLK_CILE>, + <&tegra_car TEGRA210_CLK_CSI_TPG>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>, + <&tegra_car TEGRA210_CLK_PLL_P>, + <&tegra_car TEGRA210_CLK_PLL_P>; + assigned-clock-rates = <102000000>, + <102000000>, + <102000000>, + <972000000>; + + clocks = <&tegra_car TEGRA210_CLK_CSI>, + <&tegra_car TEGRA210_CLK_CILAB>, + <&tegra_car TEGRA210_CLK_CILCD>, + <&tegra_car TEGRA210_CLK_CILE>, + <&tegra_car TEGRA210_CLK_CSI_TPG>; + clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg"; + power-domains = <&pd_sor>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml new file mode 100644 index 000000000000..fa07a40d1004 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra210-csi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra CSI controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + $nodename: + pattern: "^csi@[0-9a-f]+$" + + compatible: + enum: + - nvidia,tegra210-csi + + reg: + maxItems: 1 + + clocks: + items: + - description: module clock + - description: A/B lanes clock + - description: C/D lanes clock + - description: E lane clock + - description: test pattern generator clock + + clock-names: + items: + - const: csi + - const: cilab + - const: cilcd + - const: cile + - const: csi_tpg + + power-domains: + maxItems: 1 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + +# see nvidia,tegra20-vi.yaml for an example diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml index ff0a5c58d78c..e712444abff1 100644 --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml @@ -67,7 +67,7 @@ if: then: properties: clocks: - maxItems: 2 + minItems: 2 required: - clock-names diff --git a/Documentation/devicetree/bindings/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml new file mode 100644 index 000000000000..bdc8c129c4f5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/apple,admac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Audio DMA Controller (ADMAC) + +description: | + Apple's Audio DMA Controller (ADMAC) is used to fetch and store audio samples + on SoCs from the "Apple Silicon" family. + + The controller has been seen with up to 24 channels. Even-numbered channels + are TX-only, odd-numbered are RX-only. Individual channels are coupled to + fixed device endpoints. + +maintainers: + - Martin PoviÅ¡er <povik+lin@cutebit.org> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + items: + - enum: + - apple,t6000-admac + - apple,t8103-admac + - const: apple,admac + + reg: + maxItems: 1 + + '#dma-cells': + const: 1 + description: + Clients specify a single cell with channel number. + + dma-channels: + maximum: 24 + + interrupts: + minItems: 4 + maxItems: 4 + description: + Interrupts that correspond to the 4 IRQ outputs of the controller. Usually + only one of the controller outputs will be connected as an usable interrupt + source. The remaining interrupts will be left without a valid value, e.g. + in an interrupts-extended list the disconnected positions will contain + an empty phandle reference <0>. + +required: + - compatible + - reg + - '#dma-cells' + - dma-channels + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/apple-aic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + aic: interrupt-controller { + interrupt-controller; + #interrupt-cells = <3>; + }; + + admac: dma-controller@238200000 { + compatible = "apple,t8103-admac", "apple,admac"; + reg = <0x38200000 0x34000>; + dma-channels = <24>; + interrupts-extended = <0>, + <&aic AIC_IRQ 626 IRQ_TYPE_LEVEL_HIGH>, + <0>, + <0>; + #dma-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml new file mode 100644 index 000000000000..050e6cd57727 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/fsl,edma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale enhanced Direct Memory Access(eDMA) Controller + +description: | + The eDMA channels have multiplex capability by programmable + memory-mapped registers. channels are split into two groups, called + DMAMUX0 and DMAMUX1, specific DMA request source can only be multiplexed + by any channel of certain group, DMAMUX0 or DMAMUX1, but not both. + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +properties: + compatible: + oneOf: + - enum: + - fsl,vf610-edma + - fsl,imx7ulp-edma + - items: + - const: fsl,ls1028a-edma + - const: fsl,vf610-edma + + reg: + minItems: 2 + maxItems: 3 + + interrupts: + minItems: 2 + maxItems: 17 + + interrupt-names: + minItems: 2 + maxItems: 17 + + "#dma-cells": + const: 2 + + dma-channels: + const: 32 + + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + + big-endian: + description: | + If present registers and hardware scatter/gather descriptors of the + eDMA are implemented in big endian mode, otherwise in little mode. + type: boolean + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - dma-channels + +allOf: + - $ref: "dma-controller.yaml#" + - if: + properties: + compatible: + contains: + const: fsl,vf610-edma + then: + properties: + clock-names: + items: + - const: dmamux0 + - const: dmamux1 + interrupts: + maxItems: 2 + interrupt-names: + items: + - const: edma-tx + - const: edma-err + reg: + maxItems: 3 + + - if: + properties: + compatible: + contains: + const: fsl,imx7ulp-edma + then: + properties: + clock-names: + items: + - const: dma + - const: dmamux0 + interrupts: + maxItems: 17 + reg: + maxItems: 2 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/vf610-clock.h> + + edma0: dma-controller@40018000 { + #dma-cells = <2>; + compatible = "fsl,vf610-edma"; + reg = <0x40018000 0x2000>, + <0x40024000 0x1000>, + <0x40025000 0x1000>; + interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>, + <0 9 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "edma-tx", "edma-err"; + dma-channels = <32>; + clock-names = "dmamux0", "dmamux1"; + clocks = <&clks VF610_CLK_DMAMUX0>, <&clks VF610_CLK_DMAMUX1>; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx7ulp-clock.h> + + edma1: dma-controller@40080000 { + #dma-cells = <2>; + compatible = "fsl,imx7ulp-edma"; + reg = <0x40080000 0x2000>, + <0x40210000 0x1000>; + dma-channels = <32>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>, + /* last is eDMA2-ERR interrupt */ + <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "dma", "dmamux0"; + clocks = <&pcc2 IMX7ULP_CLK_DMA1>, <&pcc2 IMX7ULP_CLK_DMA_MUX1>; + }; diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt b/Documentation/devicetree/bindings/dma/fsl-edma.txt deleted file mode 100644 index ee1754739b4b..000000000000 --- a/Documentation/devicetree/bindings/dma/fsl-edma.txt +++ /dev/null @@ -1,111 +0,0 @@ -* Freescale enhanced Direct Memory Access(eDMA) Controller - - The eDMA channels have multiplex capability by programmble memory-mapped -registers. channels are split into two groups, called DMAMUX0 and DMAMUX1, -specific DMA request source can only be multiplexed by any channel of certain -group, DMAMUX0 or DMAMUX1, but not both. - -* eDMA Controller -Required properties: -- compatible : - - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC - - "fsl,imx7ulp-edma" for eDMA2 used similar to that on i.mx7ulp - - "fsl,ls1028a-edma" followed by "fsl,vf610-edma" for eDMA used on the - LS1028A SoC. -- reg : Specifies base physical address(s) and size of the eDMA registers. - The 1st region is eDMA control register's address and size. - The 2nd and the 3rd regions are programmable channel multiplexing - control register's address and size. -- interrupts : A list of interrupt-specifiers, one for each entry in - interrupt-names on vf610 similar SoC. But for i.mx7ulp per channel - per transmission interrupt, total 16 channel interrupt and 1 - error interrupt(located in the last), no interrupt-names list on - i.mx7ulp for clean on dts. -- #dma-cells : Must be <2>. - The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1). - Specific request source can only be multiplexed by specific channels - group called DMAMUX. - The 2nd cell specifies the request source(slot) ID. - See the SoC's reference manual for all the supported request sources. -- dma-channels : Number of channels supported by the controller -- clock-names : A list of channel group clock names. Should contain: - "dmamux0" - clock name of mux0 group - "dmamux1" - clock name of mux1 group - Note: No dmamux0 on i.mx7ulp, but another 'dma' clk added on i.mx7ulp. -- clocks : A list of phandle and clock-specifier pairs, one for each entry in - clock-names. - -Optional properties: -- big-endian: If present registers and hardware scatter/gather descriptors - of the eDMA are implemented in big endian mode, otherwise in little - mode. -- interrupt-names : Should contain the below on vf610 similar SoC but not used - on i.mx7ulp similar SoC: - "edma-tx" - the transmission interrupt - "edma-err" - the error interrupt - - -Examples: - -edma0: dma-controller@40018000 { - #dma-cells = <2>; - compatible = "fsl,vf610-edma"; - reg = <0x40018000 0x2000>, - <0x40024000 0x1000>, - <0x40025000 0x1000>; - interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>, - <0 9 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "edma-tx", "edma-err"; - dma-channels = <32>; - clock-names = "dmamux0", "dmamux1"; - clocks = <&clks VF610_CLK_DMAMUX0>, - <&clks VF610_CLK_DMAMUX1>; -}; /* vf610 */ - -edma1: dma-controller@40080000 { - #dma-cells = <2>; - compatible = "fsl,imx7ulp-edma"; - reg = <0x40080000 0x2000>, - <0x40210000 0x1000>; - dma-channels = <32>; - interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>, - /* last is eDMA2-ERR interrupt */ - <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; - clock-names = "dma", "dmamux0"; - clocks = <&pcc2 IMX7ULP_CLK_DMA1>, - <&pcc2 IMX7ULP_CLK_DMA_MUX1>; -}; /* i.mx7ulp */ - -* DMA clients -DMA client drivers that uses the DMA function must use the format described -in the dma.txt file, using a two-cell specifier for each channel: the 1st -specifies the channel group(DMAMUX) in which this request can be multiplexed, -and the 2nd specifies the request source. - -Examples: - -sai2: sai@40031000 { - compatible = "fsl,vf610-sai"; - reg = <0x40031000 0x1000>; - interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>; - clock-names = "sai"; - clocks = <&clks VF610_CLK_SAI2>; - dma-names = "tx", "rx"; - dmas = <&edma0 0 21>, - <&edma0 0 20>; -}; diff --git a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml index 54d68fc688b5..19ea8dcbcbce 100644 --- a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml +++ b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml @@ -22,6 +22,7 @@ properties: - items: - enum: - mediatek,mt2712-uart-dma + - mediatek,mt8365-uart-dma - mediatek,mt8516-uart-dma - const: mediatek,mt6577-uart-dma - enum: diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml index 9dd1476d1849..7e575296df0c 100644 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml @@ -23,7 +23,9 @@ properties: oneOf: - const: nvidia,tegra186-gpcdma - items: - - const: nvidia,tegra194-gpcdma + - enum: + - nvidia,tegra234-gpcdma + - nvidia,tegra194-gpcdma - const: nvidia,tegra186-gpcdma "#dma-cells": diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml new file mode 100644 index 000000000000..9bf3a1b164f1 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/qcom,bam-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies Inc BAM DMA controller + +maintainers: + - Andy Gross <agross@kernel.org> + - Bjorn Andersson <bjorn.andersson@linaro.org> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + enum: + # APQ8064, IPQ8064 and MSM8960 + - qcom,bam-v1.3.0 + # MSM8974, APQ8074 and APQ8084 + - qcom,bam-v1.4.0 + # MSM8916 + - qcom,bam-v1.7.0 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: bam_clk + + "#dma-cells": + const: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 4 + + num-channels: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Indicates supported number of DMA channels in a remotely controlled bam. + + qcom,controlled-remotely: + type: boolean + description: + Indicates that the bam is controlled by remote proccessor i.e. execution + environment. + + qcom,ee: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + description: + Indicates the active Execution Environment identifier (0-7) used in the + secure world. + + qcom,num-ees: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Indicates supported number of Execution Environments in a remotely + controlled bam. + + qcom,powered-remotely: + type: boolean + description: + Indicates that the bam is powered up by a remote processor but must be + initialized by the local processor. + + reg: + maxItems: 1 + +required: + - compatible + - "#dma-cells" + - interrupts + - qcom,ee + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-msm8974.h> + + dma-controller@f9944000 { + compatible = "qcom,bam-v1.4.0"; + reg = <0xf9944000 0x15000>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GCC_BLSP2_AHB_CLK>; + clock-names = "bam_clk"; + #dma-cells = <1>; + qcom,ee = <0>; + }; +... diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt deleted file mode 100644 index 6e9a5497b3f2..000000000000 --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt +++ /dev/null @@ -1,52 +0,0 @@ -QCOM BAM DMA controller - -Required properties: -- compatible: must be one of the following: - * "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084 - * "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960 - * "qcom,bam-v1.7.0" for MSM8916 -- reg: Address range for DMA registers -- interrupts: Should contain the one interrupt shared by all channels -- #dma-cells: must be <1>, the cell in the dmas property of the client device - represents the channel number -- clocks: required clock -- clock-names: must contain "bam_clk" entry -- qcom,ee : indicates the active Execution Environment identifier (0-7) used in - the secure world. -- qcom,controlled-remotely : optional, indicates that the bam is controlled by - remote proccessor i.e. execution environment. -- qcom,powered-remotely : optional, indicates that the bam is powered up by - a remote processor but must be initialized by the local processor. -- num-channels : optional, indicates supported number of DMA channels in a - remotely controlled bam. -- qcom,num-ees : optional, indicates supported number of Execution Environments - in a remotely controlled bam. - -Example: - - uart-bam: dma@f9984000 = { - compatible = "qcom,bam-v1.4.0"; - reg = <0xf9984000 0x15000>; - interrupts = <0 94 0>; - clocks = <&gcc GCC_BAM_DMA_AHB_CLK>; - clock-names = "bam_clk"; - #dma-cells = <1>; - qcom,ee = <0>; - }; - -DMA clients must use the format described in the dma.txt file, using a two cell -specifier for each channel. - -Example: - serial@f991e000 { - compatible = "qcom,msm-uart"; - reg = <0xf991e000 0x1000> - <0xf9944000 0x19000>; - interrupts = <0 108 0>; - clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, - <&gcc GCC_BLSP1_AHB_CLK>; - clock-names = "core", "iface"; - - dmas = <&uart-bam 0>, <&uart-bam 1>; - dma-names = "rx", "tx"; - }; diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml index 4324a94b26b2..67aa7bb6d36a 100644 --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml @@ -34,7 +34,12 @@ properties: - const: axidma_apb_regs interrupts: - maxItems: 1 + description: + If the IP-core synthesis parameter DMAX_INTR_IO_TYPE is set to 1, this + will be per-channel interrupts. Otherwise, this is a single combined IRQ + for all channels. + minItems: 1 + maxItems: 8 clocks: items: diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt deleted file mode 100644 index 99ab5c4d331e..000000000000 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt +++ /dev/null @@ -1,138 +0,0 @@ -* DMA40 DMA Controller - -Required properties: -- compatible: "stericsson,dma40" -- reg: Address range of the DMAC registers -- reg-names: Names of the above areas to use during resource look-up -- interrupt: Should contain the DMAC interrupt number -- #dma-cells: must be <3> -- memcpy-channels: Channels to be used for memcpy - -Optional properties: -- dma-channels: Number of channels supported by hardware - if not present - the driver will attempt to obtain the information from H/W -- disabled-channels: Channels which can not be used - -Example: - - dma: dma-controller@801c0000 { - compatible = "stericsson,db8500-dma40", "stericsson,dma40"; - reg = <0x801C0000 0x1000 0x40010000 0x800>; - reg-names = "base", "lcpa"; - interrupt-parent = <&intc>; - interrupts = <0 25 0x4>; - - #dma-cells = <2>; - memcpy-channels = <56 57 58 59 60>; - disabled-channels = <12>; - dma-channels = <8>; - }; - -Clients -Required properties: -- dmas: Comma separated list of dma channel requests -- dma-names: Names of the aforementioned requested channels - -Each dmas request consists of 4 cells: - 1. A phandle pointing to the DMA controller - 2. Device signal number, the signal line for single and burst requests - connected from the device to the DMA40 engine - 3. The DMA request line number (only when 'use fixed channel' is set) - 4. A 32bit mask specifying; mode, direction and endianness - [NB: This list will grow] - 0x00000001: Mode: - Logical channel when unset - Physical channel when set - 0x00000002: Direction: - Memory to Device when unset - Device to Memory when set - 0x00000004: Endianness: - Little endian when unset - Big endian when set - 0x00000008: Use fixed channel: - Use automatic channel selection when unset - Use DMA request line number when set - 0x00000010: Set channel as high priority: - Normal priority when unset - High priority when set - -Existing signal numbers for the DB8500 ASIC. Unless specified, the signals are -bidirectional, i.e. the same for RX and TX operations: - -0: SPI controller 0 -1: SD/MMC controller 0 (unused) -2: SD/MMC controller 1 (unused) -3: SD/MMC controller 2 (unused) -4: I2C port 1 -5: I2C port 3 -6: I2C port 2 -7: I2C port 4 -8: Synchronous Serial Port SSP0 -9: Synchronous Serial Port SSP1 -10: Multi-Channel Display Engine MCDE RX -11: UART port 2 -12: UART port 1 -13: UART port 0 -14: Multirate Serial Port MSP2 -15: I2C port 0 -16: USB OTG in/out endpoints 7 & 15 -17: USB OTG in/out endpoints 6 & 14 -18: USB OTG in/out endpoints 5 & 13 -19: USB OTG in/out endpoints 4 & 12 -20: SLIMbus or HSI channel 0 -21: SLIMbus or HSI channel 1 -22: SLIMbus or HSI channel 2 -23: SLIMbus or HSI channel 3 -24: Multimedia DSP SXA0 -25: Multimedia DSP SXA1 -26: Multimedia DSP SXA2 -27: Multimedia DSP SXA3 -28: SD/MM controller 2 -29: SD/MM controller 0 -30: MSP port 1 on DB8500 v1, MSP port 3 on DB8500 v2 -31: MSP port 0 or SLIMbus channel 0 -32: SD/MM controller 1 -33: SPI controller 2 -34: i2c3 RX2 TX2 -35: SPI controller 1 -36: USB OTG in/out endpoints 3 & 11 -37: USB OTG in/out endpoints 2 & 10 -38: USB OTG in/out endpoints 1 & 9 -39: USB OTG in/out endpoints 8 -40: SPI controller 3 -41: SD/MM controller 3 -42: SD/MM controller 4 -43: SD/MM controller 5 -44: Multimedia DSP SXA4 -45: Multimedia DSP SXA5 -46: SLIMbus channel 8 or Multimedia DSP SXA6 -47: SLIMbus channel 9 or Multimedia DSP SXA7 -48: Crypto Accelerator 1 -49: Crypto Accelerator 1 TX or Hash Accelerator 1 TX -50: Hash Accelerator 1 TX -51: memcpy TX (to be used by the DMA driver for memcpy operations) -52: SLIMbus or HSI channel 4 -53: SLIMbus or HSI channel 5 -54: SLIMbus or HSI channel 6 -55: SLIMbus or HSI channel 7 -56: memcpy (to be used by the DMA driver for memcpy operations) -57: memcpy (to be used by the DMA driver for memcpy operations) -58: memcpy (to be used by the DMA driver for memcpy operations) -59: memcpy (to be used by the DMA driver for memcpy operations) -60: memcpy (to be used by the DMA driver for memcpy operations) -61: Crypto Accelerator 0 -62: Crypto Accelerator 0 TX or Hash Accelerator 0 TX -63: Hash Accelerator 0 TX - -Example: - - uart@80120000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x80120000 0x1000>; - interrupts = <0 11 0x4>; - - dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */ - <&dma 13 0 0x0>; /* Logical - MemToDev */ - dma-names = "rx", "rx"; - - }; diff --git a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml new file mode 100644 index 000000000000..8bddfb3b6fa0 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/stericsson,dma40.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson DMA40 DMA Engine + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + "#dma-cells": + const: 3 + description: | + The first cell is the unique device channel number as indicated by this + table for DB8500 which is the only ASIC known to use DMA40: + + 0: SPI controller 0 + 1: SD/MMC controller 0 (unused) + 2: SD/MMC controller 1 (unused) + 3: SD/MMC controller 2 (unused) + 4: I2C port 1 + 5: I2C port 3 + 6: I2C port 2 + 7: I2C port 4 + 8: Synchronous Serial Port SSP0 + 9: Synchronous Serial Port SSP1 + 10: Multi-Channel Display Engine MCDE RX + 11: UART port 2 + 12: UART port 1 + 13: UART port 0 + 14: Multirate Serial Port MSP2 + 15: I2C port 0 + 16: USB OTG in/out endpoints 7 & 15 + 17: USB OTG in/out endpoints 6 & 14 + 18: USB OTG in/out endpoints 5 & 13 + 19: USB OTG in/out endpoints 4 & 12 + 20: SLIMbus or HSI channel 0 + 21: SLIMbus or HSI channel 1 + 22: SLIMbus or HSI channel 2 + 23: SLIMbus or HSI channel 3 + 24: Multimedia DSP SXA0 + 25: Multimedia DSP SXA1 + 26: Multimedia DSP SXA2 + 27: Multimedia DSP SXA3 + 28: SD/MMC controller 2 + 29: SD/MMC controller 0 + 30: MSP port 1 on DB8500 v1, MSP port 3 on DB8500 v2 + 31: MSP port 0 or SLIMbus channel 0 + 32: SD/MMC controller 1 + 33: SPI controller 2 + 34: i2c3 RX2 TX2 + 35: SPI controller 1 + 36: USB OTG in/out endpoints 3 & 11 + 37: USB OTG in/out endpoints 2 & 10 + 38: USB OTG in/out endpoints 1 & 9 + 39: USB OTG in/out endpoints 8 + 40: SPI controller 3 + 41: SD/MMC controller 3 + 42: SD/MMC controller 4 + 43: SD/MMC controller 5 + 44: Multimedia DSP SXA4 + 45: Multimedia DSP SXA5 + 46: SLIMbus channel 8 or Multimedia DSP SXA6 + 47: SLIMbus channel 9 or Multimedia DSP SXA7 + 48: Crypto Accelerator 1 + 49: Crypto Accelerator 1 TX or Hash Accelerator 1 TX + 50: Hash Accelerator 1 TX + 51: memcpy TX (to be used by the DMA driver for memcpy operations) + 52: SLIMbus or HSI channel 4 + 53: SLIMbus or HSI channel 5 + 54: SLIMbus or HSI channel 6 + 55: SLIMbus or HSI channel 7 + 56: memcpy (to be used by the DMA driver for memcpy operations) + 57: memcpy (to be used by the DMA driver for memcpy operations) + 58: memcpy (to be used by the DMA driver for memcpy operations) + 59: memcpy (to be used by the DMA driver for memcpy operations) + 60: memcpy (to be used by the DMA driver for memcpy operations) + 61: Crypto Accelerator 0 + 62: Crypto Accelerator 0 TX or Hash Accelerator 0 TX + 63: Hash Accelerator 0 TX + + The second cell is the DMA request line number. This is only used when + a fixed channel is allocated, and indicated by setting bit 3 in the + flags field (see below). + + The third cell is a 32bit flags bitfield with the following possible + bits set: + 0x00000001 (bit 0) - mode: + Logical channel when unset + Physical channel when set + 0x00000002 (bit 1) - direction: + Memory to Device when unset + Device to Memory when set + 0x00000004 (bit 2) - endianness: + Little endian when unset + Big endian when set + 0x00000008 (bit 3) - use fixed channel: + Use automatic channel selection when unset + Use DMA request line number when set + 0x00000010 (bit 4) - set channel as high priority: + Normal priority when unset + High priority when set + + compatible: + items: + - const: stericsson,db8500-dma40 + - const: stericsson,dma40 + + reg: + items: + - description: DMA40 memory base + - description: LCPA memory base + + reg-names: + items: + - const: base + - const: lcpa + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + memcpy-channels: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Array of u32 elements indicating which channels on the DMA + engine are elegible for memcpy transfers + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - memcpy-channels + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mfd/dbx500-prcmu.h> + dma-controller@801C0000 { + compatible = "stericsson,db8500-dma40", "stericsson,dma40"; + reg = <0x801C0000 0x1000>, <0x40010000 0x800>; + reg-names = "base", "lcpa"; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <3>; + memcpy-channels = <56 57 58 59 60>; + clocks = <&prcmu_clk PRCMU_DMACLK>; + }; +... diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml new file mode 100644 index 000000000000..3e63f79890b4 --- /dev/null +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dsp/mediatek,mt8186-dsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek mt8186 DSP core + +maintainers: + - Tinghan Shen <tinghan.shen@mediatek.com> + +description: | + MediaTek mt8186 SoC contains a DSP core used for + advanced pre- and post- audio processing. + +properties: + compatible: + const: mediatek,mt8186-dsp + + reg: + items: + - description: Address and size of the DSP config registers + - description: Address and size of the DSP SRAM + - description: Address and size of the DSP secure registers + - description: Address and size of the DSP bus registers + + reg-names: + items: + - const: cfg + - const: sram + - const: sec + - const: bus + + clocks: + items: + - description: mux for audio dsp clock + - description: mux for audio dsp local bus + + clock-names: + items: + - const: audiodsp + - const: adsp_bus + + power-domains: + maxItems: 1 + + mboxes: + items: + - description: mailbox for receiving audio DSP requests. + - description: mailbox for transmitting requests to audio DSP. + + mbox-names: + items: + - const: rx + - const: tx + + memory-region: + items: + - description: dma buffer between host and DSP. + - description: DSP system memory. + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - power-domains + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8186-clk.h> + dsp@10680000 { + compatible = "mediatek,mt8186-dsp"; + reg = <0x10680000 0x2000>, + <0x10800000 0x100000>, + <0x1068b000 0x100>, + <0x1068f000 0x1000>; + reg-names = "cfg", "sram", "sec", "bus"; + clocks = <&topckgen CLK_TOP_AUDIODSP>, + <&topckgen CLK_TOP_ADSP_BUS>; + clock-names = "audiodsp", + "adsp_bus"; + power-domains = <&spm 6>; + mbox-names = "rx", "tx"; + mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>; + }; diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml index b7e68b0dfa13..ca8d8661f872 100644 --- a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml @@ -50,13 +50,13 @@ properties: mboxes: items: - - description: ipc reply between host and audio DSP. - - description: ipc request between host and audio DSP. + - description: mailbox for receiving audio DSP requests. + - description: mailbox for transmitting requests to audio DSP. mbox-names: items: - - const: mbox0 - - const: mbox1 + - const: rx + - const: tx memory-region: items: @@ -100,6 +100,6 @@ examples: memory-region = <&adsp_dma_mem_reserved>, <&adsp_mem_reserved>; power-domains = <&spm 6>; //MT8195_POWER_DOMAIN_ADSP - mbox-names = "mbox0", "mbox1"; + mbox-names = "rx", "tx"; mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>; }; diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml index fbf99e346966..8b1c997caac1 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.yaml +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml @@ -44,8 +44,6 @@ properties: reg: maxItems: 1 - spi-max-frequency: true - pagesize: $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072] @@ -105,6 +103,7 @@ required: - spi-max-frequency allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# - if: properties: compatible: @@ -117,7 +116,7 @@ allOf: - size - address-width -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.yaml b/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml index 44fd2f6f0d8a..0c2f5ddb79c5 100644 --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.yaml +++ b/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/misc/eeprom-93xx46.yaml# +$id: http://devicetree.org/schemas/eeprom/microchip,93lc46b.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip 93xx46 SPI compatible EEPROM family dt bindings @@ -28,9 +28,6 @@ properties: description: chip select of EEPROM maxItems: 1 - spi-max-frequency: true - spi-cs-high: true - read-only: description: parameter-less property which disables writes to the EEPROM @@ -42,14 +39,16 @@ properties: of EEPROM (e.g. for SPI bus multiplexing) maxItems: 1 - required: - compatible - reg - data-size - spi-max-frequency -additionalProperties: false +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 948e2a38beed..1c0388da6721 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -183,6 +183,12 @@ properties: required: - reg + protocol@18: + type: object + properties: + reg: + const: 0x18 + additionalProperties: false patternProperties: @@ -323,6 +329,10 @@ examples: }; }; }; + + scmi_powercap: protocol@18 { + reg = <0x18>; + }; }; }; diff --git a/Documentation/devicetree/bindings/firmware/fsl,scu.yaml b/Documentation/devicetree/bindings/firmware/fsl,scu.yaml new file mode 100644 index 000000000000..b40b0ef56978 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/fsl,scu.yaml @@ -0,0 +1,210 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/fsl,scu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX System Controller Firmware (SCFW) + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: + The System Controller Firmware (SCFW) is a low-level system function + which runs on a dedicated Cortex-M core to provide power, clock, and + resource management. It exists on some i.MX8 processors. e.g. i.MX8QM + (QM, QP), and i.MX8QX (QXP, DX). + The AP communicates with the SC using a multi-ported MU module found + in the LSIO subsystem. The current definition of this MU module provides + 5 remote AP connections to the SC to support up to 5 execution environments + (TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces + with the LSIO DSC IP bus. The SC firmware will communicate with this MU + using the MSI bus. + +properties: + compatible: + const: fsl,imx-scu + + clock-controller: + description: + Clock controller node that provides the clocks controlled by the SCU + $ref: /schemas/clock/fsl,scu-clk.yaml + + ocotp: + description: + OCOTP controller node provided by the SCU + $ref: /schemas/nvmem/fsl,scu-ocotp.yaml + + keys: + description: + Keys provided by the SCU + $ref: /schemas/input/fsl,scu-key.yaml + + mboxes: + description: + A list of phandles of TX MU channels followed by a list of phandles of + RX MU channels. The list may include at the end one more optional MU + channel for general interrupt. The number of expected tx and rx + channels is 1 TX and 1 RX channels if MU instance is "fsl,imx8-mu-scu" + compatible, 4 TX and 4 RX channels otherwise. All MU channels must be + within the same MU instance. Cross instances are not allowed. The MU + instance can only be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users + need to ensure that one is used that does not conflict with other + execution environments such as ATF. + oneOf: + - items: + - description: TX0 MU channel + - description: RX0 MU channel + - items: + - description: TX0 MU channel + - description: RX0 MU channel + - description: optional MU channel for general interrupt + - items: + - description: TX0 MU channel + - description: TX1 MU channel + - description: TX2 MU channel + - description: TX3 MU channel + - description: RX0 MU channel + - description: RX1 MU channel + - description: RX2 MU channel + - description: RX3 MU channel + - items: + - description: TX0 MU channel + - description: TX1 MU channel + - description: TX2 MU channel + - description: TX3 MU channel + - description: RX0 MU channel + - description: RX1 MU channel + - description: RX2 MU channel + - description: RX3 MU channel + - description: optional MU channel for general interrupt + + mbox-names: + oneOf: + - items: + - const: tx0 + - const: rx0 + - items: + - const: tx0 + - const: rx0 + - const: gip3 + - items: + - const: tx0 + - const: tx1 + - const: tx2 + - const: tx3 + - const: rx0 + - const: rx1 + - const: rx2 + - const: rx3 + - items: + - const: tx0 + - const: tx1 + - const: tx2 + - const: tx3 + - const: rx0 + - const: rx1 + - const: rx2 + - const: rx3 + - const: gip3 + + pinctrl: + description: + Pin controller provided by the SCU + $ref: /schemas/pinctrl/fsl,scu-pinctrl.yaml + + power-controller: + description: + Power domains controller node that provides the power domains + controlled by the SCU + $ref: /schemas/power/fsl,scu-pd.yaml + + rtc: + description: + RTC controller provided by the SCU + $ref: /schemas/rtc/fsl,scu-rtc.yaml + + thermal-sensor: + description: + Thermal sensor provided by the SCU + $ref: /schemas/thermal/fsl,scu-thermal.yaml + + watchdog: + description: + Watchdog controller provided by the SCU + $ref: /schemas/watchdog/fsl,scu-wdt.yaml + +required: + - compatible + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + #include <dt-bindings/firmware/imx/rsrc.h> + #include <dt-bindings/input/input.h> + #include <dt-bindings/pinctrl/pads-imx8qxp.h> + + firmware { + system-controller { + compatible = "fsl,imx-scu"; + mbox-names = "tx0", "tx1", "tx2", "tx3", + "rx0", "rx1", "rx2", "rx3", + "gip3"; + mboxes = <&lsio_mu1 0 0 &lsio_mu1 0 1 &lsio_mu1 0 2 &lsio_mu1 0 3 + &lsio_mu1 1 0 &lsio_mu1 1 1 &lsio_mu1 1 2 &lsio_mu1 1 3 + &lsio_mu1 3 3>; + + clock-controller { + compatible = "fsl,imx8qxp-clk", "fsl,scu-clk"; + #clock-cells = <2>; + }; + + pinctrl { + compatible = "fsl,imx8qxp-iomuxc"; + + pinctrl_lpuart0: lpuart0grp { + fsl,pins = < + IMX8QXP_UART0_RX_ADMA_UART0_RX 0x06000020 + IMX8QXP_UART0_TX_ADMA_UART0_TX 0x06000020 + >; + }; + }; + + ocotp { + compatible = "fsl,imx8qxp-scu-ocotp"; + #address-cells = <1>; + #size-cells = <1>; + + fec_mac0: mac@2c4 { + reg = <0x2c4 6>; + }; + }; + + power-controller { + compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; + #power-domain-cells = <1>; + }; + + rtc { + compatible = "fsl,imx8qxp-sc-rtc"; + }; + + keys { + compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key"; + linux,keycodes = <KEY_POWER>; + }; + + watchdog { + compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt"; + timeout-sec = <60>; + }; + + thermal-sensor { + compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal"; + #thermal-sensor-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index 0f4e5ab26477..b3f702cbed87 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -23,10 +23,13 @@ Required properties: * "qcom,scm-msm8994" * "qcom,scm-msm8996" * "qcom,scm-msm8998" + * "qcom,scm-qcs404" * "qcom,scm-sc7180" * "qcom,scm-sc7280" + * "qcom,scm-sm6125" * "qcom,scm-sdm845" * "qcom,scm-sdx55" + * "qcom,scm-sdx65" * "qcom,scm-sm6350" * "qcom,scm-sm8150" * "qcom,scm-sm8250" @@ -43,6 +46,7 @@ Required properties: clock and "bus" for the bus clock per the requirements of the compatible. - qcom,dload-mode: phandle to the TCSR hardware block and offset of the download mode control register (optional) +- interconnects: Specifies the bandwidth requirements of the SCM interface (optional) Example for MSM8916: diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index 7d3515264838..6694ef29a267 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -330,7 +330,7 @@ succeeded. The Device Tree Overlay will contain: * "target-path" or "target" - The insertion point where the the contents of the overlay will go into the + The insertion point where the contents of the overlay will go into the live tree. target-path is a full path, while target is a phandle. * "ranges" The address space mapping from processor to FPGA bus(ses). diff --git a/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml new file mode 100644 index 000000000000..aee45cb15592 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/microchip,mpf-spi-fpga-mgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Polarfire FPGA manager. + +maintainers: + - Ivan Bornyakov <i.bornyakov@metrotek.ru> + +description: + Device Tree Bindings for Microchip Polarfire FPGA Manager using slave SPI to + load the bitstream in .dat format. + +properties: + compatible: + enum: + - microchip,mpf-spi-fpga-mgr + + reg: + description: SPI chip select + maxItems: 1 + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + fpga_mgr@0 { + compatible = "microchip,mpf-spi-fpga-mgr"; + spi-max-frequency = <20000000>; + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml index f57d22d1ebd6..ae18603697d7 100644 --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml @@ -37,6 +37,8 @@ properties: - fsl,imx8mp-gpio - fsl,imx8mq-gpio - fsl,imx8qxp-gpio + - fsl,imxrt1050-gpio + - fsl,imxrt1170-gpio - const: fsl,imx35-gpio reg: diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt deleted file mode 100644 index 0fc6700ed800..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt +++ /dev/null @@ -1,93 +0,0 @@ -* Marvell EBU GPIO controller - -Required properties: - -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio", - "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio". - - "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove, - Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio" - should be used for the Discovery MV78200. - - "marvel,armadaxp-gpio" should be used for all Armada XP SoCs - (MV78230, MV78260, MV78460). - - "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K - SoCs (either from AP or CP), see - Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt - for specific details about the offset property. - -- reg: Address and length of the register set for the device. Only one - entry is expected, except for the "marvell,armadaxp-gpio" variant - for which two entries are expected: one for the general registers, - one for the per-cpu registers. Not used for marvell,armada-8k-gpio. - -- interrupts: The list of interrupts that are used for all the pins - managed by this GPIO bank. There can be more than one interrupt - (example: 1 interrupt per 8 pins on Armada XP, which means 4 - interrupts per bank of 32 GPIOs). - -- interrupt-controller: identifies the node as an interrupt controller - -- #interrupt-cells: specifies the number of cells needed to encode an - interrupt source. Should be two. - The first cell is the GPIO number. - The second cell is used to specify flags: - bits[3:0] trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. - -- gpio-controller: marks the device node as a gpio controller - -- ngpios: number of GPIOs this controller has - -- #gpio-cells: Should be two. The first cell is the pin number. The - second cell is reserved for flags, unused at the moment. - -Optional properties: - -In order to use the GPIO lines in PWM mode, some additional optional -properties are required. - -- compatible: Must contain "marvell,armada-370-gpio" - -- reg: an additional register set is needed, for the GPIO Blink - Counter on/off registers. - -- reg-names: Must contain an entry "pwm" corresponding to the - additional register range needed for PWM operation. - -- #pwm-cells: Should be two. The first cell is the GPIO line number. The - second cell is the period in nanoseconds. - -- clocks: Must be a phandle to the clock for the GPIO controller. - -Example: - - gpio0: gpio@d0018100 { - compatible = "marvell,armadaxp-gpio"; - reg = <0xd0018100 0x40>, - <0xd0018800 0x30>; - ngpios = <32>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <16>, <17>, <18>, <19>; - }; - - gpio1: gpio@18140 { - compatible = "marvell,armada-370-gpio"; - reg = <0x18140 0x40>, <0x181c8 0x08>; - reg-names = "gpio", "pwm"; - ngpios = <17>; - gpio-controller; - #gpio-cells = <2>; - #pwm-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <87>, <88>, <89>; - clocks = <&coreclk 0>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml new file mode 100644 index 000000000000..f1bd1e6b2e1f --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell EBU GPIO controller + +maintainers: + - Thomas Petazzoni <thomas.petazzoni@free-electrons.com> + - Andrew Lunn <andrew@lunn.ch> + +properties: + compatible: + oneOf: + - enum: + - marvell,armada-8k-gpio + - marvell,orion-gpio + + - items: + - enum: + - marvell,mv78200-gpio + - marvell,armada-370-gpio + - const: marvell,orion-gpio + + - description: Deprecated binding + items: + - const: marvell,armadaxp-gpio + - const: marvell,orion-gpio + deprecated: true + + reg: + description: | + Address and length of the register set for the device. Not used for + marvell,armada-8k-gpio. + + A second entry can be provided, for the PWM function using the GPIO Blink + Counter on/off registers. + minItems: 1 + maxItems: 2 + + reg-names: + items: + - const: gpio + - const: pwm + minItems: 1 + + offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Offset in the register map for the gpio registers (in bytes) + + interrupts: + description: | + The list of interrupts that are used for all the pins managed by this + GPIO bank. There can be more than one interrupt (example: 1 interrupt + per 8 pins on Armada XP, which means 4 interrupts per bank of 32 + GPIOs). + minItems: 1 + maxItems: 4 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + gpio-controller: true + + ngpios: + minimum: 1 + maximum: 32 + + "#gpio-cells": + const: 2 + + marvell,pwm-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Offset in the register map for the pwm registers (in bytes) + + "#pwm-cells": + description: + The first cell is the GPIO line number. The second cell is the period + in nanoseconds. + const: 2 + + clocks: + description: + Clock(s) used for PWM function. + items: + - description: Core clock + - description: AXI bus clock + minItems: 1 + + clock-names: + items: + - const: core + - const: axi + minItems: 1 + +required: + - compatible + - gpio-controller + - ngpios + - "#gpio-cells" + +allOf: + - if: + properties: + compatible: + contains: + const: marvell,armada-8k-gpio + then: + required: + - offset + else: + required: + - reg + +unevaluatedProperties: true + +examples: + - | + gpio@d0018100 { + compatible = "marvell,armadaxp-gpio", "marvell,orion-gpio"; + reg = <0xd0018100 0x40>, <0xd0018800 0x30>; + ngpios = <32>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <16>, <17>, <18>, <19>; + }; + + - | + gpio@18140 { + compatible = "marvell,armada-370-gpio", "marvell,orion-gpio"; + reg = <0x18140 0x40>, <0x181c8 0x08>; + reg-names = "gpio", "pwm"; + ngpios = <17>; + gpio-controller; + #gpio-cells = <2>; + #pwm-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <87>, <88>, <89>; + clocks = <&coreclk 0>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml index 338c5312a106..1acaa0a3d35a 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml @@ -13,6 +13,7 @@ properties: compatible: enum: - nxp,pca9570 + - nxp,pca9571 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt index 414a01cdf715..fba3c61f6a5b 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt @@ -14,7 +14,7 @@ Optional properties: - ngpios : Number of used GPIO lines (0..n-1), default is 8. - load-gpios : GPIO pin specifier attached to load enable, this pin is pulsed before reading from the device to - load input pin values into the the device. + load input pin values into the device. For other required and optional properties of SPI slave nodes please refer to ../spi/spi-bus.txt. diff --git a/Documentation/devicetree/bindings/gpio/gpio-tpic2810.txt b/Documentation/devicetree/bindings/gpio/gpio-tpic2810.txt deleted file mode 100644 index 1afc2de7a537..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-tpic2810.txt +++ /dev/null @@ -1,16 +0,0 @@ -TPIC2810 GPIO controller bindings - -Required properties: - - compatible : Should be "ti,tpic2810". - - reg : The I2C address of the device - - gpio-controller : Marks the device node as a GPIO controller. - - #gpio-cells : Should be two. For consumer use see gpio.txt. - -Example: - - gpio@60 { - compatible = "ti,tpic2810"; - reg = <0x60>; - gpio-controller; - #gpio-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml b/Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml new file mode 100644 index 000000000000..cb8a5c376e1e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-tpic2810.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TPIC2810 GPIO controller bindings + +maintainers: + - Aswath Govindraju <a-govindraju@ti.com> + +properties: + compatible: + enum: + - ti,tpic2810 + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-line-names: + minItems: 1 + maxItems: 32 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + gpio@60 { + compatible = "ti,tpic2810"; + reg = <0x60>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = "LED A", "LED B", "LED C"; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml index 378da2649e66..29c27eadbac8 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml @@ -11,7 +11,11 @@ maintainers: properties: compatible: - const: xlnx,zynq-gpio-1.0 + enum: + - xlnx,zynq-gpio-1.0 + - xlnx,zynqmp-gpio-1.0 + - xlnx,versal-gpio-1.0 + - xlnx,pmc-gpio-1.0 reg: maxItems: 1 @@ -24,6 +28,11 @@ properties: gpio-controller: true + gpio-line-names: + description: strings describing the names of each gpio line + minItems: 58 + maxItems: 174 + interrupt-controller: true "#interrupt-cells": @@ -32,6 +41,54 @@ properties: clocks: maxItems: 1 + power-domains: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + enum: + - xlnx,zynqmp-gpio-1.0 + then: + properties: + gpio-line-names: + minItems: 174 + maxItems: 174 + + - if: + properties: + compatible: + enum: + - xlnx,zynq-gpio-1.0 + then: + properties: + gpio-line-names: + minItems: 118 + maxItems: 118 + + - if: + properties: + compatible: + enum: + - xlnx,versal-gpio-1.0 + then: + properties: + gpio-line-names: + minItems: 58 + maxItems: 58 + + - if: + properties: + compatible: + enum: + - xlnx,pmc-gpio-1.0 + then: + properties: + gpio-line-names: + minItems: 116 + maxItems: 116 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml index 0681a4790cd6..75e5da6a7cc0 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml @@ -49,10 +49,8 @@ properties: - const: renesas,rcar-gen3-gpio # R-Car Gen3 or RZ/G2 - items: - - const: renesas,gpio-r8a779a0 # R-Car V3U - - - items: - enum: + - renesas,gpio-r8a779a0 # R-Car V3U - renesas,gpio-r8a779f0 # R-Car S4-8 - const: renesas,rcar-gen4-gpio # R-Car Gen4 diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml index d4e42c2b995b..affd823c881d 100644 --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml @@ -27,6 +27,8 @@ properties: - description: APB interface clock source - description: GPIO debounce reference clock source + gpio-ranges: true + gpio-controller: true gpio-line-names: true diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml index 939e31c48081..fc095646adea 100644 --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml @@ -46,6 +46,10 @@ properties: maximum: 32 default: 16 + gpio-line-names: + minItems: 1 + maxItems: 32 + gpio-controller: true required: diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml index 0f628b088cec..14486aee97b4 100644 --- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml @@ -19,8 +19,14 @@ properties: oneOf: - enum: - x-powers,axp209-gpio + - x-powers,axp221-gpio - x-powers,axp813-gpio - items: + - enum: + - x-powers,axp223-gpio + - x-powers,axp809-gpio + - const: x-powers,axp221-gpio + - items: - const: x-powers,axp803-gpio - const: x-powers,axp813-gpio diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 85f8d4764740..78964c140b46 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -14,16 +14,21 @@ properties: pattern: '^gpu@[a-f0-9]+$' compatible: - items: - - enum: - - amlogic,meson-g12a-mali - - mediatek,mt8183-mali - - realtek,rtd1619-mali - - renesas,r9a07g044-mali - - renesas,r9a07g054-mali - - rockchip,px30-mali - - rockchip,rk3568-mali - - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable + oneOf: + - items: + - enum: + - amlogic,meson-g12a-mali + - mediatek,mt8183-mali + - realtek,rtd1619-mali + - renesas,r9a07g044-mali + - renesas,r9a07g054-mali + - rockchip,px30-mali + - rockchip,rk3568-mali + - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable + - items: + - enum: + - mediatek,mt8192-mali + - const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml index e6485f7b046f..217c42874f41 100644 --- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml @@ -16,6 +16,7 @@ properties: compatible: enum: + - brcm,2711-v3d - brcm,7268-v3d - brcm,7278-v3d diff --git a/Documentation/devicetree/bindings/arm/renesas,prr.yaml b/Documentation/devicetree/bindings/hwinfo/renesas,prr.yaml index 1f80767da38b..792f371cec03 100644 --- a/Documentation/devicetree/bindings/arm/renesas,prr.yaml +++ b/Documentation/devicetree/bindings/hwinfo/renesas,prr.yaml @@ -1,7 +1,7 @@ -# SPDX-License-Identifier: GPL-2.0 +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/renesas,prr.yaml# +$id: http://devicetree.org/schemas/hwinfo/renesas,prr.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Product Register diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-chipid.yaml b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml index 4bb8efb83ac1..95cbdcb56efe 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-chipid.yaml +++ b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: http://devicetree.org/schemas/soc/samsung/exynos-chipid.yaml# +$id: http://devicetree.org/schemas/hwinfo/samsung,exynos-chipid.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC series Chipid driver diff --git a/Documentation/devicetree/bindings/hwinfo/samsung,s5pv210-chipid.yaml b/Documentation/devicetree/bindings/hwinfo/samsung,s5pv210-chipid.yaml new file mode 100644 index 000000000000..563ded4fca83 --- /dev/null +++ b/Documentation/devicetree/bindings/hwinfo/samsung,s5pv210-chipid.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwinfo/samsung,s5pv210-chipid.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5PV210 SoC ChipID + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +properties: + compatible: + const: samsung,s5pv210-chipid + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + chipid@e0000000 { + compatible = "samsung,s5pv210-chipid"; + reg = <0xe0000000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml index a1a8423b2e2e..dada28b47ea0 100644 --- a/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml +++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/soc/ti/k3-socinfo.yaml# +$id: http://devicetree.org/schemas/hwinfo/ti,k3-socinfo.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K3 Multicore SoC platforms chipid module diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml index 154bee851139..d794deb08bb7 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml @@ -8,7 +8,6 @@ title: Analog Devices ADM1177 Hot Swap Controller and Digital Power Monitor maintainers: - Michael Hennerich <michael.hennerich@analog.com> - - Beniamin Bia <beniamin.bia@analog.com> description: | Analog Devices ADM1177 Hot Swap Controller and Digital Power Monitor diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml index 56baf2e5c6d1..ea595102a86e 100644 --- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml @@ -57,7 +57,7 @@ patternProperties: Configures bypassing the individual voltage input attenuator. If set to 1 the attenuator is bypassed if set to 0 the attenuator is not bypassed. If the property is absent then the attenuator - retains it's configuration from the bios/bootloader. + retains its configuration from the bios/bootloader. $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] diff --git a/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt b/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt index 5dc5d2e2573d..5dc5d2e2573d 100644 --- a/Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt +++ b/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml index b04657849852..e1719839faf0 100644 --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -16,6 +16,7 @@ properties: - adi,adm1032 - adi,adt7461 - adi,adt7461a + - adi,adt7481 - dallas,max6646 - dallas,max6647 - dallas,max6649 @@ -50,6 +51,12 @@ properties: "#thermal-sensor-cells": const: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + vcc-supply: description: phandle to the regulator that provides the +VCC supply @@ -61,6 +68,29 @@ required: - compatible - reg +patternProperties: + "^channel@([0-2])$": + type: object + description: Represents channels of the device and their specific configuration. + + properties: + reg: + description: The channel number. 0 is local channel, 1-2 are remote channels. + items: + minimum: 0 + maximum: 2 + + label: + description: A descriptive name for this channel, like "ambient" or "psu". + + temperature-offset-millicelsius: + description: Temperature offset to be added to or subtracted from remote temperature measurements. + + required: + - reg + + additionalProperties: false + allOf: - if: not: @@ -70,12 +100,84 @@ allOf: enum: - adi,adt7461 - adi,adt7461a + - adi,adt7481 - ti,tmp451 - ti,tmp461 then: properties: ti,extended-range-enable: false + - if: + properties: + compatible: + contains: + enum: + - dallas,max6646 + - dallas,max6647 + - dallas,max6649 + - dallas,max6657 + - dallas,max6658 + - dallas,max6659 + - dallas,max6695 + - dallas,max6696 + then: + patternProperties: + "^channel@([0-2])$": + properties: + temperature-offset-millicelsius: false + + - if: + properties: + compatible: + contains: + enum: + - adi,adt7461 + - adi,adt7461a + - adi,adt7481 + - onnn,nct1008 + then: + patternProperties: + "^channel@([0-2])$": + properties: + temperature-offset-millicelsius: + maximum: 127750 + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1032 + - dallas,max6680 + - dallas,max6681 + - gmt,g781 + - national,lm86 + - national,lm89 + - national,lm90 + - national,lm99 + - nxp,sa56004 + - winbond,w83l771 + then: + patternProperties: + "^channel@([0-2])$": + properties: + temperature-offset-millicelsius: + maximum: 127875 + + - if: + properties: + compatible: + contains: + enum: + - ti,tmp451 + - ti,tmp461 + then: + patternProperties: + "^channel@([0-2])$": + properties: + temperature-offset-millicelsius: + maximum: 127937 + additionalProperties: false examples: @@ -94,3 +196,32 @@ examples: #thermal-sensor-cells = <1>; }; }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "adi,adt7481"; + reg = <0x4c>; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0x0>; + label = "local"; + }; + + channel@1 { + reg = <0x1>; + label = "front"; + temperature-offset-millicelsius = <4000>; + }; + + channel@2 { + reg = <0x2>; + label = "back"; + temperature-offset-millicelsius = <750>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/arm,i2c-versatile.yaml b/Documentation/devicetree/bindings/i2c/arm,i2c-versatile.yaml new file mode 100644 index 000000000000..e58465d1b0c8 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/arm,i2c-versatile.yaml @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/arm,i2c-versatile.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I2C Controller on ARM Ltd development platforms + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + const: arm,versatile-i2c + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +... + diff --git a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt deleted file mode 100644 index 3b30e54ae3c7..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt +++ /dev/null @@ -1,33 +0,0 @@ -* Energymicro efm32 i2c controller - -Required properties : - - - reg : Offset and length of the register set for the device - - compatible : should be "energymicro,efm32-i2c" - - interrupts : the interrupt number - - clocks : reference to the module clock - -Recommended properties : - - - clock-frequency : maximal I2C bus clock frequency in Hz. - - energymicro,location : Decides the location of the USART I/O pins. - Allowed range : [0 .. 6] - -Example: - i2c0: i2c@4000a000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "energymicro,efm32-i2c"; - reg = <0x4000a000 0x400>; - interrupts = <9>; - clocks = <&cmu clk_HFPERCLKI2C0>; - clock-frequency = <100000>; - energymicro,location = <3>; - - eeprom@50 { - compatible = "microchip,24c02"; - reg = <0x50>; - pagesize = <16>; - }; - }; - diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml index 16a1a3118204..4e730fb7be56 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml @@ -27,6 +27,7 @@ properties: - const: mediatek,mt8173-i2c - const: mediatek,mt8183-i2c - const: mediatek,mt8186-i2c + - const: mediatek,mt8188-i2c - const: mediatek,mt8192-i2c - items: - enum: diff --git a/Documentation/devicetree/bindings/i2c/i2c-nomadik.txt b/Documentation/devicetree/bindings/i2c/i2c-nomadik.txt deleted file mode 100644 index 72065b0ff680..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-nomadik.txt +++ /dev/null @@ -1,23 +0,0 @@ -I2C for Nomadik based systems - -Required (non-standard) properties: - - Nil - -Recommended (non-standard) properties: - - clock-frequency : Maximum bus clock frequency for the device - -Optional (non-standard) properties: - - Nil - -Example : - -i2c@80004000 { - compatible = "stericsson,db8500-i2c", "st,nomadik-i2c"; - reg = <0x80004000 0x1000>; - interrupts = <0 21 0x4>; - #address-cells = <1>; - #size-cells = <0>; - v-i2c-supply = <&db8500_vape_reg>; - - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt deleted file mode 100644 index a37c9455b244..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt +++ /dev/null @@ -1,78 +0,0 @@ -Device tree configuration for i2c-ocores - -Required properties: -- compatible : "opencores,i2c-ocores" - "aeroflexgaisler,i2cmst" - "sifive,fu540-c000-i2c", "sifive,i2c0" - For Opencore based I2C IP block reimplemented in - FU540-C000 SoC. - "sifive,fu740-c000-i2c", "sifive,i2c0" - For Opencore based I2C IP block reimplemented in - FU740-C000 SoC. - Please refer to sifive-blocks-ip-versioning.txt for - additional details. -- reg : bus address start and address range size of device -- clocks : handle to the controller clock; see the note below. - Mutually exclusive with opencores,ip-clock-frequency -- opencores,ip-clock-frequency: frequency of the controller clock in Hz; - see the note below. Mutually exclusive with clocks -- #address-cells : should be <1> -- #size-cells : should be <0> - -Optional properties: -- interrupts : interrupt number. -- clock-frequency : frequency of bus clock in Hz; see the note below. - Defaults to 100 KHz when the property is not specified -- reg-shift : device register offsets are shifted by this value -- reg-io-width : io register width in bytes (1, 2 or 4) -- regstep : deprecated, use reg-shift above - -Note -clock-frequency property is meant to control the bus frequency for i2c bus -drivers, but it was incorrectly used to specify i2c controller input clock -frequency. So the following rules are set to fix this situation: -- if clock-frequency is present and neither opencores,ip-clock-frequency nor - clocks are, then clock-frequency specifies i2c controller clock frequency. - This is to keep backwards compatibility with setups using old DTB. i2c bus - frequency is fixed at 100 KHz. -- if clocks is present it specifies i2c controller clock. clock-frequency - property specifies i2c bus frequency. -- if opencores,ip-clock-frequency is present it specifies i2c controller - clock frequency. clock-frequency property specifies i2c bus frequency. - -Examples: - - i2c0: ocores@a0000000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "opencores,i2c-ocores"; - reg = <0xa0000000 0x8>; - interrupts = <10>; - opencores,ip-clock-frequency = <20000000>; - - reg-shift = <0>; /* 8 bit registers */ - reg-io-width = <1>; /* 8 bit read/write */ - - dummy@60 { - compatible = "dummy"; - reg = <0x60>; - }; - }; -or - i2c0: ocores@a0000000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "opencores,i2c-ocores"; - reg = <0xa0000000 0x8>; - interrupts = <10>; - clocks = <&osc>; - clock-frequency = <400000>; /* i2c bus frequency 400 KHz */ - - reg-shift = <0>; /* 8 bit registers */ - reg-io-width = <1>; /* 8 bit read/write */ - - dummy@60 { - compatible = "dummy"; - reg = <0x60>; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt deleted file mode 100644 index 924ad8c03464..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt +++ /dev/null @@ -1,95 +0,0 @@ -Qualcomm Camera Control Interface (CCI) I2C controller - -PROPERTIES: - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,msm8916-cci" - "qcom,msm8996-cci" - "qcom,sdm845-cci" - "qcom,sm8250-cci" - "qcom,sm8450-cci" - -- reg - Usage: required - Value type: <prop-encoded-array> - Definition: base address CCI I2C controller and length of memory - mapped region. - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: specifies the CCI I2C interrupt. The format of the - specifier is defined by the binding document describing - the node's interrupt parent. - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: a list of phandle, should contain an entry for each - entries in clock-names. - -- clock-names - Usage: required - Value type: <string> - Definition: a list of clock names, must include "cci" clock. - -- power-domains - Usage: required for "qcom,msm8996-cci" - Value type: <prop-encoded-array> - Definition: - -SUBNODES: - -The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996, -sdm845, sm8250 and sm8450), described as subdevices named "i2c-bus@0" and -"i2c-bus@1". - -PROPERTIES: - -- reg: - Usage: required - Value type: <u32> - Definition: Index of the CCI bus/master - -- clock-frequency: - Usage: optional - Value type: <u32> - Definition: Desired I2C bus clock frequency in Hz, defaults to 100 - kHz if omitted. - -Example: - - cci@a0c000 { - compatible = "qcom,msm8996-cci"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xa0c000 0x1000>; - interrupts = <GIC_SPI 295 IRQ_TYPE_EDGE_RISING>; - clocks = <&mmcc MMSS_MMAGIC_AHB_CLK>, - <&mmcc CAMSS_TOP_AHB_CLK>, - <&mmcc CAMSS_CCI_AHB_CLK>, - <&mmcc CAMSS_CCI_CLK>, - <&mmcc CAMSS_AHB_CLK>; - clock-names = "mmss_mmagic_ahb", - "camss_top_ahb", - "cci_ahb", - "cci", - "camss_ahb"; - - i2c-bus@0 { - reg = <0>; - clock-frequency = <400000>; - #address-cells = <1>; - #size-cells = <0>; - }; - - i2c-bus@1 { - reg = <1>; - clock-frequency = <400000>; - #address-cells = <1>; - #size-cells = <0>; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml index 5339dd4fc370..ee9f8b91d2e2 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml @@ -37,6 +37,8 @@ properties: - rockchip,rk3308-i2c - rockchip,rk3328-i2c - rockchip,rk3568-i2c + - rockchip,rk3588-i2c + - rockchip,rv1126-i2c - const: rockchip,rk3399-i2c reg: diff --git a/Documentation/devicetree/bindings/i2c/i2c-versatile.txt b/Documentation/devicetree/bindings/i2c/i2c-versatile.txt deleted file mode 100644 index 361d31c51b6f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-versatile.txt +++ /dev/null @@ -1,10 +0,0 @@ -i2c Controller on ARM Versatile platform: - -Required properties: -- compatible : Must be "arm,versatile-i2c"; -- reg -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties: -- Child nodes conforming to i2c bus binding diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index f771c09aabfc..0ec033e48830 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -21,10 +21,18 @@ properties: - enum: - allwinner,sun8i-a23-i2c - allwinner,sun8i-a83t-i2c + - allwinner,sun8i-v536-i2c - allwinner,sun50i-a64-i2c - - allwinner,sun50i-a100-i2c - allwinner,sun50i-h6-i2c + - const: allwinner,sun6i-a31-i2c + - description: Allwinner SoCs with offload support + items: + - enum: + - allwinner,sun20i-d1-i2c + - allwinner,sun50i-a100-i2c - allwinner,sun50i-h616-i2c + - allwinner,sun50i-r329-i2c + - const: allwinner,sun8i-v536-i2c - const: allwinner,sun6i-a31-i2c - const: marvell,mv64xxx-i2c - const: marvell,mv78230-i2c diff --git a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml index 128444942aec..09d2591e1fa3 100644 --- a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml @@ -7,17 +7,18 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: nuvoton NPCM7XX I2C Controller Device Tree Bindings description: | - The NPCM750x includes sixteen I2C bus controllers. All Controllers support - both master and slave mode. Each controller can switch between master and slave - at run time (i.e. IPMB mode). Each controller has two 16 byte HW FIFO for TX and - RX. + I2C bus controllers of the NPCM series support both master and + slave mode. Each controller can switch between master and slave at run time + (i.e. IPMB mode). HW FIFO for TX and RX are supported. maintainers: - Tali Perry <tali.perry1@gmail.com> properties: compatible: - const: nuvoton,npcm750-i2c + enum: + - nuvoton,npcm750-i2c + - nuvoton,npcm845-i2c reg: maxItems: 1 @@ -36,6 +37,10 @@ properties: default: 100000 enum: [100000, 400000, 1000000] + nuvoton,sys-mgr: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of system manager register node. + required: - compatible - reg @@ -44,6 +49,15 @@ required: allOf: - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + properties: + compatible: + contains: + const: nuvoton,npcm845-i2c + + then: + required: + - nuvoton,sys-mgr unevaluatedProperties: false @@ -57,6 +71,7 @@ examples: clock-frequency = <100000>; interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; compatible = "nuvoton,npcm750-i2c"; + nuvoton,sys-mgr = <&gcr>; }; ... diff --git a/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml b/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml new file mode 100644 index 000000000000..85d9efb743ee --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/opencores,i2c-ocores.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OpenCores I2C controller + +maintainers: + - Peter Korsgaard <peter@korsgaard.com> + - Andrew Lunn <andrew@lunn.ch> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - sifive,fu740-c000-i2c # Opencore based IP block FU740-C000 SoC + - sifive,fu540-c000-i2c # Opencore based IP block FU540-C000 SoC + - const: sifive,i2c0 + - enum: + - opencores,i2c-ocores + - aeroflexgaisler,i2cmst + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: + description: | + clock-frequency property is meant to control the bus frequency for i2c bus + drivers, but it was incorrectly used to specify i2c controller input clock + frequency. So the following rules are set to fix this situation: + - if clock-frequency is present and neither opencores,ip-clock-frequency nor + clocks are, then clock-frequency specifies i2c controller clock frequency. + This is to keep backwards compatibility with setups using old DTB. i2c bus + frequency is fixed at 100 KHz. + - if clocks is present it specifies i2c controller clock. clock-frequency + property specifies i2c bus frequency. + - if opencores,ip-clock-frequency is present it specifies i2c controller + clock frequency. clock-frequency property specifies i2c bus frequency. + default: 100000 + + reg-io-width: + description: | + io register width in bytes + enum: [1, 2, 4] + + reg-shift: + description: | + device register offsets are shifted by this value + default: 0 + + regstep: + description: | + deprecated, use reg-shift above + deprecated: true + + opencores,ip-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Frequency of the controller clock in Hz. Mutually exclusive with clocks. + See the note above. + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +oneOf: + - required: + - opencores,ip-clock-frequency + - required: + - clocks + +unevaluatedProperties: false + +examples: + - | + i2c@a0000000 { + compatible = "opencores,i2c-ocores"; + reg = <0xa0000000 0x8>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <10>; + opencores,ip-clock-frequency = <20000000>; + + reg-shift = <0>; /* 8 bit registers */ + reg-io-width = <1>; /* 8 bit read/write */ + }; + + i2c@b0000000 { + compatible = "opencores,i2c-ocores"; + reg = <0xa0000000 0x8>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <10>; + clocks = <&osc>; + clock-frequency = <400000>; /* i2c bus frequency 400 KHz */ + + reg-shift = <0>; /* 8 bit registers */ + reg-io-width = <1>; /* 8 bit read/write */ + }; +... diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml new file mode 100644 index 000000000000..90c9e401229e --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -0,0 +1,242 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/qcom,i2c-cci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Control Interface (CCI) I2C controller + +maintainers: + - Loic Poulain <loic.poulain@linaro.org> + - Robert Foss <robert.foss@linaro.org> + +properties: + compatible: + enum: + - qcom,msm8916-cci + - qcom,msm8974-cci + - qcom,msm8996-cci + - qcom,sdm845-cci + - qcom,sm8250-cci + - qcom,sm8450-cci + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + clocks: + minItems: 4 + maxItems: 6 + + clock-names: + minItems: 4 + maxItems: 6 + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +patternProperties: + "^i2c-bus@[01]$": + $ref: /schemas/i2c/i2c-controller.yaml# + unevaluatedProperties: false + + properties: + reg: + maxItems: 1 + + clock-frequency: + default: 100000 + +required: + - compatible + - clock-names + - clocks + - interrupts + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-cci + then: + required: + - power-domains + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8916-cci + then: + properties: + i2c-bus@1: false + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8916-cci + - qcom,msm8996-cci + then: + properties: + clocks: + maxItems: 4 + clock-names: + items: + - const: camss_top_ahb + - const: cci_ahb + - const: cci + - const: camss_ahb + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-cci + then: + properties: + clocks: + minItems: 6 + clock-names: + items: + - const: camnoc_axi + - const: soc_ahb + - const: slow_ahb_src + - const: cpas_ahb + - const: cci + - const: cci_src + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8250-cci + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: camnoc_axi + - const: slow_ahb_src + - const: cpas_ahb + - const: cci + - const: cci_src + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,camcc-sdm845.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + cci@ac4a000 { + reg = <0x0ac4a000 0x4000>; + compatible = "qcom,sdm845-cci"; + #address-cells = <1>; + #size-cells = <0>; + + interrupts = <GIC_SPI 460 IRQ_TYPE_EDGE_RISING>; + power-domains = <&clock_camcc TITAN_TOP_GDSC>; + + clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>, + <&clock_camcc CAM_CC_SOC_AHB_CLK>, + <&clock_camcc CAM_CC_SLOW_AHB_CLK_SRC>, + <&clock_camcc CAM_CC_CPAS_AHB_CLK>, + <&clock_camcc CAM_CC_CCI_CLK>, + <&clock_camcc CAM_CC_CCI_CLK_SRC>; + clock-names = "camnoc_axi", + "soc_ahb", + "slow_ahb_src", + "cpas_ahb", + "cci", + "cci_src"; + + assigned-clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>, + <&clock_camcc CAM_CC_CCI_CLK>; + assigned-clock-rates = <80000000>, + <37500000>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&cci0_default &cci1_default>; + pinctrl-1 = <&cci0_sleep &cci1_sleep>; + + i2c-bus@0 { + reg = <0>; + clock-frequency = <1000000>; + #address-cells = <1>; + #size-cells = <0>; + + camera@10 { + compatible = "ovti,ov8856"; + reg = <0x10>; + + reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&cam0_default>; + + clocks = <&clock_camcc CAM_CC_MCLK0_CLK>; + clock-names = "xvclk"; + clock-frequency = <19200000>; + + dovdd-supply = <&vreg_lvs1a_1p8>; + avdd-supply = <&cam0_avdd_2v8>; + dvdd-supply = <&cam0_dvdd_1v2>; + + port { + ov8856_ep: endpoint { + link-frequencies = /bits/ 64 <360000000 180000000>; + data-lanes = <1 2 3 4>; + remote-endpoint = <&csiphy0_ep>; + }; + }; + }; + }; + + cci_i2c1: i2c-bus@1 { + reg = <1>; + clock-frequency = <1000000>; + #address-cells = <1>; + #size-cells = <0>; + + camera@60 { + compatible = "ovti,ov7251"; + reg = <0x60>; + + enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&cam3_default>; + + clocks = <&clock_camcc CAM_CC_MCLK3_CLK>; + clock-names = "xclk"; + clock-frequency = <24000000>; + + vdddo-supply = <&vreg_lvs1a_1p8>; + vdda-supply = <&cam3_avdd_2v8>; + + port { + ov7251_ep: endpoint { + data-lanes = <0 1>; + remote-endpoint = <&csiphy3_ep>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml b/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml new file mode 100644 index 000000000000..c46378efc123 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rzv2m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2M I2C Bus Interface + +maintainers: + - Phil Edworthy <phil.edworthy@renesas.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,i2c-r9a09g011 # RZ/V2M + - const: renesas,rzv2m-i2c + + reg: + maxItems: 1 + + interrupts: + items: + - description: Data transmission/reception interrupt + - description: Status interrupt + + interrupt-names: + items: + - const: tia + - const: tis + + clock-frequency: + default: 100000 + enum: [ 100000, 400000 ] + description: + Desired I2C bus clock frequency in Hz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - power-domains + - resets + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r9a09g011-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c0: i2c@a4030000 { + compatible = "renesas,i2c-r9a09g011", "renesas,rzv2m-i2c"; + reg = <0xa4030000 0x80>; + interrupts = <GIC_SPI 232 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 236 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "tia", "tis"; + clocks = <&cpg CPG_MOD R9A09G011_IIC_PCLK0>; + resets = <&cpg R9A09G011_IIC_GPA_PRESETN>; + power-domains = <&cpg>; + clock-frequency = <100000>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml new file mode 100644 index 000000000000..42c5974ec7b0 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/st,nomadik-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST Microelectronics Nomadik I2C Bindings + +description: The Nomadik I2C host controller began its life in the ST + Microelectronics STn8800 SoC, and was then inherited into STn8810 and + STn8815. It was part of the prototype STn8500 which then became ST-Ericsson + DB8500 after the merge of these two companies wireless divisions. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +# Need a custom select here or 'arm,primecell' will match on lots of nodes +select: + properties: + compatible: + contains: + enum: + - st,nomadik-i2c + required: + - compatible + +properties: + compatible: + oneOf: + # The variant found in STn8815 + - items: + - const: st,nomadik-i2c + - const: arm,primecell + # The variant found in DB8500 + - items: + - const: stericsson,db8500-i2c + - const: st,nomadik-i2c + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + oneOf: + # Clock name in STn8815 + - items: + - const: mclk + - const: apb_pclk + # Clock name in DB8500 + - items: + - const: i2cclk + - const: apb_pclk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + clock-frequency: + minimum: 1 + maximum: 400000 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/stericsson,db8500-prcc-reset.h> + #include <dt-bindings/arm/ux500_pm_domains.h> + i2c@80004000 { + compatible = "stericsson,db8500-i2c", "st,nomadik-i2c", "arm,primecell"; + reg = <0x80004000 0x1000>; + interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; + + #address-cells = <1>; + #size-cells = <0>; + + clock-frequency = <400000>; + clocks = <&prcc_kclk 3 3>, <&prcc_pclk 3 3>; + clock-names = "i2cclk", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; + resets = <&prcc_reset DB8500_PRCC_3 DB8500_PRCC_3_RESET_I2C0>; + }; + + i2c@101f8000 { + compatible = "st,nomadik-i2c", "arm,primecell"; + reg = <0x101f8000 0x1000>; + interrupt-parent = <&vica>; + interrupts = <20>; + clock-frequency = <100000>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&i2c0clk>, <&pclki2c0>; + clock-names = "mclk", "apb_pclk"; + }; + +... diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index dccbb18b6dc0..a41588763786 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -17,6 +17,7 @@ allOf: contains: enum: - st,stm32f7-i2c + - st,stm32mp13-i2c - st,stm32mp15-i2c then: properties: @@ -45,6 +46,7 @@ properties: enum: - st,stm32f4-i2c - st,stm32f7-i2c + - st,stm32mp13-i2c - st,stm32mp15-i2c reg: diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml index 4fcbfd93e218..8d829ef878bc 100644 --- a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ADIS16240 Programmable Impact Sensor and Recorder driver maintainers: - - Alexandru Ardelean <alexandru.ardelean@analog.com> + - Alexandru Tachici <alexandru.tachici@analog.com> description: | ADIS16240 Programmable Impact Sensor and Recorder driver that supports diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml index 11d32a288535..9bb039e2f533 100644 --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml @@ -55,7 +55,7 @@ examples: /* Example for a I2C device node */ accelerometer@2a { compatible = "adi,adxl345"; - reg = <0x53>; + reg = <0x2a>; interrupt-parent = <&gpio0>; interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; }; diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml index 911a1ae9c83f..272eb48eef5a 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml @@ -17,7 +17,9 @@ description: | properties: compatible: enum: + - bosch,bmi085-accel - bosch,bmi088-accel + - bosch,bmi090l-accel reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml index 7c8f8bdc2333..9c7c66feeffc 100644 --- a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml +++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Freescale MMA7455 and MMA7456 three axis accelerometers maintainers: - - Joachim Eastwood <manabian@gmail.com> - Jonathan Cameron <jic23@kernel.org> description: diff --git a/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml index 55fd3548e3b6..f6e2a16a710b 100644 --- a/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml +++ b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - murata,sca3300 + - murata,scl3300 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml index 31ffa275f5fa..b97559f23b3a 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices AD7091R5 4-Channel 12-Bit ADC maintainers: - - Beniamin Bia <beniamin.bia@analog.com> + - Michael Hennerich <michael.hennerich@analog.com> description: | Analog Devices AD7091R5 4-Channel 12-Bit ADC diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml index 73775174cf57..516fc24d3346 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml @@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices AD7606 Simultaneous Sampling ADC maintainers: - - Beniamin Bia <beniamin.bia@analog.com> - - Stefan Popa <stefan.popa@analog.com> + - Michael Hennerich <michael.hennerich@analog.com> description: | Analog Devices AD7606 Simultaneous Sampling ADC diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml index b5aed40d8a50..2d72ff6bcbc0 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml @@ -8,7 +8,6 @@ title: Analog Devices AD9467 and similar High-Speed ADCs maintainers: - Michael Hennerich <michael.hennerich@analog.com> - - Alexandru Ardelean <alexandru.ardelean@analog.com> description: | The AD9467 and the parts similar with it, are high-speed analog-to-digital diff --git a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml index 0924b2b4972b..8e25773d69be 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml @@ -8,7 +8,6 @@ title: Analog Devices AXI ADC IP core maintainers: - Michael Hennerich <michael.hennerich@analog.com> - - Alexandru Ardelean <alexandru.ardelean@analog.com> description: | Analog Devices Generic AXI ADC IP core for interfacing an ADC device diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml b/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml index 925f355cc21f..c770ff4998f5 100644 --- a/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml @@ -14,7 +14,14 @@ description: properties: compatible: - const: fsl,vf610-adc + oneOf: + - items: + - enum: + - fsl,imx6sx-adc + - fsl,imx6ul-adc + - const: fsl,vf610-adc + - items: + - const: fsl,vf610-adc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml index 65581ad4b816..7f79a06e76f5 100644 --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml @@ -35,6 +35,7 @@ properties: - enum: - mediatek,mt8183-auxadc - mediatek,mt8186-auxadc + - mediatek,mt8188-auxadc - mediatek,mt8195-auxadc - mediatek,mt8516-auxadc - const: mediatek,mt8173-auxadc diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm750-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm750-adc.yaml index 001cf263b7d5..fede2aa64092 100644 --- a/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm750-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm750-adc.yaml @@ -10,11 +10,14 @@ maintainers: - Tomer Maimon <tmaimon77@gmail.com> description: - The NPCM ADC is a 10-bit converter for eight channel inputs. + The NPCM7XX ADC is a 10-bit converter and NPCM8XX ADC is a 12-bit converter, + both have eight channel inputs. properties: compatible: - const: nuvoton,npcm750-adc + enum: + - nuvoton,npcm750-adc + - nuvoton,npcm845-adc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml index 6404fb73f8ed..43abb300fa3d 100644 --- a/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP LPC1850 ADC bindings maintainers: - - Joachim Eastwood <manabian@gmail.com> + - Jonathan Cameron <jic23@kernel.org> description: Supports the ADC found on the LPC1850 SoC. diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml new file mode 100644 index 000000000000..c8cbfd3444be --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/qcom,spmi-rradc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm's SPMI PMIC Round Robin ADC + +maintainers: + - Caleb Connolly <caleb.connolly@linaro.org> + +description: | + The Qualcomm SPMI Round Robin ADC (RRADC) provides interface to clients to + read the voltage, current and temperature for supported peripherals such as + the battery thermistor die temperature, charger temperature, USB and DC input + voltage / current and battery ID resistor. + +properties: + compatible: + enum: + - qcom,pmi8998-rradc + - qcom,pm660-rradc + + reg: + maxItems: 1 + + qcom,batt-id-delay-ms: + description: Sets the hardware settling time for the battery ID resistor. + enum: [0, 1, 4, 12, 20, 40, 60, 80] + + "#io-channel-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pmic { + #address-cells = <1>; + #size-cells = <0>; + + pmic_rradc: adc@4500 { + compatible = "qcom,pmi8998-rradc"; + reg = <0x4500>; + #io-channel-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml index d66c24cae1e1..61c6157cf5a9 100644 --- a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml @@ -19,6 +19,7 @@ properties: compatible: items: - enum: + - renesas,r9a07g043-adc # RZ/G2UL - renesas,r9a07g044-adc # RZ/G2L - renesas,r9a07g054-adc # RZ/V2L - const: renesas,rzg2l-adc @@ -76,16 +77,35 @@ patternProperties: properties: reg: description: | - The channel number. It can have up to 8 channels numbered from 0 to 7. - items: - - minimum: 0 - maximum: 7 + The channel number. required: - reg additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: renesas,r9a07g043-adc + then: + patternProperties: + "^channel@[2-7]$": false + "^channel@[0-1]$": + properties: + reg: + minimum: 0 + maximum: 1 + else: + patternProperties: + "^channel@[0-7]$": + properties: + reg: + minimum: 0 + maximum: 7 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml index 54955f03df93..ae5ce60987fe 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments ADC108S102 and ADC128S102 maintainers: - - Bogdan Pricop <bogdan.pricop@emutex.com> + - Jonathan Cameron <jic23@kernel.org> description: | Family of 8 channel, 10/12 bit, SPI, single ended ADCs. diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml index 9f5e96439c01..2e6abc9d746a 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments' ads124s08 and ads124s06 ADC chip maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml index a557761d8016..9fda56fa49c3 100644 --- a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml +++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml @@ -8,7 +8,6 @@ title: HMC425A 6-bit Digital Step Attenuator maintainers: - Michael Hennerich <michael.hennerich@analog.com> - - Beniamin Bia <beniamin.bia@analog.com> description: | Digital Step Attenuator IIO device with gpio interface. diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml index a8f7720d1e3e..29bd16dab546 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml @@ -22,6 +22,8 @@ properties: - adi,ad5767 output-range-microvolts: + $ref: /schemas/types.yaml#/definitions/int32-array + maxItems: 2 description: Select converter output range. reg: diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml index fb2c48fc7ce4..24ac40180ac1 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices AD5770R DAC device driver maintainers: - - Mircea Caprioru <mircea.caprioru@analog.com> + - Alexandru Tachici <alexandru.tachici@analog.com> description: | Bindings for the Analog Devices AD5770R current DAC device. Datasheet can be diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml index 12a14b3f36cb..4c430abcdbf9 100644 --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml @@ -15,6 +15,7 @@ properties: enum: - microchip,mcp4902 - microchip,mcp4912 + - microchip,mcp4921 - microchip,mcp4922 reg: diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml index 714191724f7c..88298bc43b81 100644 --- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml @@ -21,6 +21,7 @@ properties: - ti,dac5573 - ti,dac6573 - ti,dac7573 + - ti,dac121c081 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml index b6bbc312a7cf..1414ba9977c1 100644 --- a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml +++ b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml @@ -24,8 +24,10 @@ properties: interrupts: minItems: 1 + maxItems: 2 description: Should be configured with type IRQ_TYPE_EDGE_RISING. + If two interrupts are provided, expected order is INT1 and INT2. required: - compatible diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml index 5dbe24be9925..dd29dc6c4c19 100644 --- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices ADIS16480 and similar IMUs maintainers: - - Alexandru Ardelean <alexandru.ardelean@analog.com> + - Alexandru Tachici <alexandru.tachici@analog.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml index 479e7065d4eb..0203b83b8587 100644 --- a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml +++ b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Freescale FXOS8700 Inertial Measurement Unit maintainers: - - Robert Jones <rjones@gateworks.com> + - Jonathan Cameron <jic23@kernel.org> description: | Accelerometer and magnetometer combo device with an i2c and SPI interface. diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml index b8a6ee16854f..b3aa2ebf9661 100644 --- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml @@ -126,6 +126,42 @@ properties: UINT_MAX (4294967295) represents infinite. Other values represent 1-1/N. + semtech,cs-idle-sleep: + description: + State of CS pins during sleep mode and idle time. + enum: + - hi-z + - gnd + - vdd + + semtech,int-comp-resistor: + description: + Internal resistor setting for compensation. + enum: + - lowest + - low + - high + - highest + + semtech,input-precharge-resistor-ohms: + default: 4000 + multipleOf: 2000 + minimum: 0 + maximum: 30000 + description: + Pre-charge input resistance in Ohm. + + semtech,input-analog-gain: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + description: | + Defines the input antenna analog gain + 0: x1.247 + 1: x1 (default) + 2: x0.768 + 3: x0.552 + required: - compatible - reg @@ -157,5 +193,8 @@ examples: semtech,ph01-proxraw-strength = <2>; semtech,ph23-proxraw-strength = <2>; semtech,avg-pos-strength = <64>; + semtech,int-comp-resistor = "lowest"; + semtech,input-precharge-resistor-ohms = <2000>; + semtech,cs-idle-sleep = "gnd"; }; }; diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml index 63e1a1fd00d4..f088c5d2be99 100644 --- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml @@ -61,6 +61,14 @@ properties: UINT_MAX (4294967295) represents infinite. Other values represent 1-1/N. + semtech,input-precharge-resistor-ohms: + default: 0 + multipleOf: 2000 + minimum: 0 + maximum: 30000 + description: + Pre-charge input resistance in Ohm. + required: - compatible - reg @@ -85,5 +93,6 @@ examples: semtech,resolution = <256>; semtech,proxraw-strength = <2>; semtech,avg-pos-strength = <64>; + semtech,input-precharge-resistor-ohms = <4000>; }; }; diff --git a/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml b/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml index 656460d9d8c8..322befc41de6 100644 --- a/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml @@ -19,6 +19,11 @@ properties: interrupts: maxItems: 1 + reset-gpios: + maxItems: 1 + + vdd-supply: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt index 5f9fbc68e58a..e5eef59a93dc 100644 --- a/Documentation/devicetree/bindings/input/da9062-onkey.txt +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt @@ -2,7 +2,7 @@ This module is part of the DA9061/DA9062/DA9063. For more details about entire DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt -For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt +For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml This module provides the KEY_POWER event. diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml new file mode 100644 index 000000000000..05e6f2df604c --- /dev/null +++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/elan,ekth6915.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Elan eKTH6915 touchscreen controller + +maintainers: + - Douglas Anderson <dianders@chromium.org> + +description: + Supports the Elan eKTH6915 touchscreen controller. + This touchscreen controller uses the i2c-hid protocol with a reset GPIO. + +properties: + compatible: + items: + - const: elan,ekth6915 + + reg: + const: 0x10 + + interrupts: + maxItems: 1 + + reset-gpios: + description: Reset GPIO; not all touchscreens using eKTH6915 hook this up. + + vcc33-supply: + description: The 3.3V supply to the touchscreen. + + vccio-supply: + description: + The IO supply to the touchscreen. Need not be specified if this is the + same as the 3.3V supply. + +required: + - compatible + - reg + - interrupts + - vcc33-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ap_ts: touchscreen@10 { + compatible = "elan,ekth6915"; + reg = <0x10>; + + interrupt-parent = <&tlmm>; + interrupts = <9 IRQ_TYPE_LEVEL_LOW>; + + reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>; + vcc33-supply = <&pp3300_ts>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/fsl,scu-key.yaml b/Documentation/devicetree/bindings/input/fsl,scu-key.yaml new file mode 100644 index 000000000000..e6266d188266 --- /dev/null +++ b/Documentation/devicetree/bindings/input/fsl,scu-key.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/fsl,scu-key.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - SCU key bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + +allOf: + - $ref: input.yaml# + +properties: + compatible: + items: + - const: fsl,imx8qxp-sc-key + - const: fsl,imx-sc-key + + linux,keycodes: + maxItems: 1 + +required: + - compatible + - linux,keycodes + +additionalProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + + keys { + compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key"; + linux,keycodes = <KEY_POWER>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt index 5eef5e7d6aae..c9f2c9f578e3 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt @@ -6,7 +6,7 @@ Required properties: - interrupts : interrupt specification for the ektf2127 interrupt - power-gpios : GPIO specification for the pin connected to the ektf2127's wake input. This needs to be driven high - to take ektf2127 out of it's low power state + to take ektf2127 out of its low power state For additional optional properties see: touchscreen.txt diff --git a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml index b8204ed22dd5..09c8948b5e25 100644 --- a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml +++ b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml @@ -26,14 +26,16 @@ properties: oneOf: - items: - enum: - - fsl,imx8mn-nic - fsl,imx8mm-nic + - fsl,imx8mn-nic + - fsl,imx8mp-nic - fsl,imx8mq-nic - const: fsl,imx8m-nic - items: - enum: - - fsl,imx8mn-noc - fsl,imx8mm-noc + - fsl,imx8mn-noc + - fsl,imx8mp-noc - fsl,imx8mq-noc - const: fsl,imx8m-noc - const: fsl,imx8m-nic diff --git a/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml b/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml new file mode 100644 index 000000000000..449c7c988229 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/mediatek,cci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Cache Coherent Interconnect (CCI) frequency and voltage scaling + +maintainers: + - Jia-Wei Chang <jia-wei.chang@mediatek.com> + - Johnson Wang <johnson.wang@mediatek.com> + +description: | + MediaTek Cache Coherent Interconnect (CCI) is a hardware engine used by + MT8183 and MT8186 SoCs to scale the frequency and adjust the voltage in + hardware. It can also optimize the voltage to reduce the power consumption. + +properties: + compatible: + enum: + - mediatek,mt8183-cci + - mediatek,mt8186-cci + + clocks: + items: + - description: + The multiplexer for clock input of the bus. + - description: + A parent of "bus" clock which is used as an intermediate clock source + when the original clock source (PLL) is under transition and not + stable yet. + + clock-names: + items: + - const: cci + - const: intermediate + + operating-points-v2: true + opp-table: true + + proc-supply: + description: + Phandle of the regulator for CCI that provides the supply voltage. + + sram-supply: + description: + Phandle of the regulator for sram of CCI that provides the supply + voltage. When it is present, the implementation needs to do + "voltage tracking" to step by step scale up/down Vproc and Vsram to fit + SoC specific needs. When absent, the voltage scaling flow is handled by + hardware, hence no software "voltage tracking" is needed. + +required: + - compatible + - clocks + - clock-names + - operating-points-v2 + - proc-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8183-clk.h> + cci: cci { + compatible = "mediatek,mt8183-cci"; + clocks = <&mcucfg CLK_MCU_BUS_SEL>, + <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>; + clock-names = "cci", "intermediate"; + operating-points-v2 = <&cci_opp>; + proc-supply = <&mt6358_vproc12_reg>; + }; + + cci_opp: opp-table-cci { + compatible = "operating-points-v2"; + opp-shared; + opp2_00: opp-273000000 { + opp-hz = /bits/ 64 <273000000>; + opp-microvolt = <650000>; + }; + opp2_01: opp-338000000 { + opp-hz = /bits/ 64 <338000000>; + opp-microvolt = <687500>; + }; + opp2_02: opp-403000000 { + opp-hz = /bits/ 64 <403000000>; + opp-microvolt = <718750>; + }; + opp2_03: opp-463000000 { + opp-hz = /bits/ 64 <463000000>; + opp-microvolt = <756250>; + }; + opp2_04: opp-546000000 { + opp-hz = /bits/ 64 <546000000>; + opp-microvolt = <800000>; + }; + opp2_05: opp-624000000 { + opp-hz = /bits/ 64 <624000000>; + opp-microvolt = <818750>; + }; + opp2_06: opp-689000000 { + opp-hz = /bits/ 64 <689000000>; + opp-microvolt = <850000>; + }; + opp2_07: opp-767000000 { + opp-hz = /bits/ 64 <767000000>; + opp-microvolt = <868750>; + }; + opp2_08: opp-845000000 { + opp-hz = /bits/ 64 <845000000>; + opp-microvolt = <893750>; + }; + opp2_09: opp-871000000 { + opp-hz = /bits/ 64 <871000000>; + opp-microvolt = <906250>; + }; + opp2_10: opp-923000000 { + opp-hz = /bits/ 64 <923000000>; + opp-microvolt = <931250>; + }; + opp2_11: opp-962000000 { + opp-hz = /bits/ 64 <962000000>; + opp-microvolt = <943750>; + }; + opp2_12: opp-1027000000 { + opp-hz = /bits/ 64 <1027000000>; + opp-microvolt = <975000>; + }; + opp2_13: opp-1092000000 { + opp-hz = /bits/ 64 <1092000000>; + opp-microvolt = <1000000>; + }; + opp2_14: opp-1144000000 { + opp-hz = /bits/ 64 <1144000000>; + opp-microvolt = <1025000>; + }; + opp2_15: opp-1196000000 { + opp-hz = /bits/ 64 <1196000000>; + opp-microvolt = <1050000>; + }; + }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml new file mode 100644 index 000000000000..c2e697f6e6cf --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,msm8998-bwmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Interconnect Bandwidth Monitor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +description: | + Bandwidth Monitor measures current throughput on buses between various NoC + fabrics and provides information when it crosses configured thresholds. + + Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:: + - Measuring the bandwidth between CPUs and Last Level Cache Controller - + called just BWMON, + - Measuring the bandwidth between Last Level Cache Controller and memory + (DDR) - called LLCC BWMON. + +properties: + compatible: + oneOf: + - items: + - enum: + - qcom,sdm845-bwmon + - const: qcom,msm8998-bwmon + - const: qcom,msm8998-bwmon # BWMON v4 + + interconnects: + maxItems: 1 + + interrupts: + maxItems: 1 + + operating-points-v2: true + opp-table: true + + reg: + # BWMON v4 (currently described) and BWMON v5 use one register address + # space. BWMON v2 uses two register spaces - not yet described. + maxItems: 1 + +required: + - compatible + - interconnects + - interrupts + - operating-points-v2 + - opp-table + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interconnect/qcom,sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pmu@1436400 { + compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon"; + reg = <0x01436400 0x600>; + interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>; + interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_LLCC 3>; + + operating-points-v2 = <&cpu_bwmon_opp_table>; + + cpu_bwmon_opp_table: opp-table { + compatible = "operating-points-v2"; + opp-0 { + opp-peak-kBps = <4800000>; + }; + opp-1 { + opp-peak-kBps = <9216000>; + }; + opp-2 { + opp-peak-kBps = <15052800>; + }; + opp-3 { + opp-peak-kBps = <20889600>; + }; + opp-4 { + opp-peak-kBps = <25497600>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index 8a676fef8c1d..4b37aa88a375 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -45,7 +45,11 @@ properties: - qcom,sdm660-snoc '#interconnect-cells': - const: 1 + description: | + Value: <1> is one cell in an interconnect specifier for the + interconnect node id, <2> requires the interconnect node id and an + extra path tag. + enum: [ 1, 2 ] clocks: minItems: 2 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-common.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-common.yaml new file mode 100644 index 000000000000..bbeb0541536b --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-common.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPMh Network-On-Chip Interconnect + +maintainers: + - Georgi Djakov <djakov@kernel.org> + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + RPMh interconnect providers support system bandwidth requirements through + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is + able to communicate with the BCM through the Resource State Coordinator (RSC) + associated with each execution environment. Provider nodes must point to at + least one RPMh device child node pertaining to their RSC and each provider + can map to multiple RPMh resources. + +properties: + '#interconnect-cells': + enum: [ 1, 2 ] + + qcom,bcm-voters: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 + maxItems: 2 + description: + List of phandles to qcom,bcm-voter nodes that are required by + this interconnect to send RPMh commands. + + qcom,bcm-voter-names: + maxItems: 2 + description: + Names for each of the qcom,bcm-voters specified. + +required: + - '#interconnect-cells' + - qcom,bcm-voters + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 28b3516aa089..a429a1ed1006 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -18,6 +18,9 @@ description: | least one RPMh device child node pertaining to their RSC and each provider can map to multiple RPMh resources. +allOf: + - $ref: qcom,rpmh-common.yaml# + properties: reg: maxItems: 1 @@ -130,28 +133,13 @@ properties: - qcom,sm8450-pcie-anoc - qcom,sm8450-system-noc - '#interconnect-cells': - enum: [ 1, 2 ] - - qcom,bcm-voters: - $ref: /schemas/types.yaml#/definitions/phandle-array - items: - maxItems: 1 - description: | - List of phandles to qcom,bcm-voter nodes that are required by - this interconnect to send RPMh commands. - - qcom,bcm-voter-names: - description: | - Names for each of the qcom,bcm-voters specified. + '#interconnect-cells': true required: - compatible - reg - - '#interconnect-cells' - - qcom,bcm-voters -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml new file mode 100644 index 000000000000..49eb156b08e0 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,sm6350-rpmh.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM6350 RPMh Network-On-Chip Interconnect + +maintainers: + - Luca Weiss <luca.weiss@fairphone.com> + +description: + Qualcomm RPMh-based interconnect provider on SM6350. + +allOf: + - $ref: qcom,rpmh-common.yaml# + +properties: + compatible: + enum: + - qcom,sm6350-aggre1-noc + - qcom,sm6350-aggre2-noc + - qcom,sm6350-config-noc + - qcom,sm6350-dc-noc + - qcom,sm6350-gem-noc + - qcom,sm6350-mmss-noc + - qcom,sm6350-npu-noc + - qcom,sm6350-system-noc + + reg: + maxItems: 1 + + '#interconnect-cells': true + +patternProperties: + '^interconnect-[a-z0-9\-]+$': + type: object + description: + The interconnect providers do not have a separate QoS register space, + but share parent's space. + $ref: qcom,rpmh-common.yaml# + + properties: + compatible: + enum: + - qcom,sm6350-clk-virt + - qcom,sm6350-compute-noc + + '#interconnect-cells': true + + required: + - compatible + + unevaluatedProperties: false + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + config_noc: interconnect@1500000 { + compatible = "qcom,sm6350-config-noc"; + reg = <0x01500000 0x28000>; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; + + system_noc: interconnect@1620000 { + compatible = "qcom,sm6350-system-noc"; + reg = <0x01620000 0x17080>; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + + clk_virt: interconnect-clk-virt { + compatible = "qcom,sm6350-clk-virt"; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; + }; diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml new file mode 100644 index 000000000000..ad9ed596dfef --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml @@ -0,0 +1,290 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/samsung,exynos-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Bus and Interconnect + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzk@kernel.org> + +description: | + The Samsung Exynos SoC has many buses for data transfer between DRAM and + sub-blocks in SoC. Most Exynos SoCs share the common architecture for buses. + Generally, each bus of Exynos SoC includes a source clock and a power line, + which are able to change the clock frequency of the bus in runtime. To + monitor the usage of each bus in runtime, the driver uses the PPMU (Platform + Performance Monitoring Unit), which is able to measure the current load of + sub-blocks. + + The Exynos SoC includes the various sub-blocks which have the each AXI bus. + The each AXI bus has the owned source clock but, has not the only owned power + line. The power line might be shared among one more sub-blocks. So, we can + divide into two type of device as the role of each sub-block. There are two + type of bus devices as following:: + - parent bus device + - passive bus device + + Basically, parent and passive bus device share the same power line. The + parent bus device can only change the voltage of shared power line and the + rest bus devices (passive bus device) depend on the decision of the parent + bus device. If there are three blocks which share the VDD_xxx power line, + Only one block should be parent device and then the rest blocks should depend + on the parent device as passive device. + + VDD_xxx |--- A block (parent) + |--- B block (passive) + |--- C block (passive) + + There are a little different composition among Exynos SoC because each Exynos + SoC has different sub-blocks. Therefore, such difference should be specified + in devicetree file instead of each device driver. In result, this driver is + able to support the bus frequency for all Exynos SoCs. + + Detailed correlation between sub-blocks and power line according + to Exynos SoC:: + - In case of Exynos3250, there are two power line as following:: + VDD_MIF |--- DMC (Dynamic Memory Controller) + + VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC + |--- G3D + |--- RIGHTBUS + |--- PERIR + |--- FSYS + |--- LCD0 + |--- PERIR + |--- ISP + |--- CAM + + - MIF bus's frequency/voltage table + ----------------------- + |Lv| Freq | Voltage | + ----------------------- + |L1| 50000 |800000 | + |L2| 100000 |800000 | + |L3| 134000 |800000 | + |L4| 200000 |825000 | + |L5| 400000 |875000 | + ----------------------- + + - INT bus's frequency/voltage table + ---------------------------------------------------------- + |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP |PERIL ||VDD_INT | + | name| |LCD0 | | | || | + | | |FSYS | | | || | + | | |MFC | | | || | + ---------------------------------------------------------- + |Mode |*parent|passive |passive|passive|passive|| | + ---------------------------------------------------------- + |Lv |Frequency ||Voltage | + ---------------------------------------------------------- + |L1 |50000 |50000 |50000 |50000 |50000 ||900000 | + |L2 |80000 |80000 |80000 |80000 |80000 ||900000 | + |L3 |100000 |100000 |100000 |100000 |100000 ||1000000 | + |L4 |134000 |134000 |200000 |200000 | ||1000000 | + |L5 |200000 |200000 |400000 |300000 | ||1000000 | + ---------------------------------------------------------- + + - In case of Exynos4210, there is one power line as following:: + VDD_INT |--- DMC (parent device, Dynamic Memory Controller) + |--- LEFTBUS + |--- PERIL + |--- MFC(L) + |--- G3D + |--- TV + |--- LCD0 + |--- RIGHTBUS + |--- PERIR + |--- MFC(R) + |--- CAM + |--- FSYS + |--- GPS + |--- LCD0 + |--- LCD1 + + - In case of Exynos4x12, there are two power line as following:: + VDD_MIF |--- DMC (Dynamic Memory Controller) + + VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC(L) + |--- G3D + |--- TV + |--- IMAGE + |--- RIGHTBUS + |--- PERIR + |--- MFC(R) + |--- CAM + |--- FSYS + |--- GPS + |--- LCD0 + |--- ISP + + - In case of Exynos5422, there are two power line as following:: + VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller) + |--- DREX 1 + + VDD_INT |--- NoC_Core (parent device) + |--- G2D + |--- G3D + |--- DISP1 + |--- NoC_WCORE + |--- GSCL + |--- MSCL + |--- ISP + |--- MFC + |--- GEN + |--- PERIS + |--- PERIC + |--- FSYS + |--- FSYS2 + + - In case of Exynos5433, there is VDD_INT power line as following:: + VDD_INT |--- G2D (parent device) + |--- MSCL + |--- GSCL + |--- JPEG + |--- MFC + |--- HEVC + |--- BUS0 + |--- BUS1 + |--- BUS2 + |--- PERIS (Fixed clock rate) + |--- PERIC (Fixed clock rate) + |--- FSYS (Fixed clock rate) + +properties: + compatible: + enum: + - samsung,exynos-bus + + clocks: + maxItems: 1 + + clock-names: + items: + - const: bus + + devfreq: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Parent bus device. Valid and required only for the passive bus devices. + + devfreq-events: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 + description: + Devfreq-event device to monitor the current utilization of buses. Valid + and required only for the parent bus devices. + + exynos,saturation-ratio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Percentage value which is used to calibrate the performance count against + total cycle count. Valid only for the parent bus devices. + + '#interconnect-cells': + const: 0 + + interconnects: + minItems: 1 + maxItems: 2 + + operating-points-v2: true + + samsung,data-clock-ratio: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 8 + description: + Ratio of the data throughput in B/s to minimum data clock frequency in + Hz. + + vdd-supply: + description: + Main bus power rail. Valid and required only for the parent bus devices. + +required: + - compatible + - clocks + - clock-names + - operating-points-v2 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos3250.h> + + bus-dmc { + compatible = "samsung,exynos-bus"; + clocks = <&cmu_dmc CLK_DIV_DMC>; + clock-names = "bus"; + operating-points-v2 = <&bus_dmc_opp_table>; + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>; + vdd-supply = <&buck1_reg>; + }; + + ppmu_dmc0: ppmu@106a0000 { + compatible = "samsung,exynos-ppmu"; + reg = <0x106a0000 0x2000>; + events { + ppmu_dmc0_3: ppmu-event3-dmc0 { + event-name = "ppmu-event3-dmc0"; + }; + }; + }; + + bus_leftbus: bus-leftbus { + compatible = "samsung,exynos-bus"; + clocks = <&cmu CLK_DIV_GDL>; + clock-names = "bus"; + operating-points-v2 = <&bus_leftbus_opp_table>; + devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>; + vdd-supply = <&buck3_reg>; + }; + + bus-rightbus { + compatible = "samsung,exynos-bus"; + clocks = <&cmu CLK_DIV_GDR>; + clock-names = "bus"; + operating-points-v2 = <&bus_leftbus_opp_table>; + devfreq = <&bus_leftbus>; + }; + + - | + dmc: bus-dmc { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_DMC>; + clock-names = "bus"; + operating-points-v2 = <&bus_dmc_opp_table>; + samsung,data-clock-ratio = <4>; + #interconnect-cells = <0>; + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>; + vdd-supply = <&buck1_reg>; + }; + + leftbus: bus-leftbus { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_GDL>; + clock-names = "bus"; + operating-points-v2 = <&bus_leftbus_opp_table>; + interconnects = <&dmc>; + #interconnect-cells = <0>; + devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>; + vdd-supply = <&buck3_reg>; + }; + + display: bus-display { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_ACLK_266>; + clock-names = "bus"; + operating-points-v2 = <&bus_display_opp_table>; + interconnects = <&leftbus &dmc>; + #interconnect-cells = <0>; + devfreq = <&leftbus>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt deleted file mode 100644 index e0062aebf025..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt +++ /dev/null @@ -1,61 +0,0 @@ -RDA Micro RDA8810PL Interrupt Controller - -The interrupt controller in RDA8810PL SoC is a custom interrupt controller -which supports up to 32 interrupts. - -Required properties: - -- compatible: Should be "rda,8810pl-intc". -- reg: Specifies base physical address of the registers set. -- interrupt-controller: Identifies the node as an interrupt controller. -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. The value shall be 2. - -The interrupt sources are as follows: - -ID Name ------------- -0: PULSE_DUMMY -1: I2C -2: NAND_NFSC -3: SDMMC1 -4: SDMMC2 -5: SDMMC3 -6: SPI1 -7: SPI2 -8: SPI3 -9: UART1 -10: UART2 -11: UART3 -12: GPIO1 -13: GPIO2 -14: GPIO3 -15: KEYPAD -16: TIMER -17: TIMEROS -18: COMREG0 -19: COMREG1 -20: USB -21: DMC -22: DMA -23: CAMERA -24: GOUDA -25: GPU -26: VPU_JPG -27: VPU_HOST -28: VOC -29: AUIFC0 -30: AUIFC1 -31: L2CC - -Example: - apb@20800000 { - compatible = "simple-bus"; - ... - intc: interrupt-controller@0 { - compatible = "rda,8810pl-intc"; - reg = <0x0 0x1000>; - interrupt-controller; - #interrupt-cells = <2>; - }; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.yaml new file mode 100644 index 000000000000..96d6285d0087 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/rda,8810pl-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RDA Micro RDA8810PL interrupt controller + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + const: rda,8810pl-intc + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + intc: interrupt-controller@0 { + compatible = "rda,8810pl-intc"; + reg = <0x0 0x1000>; + interrupt-controller; + #interrupt-cells = <2>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml new file mode 100644 index 000000000000..33b90e975e33 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/renesas,rzg2l-irqc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L (and alike SoC's) Interrupt Controller (IA55) + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + IA55 performs various interrupt controls including synchronization for the external + interrupts of NMI, IRQ, and GPIOINT and the interrupts of the built-in peripheral + interrupts output by each IP. And it notifies the interrupt to the GIC + - IRQ sense select for 8 external interrupts, mapped to 8 GIC SPI interrupts + - GPIO pins used as external interrupt input pins, mapped to 32 GIC SPI interrupts + - NMI edge select (NMI is not treated as NMI exception and supports fall edge and + stand-up edge detection interrupts) + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-irqc # RZ/G2{L,LC} + - renesas,r9a07g054-irqc # RZ/V2L + - const: renesas,rzg2l-irqc + + '#interrupt-cells': + description: The first cell should contain external interrupt number (IRQ0-7) and the + second cell is used to specify the flag. + const: 2 + + '#address-cells': + const: 0 + + interrupt-controller: true + + reg: + maxItems: 1 + + interrupts: + maxItems: 41 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: clk + - const: pclk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - '#interrupt-cells' + - '#address-cells' + - interrupt-controller + - reg + - interrupts + - clocks + - clock-names + - power-domains + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r9a07g044-cpg.h> + + irqc: interrupt-controller@110a0000 { + compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc"; + reg = <0x110a0000 0x10000>; + #interrupt-cells = <2>; + #address-cells = <0>; + interrupt-controller; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>, + <&cpg CPG_MOD R9A07G044_IA55_PCLK>; + clock-names = "clk", "pclk"; + power-domains = <&cpg>; + resets = <&cpg R9A07G044_IA55_RESETN>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 27092c6a86c4..92e0f8c3eff2 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -26,9 +26,14 @@ description: with priority below this threshold will not cause the PLIC to raise its interrupt line leading to the context. - While the PLIC supports both edge-triggered and level-triggered interrupts, - interrupt handlers are oblivious to this distinction and therefore it is not - specified in the PLIC device-tree binding. + The PLIC supports both edge-triggered and level-triggered interrupts. For + edge-triggered interrupts, the RISC-V PLIC spec allows two responses to edges + seen while an interrupt handler is active; the PLIC may either queue them or + ignore them. In the first case, handlers are oblivious to the trigger type, so + it is not included in the interrupt specifier. In the second case, software + needs to know the trigger type, so it can reorder the interrupt flow to avoid + missing interrupts. This special handling is needed by at least the Renesas + RZ/Five SoC (AX45MP AndesCore with a NCEPLIC100) and the T-HEAD C900 PLIC. While the RISC-V ISA doesn't specify a memory layout for the PLIC, the "sifive,plic-1.0.0" device is a concrete implementation of the PLIC that @@ -49,6 +54,10 @@ properties: oneOf: - items: - enum: + - renesas,r9a07g043-plic + - const: andestech,nceplic100 + - items: + - enum: - sifive,fu540-c000-plic - starfive,jh7100-plic - canaan,k210-plic @@ -64,8 +73,7 @@ properties: '#address-cells': const: 0 - '#interrupt-cells': - const: 1 + '#interrupt-cells': true interrupt-controller: true @@ -82,6 +90,12 @@ properties: description: Specifies how many external interrupts are supported by this controller. + clocks: true + + power-domains: true + + resets: true + required: - compatible - '#address-cells' @@ -91,6 +105,47 @@ required: - interrupts-extended - riscv,ndev +allOf: + - if: + properties: + compatible: + contains: + enum: + - andestech,nceplic100 + - thead,c900-plic + + then: + properties: + '#interrupt-cells': + const: 2 + + else: + properties: + '#interrupt-cells': + const: 1 + + - if: + properties: + compatible: + contains: + const: renesas,r9a07g043-plic + + then: + properties: + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + required: + - clocks + - power-domains + - resets + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunplus,sp7021-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/sunplus,sp7021-intc.yaml new file mode 100644 index 000000000000..bd0021dbab0b --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/sunplus,sp7021-intc.yaml @@ -0,0 +1,62 @@ +# 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/interrupt-controller/sunplus,sp7021-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SP7021 SoC Interrupt Controller + +maintainers: + - Qin Jian <qinjian@cqplus1.com> + +properties: + compatible: + items: + - const: sunplus,sp7021-intc + + reg: + maxItems: 2 + description: + Specifies base physical address(s) and size of the controller regs. + The 1st region include type/polarity/priority/mask regs. + The 2nd region include clear/masked_ext0/masked_ext1/group regs. + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + description: + The first cell is the IRQ number, the second cell is the trigger + type as defined in interrupt.txt in this directory. + + interrupts: + maxItems: 2 + description: + EXT_INT0 & EXT_INT1, 2 interrupts references to primary interrupt + controller. + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + intc: interrupt-controller@9c000780 { + compatible = "sunplus,sp7021-intc"; + reg = <0x9c000780 0x80>, <0x9c000a80 0x80>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, /* EXT_INT0 */ + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>; /* EXT_INT1 */ + }; + +... diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 76fc2c0f4d54..9066e6df1ba1 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -42,6 +42,7 @@ properties: - qcom,sdx55-smmu-500 - qcom,sdx65-smmu-500 - qcom,sm6350-smmu-500 + - qcom,sm6375-smmu-500 - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 - qcom,sm8350-smmu-500 diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 2ae3bbad7f1a..fee0241b5098 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -101,6 +101,10 @@ properties: items: - const: bclk + mediatek,infracfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle to the mediatek infracfg syscon + mediatek,larbs: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 @@ -167,6 +171,18 @@ allOf: required: - power-domains + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2712-m4u + - mediatek,mt8173-m4u + + then: + required: + - mediatek,infracfg + - if: # The IOMMUs don't have larbs. not: properties: @@ -191,6 +207,7 @@ examples: interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>; clocks = <&infracfg CLK_INFRA_M4U>; clock-names = "bclk"; + mediatek,infracfg = <&infracfg>; mediatek,larbs = <&larb0>, <&larb1>, <&larb2>, <&larb3>, <&larb4>, <&larb5>; #iommu-cells = <1>; diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml b/Documentation/devicetree/bindings/leds/backlight/common.yaml index 702ba350d869..3b60afbab68b 100644 --- a/Documentation/devicetree/bindings/leds/backlight/common.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Common backlight properties maintainers: - - Lee Jones <lee.jones@linaro.org> + - Lee Jones <lee@kernel.org> - Daniel Thompson <daniel.thompson@linaro.org> - Jingoo Han <jingoohan1@gmail.com> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml index 75cc569b9c55..3300451fcfd5 100644 --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: gpio-backlight bindings maintainers: - - Lee Jones <lee.jones@linaro.org> + - Lee Jones <lee@kernel.org> - Daniel Thompson <daniel.thompson@linaro.org> - Jingoo Han <jingoohan1@gmail.com> diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml index f5822f4ea667..0793d0adc4ec 100644 --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: led-backlight bindings maintainers: - - Lee Jones <lee.jones@linaro.org> + - Lee Jones <lee@kernel.org> - Daniel Thompson <daniel.thompson@linaro.org> - Jingoo Han <jingoohan1@gmail.com> diff --git a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml index 08fe5cf8614a..3c9b4054ed9a 100644 --- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI LM3630A High-Efficiency Dual-String White LED maintainers: - - Lee Jones <lee.jones@linaro.org> + - Lee Jones <lee@kernel.org> - Daniel Thompson <daniel.thompson@linaro.org> - Jingoo Han <jingoohan1@gmail.com> diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml index fcb8429f3088..78fbe20a1758 100644 --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: pwm-backlight bindings maintainers: - - Lee Jones <lee.jones@linaro.org> + - Lee Jones <lee@kernel.org> - Daniel Thompson <daniel.thompson@linaro.org> - Jingoo Han <jingoohan1@gmail.com> diff --git a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml index e0ac68694b63..99e9e138fa92 100644 --- a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml @@ -47,6 +47,11 @@ properties: minimum: 0 maximum: 3 + richtek,bled-ocp-microamp: + description: | + Backlight over current protection level. + enum: [900000, 1200000, 1500000, 1800000] + richtek,channel-use: description: | Backlight LED channel to be used. diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml index 9362b1ef9e88..14bebe1ad8f8 100644 --- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -33,6 +33,8 @@ patternProperties: "^multi-led@[0-9a-b]$": type: object $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + description: This node represents one of the RGB LED devices on Turris Omnia. No subnodes need to be added for subchannels since this controller only diff --git a/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml b/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml new file mode 100644 index 000000000000..940333f2d69c --- /dev/null +++ b/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml @@ -0,0 +1,193 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/issi,is31fl319x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ISSI LED controllers bindings for IS31FL319{0,1,3,6,9} + +maintainers: + - Vincent Knecht <vincent.knecht@mailoo.org> + +description: | + The IS31FL319X are LED controllers with I2C interface. + Previously known as Si-En SN319{0,1,3,6,9}. + + For more product information please see the links below: + https://lumissil.com/assets/pdf/core/IS31FL3190_DS.pdf + https://lumissil.com/assets/pdf/core/IS31FL3191_DS.pdf + https://lumissil.com/assets/pdf/core/IS31FL3193_DS.pdf + https://lumissil.com/assets/pdf/core/IS31FL3196_DS.pdf + https://lumissil.com/assets/pdf/core/IS31FL3199_DS.pdf + +properties: + compatible: + enum: + - issi,is31fl3190 + - issi,is31fl3191 + - issi,is31fl3193 + - issi,is31fl3196 + - issi,is31fl3199 + - si-en,sn3190 + - si-en,sn3191 + - si-en,sn3193 + - si-en,sn3196 + - si-en,sn3199 + + reg: + maxItems: 1 + + shutdown-gpios: + maxItems: 1 + description: GPIO attached to the SDB pin. + + audio-gain-db: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: Audio gain selection for external analog modulation input. + enum: [0, 3, 6, 9, 12, 15, 18, 21] + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[1-9]$": + type: object + $ref: common.yaml# + + properties: + reg: + description: Index of the LED. + minimum: 1 + maximum: 9 + + led-max-microamp: + description: + Note that a driver will take the lowest of all LED limits + since the chip has a single global setting. The lowest value + will be chosen due to the PWM specificity, where lower + brightness is achieved by reducing the duty-cycle of pulses + and not the current, which will always have its peak value + equal to led-max-microamp. + +allOf: + - if: + properties: + compatible: + contains: + enum: + - issi,is31fl3190 + - issi,is31fl3191 + - issi,is31fl3193 + - si-en,sn3190 + - si-en,sn3191 + - si-en,sn3193 + then: + properties: + reg: + enum: [0x68, 0x69, 0x6a, 0x6b] + + audio-gain-db: false + + patternProperties: + "^led@[1-9]$": + properties: + led-max-microamp: + default: 42000 + enum: [5000, 10000, 17500, 30000, 42000] + else: + properties: + reg: + enum: [0x64, 0x65, 0x66, 0x67] + + patternProperties: + "^led@[1-9]$": + properties: + led-max-microamp: + default: 20000 + enum: [5000, 10000, 15000, 20000, 25000, 30000, 35000, 40000] + - if: + properties: + compatible: + contains: + enum: + - issi,is31fl3190 + - issi,is31fl3191 + - si-en,sn3190 + - si-en,sn3191 + then: + patternProperties: + "^led@[1-9]$": + properties: + reg: + maximum: 1 + - if: + properties: + compatible: + contains: + enum: + - issi,is31fl3193 + - si-en,sn3193 + then: + patternProperties: + "^led@[1-9]$": + properties: + reg: + maximum: 3 + - if: + properties: + compatible: + contains: + enum: + - issi,is31fl3196 + - si-en,sn3196 + then: + patternProperties: + "^led@[1-9]$": + properties: + reg: + maximum: 6 + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@65 { + compatible = "issi,is31fl3196"; + reg = <0x65>; + #address-cells = <1>; + #size-cells = <0>; + + shutdown-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; + + led@1 { + reg = <1>; + label = "red:aux"; + led-max-microamp = <10000>; + }; + + led@5 { + reg = <5>; + label = "green:power"; + linux,default-trigger = "default-on"; + }; + }; + }; +... + diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt b/Documentation/devicetree/bindings/leds/leds-aat1290.txt deleted file mode 100644 index 62ed17ec075b..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-aat1290.txt +++ /dev/null @@ -1,77 +0,0 @@ -* Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs - -The device is controlled through two pins: FL_EN and EN_SET. The pins when, -asserted high, enable flash strobe and movie mode (max 1/2 of flash current) -respectively. In order to add a capability of selecting the strobe signal source -(e.g. CPU or camera sensor) there is an additional switch required, independent -of the flash chip. The switch is controlled with pin control. - -Required properties: - -- compatible : Must be "skyworks,aat1290". -- flen-gpios : Must be device tree identifier of the flash device FL_EN pin. -- enset-gpios : Must be device tree identifier of the flash device EN_SET pin. - -Optional properties: -- pinctrl-names : Must contain entries: "default", "host", "isp". Entries - "default" and "host" must refer to the same pin configuration - node, which sets the host as a strobe signal provider. Entry - "isp" must refer to the pin configuration node, which sets the - ISP as a strobe signal provider. - -A discrete LED element connected to the device must be represented by a child -node - see Documentation/devicetree/bindings/leds/common.txt. - -Required properties of the LED child node: -- led-max-microamp : see Documentation/devicetree/bindings/leds/common.txt -- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt - Maximum flash LED supply current can be calculated using - following formula: I = 1A * 162kohm / Rset. -- flash-max-timeout-us : see Documentation/devicetree/bindings/leds/common.txt - Maximum flash timeout can be calculated using following - formula: T = 8.82 * 10^9 * Ct. - -Optional properties of the LED child node: -- function : see Documentation/devicetree/bindings/leds/common.txt -- color : see Documentation/devicetree/bindings/leds/common.txt -- label : see Documentation/devicetree/bindings/leds/common.txt (deprecated) - -Example (by Ct = 220nF, Rset = 160kohm and exynos4412-trats2 board with -a switch that allows for routing strobe signal either from the host or from -the camera sensor): - -#include "exynos4412.dtsi" -#include <dt-bindings/leds/common.h> - -led-controller { - compatible = "skyworks,aat1290"; - flen-gpios = <&gpj1 1 GPIO_ACTIVE_HIGH>; - enset-gpios = <&gpj1 2 GPIO_ACTIVE_HIGH>; - - pinctrl-names = "default", "host", "isp"; - pinctrl-0 = <&camera_flash_host>; - pinctrl-1 = <&camera_flash_host>; - pinctrl-2 = <&camera_flash_isp>; - - camera_flash: led { - function = LED_FUNCTION_FLASH; - color = <LED_COLOR_ID_WHITE>; - led-max-microamp = <520833>; - flash-max-microamp = <1012500>; - flash-max-timeout-us = <1940000>; - }; -}; - -&pinctrl_0 { - camera_flash_host: camera-flash-host { - samsung,pins = "gpj1-0"; - samsung,pin-function = <1>; - samsung,pin-val = <0>; - }; - - camera_flash_isp: camera-flash-isp { - samsung,pins = "gpj1-0"; - samsung,pin-function = <1>; - samsung,pin-val = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml new file mode 100644 index 000000000000..52252fb6bb32 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-bcm63138.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom's BCM63138 LEDs controller + +maintainers: + - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> + +description: | + This LEDs controller was first used on BCM63138 and later reused on BCM4908, + BCM6848, BCM6858, BCM63138, BCM63148, BCM63381 and BCM68360 SoCs. + + It supports up to 32 LEDs that can be connected parallelly or serially. It + also includes limited support for hardware blinking. + + Binding serially connected LEDs isn't documented yet. + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,bcm4908-leds + - brcm,bcm6848-leds + - brcm,bcm6858-leds + - brcm,bcm63148-leds + - brcm,bcm63381-leds + - brcm,bcm68360-leds + - const: brcm,bcm63138-leds + - const: brcm,bcm63138-leds + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[a-f0-9]+$": + type: object + + $ref: common.yaml# + + properties: + reg: + maxItems: 1 + description: LED pin number + + active-low: + type: boolean + description: Makes LED active low + + required: + - reg + + unevaluatedProperties: false + +required: + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + leds@ff800800 { + compatible = "brcm,bcm4908-leds", "brcm,bcm63138-leds"; + reg = <0xff800800 0xdc>; + + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0x0>; + function = LED_FUNCTION_POWER; + color = <LED_COLOR_ID_GREEN>; + default-state = "on"; + }; + + led@3 { + reg = <0x3>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_GREEN>; + active-low; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml index f41d021ed677..31840e33dcf5 100644 --- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Common properties for the multicolor LED class. maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | Bindings for multi color LEDs show how to describe current outputs of @@ -19,22 +19,22 @@ description: | LED class. Common LED nodes and properties are inherited from the common.yaml within this documentation directory. -patternProperties: - "^multi-led(@[0-9a-f])?$": - type: object - description: Represents the LEDs that are to be grouped. - properties: - color: - description: | - For multicolor LED support this property should be defined as either - LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in - include/linux/leds/common.h. - enum: [ 8, 9 ] - - $ref: "common.yaml#" - - required: - - color +properties: + $nodename: + pattern: "^multi-led(@[0-9a-f])?$" + + color: + description: | + For multicolor LED support this property should be defined as either + LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in + include/linux/leds/common.h. + enum: [ 8, 9 ] + +required: + - color + +allOf: + - $ref: "common.yaml#" additionalProperties: true diff --git a/Documentation/devicetree/bindings/leds/leds-is31fl319x.txt b/Documentation/devicetree/bindings/leds/leds-is31fl319x.txt deleted file mode 100644 index 676d43ec8169..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-is31fl319x.txt +++ /dev/null @@ -1,61 +0,0 @@ -LEDs connected to is31fl319x LED controller chip - -Required properties: -- compatible : Should be any of - "issi,is31fl3190" - "issi,is31fl3191" - "issi,is31fl3193" - "issi,is31fl3196" - "issi,is31fl3199" - "si-en,sn3199". -- #address-cells: Must be 1. -- #size-cells: Must be 0. -- reg: 0x64, 0x65, 0x66, or 0x67. - -Optional properties: -- audio-gain-db : audio gain selection for external analog modulation input. - Valid values: 0 - 21, step by 3 (rounded down) - Default: 0 -- shutdown-gpios : Specifier of the GPIO connected to SDB pin of the chip. - -Each led is represented as a sub-node of the issi,is31fl319x device. -There can be less leds subnodes than the chip can support but not more. - -Required led sub-node properties: -- reg : number of LED line - Valid values: 1 - number of leds supported by the chip variant. - -Optional led sub-node properties: -- label : see Documentation/devicetree/bindings/leds/common.txt. -- linux,default-trigger : - see Documentation/devicetree/bindings/leds/common.txt. -- led-max-microamp : (optional) - Valid values: 5000 - 40000, step by 5000 (rounded down) - Default: 20000 (20 mA) - Note: a driver will take the lowest of all led limits since the - chip has a single global setting. The lowest value will be chosen - due to the PWM specificity, where lower brightness is achieved - by reducing the dury-cycle of pulses and not the current, which - will always have its peak value equal to led-max-microamp. - -Examples: - -fancy_leds: leds@65 { - compatible = "issi,is31fl3196"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x65>; - shutdown-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; - - red_aux: led@1 { - label = "red:aux"; - reg = <1>; - led-max-microamp = <10000>; - }; - - green_power: led@5 { - label = "green:power"; - reg = <5>; - linux,default-trigger = "default-on"; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml index f12fe5b53f30..63da380748bf 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LED driver for LP50XX RGB LED from Texas Instruments. maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into @@ -56,6 +56,8 @@ patternProperties: '^multi-led@[0-9a-f]$': type: object $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + properties: reg: minItems: 1 @@ -65,8 +67,14 @@ patternProperties: for the child node. The LED modules can either be used stand alone or grouped into a module bank. + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + patternProperties: - "(^led-[0-9a-f]$|led)": + "^led@[0-9a-f]+$": type: object $ref: common.yaml# @@ -78,60 +86,66 @@ additionalProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - #include <dt-bindings/leds/common.h> - - i2c { - #address-cells = <1>; - #size-cells = <0>; - - led-controller@14 { - compatible = "ti,lp5009"; - reg = <0x14>; - #address-cells = <1>; - #size-cells = <0>; - enable-gpios = <&gpio1 16>; - - multi-led@1 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0x1>; - color = <LED_COLOR_ID_RGB>; - function = LED_FUNCTION_CHARGING; - - led-0 { - color = <LED_COLOR_ID_RED>; - }; - - led-1 { - color = <LED_COLOR_ID_GREEN>; - }; - - led-2 { - color = <LED_COLOR_ID_BLUE>; - }; - }; - - multi-led@2 { - #address-cells = <1>; - #size-cells = <2>; - reg = <0x2 0x3 0x5>; - color = <LED_COLOR_ID_RGB>; - function = LED_FUNCTION_STANDBY; + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> - led-6 { - color = <LED_COLOR_ID_RED>; - }; + i2c { + #address-cells = <1>; + #size-cells = <0>; - led-7 { - color = <LED_COLOR_ID_GREEN>; + led-controller@14 { + compatible = "ti,lp5009"; + reg = <0x14>; + #address-cells = <1>; + #size-cells = <0>; + enable-gpios = <&gpio1 16>; + + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0x1>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_CHARGING; + + led@0 { + reg = <0x0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <0x1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <0x2>; + color = <LED_COLOR_ID_BLUE>; + }; }; - led-8 { - color = <LED_COLOR_ID_BLUE>; + multi-led@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0x3>, <0x4>, <0x5>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_STANDBY; + + led@3 { + reg = <0x3>; + color = <LED_COLOR_ID_RED>; + }; + + led@4 { + reg = <0x4>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@5 { + reg = <0x5>; + color = <LED_COLOR_ID_BLUE>; + }; }; - }; - }; + }; }; ... diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml index f552cd143d5b..7ec676e53851 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -108,119 +108,119 @@ additionalProperties: false examples: - | - #include <dt-bindings/leds/common.h> - - i2c { - #address-cells = <1>; - #size-cells = <0>; - - led-controller@32 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "ti,lp8501"; - reg = <0x32>; - clock-mode = /bits/ 8 <2>; - pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ - - led@0 { - reg = <0>; - chan-name = "d1"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@1 { - reg = <1>; - chan-name = "d2"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@2 { - reg = <2>; - chan-name = "d3"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@3 { - reg = <3>; - chan-name = "d4"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@4 { - reg = <4>; - chan-name = "d5"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@5 { - reg = <5>; - chan-name = "d6"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@6 { - reg = <6>; - chan-name = "d7"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@7 { - reg = <7>; - chan-name = "d8"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - led@8 { - reg = <8>; - chan-name = "d9"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@32 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp8501"; + reg = <0x32>; + clock-mode = /bits/ 8 <2>; + pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ + + led@0 { + reg = <0>; + chan-name = "d1"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@1 { + reg = <1>; + chan-name = "d2"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@2 { + reg = <2>; + chan-name = "d3"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@3 { + reg = <3>; + chan-name = "d4"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@4 { + reg = <4>; + chan-name = "d5"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@5 { + reg = <5>; + chan-name = "d6"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@6 { + reg = <6>; + chan-name = "d7"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@7 { + reg = <7>; + chan-name = "d8"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@8 { + reg = <8>; + chan-name = "d9"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; }; - led-controller@33 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "national,lp5523"; - reg = <0x33>; - clock-mode = /bits/ 8 <0>; - - multi-led@2 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0x2>; - color = <LED_COLOR_ID_RGB>; - function = LED_FUNCTION_STANDBY; - linux,default-trigger = "heartbeat"; - - led@0 { - led-cur = /bits/ 8 <50>; - max-cur = /bits/ 8 <100>; - reg = <0x0>; - color = <LED_COLOR_ID_GREEN>; - }; - - led@1 { - led-cur = /bits/ 8 <50>; - max-cur = /bits/ 8 <100>; - reg = <0x1>; - color = <LED_COLOR_ID_BLUE>; - }; - - led@6 { - led-cur = /bits/ 8 <50>; - max-cur = /bits/ 8 <100>; - reg = <0x6>; - color = <LED_COLOR_ID_RED>; - }; + led-controller@33 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "national,lp5523"; + reg = <0x33>; + clock-mode = /bits/ 8 <0>; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0x2>; + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_STANDBY; + linux,default-trigger = "heartbeat"; + + led@0 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x0>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@1 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x1>; + color = <LED_COLOR_ID_BLUE>; + }; + + led@6 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x6>; + color = <LED_COLOR_ID_RED>; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml index 6625a528f727..bd6ec04a8727 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml @@ -19,6 +19,14 @@ properties: multi-led: type: object + $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + + properties: + max-brightness: + description: + Maximum brightness possible for the LED + $ref: /schemas/types.yaml#/definitions/uint32 patternProperties: "^led-[0-9a-z]+$": @@ -33,6 +41,10 @@ properties: pwm-names: true + active-low: + description: For PWMs where the LED is wired to supply rather than ground. + type: boolean + color: true required: @@ -42,9 +54,6 @@ properties: required: - compatible -allOf: - - $ref: leds-class-multicolor.yaml# - additionalProperties: false examples: @@ -55,24 +64,24 @@ examples: 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>; - }; + 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 index 409a4c7298e1..497db289169d 100644 --- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -17,6 +17,7 @@ description: > properties: compatible: enum: + - qcom,pm660l-lpg - qcom,pm8150b-lpg - qcom,pm8150l-lpg - qcom,pm8350c-pwm @@ -58,6 +59,8 @@ properties: multi-led: type: object $ref: leds-class-multicolor.yaml# + unevaluatedProperties: false + properties: "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml new file mode 100644 index 000000000000..a6aaa92dbccd --- /dev/null +++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/skyworks,aat1290.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs + +maintainers: + - Jacek Anaszewski <jacek.anaszewski@gmail.com> + - Krzysztof Kozlowski <krzk@kernel.org> + +description: | + The device is controlled through two pins:: FL_EN and EN_SET. The pins when, + asserted high, enable flash strobe and movie mode (max 1/2 of flash current) + respectively. In order to add a capability of selecting the strobe signal + source (e.g. CPU or camera sensor) there is an additional switch required, + independent of the flash chip. The switch is controlled with pin control. + +properties: + compatible: + const: skyworks,aat1290 + + enset-gpios: + maxItems: 1 + description: EN_SET pin + + flen-gpios: + maxItems: 1 + description: FL_EN pin + + led: + $ref: common.yaml# + unevaluatedProperties: false + + properties: + led-max-microamp: true + + flash-max-microamp: + description: | + Maximum flash LED supply current can be calculated using following + formula:: I = 1A * 162 kOhm / Rset. + + flash-max-timeout-us: + description: | + Maximum flash timeout can be calculated using following formula:: + T = 8.82 * 10^9 * Ct. + + required: + - flash-max-microamp + - flash-max-timeout-us + - led-max-microamp + + pinctrl-names: + items: + - const: default + - const: host + - const: isp + + pinctrl-0: true + pinctrl-1: true + pinctrl-2: true + +required: + - compatible + - enset-gpios + - flen-gpios + - led + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + // Ct = 220 nF, Rset = 160 kOhm + led-controller { + compatible = "skyworks,aat1290"; + flen-gpios = <&gpj1 1 GPIO_ACTIVE_HIGH>; + enset-gpios = <&gpj1 2 GPIO_ACTIVE_HIGH>; + + pinctrl-names = "default", "host", "isp"; + pinctrl-0 = <&camera_flash_host>; + pinctrl-1 = <&camera_flash_host>; + pinctrl-2 = <&camera_flash_isp>; + + led { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + led-max-microamp = <520833>; + flash-max-microamp = <1012500>; + flash-max-timeout-us = <1940000>; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index bd49c201477d..d9a4f4a02d7c 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -57,6 +57,7 @@ properties: maxItems: 1 interrupts: + minItems: 2 items: - description: low-priority non-secure - description: high-priority non-secure diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 7a86e7926dd2..191c1ce15009 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -72,14 +72,16 @@ properties: type : Channel type channel : Channel number - This MU support 4 type of unidirectional channels, each type - has 4 channels. A total of 16 channels. Following types are + This MU support 5 type of unidirectional channels, each type + has 4 channels except RST channel which only has 1 channel. + A total of 17 channels. Following types are supported: 0 - TX channel with 32bit transmit register and IRQ transmit acknowledgment support. 1 - RX channel with 32bit receive register and IRQ support 2 - TX doorbell channel. Without own register and no ACK support. 3 - RX doorbell channel. + 4 - RST channel const: 2 clocks: diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 3b5ba7ecc19d..f504652fc0ea 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -15,26 +15,30 @@ maintainers: properties: compatible: - enum: - - qcom,ipq6018-apcs-apps-global - - qcom,ipq8074-apcs-apps-global - - qcom,msm8916-apcs-kpss-global - - qcom,msm8939-apcs-kpss-global - - qcom,msm8953-apcs-kpss-global - - qcom,msm8976-apcs-kpss-global - - qcom,msm8994-apcs-kpss-global - - qcom,msm8996-apcs-hmss-global - - qcom,msm8998-apcs-hmss-global - - qcom,qcm2290-apcs-hmss-global - - qcom,qcs404-apcs-apps-global - - qcom,sc7180-apss-shared - - qcom,sc8180x-apss-shared - - qcom,sdm660-apcs-hmss-global - - qcom,sdm845-apss-shared - - qcom,sm6125-apcs-hmss-global - - qcom,sm6115-apcs-hmss-global - - qcom,sm8150-apss-shared - + oneOf: + - items: + - enum: + - qcom,ipq6018-apcs-apps-global + - qcom,ipq8074-apcs-apps-global + - qcom,msm8976-apcs-kpss-global + - qcom,msm8996-apcs-hmss-global + - qcom,msm8998-apcs-hmss-global + - qcom,qcm2290-apcs-hmss-global + - qcom,sc7180-apss-shared + - qcom,sc8180x-apss-shared + - qcom,sdm660-apcs-hmss-global + - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global + - qcom,sm6115-apcs-hmss-global + - qcom,sm8150-apss-shared + - items: + - enum: + - qcom,msm8916-apcs-kpss-global + - qcom,msm8939-apcs-kpss-global + - qcom,msm8953-apcs-kpss-global + - qcom,msm8994-apcs-kpss-global + - qcom,qcs404-apcs-apps-global + - const: syscon reg: maxItems: 1 @@ -121,7 +125,7 @@ examples: #define GCC_APSS_AHB_CLK_SRC 1 #define GCC_GPLL0_AO_OUT_MAIN 123 apcs: mailbox@b011000 { - compatible = "qcom,qcs404-apcs-apps-global"; + compatible = "qcom,qcs404-apcs-apps-global", "syscon"; reg = <0x0b011000 0x1000>; #mbox-cells = <1>; clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>; diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index 1994be858940..baca4786ff94 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -25,6 +25,7 @@ properties: items: - enum: - qcom,sm6350-ipcc + - qcom,sm6375-ipcc - qcom,sm8250-ipcc - qcom,sm8350-ipcc - qcom,sm8450-ipcc diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml index 8b568072a069..8551c4a711dc 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml @@ -42,6 +42,7 @@ properties: port: $ref: /schemas/graph.yaml#/$defs/port-base + description: Parallel input port, connect to a parallel sensor properties: endpoint: @@ -59,7 +60,24 @@ properties: required: - bus-width - additionalProperties: false + unevaluatedProperties: false + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: "#/properties/port" + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: MIPI CSI-2 bridge input port + + anyOf: + - required: + - port@0 + - required: + - port@1 required: - compatible @@ -69,6 +87,12 @@ required: - clock-names - resets +oneOf: + - required: + - ports + - required: + - port + additionalProperties: false examples: @@ -89,19 +113,25 @@ examples: "ram"; resets = <&ccu RST_BUS_CSI>; - port { - /* Parallel bus endpoint */ - csi1_ep: endpoint { - remote-endpoint = <&adv7611_ep>; - bus-width = <16>; - - /* - * If hsync-active/vsync-active are missing, - * embedded BT.656 sync is used. - */ - hsync-active = <0>; /* Active low */ - vsync-active = <0>; /* Active low */ - pclk-sample = <1>; /* Rising */ + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + /* Parallel bus endpoint */ + csi1_ep: endpoint { + remote-endpoint = <&adv7611_ep>; + bus-width = <16>; + + /* + * If hsync-active/vsync-active are missing, + * embedded BT.656 sync is used. + */ + hsync-active = <0>; /* Active low */ + vsync-active = <0>; /* Active low */ + pclk-sample = <1>; /* Rising */ + }; }; }; }; diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml new file mode 100644 index 000000000000..09725ca955f6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A31 MIPI CSI-2 Device Tree Bindings + +maintainers: + - Paul Kocialkowski <paul.kocialkowski@bootlin.com> + +properties: + compatible: + oneOf: + - const: allwinner,sun6i-a31-mipi-csi2 + - items: + - const: allwinner,sun8i-v3s-mipi-csi2 + - const: allwinner,sun6i-a31-mipi-csi2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: bus + - const: mod + + phys: + maxItems: 1 + description: MIPI D-PHY + + phy-names: + items: + - const: dphy + + resets: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + description: Input port, connect to a MIPI CSI-2 sensor + + properties: + reg: + const: 0 + + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + unevaluatedProperties: false + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output port, connect to a CSI controller + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - resets + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/sun8i-v3s-ccu.h> + #include <dt-bindings/reset/sun8i-v3s-ccu.h> + + mipi_csi2: csi@1cb1000 { + compatible = "allwinner,sun8i-v3s-mipi-csi2", + "allwinner,sun6i-a31-mipi-csi2"; + reg = <0x01cb1000 0x1000>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_CSI>, + <&ccu CLK_CSI1_SCLK>; + clock-names = "bus", "mod"; + resets = <&ccu RST_BUS_CSI>; + + phys = <&dphy>; + phy-names = "dphy"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + mipi_csi2_in: port@0 { + reg = <0>; + + mipi_csi2_in_ov5648: endpoint { + data-lanes = <1 2 3 4>; + + remote-endpoint = <&ov5648_out_mipi_csi2>; + }; + }; + + mipi_csi2_out: port@1 { + reg = <1>; + + mipi_csi2_out_csi0: endpoint { + remote-endpoint = <&csi0_in_mipi_csi2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml new file mode 100644 index 000000000000..5b27482b5687 --- /dev/null +++ b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml @@ -0,0 +1,125 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A83T MIPI CSI-2 Device Tree Bindings + +maintainers: + - Paul Kocialkowski <paul.kocialkowski@bootlin.com> + +properties: + compatible: + const: allwinner,sun8i-a83t-mipi-csi2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + - description: MIPI-specific Clock + - description: Misc CSI Clock + + clock-names: + items: + - const: bus + - const: mod + - const: mipi + - const: misc + + resets: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + description: Input port, connect to a MIPI CSI-2 sensor + + properties: + reg: + const: 0 + + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + unevaluatedProperties: false + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output port, connect to a CSI controller + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/sun8i-a83t-ccu.h> + #include <dt-bindings/reset/sun8i-a83t-ccu.h> + + mipi_csi2: csi@1cb1000 { + compatible = "allwinner,sun8i-a83t-mipi-csi2"; + reg = <0x01cb1000 0x1000>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_CSI>, + <&ccu CLK_CSI_SCLK>, + <&ccu CLK_MIPI_CSI>, + <&ccu CLK_CSI_MISC>; + clock-names = "bus", "mod", "mipi", "misc"; + resets = <&ccu RST_BUS_CSI>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + mipi_csi2_in: port@0 { + reg = <0>; + + mipi_csi2_in_ov8865: endpoint { + data-lanes = <1 2 3 4>; + + remote-endpoint = <&ov8865_out_mipi_csi2>; + }; + }; + + mipi_csi2_out: port@1 { + reg = <1>; + + mipi_csi2_out_csi: endpoint { + remote-endpoint = <&csi_in_mipi_csi2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt deleted file mode 100644 index ce9a22689e53..000000000000 --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt +++ /dev/null @@ -1,16 +0,0 @@ -Samsung S5P/Exynos SoC series JPEG codec - -Required properties: - -- compatible : should be one of: - "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg", - "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg", - "samsung,exynos5433-jpeg"; -- reg : address and length of the JPEG codec IP register set; -- interrupts : specifies the JPEG codec IP interrupt; -- clock-names : should contain: - - "jpeg" for the core gate clock, - - "sclk" for the special clock (optional). -- clocks : should contain the clock specifier and clock ID list - matching entries in the clock-names property; from - the common clock bindings. diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt deleted file mode 100644 index 108bf435b933..000000000000 --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt +++ /dev/null @@ -1,20 +0,0 @@ -Device-Tree bindings for GPIO IR receiver - -Required properties: - - compatible: should be "gpio-ir-receiver". - - gpios: specifies GPIO used for IR signal reception. - -Optional properties: - - linux,rc-map-name: see rc.txt file in the same - directory. - - linux,autosuspend-period: autosuspend delay time, - the unit is milisecond. - -Example node: - - ir: ir-receiver { - compatible = "gpio-ir-receiver"; - gpios = <&gpio0 19 1>; - linux,rc-map-name = "rc-rc6-mce"; - linux,autosuspend-period = <125>; - }; diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml new file mode 100644 index 000000000000..61072745b983 --- /dev/null +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/gpio-ir-receiver.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO Based IR receiver + +maintainers: + - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> + +allOf: + - $ref: rc.yaml# + +properties: + compatible: + const: gpio-ir-receiver + + gpios: + maxItems: 1 + + linux,autosuspend-period: + description: autosuspend delay time in milliseconds + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - gpios + +unevaluatedProperties: false + +examples: + - | + ir-receiver { + compatible = "gpio-ir-receiver"; + gpios = <&gpio0 19 1>; + linux,rc-map-name = "rc-rc6-mce"; + linux,autosuspend-period = <125>; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml index c2ba78116dbb..1d6af1bf9a6b 100644 --- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml @@ -17,6 +17,7 @@ description: | properties: compatible: enum: + - aptina,mt9p006 - aptina,mt9p031 - aptina,mt9p031m diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file mode 100644 index 000000000000..b617cc5c6a9f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/onnn,ar0521.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ON Semiconductor AR0521 MIPI CSI-2 sensor + +maintainers: + - Krzysztof HaÅ‚asa <khalasa@piap.pl> + +description: |- + The AR0521 is a raw CMOS image sensor with MIPI CSI-2 and + I2C-compatible control interface. + +properties: + compatible: + const: onnn,ar0521 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: extclk + + vaa-supply: + description: + Definition of the regulator used as analog (2.7 V) voltage supply. + + vdd-supply: + description: + Definition of the regulator used as digital core (1.2 V) voltage supply. + + vdd_io-supply: + description: + Definition of the regulator used as digital I/O (1.8 V) voltage supply. + + reset-gpios: + description: reset GPIO, usually active low + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: | + Video output port. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + bus-type: + const: 4 + data-lanes: + anyOf: + - items: + - const: 1 + - items: + - const: 1 + - const: 2 + - items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + +required: + - compatible + - reg + - clocks + - clock-names + - vaa-supply + - vdd-supply + - vdd_io-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ar0521: camera-sensor@36 { + compatible = "onnn,ar0521"; + reg = <0x36>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mipi_camera>; + clocks = <&clks IMX6QDL_CLK_CKO>; + clock-names = "extclk"; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + vaa-supply = <®_2p7v>; + vdd-supply = <®_1p2v>; + vdd_io-supply = <®_1p8v>; + + port { + mipi_camera_to_mipi_csi2: endpoint { + remote-endpoint = <&mipi_csi2_in>; + data-lanes = <1 2 3 4>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml new file mode 100644 index 000000000000..359dc08440a8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2022 Amarulasolutions +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov5693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Omnivision OV5693 CMOS Sensor + +maintainers: + - Tommaso Merciai <tommaso.merciai@amarulasolutions.com> + +description: | + The Omnivision OV5693 is a high performance, 1/4-inch, 5 megapixel, CMOS + image sensor that delivers 2592x1944 at 30fps. It provides full-frame, + sub-sampled, and windowed 10-bit MIPI images in various formats via the + Serial Camera Control Bus (SCCB) interface. + + OV5693 is controlled via I2C and two-wire Serial Camera Control Bus (SCCB). + The sensor output is available via CSI-2 serial data output (up to 2-lane). + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: ovti,ov5693 + + reg: + maxItems: 1 + + clocks: + description: + System input clock (aka XVCLK). From 6 to 27 MHz. + maxItems: 1 + + dovdd-supply: + description: + Digital I/O voltage supply, 1.8V. + + avdd-supply: + description: + Analog voltage supply, 2.8V. + + dvdd-supply: + description: + Digital core voltage supply, 1.2V. + + reset-gpios: + description: + The phandle and specifier for the GPIO that controls sensor reset. + This corresponds to the hardware pin XSHUTDN which is physically + active low. + maxItems: 1 + + port: + description: MIPI CSI-2 transmitter port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + link-frequencies: true + + data-lanes: + minItems: 1 + maxItems: 2 + + required: + - data-lanes + - link-frequencies + +required: + - compatible + - reg + - clocks + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/pinctrl/rockchip.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov5693: camera@36 { + compatible = "ovti,ov5693"; + reg = <0x36>; + + reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&cif_clkout_m0>; + + clocks = <&cru SCLK_CIF_OUT>; + assigned-clocks = <&cru SCLK_CIF_OUT>; + assigned-clock-rates = <19200000>; + + avdd-supply = <&vcc_1v8>; + dvdd-supply = <&vcc_1v2>; + dovdd-supply = <&vcc_2v8>; + + rotation = <90>; + orientation = <0>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <450000000>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index 440646e44c0d..d4e2051beeb6 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -17,20 +17,20 @@ description: | About the Decoder Hardware Block Diagram, please check below: - +---------------------------------+------------------------------------+ - | | | - | input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | - | || | || | - +------------||-------------------+---------------------||-------------+ - lat workqueue | core workqueue <parent> - -------------||-----------------------------------------||------------------ - || || <child> - \/ <----------------HW index-------------->\/ - +------------------------------------------------------+ - | enable/disable | - | clk power irq iommu | - | (lat/lat soc/core0/core1) | - +------------------------------------------------------+ + +------------------------------------------------+-------------------------------------+ + | | | + | input -> lat soc HW -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | + | || || | || | + +------------||-------------||-------------------+---------------------||--------------+ + || lat || | core workqueue <parent> + -------------||-------------||-------------------|---------------------||--------------- + ||<------------||----------------HW index---------------->|| <child> + \/ \/ \/ + +-------------------------------------------------------------+ + | enable/disable | + | clk power irq iommu | + | (lat/lat soc/core0/core1) | + +-------------------------------------------------------------+ As above, there are parent and child devices, child mean each hardware. The child device controls the information of each hardware independent which include clk/power/irq. @@ -45,11 +45,19 @@ description: | For the smi common may not the same for each hardware, can't combine all hardware in one node, or leading to iommu fault when access dram data. + Lat soc is a hardware which is related with some larb(local arbiter) ports. For mt8195 + platform, there are some ports like RDMA, UFO in lat soc larb, need to enable its power and + clock when lat start to work, don't have interrupt. + + mt8195: lat soc HW + lat HW + core HW + mt8192: lat HW + core HW + properties: compatible: enum: - mediatek,mt8192-vcodec-dec - mediatek,mt8186-vcodec-dec + - mediatek,mt8195-vcodec-dec reg: maxItems: 1 @@ -87,7 +95,9 @@ patternProperties: properties: compatible: - const: mediatek,mtk-vcodec-lat + enum: + - mediatek,mtk-vcodec-lat + - mediatek,mtk-vcodec-lat-soc reg: maxItems: 1 @@ -125,7 +135,6 @@ patternProperties: required: - compatible - reg - - interrupts - iommus - clocks - clock-names @@ -196,6 +205,17 @@ required: - dma-ranges - ranges +if: + properties: + compatible: + contains: + enum: + - mediatek,mtk-vcodec-lat + +then: + required: + - interrupts + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml index 8bfdfdfaba59..4fd390c042a9 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -18,6 +18,7 @@ properties: - enum: - mediatek,mt2701-jpgenc - mediatek,mt8183-jpgenc + - mediatek,mt8186-jpgenc - const: mediatek,mtk-jpgenc reg: maxItems: 1 @@ -42,6 +43,11 @@ properties: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. Ports are according to the HW. + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml index 36b135bf9f2a..03a23a26c4f3 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml @@ -22,9 +22,14 @@ description: |- properties: compatible: - enum: - - fsl,imx7-mipi-csi2 - - fsl,imx8mm-mipi-csi2 + oneOf: + - enum: + - fsl,imx7-mipi-csi2 + - fsl,imx8mm-mipi-csi2 + - items: + - enum: + - fsl,imx8mp-mipi-csi2 + - const: fsl,imx8mm-mipi-csi2 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index 338ab28d5f3b..b28c8e17f158 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -84,6 +84,13 @@ properties: - const: vfe0 - const: vfe1 + interconnects: + maxItems: 1 + + interconnect-names: + items: + - const: vfe-mem + iommus: maxItems: 4 diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index d4c541c4b164..b11d14ab89c4 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -12,7 +12,7 @@ maintainers: properties: $nodename: - pattern: "^ir(@[a-f0-9]+)?$" + pattern: "^ir(-receiver)?(@[a-f0-9]+)?$" linux,rc-map-name: description: diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml new file mode 100644 index 000000000000..81b26eb4cd35 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Hantro G1 VPU encoders implemented on Rockchip SoCs + +maintainers: + - Nicolas Frattaroli <frattaroli.nicolas@gmail.com> + +description: + Hantro G1 video encode-only accelerators present on Rockchip SoCs. + +properties: + compatible: + enum: + - rockchip,rk3568-vepu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: aclk + - const: hclk + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3568-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/rk3568-power.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + + vepu: video-codec@fdee0000 { + compatible = "rockchip,rk3568-vepu"; + reg = <0x0 0xfdee0000 0x0 0x800>; + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_JENC>, <&cru HCLK_JENC>; + clock-names = "aclk", "hclk"; + iommus = <&vepu_mmu>; + power-domains = <&power RK3568_PD_RGA>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml index d1489b177331..b3661d7d4357 100644 --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml @@ -84,8 +84,27 @@ properties: minItems: 1 maxItems: 4 - required: - - port@0 + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: connection point for input on the parallel interface + + properties: + bus-type: + enum: [5, 6] + + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + required: + - bus-type + + anyOf: + - required: + - port@0 + - required: + - port@1 required: - compatible diff --git a/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml b/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml new file mode 100644 index 000000000000..e28d6ec56c0b --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,s5pv210-jpeg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5PV210 and Exynos SoC JPEG codec + +maintainers: + - Jacek Anaszewski <jacek.anaszewski@gmail.com> + - Krzysztof Kozlowski <krzk@kernel.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Andrzej Pietrasiewicz <andrzejtp2010@gmail.com> + +properties: + compatible: + enum: + - samsung,s5pv210-jpeg + - samsung,exynos3250-jpeg + - samsung,exynos4210-jpeg + - samsung,exynos4212-jpeg + - samsung,exynos5420-jpeg + - samsung,exynos5433-jpeg + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-jpeg + - samsung,exynos4210-jpeg + - samsung,exynos4212-jpeg + - samsung,exynos5420-jpeg + then: + properties: + clocks: + maxItems: 1 + clock-names: + items: + - const: jpeg + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos3250-jpeg + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: jpeg + - const: sclk + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5433-jpeg + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: pclk + - const: aclk + - const: aclk_xiu + - const: sclk + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + codec@15020000 { + compatible = "samsung,exynos5433-jpeg"; + reg = <0x15020000 0x10000>; + interrupts = <GIC_SPI 411 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "pclk", "aclk", "aclk_xiu", "sclk"; + clocks = <&cmu_mscl CLK_PCLK_JPEG>, + <&cmu_mscl CLK_ACLK_JPEG>, + <&cmu_mscl CLK_ACLK_XIU_MSCLX>, + <&cmu_mscl CLK_SCLK_JPEG>; + iommus = <&sysmmu_jpeg>; + power-domains = <&pd_mscl>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml new file mode 100644 index 000000000000..f81fb866e319 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/canaan,k210-sram.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Canaan K210 SRAM memory controller + +description: + The Canaan K210 SRAM memory controller is responsible for the system's 8 MiB + of SRAM. The controller is initialised by the bootloader, which configures + its clocks, before OS bringup. + +maintainers: + - Conor Dooley <conor@kernel.org> + +properties: + compatible: + enum: + - canaan,k210-sram + + clocks: + minItems: 1 + items: + - description: sram0 clock + - description: sram1 clock + - description: aisram clock + + clock-names: + minItems: 1 + items: + - const: sram0 + - const: sram1 + - const: aisram + +required: + - compatible + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/k210-clk.h> + memory-controller { + compatible = "canaan,k210-sram"; + clocks = <&sysclk K210_CLK_SRAM0>, + <&sysclk K210_CLK_SRAM1>, + <&sysclk K210_CLK_AI>; + clock-names = "sram0", "sram1", "aisram"; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a98b359bf909..71bc5cefb49c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -32,6 +32,7 @@ properties: - mediatek,mt2701-smi-common - mediatek,mt2712-smi-common - mediatek,mt6779-smi-common + - mediatek,mt6795-smi-common - mediatek,mt8167-smi-common - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index c886681f62a7..59dcd163668f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -20,6 +20,7 @@ properties: - mediatek,mt2701-smi-larb - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb + - mediatek,mt6795-smi-larb - mediatek,mt8167-smi-larb - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt b/Documentation/devicetree/bindings/mfd/da9063.txt deleted file mode 100644 index aa8b800cc4ad..000000000000 --- a/Documentation/devicetree/bindings/mfd/da9063.txt +++ /dev/null @@ -1,114 +0,0 @@ -* Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC) - -DA9063 consists of a large and varied group of sub-devices (I2C Only): - -Device Supply Names Description ------- ------------ ----------- -da9063-regulator : : LDOs & BUCKs -da9063-onkey : : On Key -da9063-rtc : : Real-Time Clock (DA9063 only) -da9063-watchdog : : Watchdog - -====== - -Required properties: - -- compatible : Should be "dlg,da9063" or "dlg,da9063l" -- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be - modified to match the chip's OTP settings). -- interrupts : IRQ line information. -- interrupt-controller - -Sub-nodes: - -- regulators : This node defines the settings for the LDOs and BUCKs. - The DA9063(L) regulators are bound using their names listed below: - - bcore1 : BUCK CORE1 - bcore2 : BUCK CORE2 - bpro : BUCK PRO - bmem : BUCK MEM - bio : BUCK IO - bperi : BUCK PERI - ldo1 : LDO_1 (DA9063 only) - ldo2 : LDO_2 (DA9063 only) - ldo3 : LDO_3 - ldo4 : LDO_4 (DA9063 only) - ldo5 : LDO_5 (DA9063 only) - ldo6 : LDO_6 (DA9063 only) - ldo7 : LDO_7 - ldo8 : LDO_8 - ldo9 : LDO_9 - ldo10 : LDO_10 (DA9063 only) - ldo11 : LDO_11 - - The component follows the standard regulator framework and the bindings - details of individual regulator device can be found in: - Documentation/devicetree/bindings/regulator/regulator.txt - -- rtc : This node defines settings for the Real-Time Clock associated with - the DA9063 only. The RTC is not present in DA9063L. There are currently - no entries in this binding, however compatible = "dlg,da9063-rtc" should - be added if a node is created. - -- onkey : This node defines the OnKey settings for controlling the key - functionality of the device. The node should contain the compatible property - with the value "dlg,da9063-onkey". - - Optional onkey properties: - - - dlg,disable-key-power : Disable power-down using a long key-press. If this - entry exists the OnKey driver will remove support for the KEY_POWER key - press. If this entry does not exist then by default the key-press - triggered power down is enabled and the OnKey will support both KEY_POWER - and KEY_SLEEP. - -- watchdog : This node defines settings for the Watchdog timer associated - 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: - - pmic0: da9063@58 { - compatible = "dlg,da9063" - reg = <0x58>; - interrupt-parent = <&gpio6>; - interrupts = <11 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - - rtc { - compatible = "dlg,da9063-rtc"; - }; - - wdt { - compatible = "dlg,da9063-watchdog"; - }; - - onkey { - compatible = "dlg,da9063-onkey"; - dlg,disable-key-power; - }; - - regulators { - DA9063_BCORE1: bcore1 { - regulator-name = "BCORE1"; - regulator-min-microvolt = <300000>; - regulator-max-microvolt = <1570000>; - regulator-min-microamp = <500000>; - regulator-max-microamp = <2000000>; - regulator-boot-on; - }; - DA9063_LDO11: ldo11 { - regulator-name = "LDO_11"; - regulator-min-microvolt = <900000>; - regulator-max-microvolt = <3600000>; - regulator-boot-on; - }; - }; - }; - diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml new file mode 100644 index 000000000000..d71933460e90 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/dlg,da9063.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC) + +maintainers: + - Steve Twiss <stwiss.opensource@diasemi.com> + +description: | + For device-tree bindings of other sub-modules refer to the binding documents + under the respective sub-system directories. + +properties: + compatible: + enum: + - dlg,da9063 + - dlg,da9063l + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + dlg,use-sw-pm: + type: boolean + description: + 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). + + watchdog: + type: object + $ref: /schemas/watchdog/watchdog.yaml# + unevaluatedProperties: false + properties: + compatible: + const: dlg,da9063-watchdog + + rtc: + type: object + $ref: /schemas/rtc/rtc.yaml# + unevaluatedProperties: false + properties: + compatible: + const: dlg,da9063-rtc + + onkey: + type: object + $ref: /schemas/input/input.yaml# + unevaluatedProperties: false + properties: + compatible: + const: dlg,da9063-onkey + + dlg,disable-key-power: + type: boolean + description: | + Disable power-down using a long key-press. + If this entry does not exist then by default the key-press triggered + power down is enabled and the OnKey will support both KEY_POWER and + KEY_SLEEP. + + regulators: + type: object + patternProperties: + "^(ldo[1-11]|bcore[1-2]|bpro|bmem|bio|bperi)$": + $ref: /schemas/regulator/regulator.yaml + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + pmic@58 { + compatible = "dlg,da9063"; + reg = <0x58>; + #interrupt-cells = <2>; + interrupt-parent = <&gpio6>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + + rtc { + compatible = "dlg,da9063-rtc"; + }; + + watchdog { + compatible = "dlg,da9063-watchdog"; + }; + + onkey { + compatible = "dlg,da9063-onkey"; + dlg,disable-key-power; + }; + + regulators { + regulator-bcore1 { + regulator-name = "BCORE1"; + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <500000>; + regulator-max-microamp = <2000000>; + regulator-boot-on; + }; + regulator-ldo11 { + regulator-name = "LDO_11"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <3600000>; + regulator-boot-on; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml new file mode 100644 index 000000000000..f09577105b50 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml @@ -0,0 +1,192 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/fsl,imx8qxp-csr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings + +maintainers: + - Liu Ying <victor.liu@nxp.com> + +description: | + As a system controller, the Freescale i.MX8qm/qxp Control and Status + Registers(CSR) module represents a set of miscellaneous registers of a + specific subsystem. It may provide control and/or status report interfaces + to a mix of standalone hardware devices within that subsystem. One typical + use-case is for some other nodes to acquire a reference to the syscon node + by phandle, and the other typical use-case is that the operating system + should consider all subnodes of the CSR module as separate child devices. + +properties: + $nodename: + pattern: "^syscon@[0-9a-f]+$" + + compatible: + items: + - enum: + - fsl,imx8qxp-mipi-lvds-csr + - fsl,imx8qm-lvds-csr + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ipg + +patternProperties: + "^(ldb|phy|pxl2dpi)$": + type: object + description: The possible child devices of the CSR module. + +required: + - compatible + - reg + - clocks + - clock-names + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx8qxp-mipi-lvds-csr + then: + required: + - pxl2dpi + - ldb + + - if: + properties: + compatible: + contains: + const: fsl,imx8qm-lvds-csr + then: + required: + - phy + - ldb + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8-lpcg.h> + #include <dt-bindings/firmware/imx/rsrc.h> + mipi_lvds_0_csr: syscon@56221000 { + compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd"; + reg = <0x56221000 0x1000>; + clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>; + clock-names = "ipg"; + + mipi_lvds_0_pxl2dpi: pxl2dpi { + compatible = "fsl,imx8qxp-pxl2dpi"; + fsl,sc-resource = <IMX_SC_R_MIPI_0>; + power-domains = <&pd IMX_SC_R_MIPI_0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 { + reg = <0>; + remote-endpoint = <&dc0_pixel_link0_mipi_lvds_0_pxl2dpi>; + }; + + mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 { + reg = <1>; + remote-endpoint = <&dc0_pixel_link1_mipi_lvds_0_pxl2dpi>; + }; + }; + + port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 { + reg = <0>; + remote-endpoint = <&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>; + }; + + mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 { + reg = <1>; + remote-endpoint = <&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>; + }; + }; + }; + }; + + mipi_lvds_0_ldb: ldb { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx8qxp-ldb"; + clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>, + <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>; + clock-names = "pixel", "bypass"; + power-domains = <&pd IMX_SC_R_LVDS_0>; + + channel@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + phys = <&mipi_lvds_0_phy>; + phy-names = "lvds_phy"; + + port@0 { + reg = <0>; + + mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint { + remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0>; + }; + }; + + port@1 { + reg = <1>; + + /* ... */ + }; + }; + + channel@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + phys = <&mipi_lvds_0_phy>; + phy-names = "lvds_phy"; + + port@0 { + reg = <0>; + + mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi: endpoint { + remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1>; + }; + }; + + port@1 { + reg = <1>; + + /* ... */ + }; + }; + }; + }; + + mipi_lvds_0_phy: phy@56228300 { + compatible = "fsl,imx8qxp-mipi-dphy"; + reg = <0x56228300 0x100>; + clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_PHY>; + clock-names = "phy_ref"; + #phy-cells = <0>; + fsl,syscon = <&mipi_lvds_0_csr>; + power-domains = <&pd IMX_SC_R_MIPI_0>; + }; diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml index 5a1e8d21f7a0..5e0fe3ebe1d2 100644 --- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml @@ -19,7 +19,6 @@ description: | maintainers: - Tim Harvey <tharvey@gateworks.com> - - Robert Jones <rjones@gateworks.com> properties: $nodename: diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index e25caf8ef9f4..04962bb29576 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -90,6 +90,9 @@ properties: pwm: $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" + kbd-led-backlight: + $ref: "/schemas/chrome/google,cros-kbd-led-backlight.yaml#" + keyboard-controller: $ref: "/schemas/input/google,cros-ec-keyb.yaml#" diff --git a/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml b/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml index f91acc42d652..5ba849d78d8a 100644 --- a/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml +++ b/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml @@ -18,7 +18,9 @@ description: | properties: compatible: - const: mps,mp2629 + enum: + - mps,mp2629 + - mps,mp2733 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 293db2a71ef2..0088442efca1 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -20,6 +20,7 @@ This document describes the binding for MFD device and its sub module. Required properties: compatible: "mediatek,mt6323" for PMIC MT6323 + "mediatek,mt6331" for PMIC MT6331 and MT6332 "mediatek,mt6358" for PMIC MT6358 and MT6366 "mediatek,mt6359" for PMIC MT6359 "mediatek,mt6397" for PMIC MT6397 @@ -29,6 +30,7 @@ Optional subnodes: - rtc Required properties: Should be one of follows - compatible: "mediatek,mt6323-rtc" + - compatible: "mediatek,mt6331-rtc" - compatible: "mediatek,mt6358-rtc" - compatible: "mediatek,mt6397-rtc" For details, see ../rtc/rtc-mt6397.txt @@ -52,8 +54,10 @@ Optional subnodes: see ../leds/leds-mt6323.txt - keys - Required properties: - - compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys" + Required properties: Should be one of the following + - compatible: "mediatek,mt6323-keys" + - compatible: "mediatek,mt6331-keys" + - compatible: "mediatek,mt6397-keys" see ../input/mtk-pmic-keys.txt - power-controller diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt deleted file mode 100644 index eb78e3ae7703..000000000000 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ /dev/null @@ -1,94 +0,0 @@ - Qualcomm SPMI PMICs multi-function device bindings - -The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084 -PMICs. These PMICs use a QPNP scheme through SPMI interface. -QPNP is effectively a partitioning scheme for dividing the SPMI extended -register space up into logical pieces, and set of fixed register -locations/definitions within these regions, with some of these regions -specifically used for interrupt handling. - -The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are -interfaced to the chip via the SPMI (System Power Management Interface) bus. -Support for multiple independent functions are implemented by splitting the -16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes -each. A function can consume one or more of these fixed-size register regions. - -Required properties: -- compatible: Should contain one of: - "qcom,pm660", - "qcom,pm660l", - "qcom,pm7325", - "qcom,pm8004", - "qcom,pm8005", - "qcom,pm8019", - "qcom,pm8028", - "qcom,pm8110", - "qcom,pm8150", - "qcom,pm8150b", - "qcom,pm8150c", - "qcom,pm8150l", - "qcom,pm8226", - "qcom,pm8350c", - "qcom,pm8841", - "qcom,pm8901", - "qcom,pm8909", - "qcom,pm8916", - "qcom,pm8941", - "qcom,pm8950", - "qcom,pm8953", - "qcom,pm8994", - "qcom,pm8998", - "qcom,pma8084", - "qcom,pmd9635", - "qcom,pmi8950", - "qcom,pmi8962", - "qcom,pmi8994", - "qcom,pmi8998", - "qcom,pmk8002", - "qcom,pmk8350", - "qcom,pmr735a", - "qcom,smb2351", - or generalized "qcom,spmi-pmic". -- reg: Specifies the SPMI USID slave address for this device. - For more information see: - Documentation/devicetree/bindings/spmi/spmi.yaml - -Required properties for peripheral child nodes: -- compatible: Should contain "qcom,xxx", where "xxx" is a peripheral name. - -Optional properties for peripheral child nodes: -- interrupts: Interrupts are specified as a 4-tuple. For more information - see: - Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml -- interrupt-names: Corresponding interrupt name to the interrupts property - -Each child node of SPMI slave id represents a function of the PMIC. In the -example below the rtc device node represents a peripheral of pm8941 -SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1. - -Example: - - spmi { - compatible = "qcom,spmi-pmic-arb"; - - pm8941@0 { - compatible = "qcom,pm8941", "qcom,spmi-pmic"; - reg = <0x0 SPMI_USID>; - - rtc { - compatible = "qcom,rtc"; - interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "alarm"; - }; - }; - - pm8941@1 { - compatible = "qcom,pm8941", "qcom,spmi-pmic"; - reg = <0x1 SPMI_USID>; - - regulator { - compatible = "qcom,regulator"; - regulator-name = "8941_boost"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml new file mode 100644 index 000000000000..65cbc6dee545 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -0,0 +1,190 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SPMI PMICs multi-function device + +description: | + Some Qualcomm PMICs used with the Snapdragon series SoCs are interfaced + to the chip via the SPMI (System Power Management Interface) bus. + Support for multiple independent functions are implemented by splitting the + 16-bit SPMI peripheral address space into 256 smaller fixed-size regions, 256 bytes + each. A function can consume one or more of these fixed-size register regions. + + The Qualcomm SPMI series includes the PM8941, PM8841, PMA8084, PM8998 and other + PMICs. These PMICs use a "QPNP" scheme through SPMI interface. + QPNP is effectively a partitioning scheme for dividing the SPMI extended + register space up into logical pieces, and set of fixed register + locations/definitions within these regions, with some of these regions + specifically used for interrupt handling. + +maintainers: + - Stephen Boyd <sboyd@kernel.org> + +properties: + $nodename: + oneOf: + - pattern: '^pmic@.*$' + - pattern: '^pm(a|s)?[0-9]*@.*$' + deprecated: true + + compatible: + items: + - enum: + - qcom,pm660 + - qcom,pm660l + - qcom,pm6150 + - qcom,pm6150l + - qcom,pm6350 + - qcom,pm7325 + - qcom,pm8004 + - qcom,pm8005 + - qcom,pm8009 + - qcom,pm8019 + - qcom,pm8110 + - qcom,pm8150 + - qcom,pm8150b + - qcom,pm8150l + - qcom,pm8226 + - qcom,pm8350 + - qcom,pm8350b + - qcom,pm8350c + - qcom,pm8841 + - qcom,pm8909 + - qcom,pm8916 + - qcom,pm8941 + - qcom,pm8950 + - qcom,pm8994 + - qcom,pm8998 + - qcom,pma8084 + - qcom,pmd9635 + - qcom,pmi8950 + - qcom,pmi8962 + - qcom,pmi8994 + - qcom,pmi8998 + - qcom,pmk8350 + - qcom,pmm8155au + - qcom,pmr735a + - qcom,pmr735b + - qcom,pms405 + - qcom,pmx55 + - qcom,pmx65 + - qcom,smb2351 + - const: qcom,spmi-pmic + + reg: + minItems: 1 + maxItems: 2 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + labibb: + type: object + $ref: /schemas/regulator/qcom-labibb-regulator.yaml# + + regulators: + type: object + $ref: /schemas/regulator/regulator.yaml# + +patternProperties: + "^adc@[0-9a-f]+$": + type: object + $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml# + + "^adc-tm@[0-9a-f]+$": + type: object + $ref: /schemas/thermal/qcom-spmi-adc-tm5.yaml# + + "^audio-codec@[0-9a-f]+$": + type: object + additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet + + "extcon@[0-9a-f]+$": + type: object + $ref: /schemas/extcon/qcom,pm8941-misc.yaml# + + "gpio(s)?@[0-9a-f]+$": + type: object + $ref: /schemas/pinctrl/qcom,pmic-gpio.yaml# + + "pon@[0-9a-f]+$": + type: object + $ref: /schemas/power/reset/qcom,pon.yaml# + + "pwm@[0-9a-f]+$": + type: object + $ref: /schemas/leds/leds-qcom-lpg.yaml# + + "^rtc@[0-9a-f]+$": + type: object + $ref: /schemas/rtc/qcom-pm8xxx-rtc.yaml# + + "^temp-alarm@[0-9a-f]+$": + type: object + $ref: /schemas/thermal/qcom,spmi-temp-alarm.yaml# + + "^vibrator@[0-9a-f]+$": + type: object + additionalProperties: true # FIXME qcom,pm8916-vib binding not converted yet + + "^mpps@[0-9a-f]+$": + type: object + $ref: /schemas/pinctrl/qcom,pmic-mpp.yaml# + + "(.*)?(wled|leds)@[0-9a-f]+$": + type: object + $ref: /schemas/leds/backlight/qcom-wled.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/spmi/spmi.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + spmi@c440000 { + compatible = "qcom,spmi-pmic-arb"; + reg = <0x0c440000 0x1100>, + <0x0c600000 0x2000000>, + <0x0e600000 0x100000>, + <0x0e700000 0xa0000>, + <0x0c40a000 0x26000>; + reg-names = "core", "chnls", "obsrvr", "intr", "cnfg"; + interrupt-names = "periph_irq"; + interrupts = <GIC_SPI 481 IRQ_TYPE_LEVEL_HIGH>; + qcom,ee = <0>; + qcom,channel = <0>; + #address-cells = <2>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <4>; + + pmi8998_lsid0: pmic@2 { + compatible = "qcom,pmi8998", "qcom,spmi-pmic"; + reg = <0x2 SPMI_USID>; + #address-cells = <1>; + #size-cells = <0>; + + pmi8998_gpio: gpios@c000 { + compatible = "qcom,pmi8998-gpio", "qcom,spmi-gpio"; + reg = <0xc000>; + gpio-controller; + gpio-ranges = <&pmi8998_gpio 0 0 14>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt deleted file mode 100644 index add61bcc3c74..000000000000 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt +++ /dev/null @@ -1,24 +0,0 @@ -QCOM Top Control and Status Register - -Qualcomm devices have a set of registers that provide various control and status -functions for their peripherals. This node is intended to allow access to these -registers via syscon. - -Required properties: -- compatible: Should contain: - "qcom,tcsr-ipq6018", "syscon", "simple-mfd" for IPQ6018 - "qcom,tcsr-ipq8064", "syscon" for IPQ8064 - "qcom,tcsr-apq8064", "syscon" for APQ8064 - "qcom,tcsr-msm8660", "syscon" for MSM8660 - "qcom,tcsr-msm8953", "syscon" for MSM8953 - "qcom,tcsr-msm8960", "syscon" for MSM8960 - "qcom,tcsr-msm8974", "syscon" for MSM8974 - "qcom,tcsr-apq8084", "syscon" for APQ8084 - "qcom,tcsr-msm8916", "syscon" for MSM8916 -- reg: Address range for TCSR registers - -Example: - tcsr: syscon@1a400000 { - compatible = "qcom,tcsr-msm8960", "syscon"; - reg = <0x1a400000 0x100>; - }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml new file mode 100644 index 000000000000..2f816fd0c9ec --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/qcom,tcsr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Top Control and Status Register + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + Qualcomm devices have a set of registers that provide various control and + status functions for their peripherals. + +properties: + compatible: + oneOf: + - items: + - enum: + - qcom,tcsr-apq8064 + - qcom,tcsr-apq8084 + - qcom,tcsr-ipq8064 + - qcom,tcsr-mdm9615 + - qcom,tcsr-msm8660 + - qcom,tcsr-msm8916 + - qcom,tcsr-msm8953 + - qcom,tcsr-msm8960 + - qcom,tcsr-msm8974 + - const: syscon + - items: + - const: qcom,tcsr-ipq6018 + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@1a400000 { + compatible = "qcom,tcsr-msm8960", "syscon"; + reg = <0x1a400000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml index 2568736701be..61bd0b3ce02f 100644 --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm PM8xxx PMIC multi-function devices maintainers: - - Satya Priya <skakit@codeaurora.org> + - Satya Priya <quic_c_skakit@quicinc.com> description: | The PM8xxx family of Power Management ICs are used to provide regulated diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml index fe265bcab50d..fbface720678 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml @@ -74,7 +74,7 @@ properties: rohm,enable-hidden-gpo: description: | The BD71815 has undocumented GPO at pin E5. Pin is marked as GND at the - data-sheet as it's location in the middle of GND pins makes it hard to + data-sheet as its location in the middle of GND pins makes it hard to use on PCB. If your board has managed to use this pin you can enable the second GPO by defining this property. Dont enable this if you are unsure about how the E5 pin is connected on your board. diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index ec7f0190f46e..a58f08aa430d 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml @@ -58,43 +58,43 @@ properties: - "#pwm-cells" - compatible -patternProperties: - "^trigger@[0-9]+$": + counter: type: object properties: compatible: - const: st,stm32-lptimer-trigger - - reg: - description: Identify trigger hardware block. - items: - minimum: 0 - maximum: 2 + const: st,stm32-lptimer-counter required: - compatible - - reg - counter: + timer: type: object properties: compatible: - const: st,stm32-lptimer-counter + const: st,stm32-lptimer-timer required: - compatible - timer: +patternProperties: + "^trigger@[0-9]+$": type: object properties: compatible: - const: st,stm32-lptimer-timer + const: st,stm32-lptimer-trigger + + reg: + description: Identify trigger hardware block. + items: + minimum: 0 + maximum: 2 required: - compatible + - reg required: - "#address-cells" diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index 10b330d42901..5db00af8e116 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -33,7 +33,7 @@ properties: items: - const: int - reset: + resets: maxItems: 1 dmas: @@ -46,6 +46,21 @@ properties: minItems: 1 maxItems: 7 + interrupts: + oneOf: + - maxItems: 1 + - maxItems: 4 + + interrupt-names: + oneOf: + - items: + - const: global + - items: + - const: brk + - const: up + - const: trg-com + - const: cc + "#address-cells": const: 1 @@ -87,6 +102,16 @@ properties: - "#pwm-cells" - compatible + counter: + type: object + + properties: + compatible: + const: st,stm32-timer-counter + + required: + - compatible + patternProperties: "^timer@[0-9]+$": type: object @@ -107,16 +132,6 @@ patternProperties: - compatible - reg - counter: - type: object - - properties: - compatible: - const: st,stm32-timer-counter - - required: - - compatible - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index fb784045013f..c10f0b577268 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -17,7 +17,7 @@ description: | and access the registers directly. maintainers: - - Lee Jones <lee.jones@linaro.org> + - Lee Jones <lee@kernel.org> select: properties: diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index fa86691ebf16..73cffc45e056 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -48,6 +48,12 @@ patternProperties: description: This is the SERDES lane control mux. + "^clock-controller@[0-9a-f]+$": + type: object + $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml# + description: + Clock provider for TI EHRPWM nodes. + required: - compatible - reg @@ -79,5 +85,11 @@ examples: <0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>; /* SERDES4 lane0/1/2/3 select */ }; + + clock-controller@4140 { + compatible = "ti,am654-ehrpwm-tbclk", "syscon"; + reg = <0x4140 0x18>; + #clock-cells = <1>; + }; }; ... diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu.txt index 58d51f480c9e..8ec6191c1712 100644 --- a/Documentation/devicetree/bindings/mips/lantiq/rcu.txt +++ b/Documentation/devicetree/bindings/mips/lantiq/rcu.txt @@ -2,7 +2,7 @@ Lantiq XWAY SoC RCU binding =========================== This binding describes the RCU (reset controller unit) multifunction device, -where each sub-device has it's own set of registers. +where each sub-device has its own set of registers. The RCU register range is used for multiple purposes. Mostly one device uses one or multiple register exclusively, but for some registers some diff --git a/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml b/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml new file mode 100644 index 000000000000..1aebeb696ee0 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/qemu,vcpu-stall-detector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: VCPU stall detector + +description: + This binding describes a CPU stall detector mechanism for virtual CPUs + which is accessed through MMIO. + +maintainers: + - Sebastian Ene <sebastianene@google.com> + +properties: + compatible: + enum: + - qemu,vcpu-stall-detector + + reg: + maxItems: 1 + + clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + The internal clock of the stall detector peripheral measure in Hz used + to decrement its internal counter register on each tick. + Defaults to 10 if unset. + default: 10 + + timeout-sec: + description: | + The stall detector expiration timeout measured in seconds. + Defaults to 8 if unset. Please note that it also takes into account the + time spent while the VCPU is not running. + default: 8 + +required: + - compatible + +additionalProperties: false + +examples: + - | + vmwdt@9030000 { + compatible = "qemu,vcpu-stall-detector"; + reg = <0x9030000 0x10000>; + clock-frequency = <10>; + timeout-sec = <8>; + }; diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml index 5ecdac9de484..dead421e17d6 100644 --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml @@ -10,9 +10,6 @@ maintainers: - Al Cooper <alcooperx@gmail.com> - Florian Fainelli <f.fainelli@gmail.com> -allOf: - - $ref: mmc-controller.yaml# - properties: compatible: oneOf: @@ -42,23 +39,46 @@ properties: maxItems: 1 clocks: - maxItems: 1 - description: - handle to core clock for the sdhci controller. + minItems: 1 + items: + - description: handle to core clock for the sdhci controller + - description: handle to improved 150Mhz clock for sdhci controller (Optional clock) clock-names: + minItems: 1 items: - const: sw_sdio + - const: sdio_freq # Optional clock + + clock-frequency: + description: + Maximum operating frequency of sdio_freq sdhci controller clock + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 100000000 + maximum: 150000000 sdhci,auto-cmd12: type: boolean description: Specifies that controller should use auto CMD12 +allOf: + - $ref: mmc-controller.yaml# + - if: + properties: + clock-names: + contains: + const: sdio_freq + + then: + required: + - clock-frequency + required: - compatible - reg - interrupts - clocks + - clock-names unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt deleted file mode 100644 index 753e9d7d8956..000000000000 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt +++ /dev/null @@ -1,94 +0,0 @@ -* Samsung Exynos specific extensions to the Synopsys Designware Mobile - Storage Host Controller - -The Synopsys designware mobile storage host controller is used to interface -a SoC with storage medium such as eMMC or SD/MMC cards. This file documents -differences between the core Synopsys dw mshc controller properties described -by synopsys-dw-mshc.txt and the properties used by the Samsung Exynos specific -extensions to the Synopsys Designware Mobile Storage Host Controller. - -Required Properties: - -* compatible: should be - - "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210 - specific extensions. - - "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412 - specific extensions. - - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250 - specific extensions. - - "samsung,exynos5420-dw-mshc": for controllers with Samsung Exynos5420 - specific extensions. - - "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7 - specific extensions. - - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7 - specific extensions having an SMU. - - "axis,artpec8-dw-mshc": for controllers with ARTPEC-8 specific - extensions. - -* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface - unit (ciu) clock. This property is applicable only for Exynos5 SoC's and - ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7. - -* samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value - in transmit mode and CIU clock phase shift value in receive mode for single - data rate mode operation. Refer notes below for the order of the cells and the - valid values. - -* samsung,dw-mshc-ddr-timing: Specifies the value of CUI clock phase shift value - in transmit mode and CIU clock phase shift value in receive mode for double - data rate mode operation. Refer notes below for the order of the cells and the - valid values. -* samsung,dw-mshc-hs400-timing: Specifies the value of CIU TX and RX clock phase - shift value for hs400 mode operation. - - Notes for the sdr-timing and ddr-timing values: - - The order of the cells should be - - First Cell: CIU clock phase shift value for tx mode. - - Second Cell: CIU clock phase shift value for rx mode. - - Valid values for SDR and DDR CIU clock timing for Exynos5250: - - valid value for tx phase shift and rx phase shift is 0 to 7. - - when CIU clock divider value is set to 3, all possible 8 phase shift - values can be used. - - if CIU clock divider value is 0 (that is divide by 1), both tx and rx - phase shift clocks should be 0. - -* samsung,read-strobe-delay: RCLK (Data strobe) delay to control HS400 mode - (Latency value for delay line in Read path) - -Required properties for a slot (Deprecated - Recommend to use one slot per host): - -* gpios: specifies a list of gpios used for command, clock and data bus. The - first gpio is the command line and the second gpio is the clock line. The - rest of the gpios (depending on the bus-width property) are the data lines in - no particular order. The format of the gpio specifier depends on the gpio - controller. -(Deprecated - Refer to Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt) - -Example: - - The MSHC controller node can be split into two portions, SoC specific and - board specific portions as listed below. - - dwmmc0@12200000 { - compatible = "samsung,exynos5250-dw-mshc"; - reg = <0x12200000 0x1000>; - interrupts = <0 75 0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - dwmmc0@12200000 { - cap-mmc-highspeed; - cap-sd-highspeed; - broken-cd; - fifo-depth = <0x80>; - card-detect-delay = <200>; - samsung,dw-mshc-ciu-div = <3>; - samsung,dw-mshc-sdr-timing = <2 3>; - samsung,dw-mshc-ddr-timing = <1 2>; - samsung,dw-mshc-hs400-timing = <0 2>; - samsung,read-strobe-delay = <90>; - bus-width = <8>; - }; diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt deleted file mode 100644 index 5e74db69f581..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt +++ /dev/null @@ -1,29 +0,0 @@ -MMC/SD/SDIO slot directly connected to a SPI bus - -This file documents differences between the core properties described -by mmc.txt and the properties used by the mmc_spi driver. - -Required properties: -- spi-max-frequency : maximum frequency for this device (Hz). - -Optional properties: -- voltage-ranges : two cells are required, first cell specifies minimum - slot voltage (mV), second cell specifies maximum slot voltage (mV). - Several ranges could be specified. If not provided, 3.2v..3.4v is assumed. -- gpios : may specify GPIOs in this order: Card-Detect GPIO, - Write-Protect GPIO. Note that this does not follow the - binding from mmc.txt, for historical reasons. - -Example: - - mmc-slot@0 { - compatible = "fsl,mpc8323rdb-mmc-slot", - "mmc-spi-slot"; - reg = <0>; - gpios = <&qe_pio_d 14 1 - &qe_pio_d 15 0>; - voltage-ranges = <3300 3300>; - spi-max-frequency = <50000000>; - interrupts = <42>; - interrupt-parent = <&PIC>; - }; diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml new file mode 100644 index 000000000000..c45b91099325 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-spi-slot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MMC/SD/SDIO slot directly connected to a SPI bus + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +allOf: + - $ref: "mmc-controller.yaml" + - $ref: /schemas/spi/spi-peripheral-props.yaml + +description: | + The extra properties used by an mmc connected via SPI. + +properties: + compatible: + const: mmc-spi-slot + + reg: + maxItems: 1 + + spi-max-frequency: true + + interrupts: + maxItems: 1 + + voltage-ranges: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Two cells are required, first cell specifies minimum slot voltage (mV), + second cell specifies maximum slot voltage (mV). + items: + - description: | + value for minimum slot voltage in mV + default: 3200 + - description: | + value for maximum slot voltage in mV + default: 3400 + + gpios: + description: | + For historical reasons, this does not follow the generic mmc-controller + binding. + minItems: 1 + items: + - description: Card-Detect GPIO + - description: Write-Protect GPIO + +required: + - compatible + - reg + - spi-max-frequency + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + mmc@0 { + compatible = "mmc-spi-slot"; + reg = <0>; + gpios = <&gpio 14 GPIO_ACTIVE_LOW>, <&gpio 15 GPIO_ACTIVE_HIGH>; + voltage-ranges = <3300 3300>; + spi-max-frequency = <50000000>; + interrupts = <42>; + interrupt-parent = <&PIC>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 2a2e9fa8c188..083d1ec2f661 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -30,13 +30,11 @@ properties: - const: mediatek,mt7623-mmc - const: mediatek,mt2701-mmc - items: - - const: mediatek,mt8186-mmc - - const: mediatek,mt8183-mmc - - items: - - const: mediatek,mt8192-mmc - - const: mediatek,mt8183-mmc - - items: - - const: mediatek,mt8195-mmc + - enum: + - mediatek,mt8186-mmc + - mediatek,mt8188-mmc + - mediatek,mt8192-mmc + - mediatek,mt8195-mmc - const: mediatek,mt8183-mmc reg: @@ -72,12 +70,27 @@ properties: - const: ahb_cg interrupts: - maxItems: 1 + description: + Should at least contain MSDC GIC interrupt. To support SDIO in-band wakeup, an extended + interrupt is required and be configured as wakeup source irq. + minItems: 1 + maxItems: 2 + + interrupt-names: + items: + - const: msdc + - const: sdio_wakeup pinctrl-names: + description: + Should at least contain default and state_uhs. To support SDIO in-band wakeup, dat1 pin + will be switched between GPIO mode and SDIO DAT1 mode, state_eint is mandatory in this + scenario. + minItems: 2 items: - const: default - const: state_uhs + - const: state_eint pinctrl-0: description: @@ -89,6 +102,11 @@ properties: should contain uhs mode pin ctrl. maxItems: 1 + pinctrl-2: + description: + should switch dat1 pin to GPIO mode. + maxItems: 1 + assigned-clocks: description: PLL of the source clock. @@ -208,4 +226,32 @@ examples: mediatek,hs400-cmd-resp-sel-rising; }; + mmc3: mmc@11260000 { + compatible = "mediatek,mt8173-mmc"; + reg = <0x11260000 0x1000>; + clock-names = "source", "hclk"; + clocks = <&pericfg CLK_PERI_MSDC30_3>, + <&topckgen CLK_TOP_MSDC50_2_H_SEL>; + interrupt-names = "msdc", "sdio_wakeup"; + interrupts-extended = <&gic GIC_SPI 74 IRQ_TYPE_LEVEL_LOW 0>, + <&pio 23 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default", "state_uhs", "state_eint"; + pinctrl-0 = <&mmc2_pins_default>; + pinctrl-1 = <&mmc2_pins_uhs>; + pinctrl-2 = <&mmc2_pins_eint>; + bus-width = <4>; + max-frequency = <200000000>; + cap-sd-highspeed; + sd-uhs-sdr104; + keep-power-in-suspend; + wakeup-source; + cap-sdio-irq; + no-mmc; + no-sd; + non-removable; + vmmc-supply = <&sdio_fixed_3v3>; + vqmmc-supply = <&mt6397_vgp3_reg>; + mmc-pwrseq = <&wifi_pwrseq>; + }; + ... diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 9ac4986988c5..14945ebc31d2 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -56,11 +56,15 @@ properties: - renesas,sdhi-r8a77980 # R-Car V3H - renesas,sdhi-r8a77990 # R-Car E3 - renesas,sdhi-r8a77995 # R-Car D3 - - renesas,sdhi-r8a779a0 # R-Car V3U - renesas,sdhi-r9a07g043 # RZ/G2UL - renesas,sdhi-r9a07g044 # RZ/G2{L,LC} - renesas,sdhi-r9a07g054 # RZ/V2L - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 + - items: + - enum: + - renesas,sdhi-r8a779a0 # R-Car V3U + - renesas,sdhi-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-sdhi # R-Car Gen4 reg: maxItems: 1 @@ -141,6 +145,7 @@ allOf: enum: - renesas,rcar-gen2-sdhi - renesas,rcar-gen3-sdhi + - renesas,rcar-gen4-sdhi then: properties: clocks: diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index 54fb59820d2b..8d888b435817 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -39,6 +39,7 @@ properties: - rockchip,rk3399-dw-mshc - rockchip,rk3568-dw-mshc - rockchip,rv1108-dw-mshc + - rockchip,rv1126-dw-mshc - const: rockchip,rk3288-dw-mshc reg: diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml new file mode 100644 index 000000000000..fdaa18481aa0 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/samsung,exynos-dw-mshc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: + Samsung Exynos SoC specific extensions to the Synopsys Designware Mobile + Storage Host Controller + +maintainers: + - Jaehoon Chung <jh80.chung@samsung.com> + - Krzysztof Kozlowski <krzk@kernel.org> + +properties: + compatible: + enum: + - samsung,exynos4210-dw-mshc + - samsung,exynos4412-dw-mshc + - samsung,exynos5250-dw-mshc + - samsung,exynos5420-dw-mshc + - samsung,exynos5420-dw-mshc-smu + - samsung,exynos7-dw-mshc + - samsung,exynos7-dw-mshc-smu + - axis,artpec8-dw-mshc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + description: + Handle to "biu" and "ciu" clocks for the + bus interface unit clock and the card interface unit clock. + + clock-names: + items: + - const: biu + - const: ciu + + samsung,dw-mshc-ciu-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + description: + The divider value for the card interface unit (ciu) clock. + + samsung,dw-mshc-ddr-timing: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: CIU clock phase shift value for tx mode + minimum: 0 + maximum: 7 + - description: CIU clock phase shift value for rx mode + minimum: 0 + maximum: 7 + description: + The value of CUI clock phase shift value in transmit mode and CIU clock + phase shift value in receive mode for double data rate mode operation. + See also samsung,dw-mshc-hs400-timing property. + + samsung,dw-mshc-hs400-timing: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: CIU clock phase shift value for tx mode + minimum: 0 + maximum: 7 + - description: CIU clock phase shift value for rx mode + minimum: 0 + maximum: 7 + description: | + The value of CIU TX and RX clock phase shift value for HS400 mode + operation. + Valid values for SDR and DDR CIU clock timing:: + - valid value for tx phase shift and rx phase shift is 0 to 7. + - when CIU clock divider value is set to 3, all possible 8 phase shift + values can be used. + - if CIU clock divider value is 0 (that is divide by 1), both tx and rx + phase shift clocks should be 0. + If missing, values from samsung,dw-mshc-ddr-timing property are used. + + samsung,dw-mshc-sdr-timing: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: CIU clock phase shift value for tx mode + minimum: 0 + maximum: 7 + - description: CIU clock phase shift value for rx mode + minimum: 0 + maximum: 7 + description: + The value of CIU clock phase shift value in transmit mode and CIU clock + phase shift value in receive mode for single data rate mode operation. + See also samsung,dw-mshc-hs400-timing property. + + samsung,read-strobe-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + RCLK (Data strobe) delay to control HS400 mode (Latency value for delay + line in Read path). If missing, default from hardware is used. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - samsung,dw-mshc-ddr-timing + - samsung,dw-mshc-sdr-timing + +allOf: + - $ref: "synopsys-dw-mshc-common.yaml#" + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5250-dw-mshc + - samsung,exynos5420-dw-mshc + - samsung,exynos7-dw-mshc + - samsung,exynos7-dw-mshc-smu + - axis,artpec8-dw-mshc + then: + required: + - samsung,dw-mshc-ciu-div + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mmc@12220000 { + compatible = "samsung,exynos5420-dw-mshc"; + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x12220000 0x1000>; + clocks = <&clock CLK_MMC2>, <&clock CLK_SCLK_MMC2>; + clock-names = "biu", "ciu"; + fifo-depth = <0x40>; + card-detect-delay = <200>; + samsung,dw-mshc-ciu-div = <3>; + samsung,dw-mshc-sdr-timing = <0 4>; + samsung,dw-mshc-ddr-timing = <0 2>; + pinctrl-names = "default"; + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_wp &sd2_bus1 &sd2_bus4>; + bus-width = <4>; + cap-sd-highspeed; + max-frequency = <200000000>; + vmmc-supply = <&ldo19_reg>; + vqmmc-supply = <&ldo13_reg>; + sd-uhs-sdr50; + sd-uhs-sdr104; + sd-uhs-ddr50; + }; diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3c6410-sdhci.yaml b/Documentation/devicetree/bindings/mmc/samsung,s3c6410-sdhci.yaml new file mode 100644 index 000000000000..5d873a60f650 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/samsung,s3c6410-sdhci.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/samsung,s3c6410-sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SoC SDHCI Controller + +maintainers: + - Jaehoon Chung <jh80.chung@samsung.com> + - Krzysztof Kozlowski <krzk@kernel.org> + +properties: + compatible: + enum: + - samsung,s3c6410-sdhci + - samsung,exynos4210-sdhci + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 5 + + clock-names: + minItems: 2 + items: + - const: hsmmc + - pattern: "^mmc_busclk.[0-3]$" + - pattern: "^mmc_busclk.[0-3]$" + - pattern: "^mmc_busclk.[0-3]$" + - pattern: "^mmc_busclk.[0-3]$" + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +allOf: + - $ref: mmc-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos4210-sdhci + then: + properties: + clocks: + maxItems: 2 + clock-names: + items: + - const: hsmmc + - const: mmc_busclk.2 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mmc@12510000 { + compatible = "samsung,exynos4210-sdhci"; + reg = <0x12510000 0x100>; + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_SDMMC0>, <&clock CLK_SCLK_MMC0>; + clock-names = "hsmmc", "mmc_busclk.2"; + bus-width = <4>; + cd-gpios = <&gpx3 4 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sdhci2_cd>; + pinctrl-names = "default"; + vmmc-supply = <&ldo21_reg>; + }; diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt deleted file mode 100644 index 42e0a9afa100..000000000000 --- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt +++ /dev/null @@ -1,32 +0,0 @@ -* Samsung's SDHCI Controller device tree bindings - -Samsung's SDHCI controller is used as a connectivity interface with external -MMC, SD and eMMC storage mediums. This file documents differences between the -core mmc properties described by mmc.txt and the properties used by the -Samsung implementation of the SDHCI controller. - -Required SoC Specific Properties: -- compatible: should be one of the following - - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci - controller. - - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci - controller. - -Required Board Specific Properties: -- pinctrl-0: Should specify pin control groups used for this controller. -- pinctrl-names: Should contain only one value - "default". - -Example: - sdhci@12530000 { - compatible = "samsung,exynos4210-sdhci"; - reg = <0x12530000 0x100>; - interrupts = <0 75 0>; - bus-width = <4>; - cd-gpios = <&gpk2 2 0>; - pinctrl-names = "default"; - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>; - }; - - Note: This example shows both SoC specific and board specific properties - in a single device node. The properties can be actually be separated - into SoC specific node and board specific node. diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml index e4236334e748..fc0e81c2066c 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -17,6 +17,9 @@ description: properties: compatible: oneOf: + - enum: + - qcom,sdhci-msm-v4 + deprecated: true - items: - enum: - qcom,apq8084-sdhci @@ -27,6 +30,10 @@ properties: - qcom,msm8992-sdhci - qcom,msm8994-sdhci - qcom,msm8996-sdhci + - qcom,msm8998-sdhci + - const: qcom,sdhci-msm-v4 # for sdcc versions less than 5.0 + - items: + - enum: - qcom,qcs404-sdhci - qcom,sc7180-sdhci - qcom,sc7280-sdhci @@ -38,20 +45,16 @@ properties: - qcom,sm6350-sdhci - qcom,sm8150-sdhci - qcom,sm8250-sdhci - - enum: - - qcom,sdhci-msm-v4 # for sdcc versions less than 5.0 - - qcom,sdhci-msm-v5 # for sdcc version 5.0 - - items: - - const: qcom,sdhci-msm-v4 # Deprecated (only for backward compatibility) - # for sdcc versions less than 5.0 + - qcom,sm8450-sdhci + - const: qcom,sdhci-msm-v5 # for sdcc version 5.0 reg: minItems: 1 - items: - - description: Host controller register map - - description: SD Core register map - - description: CQE register map - - description: Inline Crypto Engine register map + maxItems: 4 + + reg-names: + minItems: 1 + maxItems: 4 clocks: minItems: 3 @@ -93,6 +96,9 @@ properties: description: Should specify pin control groups used for this controller. + resets: + maxItems: 1 + qcom,ddr-config: $ref: /schemas/types.yaml#/definitions/uint32 description: platform specific settings for DDR_CONFIG reg. @@ -121,6 +127,18 @@ properties: description: A phandle to sdhci power domain node maxItems: 1 + mmc-ddr-1_8v: true + + mmc-hs200-1_8v: true + + mmc-hs400-1_8v: true + + bus-width: true + + max-frequency: true + + operating-points-v2: true + patternProperties: '^opp-table(-[a-z0-9]+)?$': if: @@ -140,7 +158,47 @@ required: - clock-names - interrupts -additionalProperties: true +allOf: + - $ref: mmc-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdhci-msm-v4 + then: + properties: + reg: + minItems: 2 + items: + - description: Host controller register map + - description: SD Core register map + - description: CQE register map + - description: Inline Crypto Engine register map + reg-names: + minItems: 2 + items: + - const: hc + - const: core + - const: cqhci + - const: ice + else: + properties: + reg: + minItems: 1 + items: + - description: Host controller register map + - description: CQE register map + - description: Inline Crypto Engine register map + reg-names: + minItems: 1 + items: + - const: hc + - const: cqhci + - const: ice + +unevaluatedProperties: false examples: - | @@ -149,7 +207,7 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/power/qcom-rpmpd.h> - sdhc_2: sdhci@8804000 { + sdhc_2: mmc@8804000 { compatible = "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5"; reg = <0 0x08804000 0 0x1000>; diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml index 2cdf6bf3dc4a..8cc2a7ceb5fb 100644 --- a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml @@ -22,13 +22,14 @@ properties: reg: maxItems: 1 - spi-max-frequency: true - required: - compatible - reg -additionalProperties: false +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml index 73b86f2226c7..66da1b476ab7 100644 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -37,6 +37,4 @@ examples: compatible = "fsl,imx27-nand"; reg = <0xd8000000 0x1000>; interrupts = <29>; - nand-bus-width = <8>; - nand-ecc-mode = "hw"; }; diff --git a/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.txt b/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.txt deleted file mode 100644 index d5c5616f6db5..000000000000 --- a/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.txt +++ /dev/null @@ -1,17 +0,0 @@ -ARM AFS - ARM Firmware Suite Partitions -======================================= - -The ARM Firmware Suite is a flash partitioning system found on the -ARM reference designs: Integrator AP, Integrator CP, Versatile AB, -Versatile PB, the RealView family, Versatile Express and Juno. - -Required properties: -- compatible : (required) must be "arm,arm-firmware-suite" - -Example: - -flash@0 { - partitions { - compatible = "arm,arm-firmware-suite"; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml b/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml new file mode 100644 index 000000000000..76c88027b6d2 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/arm,arm-firmware-suite.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Firmware Suite (AFS) Partitions + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The ARM Firmware Suite is a flash partitioning system found on the + ARM reference designs: Integrator AP, Integrator CP, Versatile AB, + Versatile PB, the RealView family, Versatile Express and Juno. + +properties: + compatible: + const: arm,arm-firmware-suite + +additionalProperties: false + +examples: + - | + partitions { + compatible = "arm,arm-firmware-suite"; + }; +... diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml index e1ac08064425..f1a02d840b12 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -11,6 +11,17 @@ description: | relative offset and size specified. Depending on partition function extra properties can be used. + A partition may be dynamically allocated by a specific parser at runtime. + In this specific case, a specific suffix is required to the node name. + Everything after 'partition-' will be used as the partition name to compare + with the one dynamically allocated by the specific parser. + If the partition contains invalid char a label can be provided that will + be used instead of the node name to make the comparison. + This is used to assign an OF node to the dynamiccally allocated partition + so that subsystem like NVMEM can provide an OF node and declare NVMEM cells. + The OF node will be assigned only if the partition label declared match the + one assigned by the parser at runtime. + maintainers: - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> @@ -41,7 +52,12 @@ properties: immune to paired-pages corruptions type: boolean -required: - - reg +if: + not: + required: [ reg ] +then: + properties: + $nodename: + pattern: '^partition-.*$' additionalProperties: true diff --git a/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml b/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml index cf3f8c1e035d..dc07909af023 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml @@ -19,6 +19,10 @@ properties: compatible: const: qcom,smem-part +patternProperties: + "^partition-[0-9a-z]+$": + $ref: partition.yaml# + required: - compatible @@ -31,3 +35,26 @@ examples: compatible = "qcom,smem-part"; }; }; + + - | + /* Example declaring dynamic partition */ + flash { + partitions { + compatible = "qcom,smem-part"; + + partition-art { + compatible = "nvmem-cells"; + #address-cells = <1>; + #size-cells = <1>; + label = "0:art"; + + macaddr_art_0: macaddr@0 { + reg = <0x0 0x6>; + }; + + macaddr_art_6: macaddr@6 { + reg = <0x6 0x6>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml index 84ad7ff30121..482a2c068740 100644 --- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml @@ -102,6 +102,31 @@ allOf: - const: rx - const: cmd + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq806x-nand + + then: + properties: + qcom,boot-partitions: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: offset + - description: size + description: + Boot partition use a different layout where the 4 bytes of spare + data are not protected by ECC. Use this to declare these special + partitions by defining first the offset and then the size. + + It's in the form of <offset1 size1 offset2 size2 offset3 ...> + and should be declared in ascending order. + + Refer to the ipq8064 example on how to use this special binding. + required: - compatible - reg @@ -135,6 +160,8 @@ examples: nand-ecc-strength = <4>; nand-bus-width = <8>; + qcom,boot-partitions = <0x0 0x58a0000>; + partitions { compatible = "fixed-partitions"; #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index 6a4831fd3616..55fc620c72cd 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml @@ -22,6 +22,7 @@ properties: - enum: - allwinner,sun20i-d1-emac - allwinner,sun50i-h6-emac + - allwinner,sun50i-h616-emac0 - const: allwinner,sun50i-a64-emac reg: diff --git a/Documentation/devicetree/bindings/net/altera_tse.txt b/Documentation/devicetree/bindings/net/altera_tse.txt index 0b7d4d3758ea..1d9148ff5130 100644 --- a/Documentation/devicetree/bindings/net/altera_tse.txt +++ b/Documentation/devicetree/bindings/net/altera_tse.txt @@ -15,7 +15,7 @@ Required properties: "rx_desc": MSGDMA Rx dispatcher descriptor space region "rx_resp": MSGDMA Rx dispatcher response space region "s1": SGDMA descriptor memory -- interrupts: Should contain the TSE interrupts and it's mode. +- interrupts: Should contain the TSE interrupts and its mode. - interrupt-names: Should contain the interrupt names "rx_irq": xDMA Rx dispatcher interrupt "tx_irq": xDMA Tx dispatcher interrupt diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml index 5aac094fd217..445b2a553625 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -23,6 +23,8 @@ properties: - brcm,bcm4345c5 - brcm,bcm43540-bt - brcm,bcm4335a0 + - brcm,bcm4349-bt + - infineon,cyw55572-bt shutdown-gpios: maxItems: 1 @@ -92,6 +94,13 @@ properties: pcm-sync-mode: slave, master pcm-clock-mode: slave, master + brcm,requires-autobaud-mode: + type: boolean + description: + Set this property if autobaud mode is required. Autobaud mode is required + if the device's initial baud rate in normal mode is not supported by the + host or if the device requires autobaud mode startup before loading FW. + interrupts: items: - description: Handle to the line HOST_WAKE used to wake @@ -108,6 +117,22 @@ properties: required: - compatible +dependencies: + brcm,requires-autobaud-mode: [ 'shutdown-gpios' ] + +if: + not: + properties: + compatible: + contains: + enum: + - brcm,bcm20702a1 + - brcm,bcm4329-bt + - brcm,bcm4330-bt +then: + properties: + reset-gpios: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml new file mode 100644 index 000000000000..45aa3de7cf01 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/microchip,mpfs-can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: + Microchip PolarFire SoC (MPFS) can controller + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + const: microchip,mpfs-can + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + can@2010c000 { + compatible = "microchip,mpfs-can"; + reg = <0x2010c000 0x1000>; + clocks = <&clkcfg 17>; + interrupt-parent = <&plic>; + interrupts = <56>; + }; diff --git a/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml new file mode 100644 index 000000000000..b1327c5b86cf --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/nxp,sja1000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Memory mapped SJA1000 CAN controller from NXP (formerly Philips) + +maintainers: + - Wolfgang Grandegger <wg@grandegger.com> + +properties: + compatible: + oneOf: + - enum: + - nxp,sja1000 + - technologic,sja1000 + - items: + - enum: + - renesas,r9a06g032-sja1000 # RZ/N1D + - renesas,r9a06g033-sja1000 # RZ/N1S + - const: renesas,rzn1-sja1000 # RZ/N1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + reg-io-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: I/O register width (in bytes) implemented by this device + default: 1 + enum: [ 1, 2, 4 ] + + nxp,external-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 16000000 + description: | + Frequency of the external oscillator clock in Hz. + The internal clock frequency used by the SJA1000 is half of that value. + + nxp,tx-output-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3 ] + default: 1 + description: | + operation mode of the TX output control logic. Valid values are: + <0> : bi-phase output mode + <1> : normal output mode (default) + <2> : test output mode + <3> : clock output mode + + nxp,tx-output-config: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x02 + description: | + TX output pin configuration. Valid values are any one of the below + or combination of TX0 and TX1: + <0x01> : TX0 invert + <0x02> : TX0 pull-down (default) + <0x04> : TX0 pull-up + <0x06> : TX0 push-pull + <0x08> : TX1 invert + <0x10> : TX1 pull-down + <0x20> : TX1 pull-up + <0x30> : TX1 push-pull + + nxp,clock-out-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + clock frequency in Hz on the CLKOUT pin. + If not specified or if the specified value is 0, the CLKOUT pin + will be disabled. + + nxp,no-comparator-bypass: + type: boolean + description: Allows to disable the CAN input comparator. + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: can-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - technologic,sja1000 + - renesas,rzn1-sja1000 + then: + required: + - reg-io-width + - if: + properties: + compatible: + contains: + const: renesas,rzn1-sja1000 + then: + required: + - clocks + +unevaluatedProperties: false + +examples: + - | + can@1a000 { + compatible = "technologic,sja1000"; + reg = <0x1a000 0x100>; + interrupts = <1>; + reg-io-width = <2>; + nxp,tx-output-config = <0x06>; + nxp,external-clock-frequency = <24000000>; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r9a06g032-sysctrl.h> + + can@52104000 { + compatible = "renesas,r9a06g032-sja1000", "renesas,rzn1-sja1000"; + reg = <0x52104000 0x800>; + reg-io-width = <4>; + interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sysctrl R9A06G032_HCLK_CAN0>; + }; diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt deleted file mode 100644 index ac3160eca96a..000000000000 --- a/Documentation/devicetree/bindings/net/can/sja1000.txt +++ /dev/null @@ -1,58 +0,0 @@ -Memory mapped SJA1000 CAN controller from NXP (formerly Philips) - -Required properties: - -- compatible : should be one of "nxp,sja1000", "technologic,sja1000". - -- reg : should specify the chip select, address offset and size required - to map the registers of the SJA1000. The size is usually 0x80. - -- interrupts: property with a value describing the interrupt source - (number and sensitivity) required for the SJA1000. - -Optional properties: - -- reg-io-width : Specify the size (in bytes) of the IO accesses that - should be performed on the device. Valid value is 1, 2 or 4. - This property is ignored for technologic version. - Default to 1 (8 bits). - -- nxp,external-clock-frequency : Frequency of the external oscillator - clock in Hz. Note that the internal clock frequency used by the - SJA1000 is half of that value. If not specified, a default value - of 16000000 (16 MHz) is used. - -- nxp,tx-output-mode : operation mode of the TX output control logic: - <0x0> : bi-phase output mode - <0x1> : normal output mode (default) - <0x2> : test output mode - <0x3> : clock output mode - -- nxp,tx-output-config : TX output pin configuration: - <0x01> : TX0 invert - <0x02> : TX0 pull-down (default) - <0x04> : TX0 pull-up - <0x06> : TX0 push-pull - <0x08> : TX1 invert - <0x10> : TX1 pull-down - <0x20> : TX1 pull-up - <0x30> : TX1 push-pull - -- nxp,clock-out-frequency : clock frequency in Hz on the CLKOUT pin. - If not specified or if the specified value is 0, the CLKOUT pin - will be disabled. - -- nxp,no-comparator-bypass : Allows to disable the CAN input comparator. - -For further information, please have a look to the SJA1000 data sheet. - -Examples: - -can@3,100 { - compatible = "nxp,sja1000"; - reg = <3 0x100 0x80>; - interrupts = <2 0>; - interrupt-parent = <&mpic>; - nxp,external-clock-frequency = <16000000>; -}; - diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index 86fc31c2d91b..318f4efe7f6f 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -23,11 +23,20 @@ properties: - cdns,zynq-gem # Xilinx Zynq-7xxx SoC - cdns,zynqmp-gem # Xilinx Zynq Ultrascale+ MPSoC - const: cdns,gem # Generic + deprecated: true + + - items: + - enum: + - xlnx,versal-gem # Xilinx Versal + - xlnx,zynq-gem # Xilinx Zynq-7xxx SoC + - xlnx,zynqmp-gem # Xilinx Zynq Ultrascale+ MPSoC + - const: cdns,gem # Generic - items: - enum: - cdns,at91sam9260-macb # Atmel at91sam9 SoCs - cdns,sam9x60-macb # Microchip sam9x60 SoC + - microchip,mpfs-macb # Microchip PolarFire SoC - const: cdns,macb # Generic - items: @@ -42,7 +51,6 @@ properties: - atmel,sama5d2-gem # GEM IP (10/100) on Atmel sama5d2 SoCs - atmel,sama5d3-gem # Gigabit IP on Atmel sama5d3 SoCs - atmel,sama5d4-gem # GEM IP (10/100) on Atmel sama5d4 SoCs - - cdns,at32ap7000-macb # Other 10/100 usage or use the generic form - cdns,np4-macb # NP4 SoC devices - microchip,sama7g5-emac # Microchip SAMA7G5 ethernet interface - microchip,sama7g5-gem # Microchip SAMA7G5 gigabit ethernet interface @@ -155,7 +163,7 @@ unevaluatedProperties: false examples: - | macb0: ethernet@fffc4000 { - compatible = "cdns,at32ap7000-macb"; + compatible = "cdns,macb"; reg = <0xfffc4000 0x4000>; interrupts = <21>; phy-mode = "rmii"; @@ -181,7 +189,7 @@ examples: #address-cells = <2>; #size-cells = <2>; gem1: ethernet@ff0c0000 { - compatible = "cdns,zynqmp-gem", "cdns,gem"; + compatible = "xlnx,zynqmp-gem", "cdns,gem"; interrupt-parent = <&gic>; interrupts = <0 59 4>, <0 59 4>; reg = <0x0 0xff0c0000 0x0 0x1000>; diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 7c7ac5eb0313..ef655f386b2e 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -20,7 +20,7 @@ Required properties: - active_slave : Specifies the slave to use for time stamping, ethtool and SIOCGMIIPHY - cpsw-phy-sel : Specifies the phandle to the CPSW phy mode selection - device. See also cpsw-phy-sel.txt for it's binding. + device. See also cpsw-phy-sel.txt for its binding. Note that in legacy cases cpsw-phy-sel may be a child device instead of a phandle (DEPRECATED, use phys property instead). diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml index 5592f58fa6f0..228683773151 100644 --- a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml +++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml @@ -48,7 +48,7 @@ properties: "^led@[01]$": type: object description: Hellcreek leds - $ref: ../../leds/common.yaml# + $ref: /schemas/leds/common.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml new file mode 100644 index 000000000000..17ab6c69ecc7 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml @@ -0,0 +1,407 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7530.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT7530 Ethernet switch + +maintainers: + - Sean Wang <sean.wang@mediatek.com> + - Landen Chao <Landen.Chao@mediatek.com> + - DENG Qingfang <dqfext@gmail.com> + +description: | + Port 5 of mt7530 and mt7621 switch is muxed between: + 1. GMAC5: GMAC5 can interface with another external MAC or PHY. + 2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC + of the SOC. Used in many setups where port 0/4 becomes the WAN port. + Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to + GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not + connected to external component! + + Port 5 modes/configurations: + 1. Port 5 is disabled and isolated: An external phy can interface to the 2nd + GMAC of the SOC. + In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd + GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC! + 2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC. + It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode + and RGMII delay. + 3. Port 5 is muxed to GMAC5 and can interface to an external phy. + Port 5 becomes an extra switch port. + Only works on platform where external phy TX<->RX lines are swapped. + Like in the Ubiquiti ER-X-SFP. + 4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port. + Currently a 2nd CPU port is not supported by DSA code. + + Depending on how the external PHY is wired: + 1. normal: The PHY can only connect to 2nd GMAC but not to the switch + 2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as + a ethernet port. But can't interface to the 2nd GMAC. + + Based on the DT the port 5 mode is configured. + + Driver tries to lookup the phy-handle of the 2nd GMAC of the master device. + When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2. + phy-mode must be set, see also example 2 below! + * mt7621: phy-mode = "rgmii-txid"; + * mt7623: phy-mode = "rgmii"; + + CPU-Ports need a phy-mode property: + Allowed values on mt7530 and mt7621: + - "rgmii" + - "trgmii" + On mt7531: + - "1000base-x" + - "2500base-x" + - "rgmii" + - "sgmii" + + +properties: + compatible: + enum: + - mediatek,mt7530 + - mediatek,mt7531 + - mediatek,mt7621 + + reg: + maxItems: 1 + + core-supply: + description: + Phandle to the regulator node necessary for the core power. + + "#gpio-cells": + const: 2 + + gpio-controller: + type: boolean + description: + if defined, MT7530's LED controller will run on GPIO mode. + + "#interrupt-cells": + const: 1 + + interrupt-controller: true + + interrupts: + maxItems: 1 + + io-supply: + description: + Phandle to the regulator node necessary for the I/O power. + See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt + for details for the regulator setup on these boards. + + mediatek,mcm: + type: boolean + description: + if defined, indicates that either MT7530 is the part on multi-chip + module belong to MT7623A has or the remotely standalone chip as the + function MT7623N reference board provided for. + + reset-gpios: + maxItems: 1 + + reset-names: + const: mcm + + resets: + description: + Phandle pointing to the system reset controller with line index for + the ethsys. + maxItems: 1 + +patternProperties: + "^(ethernet-)?ports$": + type: object + + patternProperties: + "^(ethernet-)?port@[0-9]+$": + type: object + description: Ethernet switch ports + + unevaluatedProperties: false + + properties: + reg: + description: + Port address described must be 5 or 6 for CPU port and from 0 + to 5 for user ports. + + allOf: + - $ref: dsa-port.yaml# + - if: + properties: + label: + items: + - const: cpu + then: + required: + - reg + - phy-mode + +required: + - compatible + - reg + +allOf: + - $ref: "dsa.yaml#" + - if: + required: + - mediatek,mcm + then: + required: + - resets + - reset-names + + - dependencies: + interrupt-controller: [ interrupts ] + + - if: + properties: + compatible: + items: + - const: mediatek,mt7530 + then: + required: + - core-supply + - io-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + mdio { + #address-cells = <1>; + #size-cells = <0>; + switch@0 { + compatible = "mediatek,mt7530"; + reg = <0>; + + core-supply = <&mt6323_vpa_reg>; + io-supply = <&mt6323_vemc3v3_reg>; + reset-gpios = <&pio 33 GPIO_ACTIVE_HIGH>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "lan0"; + }; + + port@1 { + reg = <1>; + label = "lan1"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan3"; + }; + + port@4 { + reg = <4>; + label = "wan"; + }; + + port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&gmac0>; + phy-mode = "trgmii"; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; + + - | + //Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4. + + ethernet { + #address-cells = <1>; + #size-cells = <0>; + gmac0: mac@0 { + compatible = "mediatek,eth-mac"; + reg = <0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + + gmac1: mac@1 { + compatible = "mediatek,eth-mac"; + reg = <1>; + phy-mode = "rgmii-txid"; + phy-handle = <&phy4>; + }; + + mdio: mdio-bus { + #address-cells = <1>; + #size-cells = <0>; + + /* Internal phy */ + phy4: ethernet-phy@4 { + reg = <4>; + }; + + mt7530: switch@1f { + compatible = "mediatek,mt7621"; + reg = <0x1f>; + mediatek,mcm; + + resets = <&rstctrl 2>; + reset-names = "mcm"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan0"; + }; + + port@1 { + reg = <1>; + label = "lan1"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan3"; + }; + + /* Commented out. Port 4 is handled by 2nd GMAC. + port@4 { + reg = <4>; + label = "lan4"; + }; + */ + + port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&gmac0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + }; + }; + }; + + - | + //Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY. + + ethernet { + #address-cells = <1>; + #size-cells = <0>; + gmac_0: mac@0 { + compatible = "mediatek,eth-mac"; + reg = <0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + + mdio0: mdio-bus { + #address-cells = <1>; + #size-cells = <0>; + + /* External phy */ + ephy5: ethernet-phy@7 { + reg = <7>; + }; + + switch@1f { + compatible = "mediatek,mt7621"; + reg = <0x1f>; + mediatek,mcm; + + resets = <&rstctrl 2>; + reset-names = "mcm"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan0"; + }; + + port@1 { + reg = <1>; + label = "lan1"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan3"; + }; + + port@4 { + reg = <4>; + label = "lan4"; + }; + + port@5 { + reg = <5>; + label = "lan5"; + phy-mode = "rgmii"; + phy-handle = <&ephy5>; + }; + + cpu_port0: port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&gmac_0>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml new file mode 100644 index 000000000000..630bf0f8294b --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml @@ -0,0 +1,192 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/microchip,lan937x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LAN937x Ethernet Switch Series Tree Bindings + +maintainers: + - UNGLinuxDriver@microchip.com + +allOf: + - $ref: dsa.yaml# + +properties: + compatible: + enum: + - microchip,lan9370 + - microchip,lan9371 + - microchip,lan9372 + - microchip,lan9373 + - microchip,lan9374 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 50000000 + + reset-gpios: + description: Optional gpio specifier for a reset line + maxItems: 1 + + mdio: + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false + +patternProperties: + "^(ethernet-)?ports$": + patternProperties: + "^(ethernet-)?port@[0-9]+$": + allOf: + - if: + properties: + phy-mode: + contains: + enum: + - rgmii + - rgmii-id + - rgmii-txid + - rgmii-rxid + then: + properties: + rx-internal-delay-ps: + enum: [0, 2000] + default: 0 + tx-internal-delay-ps: + enum: [0, 2000] + default: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + macb0 { + #address-cells = <1>; + #size-cells = <0>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + spi { + #address-cells = <1>; + #size-cells = <0>; + + lan9374: switch@0 { + compatible = "microchip,lan9374"; + reg = <0>; + spi-max-frequency = <44000000>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan1"; + phy-mode = "internal"; + phy-handle = <&t1phy0>; + }; + + port@1 { + reg = <1>; + label = "lan2"; + phy-mode = "internal"; + phy-handle = <&t1phy1>; + }; + + port@2 { + reg = <2>; + label = "lan4"; + phy-mode = "internal"; + phy-handle = <&t1phy2>; + }; + + port@3 { + reg = <3>; + label = "lan6"; + phy-mode = "internal"; + phy-handle = <&t1phy3>; + }; + + port@4 { + reg = <4>; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <2000>; + ethernet = <&macb0>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + port@5 { + reg = <5>; + label = "lan7"; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <2000>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + port@6 { + reg = <6>; + label = "lan5"; + phy-mode = "internal"; + phy-handle = <&t1phy6>; + }; + + port@7 { + reg = <7>; + label = "lan3"; + phy-mode = "internal"; + phy-handle = <&t1phy7>; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + t1phy0: ethernet-phy@0{ + reg = <0x0>; + }; + + t1phy1: ethernet-phy@1{ + reg = <0x1>; + }; + + t1phy2: ethernet-phy@2{ + reg = <0x2>; + }; + + t1phy3: ethernet-phy@3{ + reg = <0x3>; + }; + + t1phy6: ethernet-phy@6{ + reg = <0x6>; + }; + + t1phy7: ethernet-phy@7{ + reg = <0x7>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt deleted file mode 100644 index 18247ebfc487..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ /dev/null @@ -1,327 +0,0 @@ -Mediatek MT7530 Ethernet switch -================================ - -Required properties: - -- compatible: may be compatible = "mediatek,mt7530" - or compatible = "mediatek,mt7621" - or compatible = "mediatek,mt7531" -- #address-cells: Must be 1. -- #size-cells: Must be 0. -- mediatek,mcm: Boolean; if defined, indicates that either MT7530 is the part - on multi-chip module belong to MT7623A has or the remotely standalone - chip as the function MT7623N reference board provided for. - -If compatible mediatek,mt7530 is set then the following properties are required - -- core-supply: Phandle to the regulator node necessary for the core power. -- io-supply: Phandle to the regulator node necessary for the I/O power. - See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt - for details for the regulator setup on these boards. - -If the property mediatek,mcm isn't defined, following property is required - -- reset-gpios: Should be a gpio specifier for a reset line. - -Else, following properties are required - -- resets : Phandle pointing to the system reset controller with - line index for the ethsys. -- reset-names : Should be set to "mcm". - -Required properties for the child nodes within ports container: - -- reg: Port address described must be 6 for CPU port and from 0 to 5 for - user ports. -- phy-mode: String, the following values are acceptable for port labeled - "cpu": - If compatible mediatek,mt7530 or mediatek,mt7621 is set, - must be either "trgmii" or "rgmii" - If compatible mediatek,mt7531 is set, - must be either "sgmii", "1000base-x" or "2500base-x" - -Port 5 of mt7530 and mt7621 switch is muxed between: -1. GMAC5: GMAC5 can interface with another external MAC or PHY. -2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC - of the SOC. Used in many setups where port 0/4 becomes the WAN port. - Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to - GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not - connected to external component! - -Port 5 modes/configurations: -1. Port 5 is disabled and isolated: An external phy can interface to the 2nd - GMAC of the SOC. - In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd - GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC! -2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC. - It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode - and RGMII delay. -3. Port 5 is muxed to GMAC5 and can interface to an external phy. - Port 5 becomes an extra switch port. - Only works on platform where external phy TX<->RX lines are swapped. - Like in the Ubiquiti ER-X-SFP. -4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port. - Currently a 2nd CPU port is not supported by DSA code. - -Depending on how the external PHY is wired: -1. normal: The PHY can only connect to 2nd GMAC but not to the switch -2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as - a ethernet port. But can't interface to the 2nd GMAC. - -Based on the DT the port 5 mode is configured. - -Driver tries to lookup the phy-handle of the 2nd GMAC of the master device. -When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2. -phy-mode must be set, see also example 2 below! - * mt7621: phy-mode = "rgmii-txid"; - * mt7623: phy-mode = "rgmii"; - -Optional properties: - -- gpio-controller: Boolean; if defined, MT7530's LED controller will run on - GPIO mode. -- #gpio-cells: Must be 2 if gpio-controller is defined. -- interrupt-controller: Boolean; Enables the internal interrupt controller. - -If interrupt-controller is defined, the following properties are required. - -- #interrupt-cells: Must be 1. -- interrupts: Parent interrupt for the interrupt controller. - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional -required, optional properties and how the integrated switch subnodes must -be specified. - -Example: - - &mdio0 { - switch@0 { - compatible = "mediatek,mt7530"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - - core-supply = <&mt6323_vpa_reg>; - io-supply = <&mt6323_vemc3v3_reg>; - reset-gpios = <&pio 33 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - port@0 { - reg = <0>; - label = "lan0"; - }; - - port@1 { - reg = <1>; - label = "lan1"; - }; - - port@2 { - reg = <2>; - label = "lan2"; - }; - - port@3 { - reg = <3>; - label = "lan3"; - }; - - port@4 { - reg = <4>; - label = "wan"; - }; - - port@6 { - reg = <6>; - label = "cpu"; - ethernet = <&gmac0>; - phy-mode = "trgmii"; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; - }; - -Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4. - -ð { - gmac0: mac@0 { - compatible = "mediatek,eth-mac"; - reg = <0>; - phy-mode = "rgmii"; - - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - - gmac1: mac@1 { - compatible = "mediatek,eth-mac"; - reg = <1>; - phy-mode = "rgmii-txid"; - phy-handle = <&phy4>; - }; - - mdio: mdio-bus { - #address-cells = <1>; - #size-cells = <0>; - - /* Internal phy */ - phy4: ethernet-phy@4 { - reg = <4>; - }; - - mt7530: switch@1f { - compatible = "mediatek,mt7621"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x1f>; - pinctrl-names = "default"; - mediatek,mcm; - - resets = <&rstctrl 2>; - reset-names = "mcm"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - label = "lan0"; - }; - - port@1 { - reg = <1>; - label = "lan1"; - }; - - port@2 { - reg = <2>; - label = "lan2"; - }; - - port@3 { - reg = <3>; - label = "lan3"; - }; - -/* Commented out. Port 4 is handled by 2nd GMAC. - port@4 { - reg = <4>; - label = "lan4"; - }; -*/ - - cpu_port0: port@6 { - reg = <6>; - label = "cpu"; - ethernet = <&gmac0>; - phy-mode = "rgmii"; - - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - }; - }; - }; -}; - -Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY. - -ð { - gmac0: mac@0 { - compatible = "mediatek,eth-mac"; - reg = <0>; - phy-mode = "rgmii"; - - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - - mdio: mdio-bus { - #address-cells = <1>; - #size-cells = <0>; - - /* External phy */ - ephy5: ethernet-phy@7 { - reg = <7>; - }; - - mt7530: switch@1f { - compatible = "mediatek,mt7621"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x1f>; - pinctrl-names = "default"; - mediatek,mcm; - - resets = <&rstctrl 2>; - reset-names = "mcm"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - label = "lan0"; - }; - - port@1 { - reg = <1>; - label = "lan1"; - }; - - port@2 { - reg = <2>; - label = "lan2"; - }; - - port@3 { - reg = <3>; - label = "lan3"; - }; - - port@4 { - reg = <4>; - label = "lan4"; - }; - - port@5 { - reg = <5>; - label = "lan5"; - phy-mode = "rgmii"; - phy-handle = <&ephy5>; - }; - - cpu_port0: port@6 { - reg = <6>; - label = "cpu"; - ethernet = <&gmac0>; - phy-mode = "rgmii"; - - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml new file mode 100644 index 000000000000..4d428f5ad044 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml @@ -0,0 +1,157 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/renesas,rzn1-a5psw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/N1 Advanced 5 ports ethernet switch + +maintainers: + - Clément Léger <clement.leger@bootlin.com> + +description: | + The advanced 5 ports switch is present on the Renesas RZ/N1 SoC family and + handles 4 ports + 1 CPU management port. + +allOf: + - $ref: dsa.yaml# + +properties: + compatible: + items: + - enum: + - renesas,r9a06g032-a5psw + - const: renesas,rzn1-a5psw + + reg: + maxItems: 1 + + interrupts: + items: + - description: Device Level Ring (DLR) interrupt + - description: Switch interrupt + - description: Parallel Redundancy Protocol (PRP) interrupt + - description: Integrated HUB module interrupt + - description: Receive Pattern Match interrupt + + interrupt-names: + items: + - const: dlr + - const: switch + - const: prp + - const: hub + - const: ptrn + + power-domains: + maxItems: 1 + + mdio: + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false + + clocks: + items: + - description: AHB clock used for the switch register interface + - description: Switch system clock + + clock-names: + items: + - const: hclk + - const: clk + + ethernet-ports: + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^(ethernet-)?port@[0-4]$": + type: object + description: Ethernet switch ports + + properties: + pcs-handle: + description: + phandle pointing to a PCS sub-node compatible with + renesas,rzn1-miic.yaml# + $ref: /schemas/types.yaml#/definitions/phandle + +unevaluatedProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/clock/r9a06g032-sysctrl.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + switch@44050000 { + compatible = "renesas,r9a06g032-a5psw", "renesas,rzn1-a5psw"; + reg = <0x44050000 0x10000>; + clocks = <&sysctrl R9A06G032_HCLK_SWITCH>, <&sysctrl R9A06G032_CLK_SWITCH>; + clock-names = "hclk", "clk"; + power-domains = <&sysctrl>; + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "dlr", "switch", "prp", "hub", "ptrn"; + + dsa,member = <0 0>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan0"; + phy-handle = <&switch0phy3>; + pcs-handle = <&mii_conv4>; + }; + + port@1 { + reg = <1>; + label = "lan1"; + phy-handle = <&switch0phy1>; + pcs-handle = <&mii_conv3>; + }; + + port@4 { + reg = <4>; + ethernet = <&gmac2>; + label = "cpu"; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + reset-gpios = <&gpio0a 2 GPIO_ACTIVE_HIGH>; + reset-delay-us = <15>; + clock-frequency = <2500000>; + + switch0phy1: ethernet-phy@1{ + reg = <1>; + }; + + switch0phy3: ethernet-phy@3{ + reg = <3>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/emac_rockchip.txt b/Documentation/devicetree/bindings/net/emac_rockchip.txt deleted file mode 100644 index 05bd7dafce17..000000000000 --- a/Documentation/devicetree/bindings/net/emac_rockchip.txt +++ /dev/null @@ -1,52 +0,0 @@ -* ARC EMAC 10/100 Ethernet platform driver for Rockchip RK3036/RK3066/RK3188 SoCs - -Required properties: -- compatible: should be "rockchip,<name>-emac" - "rockchip,rk3036-emac": found on RK3036 SoCs - "rockchip,rk3066-emac": found on RK3066 SoCs - "rockchip,rk3188-emac": found on RK3188 SoCs -- reg: Address and length of the register set for the device -- interrupts: Should contain the EMAC interrupts -- rockchip,grf: phandle to the syscon grf used to control speed and mode - for emac. -- phy: see ethernet.txt file in the same directory. -- phy-mode: see ethernet.txt file in the same directory. - -Optional properties: -- phy-supply: phandle to a regulator if the PHY needs one - -Clock handling: -- clocks: Must contain an entry for each entry in clock-names. -- clock-names: Shall be "hclk" for the host clock needed to calculate and set - polling period of EMAC and "macref" for the reference clock needed to transfer - data to and from the phy. - -Child nodes of the driver are the individual PHY devices connected to the -MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. - -Examples: - -ethernet@10204000 { - compatible = "rockchip,rk3188-emac"; - reg = <0xc0fc2000 0x3c>; - interrupts = <6>; - mac-address = [ 00 11 22 33 44 55 ]; - - clocks = <&cru HCLK_EMAC>, <&cru SCLK_MAC>; - clock-names = "hclk", "macref"; - - pinctrl-names = "default"; - pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>; - - rockchip,grf = <&grf>; - - phy = <&phy0>; - phy-mode = "rmii"; - phy-supply = <&vcc_rmii>; - - #address-cells = <1>; - #size-cells = <0>; - phy0: ethernet-phy@0 { - reg = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 4f15463611f8..c138a1022879 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -133,12 +133,6 @@ properties: and is useful for determining certain configuration settings such as flow control thresholds. - rx-internal-delay-ps: - description: | - RGMII Receive Clock Delay defined in pico seconds. - This is used for controllers that have configurable RX internal delays. - If this property is present then the MAC applies the RX delay. - sfp: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -150,12 +144,6 @@ properties: The size of the controller\'s transmit fifo in bytes. This is used for components that can have configurable fifo sizes. - tx-internal-delay-ps: - description: | - RGMII Transmit Clock Delay defined in pico seconds. - This is used for controllers that have configurable TX internal delays. - If this property is present then the MAC applies the TX delay. - managed: description: Specifies the PHY management type. If auto is set and fixed-link @@ -167,70 +155,88 @@ properties: - in-band-status fixed-link: - allOf: - - if: - type: array - then: - deprecated: true - items: - - minimum: 0 - maximum: 31 - description: - Emulated PHY ID, choose any but unique to the all - specified fixed-links - - - enum: [0, 1] - description: - Duplex configuration. 0 for half duplex or 1 for - full duplex - - - enum: [10, 100, 1000, 2500, 10000] - description: - Link speed in Mbits/sec. - - - enum: [0, 1] - description: - Pause configuration. 0 for no pause, 1 for pause - - - enum: [0, 1] - description: - Asymmetric pause configuration. 0 for no asymmetric - pause, 1 for asymmetric pause - - - - if: - type: object - then: - properties: - speed: - description: - Link speed. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [10, 100, 1000, 2500, 10000] - - full-duplex: - $ref: /schemas/types.yaml#/definitions/flag - description: - Indicates that full-duplex is used. When absent, half - duplex is assumed. - - pause: - $ref: /schemas/types.yaml#definitions/flag - description: - Indicates that pause should be enabled. - - asym-pause: - $ref: /schemas/types.yaml#/definitions/flag - description: - Indicates that asym_pause should be enabled. - - link-gpios: - maxItems: 1 - description: - GPIO to determine if the link is up - - required: - - speed + oneOf: + - $ref: /schemas/types.yaml#/definitions/uint32-array + deprecated: true + items: + - minimum: 0 + maximum: 31 + description: + Emulated PHY ID, choose any but unique to the all + specified fixed-links + + - enum: [0, 1] + description: + Duplex configuration. 0 for half duplex or 1 for + full duplex + + - enum: [10, 100, 1000, 2500, 10000] + description: + Link speed in Mbits/sec. + + - enum: [0, 1] + description: + Pause configuration. 0 for no pause, 1 for pause + + - enum: [0, 1] + description: + Asymmetric pause configuration. 0 for no asymmetric + pause, 1 for asymmetric pause + - type: object + additionalProperties: false + properties: + speed: + description: + Link speed. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [10, 100, 1000, 2500, 10000] + + full-duplex: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates that full-duplex is used. When absent, half + duplex is assumed. + + pause: + $ref: /schemas/types.yaml#definitions/flag + description: + Indicates that pause should be enabled. + + asym-pause: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates that asym_pause should be enabled. + + link-gpios: + maxItems: 1 + description: + GPIO to determine if the link is up + + required: + - speed + +allOf: + - if: + properties: + phy-mode: + contains: + enum: + - rgmii + - rgmii-rxid + - rgmii-txid + - rgmii-id + then: + properties: + rx-internal-delay-ps: + description: + RGMII Receive Clock Delay defined in pico seconds.This is used for + controllers that have configurable RX internal delays. If this + property is present then the MAC applies the RX delay. + tx-internal-delay-ps: + description: + RGMII Transmit Clock Delay defined in pico seconds.This is used for + controllers that have configurable TX internal delays. If this + property is present then the MAC applies the TX delay. additionalProperties: true diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index daa2f79a294f..5cfb661be124 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -58,6 +58,11 @@ properties: - fsl,imx8qxp-fec - const: fsl,imx8qm-fec - const: fsl,imx6sx-fec + - items: + - enum: + - fsl,imx8ulp-fec + - const: fsl,imx6ul-fec + - const: fsl,imx6q-fec reg: maxItems: 1 @@ -121,6 +126,10 @@ properties: mac-address: true + nvmem-cells: true + + nvmem-cell-names: true + tx-internal-delay-ps: enum: [0, 2000] @@ -183,6 +192,7 @@ properties: Should specify the gpio for phy reset. phy-reset-duration: + $ref: /schemas/types.yaml#/definitions/uint32 deprecated: true description: Reset duration in milliseconds. Should present only if property @@ -191,12 +201,14 @@ properties: and 1 millisecond will be used instead. phy-reset-active-high: + type: boolean deprecated: true description: If present then the reset sequence using the GPIO specified in the "phy-reset-gpios" property is reversed (H=reset state, L=operation state). phy-reset-post-delay: + $ref: /schemas/types.yaml#/definitions/uint32 deprecated: true description: Post reset delay in milliseconds. If present then a delay of phy-reset-post-delay @@ -213,7 +225,7 @@ required: # least undocumented properties. However, PHY may have a deprecated option to # place PHY OF properties in the MAC node, such as Micrel PHY, and we can find # these boards which is based on i.MX6QDL. -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml index def994c9cbb4..64c893c98d80 100644 --- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml @@ -23,6 +23,7 @@ properties: - mediatek,mt8516-eth - mediatek,mt8518-eth - mediatek,mt8175-eth + - mediatek,mt8365-eth reg: maxItems: 1 @@ -47,6 +48,22 @@ properties: Phandle to the device containing the PERICFG register range. This is used to control the MII mode. + mediatek,rmii-rxc: + type: boolean + description: + If present, indicates that the RMII reference clock, which is from external + PHYs, is connected to RXC pin. Otherwise, is connected to TXC pin. + + mediatek,rxc-inverse: + type: boolean + description: + If present, indicates that clock on RXC pad will be inversed. + + mediatek,txc-inverse: + type: boolean + description: + If present, indicates that clock on TXC pad will be inversed. + mdio: $ref: mdio.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt index a9ed691ffb03..a407dd1b4614 100644 --- a/Documentation/devicetree/bindings/net/micrel.txt +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -16,6 +16,7 @@ Optional properties: KSZ8051: register 0x1f, bits 5..4 KSZ8081: register 0x1f, bits 5..4 KSZ8091: register 0x1f, bits 5..4 + LAN8814: register EP5.0, bit 6 See the respective PHY datasheet for the mode values. diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml index 1bcaf6ba822c..a191a04e681c 100644 --- a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml @@ -58,7 +58,6 @@ properties: spi-cpha: true spi-cpol: true - spi-max-frequency: true required: - compatible @@ -85,6 +84,7 @@ allOf: contains: const: marvell,nfc-spi then: + $ref: /schemas/spi/spi-peripheral-props.yaml# properties: break-control: false flow-control: false @@ -108,7 +108,7 @@ allOf: spi-max-frequency: false reg: false -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml index e381a3c14836..b2558421268a 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP Semiconductors NCI NFC controller maintainers: - - Charles Gorand <charles.gorand@effinnov.com> - Krzysztof Kozlowski <krzk@kernel.org> properties: diff --git a/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml b/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml index ef1155038a2f..1dcbddbc5a74 100644 --- a/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml @@ -30,8 +30,6 @@ properties: reg: maxItems: 1 - spi-max-frequency: true - uicc-present: type: boolean description: | @@ -55,10 +53,11 @@ then: properties: spi-max-frequency: false else: + $ref: /schemas/spi/spi-peripheral-props.yaml# required: - spi-max-frequency -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml b/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml index 963d9531a856..647569051ed8 100644 --- a/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml +++ b/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml @@ -25,8 +25,6 @@ properties: st95hfvin-supply: description: ST95HF transceiver's Vin regulator supply - spi-max-frequency: true - required: - compatible - enable-gpio @@ -34,7 +32,10 @@ required: - reg - spi-max-frequency -additionalProperties: false +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml index 404c8df99364..9cc236ec42f2 100644 --- a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml +++ b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml @@ -40,8 +40,6 @@ properties: reg: maxItems: 1 - spi-max-frequency: true - ti,enable-gpios: minItems: 1 maxItems: 2 @@ -65,7 +63,10 @@ required: - ti,enable-gpios - vin-supply -additionalProperties: false +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml b/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml new file mode 100644 index 000000000000..2d33bbab7163 --- /dev/null +++ b/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml @@ -0,0 +1,171 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pcs/renesas,rzn1-miic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/N1 MII converter + +maintainers: + - Clément Léger <clement.leger@bootlin.com> + +description: | + This MII converter is present on the Renesas RZ/N1 SoC family. It is + responsible to do MII passthrough or convert it to RMII/RGMII. + +properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + compatible: + items: + - enum: + - renesas,r9a06g032-miic + - const: renesas,rzn1-miic + + reg: + maxItems: 1 + + clocks: + items: + - description: MII reference clock + - description: RGMII reference clock + - description: RMII reference clock + - description: AHB clock used for the MII converter register interface + + clock-names: + items: + - const: mii_ref + - const: rgmii_ref + - const: rmii_ref + - const: hclk + + renesas,miic-switch-portin: + description: MII Switch PORTIN configuration. This value should use one of + the values defined in dt-bindings/net/pcs-rzn1-miic.h. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + + power-domains: + maxItems: 1 + +patternProperties: + "^mii-conv@[0-5]$": + type: object + description: MII converter port + + properties: + reg: + description: MII Converter port number. + enum: [1, 2, 3, 4, 5] + + renesas,miic-input: + description: Converter input port configuration. This value should use + one of the values defined in dt-bindings/net/pcs-rzn1-miic.h. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - reg + - renesas,miic-input + + additionalProperties: false + + allOf: + - if: + properties: + reg: + const: 1 + then: + properties: + renesas,miic-input: + const: 0 + - if: + properties: + reg: + const: 2 + then: + properties: + renesas,miic-input: + enum: [1, 11] + - if: + properties: + reg: + const: 3 + then: + properties: + renesas,miic-input: + enum: [7, 10] + - if: + properties: + reg: + const: 4 + then: + properties: + renesas,miic-input: + enum: [4, 6, 9, 13] + - if: + properties: + reg: + const: 5 + then: + properties: + renesas,miic-input: + enum: [3, 5, 8, 12] + +required: + - '#address-cells' + - '#size-cells' + - compatible + - reg + - clocks + - clock-names + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/net/pcs-rzn1-miic.h> + #include <dt-bindings/clock/r9a06g032-sysctrl.h> + + eth-miic@44030000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,r9a06g032-miic", "renesas,rzn1-miic"; + reg = <0x44030000 0x10000>; + clocks = <&sysctrl R9A06G032_CLK_MII_REF>, + <&sysctrl R9A06G032_CLK_RGMII_REF>, + <&sysctrl R9A06G032_CLK_RMII_REF>, + <&sysctrl R9A06G032_HCLK_SWITCH_RG>; + clock-names = "mii_ref", "rgmii_ref", "rmii_ref", "hclk"; + renesas,miic-switch-portin = <MIIC_GMAC2_PORT>; + power-domains = <&sysctrl>; + + mii_conv1: mii-conv@1 { + renesas,miic-input = <MIIC_GMAC1_PORT>; + reg = <1>; + }; + + mii_conv2: mii-conv@2 { + renesas,miic-input = <MIIC_SWITCH_PORTD>; + reg = <2>; + }; + + mii_conv3: mii-conv@3 { + renesas,miic-input = <MIIC_SWITCH_PORTC>; + reg = <3>; + }; + + mii_conv4: mii-conv@4 { + renesas,miic-input = <MIIC_SWITCH_PORTB>; + reg = <4>; + }; + + mii_conv5: mii-conv@5 { + renesas,miic-input = <MIIC_SWITCH_PORTA>; + reg = <5>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/qcom-emac.txt b/Documentation/devicetree/bindings/net/qcom-emac.txt index 346e6c7f47b7..7ae8aa148634 100644 --- a/Documentation/devicetree/bindings/net/qcom-emac.txt +++ b/Documentation/devicetree/bindings/net/qcom-emac.txt @@ -14,7 +14,7 @@ MAC node: - mac-address : The 6-byte MAC address. If present, it is the default MAC address. - internal-phy : phandle to the internal PHY node -- phy-handle : phandle the the external PHY node +- phy-handle : phandle to the external PHY node Internal PHY node: - compatible : Should be "qcom,fsm9900-emac-sgmii" or "qcom,qdf2432-emac-sgmii". diff --git a/Documentation/devicetree/bindings/net/rockchip,emac.yaml b/Documentation/devicetree/bindings/net/rockchip,emac.yaml new file mode 100644 index 000000000000..a6d4f14df442 --- /dev/null +++ b/Documentation/devicetree/bindings/net/rockchip,emac.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/rockchip,emac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3036/RK3066/RK3188 Ethernet Media Access Controller (EMAC) + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,rk3036-emac + - rockchip,rk3066-emac + - rockchip,rk3188-emac + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + items: + - description: host clock + - description: reference clock + - description: mac TX/RX clock + + clock-names: + minItems: 2 + items: + - const: hclk + - const: macref + - const: macclk + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon GRF used to control speed and mode for the EMAC. + + phy-supply: + description: + Phandle to a regulator if the PHY needs one. + + mdio: + $ref: mdio.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - rockchip,grf + - phy + - phy-mode + - mdio + +allOf: + - $ref: "ethernet-controller.yaml#" + - if: + properties: + compatible: + contains: + const: rockchip,rk3036-emac + + then: + properties: + clocks: + minItems: 3 + + clock-names: + minItems: 3 + + else: + properties: + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3188-cru-common.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + ethernet@10204000 { + compatible = "rockchip,rk3188-emac"; + reg = <0xc0fc2000 0x3c>; + interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru HCLK_EMAC>, <&cru SCLK_MAC>; + clock-names = "hclk", "macref"; + rockchip,grf = <&grf>; + pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&phy_int>; + pinctrl-names = "default"; + phy = <&phy0>; + phy-mode = "rmii"; + phy-supply = <&vcc_rmii>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt deleted file mode 100644 index 832139919f20..000000000000 --- a/Documentation/devicetree/bindings/net/sff,sfp.txt +++ /dev/null @@ -1,85 +0,0 @@ -Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP) -Transceiver - -Required properties: - -- compatible : must be one of - "sff,sfp" for SFP modules - "sff,sff" for soldered down SFF modules - -- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial - interface - -Optional Properties: - -- mod-def0-gpios : GPIO phandle and a specifier of the MOD-DEF0 (AKA Mod_ABS) - module presence input gpio signal, active (module absent) high. Must - not be present for SFF modules - -- los-gpios : GPIO phandle and a specifier of the Receiver Loss of Signal - Indication input gpio signal, active (signal lost) high - -- tx-fault-gpios : GPIO phandle and a specifier of the Module Transmitter - Fault input gpio signal, active (fault condition) high - -- tx-disable-gpios : GPIO phandle and a specifier of the Transmitter Disable - output gpio signal, active (Tx disable) high - -- rate-select0-gpios : GPIO phandle and a specifier of the Rx Signaling Rate - Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx rate - Must not be present for SFF modules - -- rate-select1-gpios : GPIO phandle and a specifier of the Tx Signaling Rate - Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate, high: - high Tx rate. Must not be present for SFF modules - -- maximum-power-milliwatt : Maximum module power consumption - Specifies the maximum power consumption allowable by a module in the - slot, in milli-Watts. Presently, modules can be up to 1W, 1.5W or 2W. - -Example #1: Direct serdes to SFP connection - -sfp_eth3: sfp-eth3 { - compatible = "sff,sfp"; - i2c-bus = <&sfp_1g_i2c>; - los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>; - mod-def0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>; - maximum-power-milliwatt = <1000>; - pinctrl-names = "default"; - pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>; - tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>; - tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>; -}; - -&cps_emac3 { - phy-names = "comphy"; - phys = <&cps_comphy5 0>; - sfp = <&sfp_eth3>; -}; - -Example #2: Serdes to PHY to SFP connection - -sfp_eth0: sfp-eth0 { - compatible = "sff,sfp"; - i2c-bus = <&sfpp0_i2c>; - los-gpios = <&cps_gpio1 28 GPIO_ACTIVE_HIGH>; - mod-def0-gpios = <&cps_gpio1 27 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&cps_sfpp0_pins>; - tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>; - tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>; -}; - -p0_phy: ethernet-phy@0 { - compatible = "ethernet-phy-ieee802.3-c45"; - pinctrl-names = "default"; - pinctrl-0 = <&cpm_phy0_pins &cps_phy0_pins>; - reg = <0>; - interrupt = <&cpm_gpio2 18 IRQ_TYPE_EDGE_FALLING>; - sfp = <&sfp_eth0>; -}; - -&cpm_eth0 { - phy = <&p0_phy>; - phy-mode = "10gbase-kr"; -}; diff --git a/Documentation/devicetree/bindings/net/sff,sfp.yaml b/Documentation/devicetree/bindings/net/sff,sfp.yaml new file mode 100644 index 000000000000..06c66ab81c01 --- /dev/null +++ b/Documentation/devicetree/bindings/net/sff,sfp.yaml @@ -0,0 +1,142 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/sff,sfp.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP) + Transceiver + +maintainers: + - Russell King <linux@armlinux.org.uk> + +properties: + compatible: + enum: + - sff,sfp # for SFP modules + - sff,sff # for soldered down SFF modules + + i2c-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle of an I2C bus controller for the SFP two wire serial + + maximum-power-milliwatt: + maxItems: 1 + description: + Maximum module power consumption Specifies the maximum power consumption + allowable by a module in the slot, in milli-Watts. Presently, modules can + be up to 1W, 1.5W or 2W. + + "mod-def0-gpios": + maxItems: 1 + description: + GPIO phandle and a specifier of the MOD-DEF0 (AKA Mod_ABS) module + presence input gpio signal, active (module absent) high. Must not be + present for SFF modules + + "los-gpios": + maxItems: 1 + description: + GPIO phandle and a specifier of the Receiver Loss of Signal Indication + input gpio signal, active (signal lost) high + + "tx-fault-gpios": + maxItems: 1 + description: + GPIO phandle and a specifier of the Module Transmitter Fault input gpio + signal, active (fault condition) high + + "tx-disable-gpios": + maxItems: 1 + description: + GPIO phandle and a specifier of the Transmitter Disable output gpio + signal, active (Tx disable) high + + "rate-select0-gpios": + maxItems: 1 + description: + GPIO phandle and a specifier of the Rx Signaling Rate Select (AKA RS0) + output gpio signal, low - low Rx rate, high - high Rx rate Must not be + present for SFF modules + + "rate-select1-gpios": + maxItems: 1 + description: + GPIO phandle and a specifier of the Tx Signaling Rate Select (AKA RS1) + output gpio signal (SFP+ only), low - low Tx rate, high - high Tx rate. Must + not be present for SFF modules + +allOf: + - if: + properties: + compatible: + contains: + const: sff,sff + then: + properties: + mod-def0-gpios: false + rate-select0-gpios: false + rate-select1-gpios: false + +required: + - compatible + - i2c-bus + +additionalProperties: false + +examples: + - | # Direct serdes to SFP connection + #include <dt-bindings/gpio/gpio.h> + + sfp1: sfp { + compatible = "sff,sfp"; + i2c-bus = <&sfp_1g_i2c>; + los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>; + maximum-power-milliwatt = <1000>; + pinctrl-names = "default"; + pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>; + tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>; + }; + + ethernet { + phy-names = "comphy"; + phys = <&cps_comphy5 0>; + sfp = <&sfp1>; + }; + + - | # Serdes to PHY to SFP connection + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + sfp2: sfp { + compatible = "sff,sfp"; + i2c-bus = <&sfp_i2c>; + los-gpios = <&cps_gpio1 28 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&cps_gpio1 27 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&cps_sfpp0_pins>; + tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c45"; + pinctrl-names = "default"; + pinctrl-0 = <&cpm_phy0_pins &cps_phy0_pins>; + reg = <0>; + interrupt = <&cpm_gpio2 18 IRQ_TYPE_EDGE_FALLING>; + sfp = <&sfp2>; + }; + }; + + ethernet { + phy = <&phy>; + phy-mode = "10gbase-kr"; + }; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 36c85eb3dc0d..491597c02edf 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -65,6 +65,8 @@ properties: - ingenic,x2000-mac - loongson,ls2k-dwmac - loongson,ls7a-dwmac + - renesas,r9a06g032-gmac + - renesas,rzn1-gmac - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac @@ -135,6 +137,9 @@ properties: reset-names: const: stmmaceth + power-domains: + maxItems: 1 + mac-mode: $ref: ethernet-controller.yaml#/properties/phy-connection-type description: diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml index 75e8712e903a..f2489a9c852f 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: TI DP83822 ethernet PHY maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The DP83822 is a low-power, single-port, 10/100 Mbps Ethernet PHY. It diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml index 047d757e8d82..b8c0e4b5b494 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml @@ -11,7 +11,7 @@ allOf: - $ref: "ethernet-controller.yaml#" maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The DP83867 device is a robust, low power, fully featured Physical Layer @@ -31,6 +31,16 @@ properties: reg: maxItems: 1 + nvmem-cells: + maxItems: 1 + description: + Nvmem data cell containing the value to write to the + IO_IMPEDANCE_CTRL field of the IO_MUX_CFG register. + + nvmem-cell-names: + items: + - const: io_impedance_ctrl + ti,min-output-impedance: type: boolean description: | @@ -42,9 +52,11 @@ properties: description: | MAC Interface Impedance control to set the programmable output impedance to a maximum value (70 ohms). - Note: ti,min-output-impedance and ti,max-output-impedance are mutually - exclusive. When both properties are present ti,max-output-impedance - takes precedence. + Note: Specifying an io_impedance_ctrl nvmem cell or one of the + ti,min-output-impedance, ti,max-output-impedance properties + are mutually exclusive. If more than one is present, an nvmem + cell takes precedence over ti,max-output-impedance, which in + turn takes precedence over ti,min-output-impedance. tx-fifo-depth: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 1b780dce61ab..b04ff0014a59 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -11,7 +11,7 @@ allOf: - $ref: "ethernet-phy.yaml#" maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The DP83869HM device is a robust, fully-featured Gigabit (PHY) transceiver diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml index c11f23b20c4c..53b4153d9bfc 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml @@ -75,6 +75,16 @@ properties: items: pattern: '^[A-Z][A-Z]-[A-Z][0-9A-Z]-[0-9]+$' + brcm,ccode-map-trivial: + description: | + Use a trivial mapping of ISO3166 country codes to brcmfmac firmware + country code and revision: cc -> { cc, 0 }. In other words, assume that + the CLM blob firmware uses ISO3166 country codes as well, and that all + revisions are zero. This property is mutually exclusive with + brcm,ccode-map. If both properties are specified, then brcm,ccode-map + takes precedence. + type: boolean + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 5a12dc32288a..70e328589cfb 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -54,6 +54,16 @@ properties: reset-names: const: consys + clocks: + maxItems: 2 + description: + Specify the consys clocks for mt7986. + + clock-names: + items: + - const: mcu + - const: ap2conn + mediatek,infracfg: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -269,5 +279,8 @@ examples: <0x10003000 0x1000>, <0x11d10000 0x1000>; interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&topckgen 50>, + <&topckgen 62>; + clock-names = "mcu", "ap2conn"; memory-region = <&wmcpu_emi>; }; diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml index 8cd0adbf7021..7029cb1f38ff 100644 --- a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Atheros ath9k wireless devices Generic Binding maintainers: - - Kalle Valo <kvalo@codeaurora.org> + - Toke Høiland-Jørgensen <toke@toke.dk> description: | This node provides properties for configuring the ath9k wireless device. diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index 8c01fdba134b..a677b056f112 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -9,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath11k wireless devices Generic Binding maintainers: - - Kalle Valo <kvalo@codeaurora.org> + - Kalle Valo <kvalo@kernel.org> description: | These are dt entries for Qualcomm Technologies, Inc. IEEE 802.11ax diff --git a/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml b/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml new file mode 100644 index 000000000000..92d8ade988f6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/xlnx,emaclite.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Emaclite Ethernet controller + +maintainers: + - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> + - Harini Katakam <harini.katakam@amd.com> + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + enum: + - xlnx,opb-ethernetlite-1.01.a + - xlnx,opb-ethernetlite-1.01.b + - xlnx,xps-ethernetlite-1.00.a + - xlnx,xps-ethernetlite-2.00.a + - xlnx,xps-ethernetlite-2.01.a + - xlnx,xps-ethernetlite-3.00.a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + phy-handle: true + + local-mac-address: true + + xlnx,tx-ping-pong: + type: boolean + description: hardware supports tx ping pong buffer. + + xlnx,rx-ping-pong: + type: boolean + description: hardware supports rx ping pong buffer. + +required: + - compatible + - reg + - interrupts + - phy-handle + +additionalProperties: false + +examples: + - | + axi_ethernetlite_1: ethernet@40e00000 { + compatible = "xlnx,xps-ethernetlite-3.00.a"; + reg = <0x40e00000 0x10000>; + interrupt-parent = <&axi_intc_1>; + interrupts = <1>; + local-mac-address = [00 00 00 00 00 00]; + phy-handle = <&phy0>; + xlnx,rx-ping-pong; + xlnx,tx-ping-pong; + }; diff --git a/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml new file mode 100644 index 000000000000..682688299b26 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/fsl,scu-ocotp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - OCOTP bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + enum: + - fsl,imx8qm-scu-ocotp + - fsl,imx8qxp-scu-ocotp + +patternProperties: + '^mac@[0-9a-f]*$': + type: object + description: + MAC address. + + properties: + reg: + description: + Byte offset within OCOTP where the MAC address is stored + maxItems: 1 + + required: + - reg + + additionalProperties: false + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + ocotp { + compatible = "fsl,imx8qxp-scu-ocotp"; + #address-cells = <1>; + #size-cells = <1>; + + fec_mac0: mac@2c4 { + reg = <0x2c4 6>; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml new file mode 100644 index 000000000000..b5a1109f2ee1 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/mediatek,efuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek efuse + +description: | + MediaTek's efuse is used for storing calibration data, it can be accessed + on ARM devices usiong I/O mapped memory. + +maintainers: + - Andrew-CT Chen <andrew-ct.chen@mediatek.com> + - Lala Lin <lala.lin@mediatek.com> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + $nodename: + pattern: "^efuse@[0-9a-f]+$" + + compatible: + oneOf: + - items: + - enum: + - mediatek,mt7622-efuse + - mediatek,mt7623-efuse + - mediatek,mt8173-efuse + - mediatek,mt8183-efuse + - mediatek,mt8186-efuse + - mediatek,mt8192-efuse + - mediatek,mt8195-efuse + - mediatek,mt8516-efuse + - const: mediatek,efuse + - const: mediatek,mt8173-efuse + deprecated: true + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + efuse@11c10000 { + compatible = "mediatek,mt8195-efuse", "mediatek,efuse"; + reg = <0x11c10000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + + u3_tx_imp_p0: usb3-tx-imp@184,1 { + reg = <0x184 0x1>; + bits = <0 5>; + }; + u3_rx_imp_p0: usb3-rx-imp@184,2 { + reg = <0x184 0x2>; + bits = <5 5>; + }; + u3_intr_p0: usb3-intr@185 { + reg = <0x185 0x1>; + bits = <2 6>; + }; + comb_tx_imp_p1: usb3-tx-imp@186,1 { + reg = <0x186 0x1>; + bits = <0 5>; + }; + comb_rx_imp_p1: usb3-rx-imp@186,2 { + reg = <0x186 0x2>; + bits = <5 5>; + }; + comb_intr_p1: usb3-intr@187 { + reg = <0x187 0x1>; + bits = <2 6>; + }; + u2_intr_p0: usb2-intr-p0@188,1 { + reg = <0x188 0x1>; + bits = <0 5>; + }; + u2_intr_p1: usb2-intr-p1@188,2 { + reg = <0x188 0x2>; + bits = <5 5>; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml new file mode 100644 index 000000000000..c3c96fd0baac --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/microchip,sama7g5-otpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip SAMA7G5 OTP Controller (OTPC) + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: | + OTP controller drives a NVMEM memory where system specific data + (e.g. calibration data for analog cells, hardware configuration + settings, chip identifiers) or user specific data could be stored. + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + items: + - const: microchip,sama7g5-otpc + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/nvmem/microchip,sama7g5-otpc.h> + + otpc: efuse@e8c00000 { + compatible = "microchip,sama7g5-otpc", "syscon"; + reg = <0xe8c00000 0xec>; + #address-cells = <1>; + #size-cells = <1>; + + temperature_calib: calib@1 { + reg = <OTP_PKT(1) 76>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt deleted file mode 100644 index 39d529599444..000000000000 --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt +++ /dev/null @@ -1,43 +0,0 @@ -= Mediatek MTK-EFUSE device tree bindings = - -This binding is intended to represent MTK-EFUSE which is found in most Mediatek SOCs. - -Required properties: -- compatible: should be - "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622 - "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623 - "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173 - "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192 - "mediatek,mt8195-efuse", "mediatek,efuse": for MT8195 - "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516 -- reg: Should contain registers location and length -- bits: contain the bits range by offset and size - -= Data cells = -Are child nodes of MTK-EFUSE, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example: - - efuse: efuse@10206000 { - compatible = "mediatek,mt8173-efuse"; - reg = <0 0x10206000 0 0x1000>; - #address-cells = <1>; - #size-cells = <1>; - - /* Data cells */ - thermal_calibration: calib@528 { - reg = <0x528 0xc>; - }; - }; - -= Data consumers = -Are device nodes which consume nvmem data cells. - -For example: - - thermal { - ... - nvmem-cells = <&thermal_calibration>; - nvmem-cell-names = "calibration"; - }; diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index 76c8acd981b3..66d0ec763f0b 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -50,6 +50,16 @@ patternProperties: property to uniquely identify the OPP nodes exists. Devices like power domains must have another (implementation dependent) property. + Entries for multiple clocks shall be provided in the same field, as + array of frequencies. The OPP binding doesn't provide any provisions + to relate the values to their clocks or the order in which the clocks + need to be configured and that is left for the implementation + specific binding. + minItems: 1 + maxItems: 16 + items: + maxItems: 1 + opp-microvolt: description: | Voltage for the OPP diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml index 30f7b596d609..59663e897dae 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -98,6 +98,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 0>; operating-points-v2 = <&cluster0_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_0>; L2_0: l2-cache { @@ -115,6 +117,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 0>; operating-points-v2 = <&cluster0_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_0>; }; @@ -128,6 +132,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 1>; operating-points-v2 = <&cluster1_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_1>; L2_1: l2-cache { @@ -145,6 +151,8 @@ examples: capacity-dmips-mhz = <1024>; clocks = <&kryocc 1>; operating-points-v2 = <&cluster1_opp>; + power-domains = <&cpr>; + power-domain-names = "cpr"; #cooling-cells = <2>; next-level-cache = <&L2_1>; }; @@ -182,18 +190,21 @@ examples: opp-microvolt = <905000 905000 1140000>; opp-supported-hw = <0x7>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp1>; }; opp-1401600000 { opp-hz = /bits/ 64 <1401600000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x5>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp2>; }; opp-1593600000 { opp-hz = /bits/ 64 <1593600000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x1>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp3>; }; }; @@ -207,24 +218,28 @@ examples: opp-microvolt = <905000 905000 1140000>; opp-supported-hw = <0x7>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp1>; }; opp-1804800000 { opp-hz = /bits/ 64 <1804800000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x6>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp4>; }; opp-1900800000 { opp-hz = /bits/ 64 <1900800000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x4>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp5>; }; opp-2150400000 { opp-hz = /bits/ 64 <2150400000>; opp-microvolt = <1140000 905000 1140000>; opp-supported-hw = <0x1>; clock-latency-ns = <200000>; + required-opps = <&cpr_opp6>; }; }; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 252e5b72aee0..376e739bcad4 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -144,6 +144,7 @@ properties: description: If present then the reset sequence using the GPIO specified in the "reset-gpio" property is reversed (H=reset state, L=operation state) (optional required). + type: boolean vpcie-supply: description: Should specify the regulator in charge of PCIe port power. diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml index 6bcaa8f2c3cf..d25423aa7167 100644 --- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml @@ -106,6 +106,9 @@ properties: maxItems: 3 dma-coherent: true + iommu-map: true + iommu-map-mask: true + msi-parent: true required: - compatible diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt index 57ae73462272..684227522267 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt @@ -7,6 +7,7 @@ Required properties: "mediatek,mt7622-pcie" "mediatek,mt7623-pcie" "mediatek,mt7629-pcie" + "airoha,en7523-pcie" - device_type: Must be "pci" - reg: Base addresses and lengths of the root ports. - reg-names: Names of the above areas to use during resource lookup. diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml new file mode 100644 index 000000000000..a24fb8307d29 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml @@ -0,0 +1,319 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/nvidia,tegra194-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra194 (and later) PCIe Endpoint controller (Synopsys DesignWare Core based) + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Vidya Sagar <vidyas@nvidia.com> + +description: | + This PCIe controller is based on the Synopsys DesignWare PCIe IP and thus + inherits all the common properties defined in snps,dw-pcie-ep.yaml. Some + of the controller instances are dual mode; they can work either in Root + Port mode or Endpoint mode but one at a time. + + On Tegra194, controllers C0, C4 and C5 support Endpoint mode. + On Tegra234, controllers C5, C6, C7 and C10 support Endpoint mode. + + Note: On Tegra194's P2972-0000 platform, only C5 controller can be enabled to + operate in the Endpoint mode because of the way the platform is designed. + +properties: + compatible: + enum: + - nvidia,tegra194-pcie-ep + - nvidia,tegra234-pcie-ep + + reg: + items: + - description: controller's application logic registers + - description: iATU and DMA registers. This is where the iATU (internal + Address Translation Unit) registers of the PCIe core are made + available for software access. + - description: aperture where the Root Port's own configuration + registers are available. + - description: aperture used to map the remote Root Complex address space + + reg-names: + items: + - const: appl + - const: atu_dma + - const: dbi + - const: addr_space + + interrupts: + items: + - description: controller interrupt + + interrupt-names: + items: + - const: intr + + clocks: + items: + - description: module clock + + clock-names: + items: + - const: core + + resets: + items: + - description: APB bus interface reset + - description: module reset + + reset-names: + items: + - const: apb + - const: core + + reset-gpios: + description: Must contain a phandle to a GPIO controller followed by GPIO + that is being used as PERST input signal. Please refer to pci.txt. + + phys: + minItems: 1 + maxItems: 8 + + phy-names: + minItems: 1 + items: + - const: p2u-0 + - const: p2u-1 + - const: p2u-2 + - const: p2u-3 + - const: p2u-4 + - const: p2u-5 + - const: p2u-6 + - const: p2u-7 + + power-domains: + maxItems: 1 + description: | + A phandle to the node that controls power to the respective PCIe + controller and a specifier name for the PCIe controller. + + Tegra194 specifiers are defined in "include/dt-bindings/power/tegra194-powergate.h" + Tegra234 specifiers are defined in "include/dt-bindings/power/tegra234-powergate.h" + + interconnects: + items: + - description: memory read client + - description: memory write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + dma-coherent: true + + nvidia,bpmp: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + Must contain a pair of phandles to BPMP controller node followed by + controller ID. Following are the controller IDs for each controller: + + Tegra194 + + 0: C0 + 1: C1 + 2: C2 + 3: C3 + 4: C4 + 5: C5 + + Tegra234 + + 0 : C0 + 1 : C1 + 2 : C2 + 3 : C3 + 4 : C4 + 5 : C5 + 6 : C6 + 7 : C7 + 8 : C8 + 9 : C9 + 10: C10 + + items: + - items: + - description: phandle to BPMP controller node + - description: PCIe controller ID + maximum: 10 + + nvidia,aspm-cmrt-us: + description: Common Mode Restore Time for proper operation of ASPM to be + specified in microseconds + + nvidia,aspm-pwr-on-t-us: + description: Power On time for proper operation of ASPM to be specified in + microseconds + + nvidia,aspm-l0s-entrance-latency-us: + description: ASPM L0s entrance latency to be specified in microseconds + + vddio-pex-ctl-supply: + description: A phandle to the regulator supply for PCIe side band signals + + nvidia,refclk-select-gpios: + maxItems: 1 + description: GPIO used to enable REFCLK to controller from the host + + nvidia,enable-ext-refclk: + description: | + This boolean property needs to be present if the controller is configured + to receive Reference Clock from the host. + NOTE: This is applicable only for Tegra234. + + $ref: /schemas/types.yaml#/definitions/flag + + nvidia,enable-srns: + description: | + This boolean property needs to be present if the controller is + configured to operate in SRNS (Separate Reference Clocks with No + Spread-Spectrum Clocking). NOTE: This is applicable only for + Tegra234. + + $ref: /schemas/types.yaml#/definitions/flag + +allOf: + - $ref: /schemas/pci/snps,dw-pcie-ep.yaml# + +unevaluatedProperties: false + +required: + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - reset-names + - power-domains + - reset-gpios + - vddio-pex-ctl-supply + - num-lanes + - phys + - phy-names + - nvidia,bpmp + +examples: + - | + #include <dt-bindings/clock/tegra194-clock.h> + #include <dt-bindings/gpio/tegra194-gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/tegra194-powergate.h> + #include <dt-bindings/reset/tegra194-reset.h> + + bus@0 { + #address-cells = <2>; + #size-cells = <2>; + ranges = <0x0 0x0 0x0 0x8 0x0>; + + pcie-ep@141a0000 { + compatible = "nvidia,tegra194-pcie-ep"; + reg = <0x00 0x141a0000 0x0 0x00020000>, /* appl registers (128K) */ + <0x00 0x3a040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */ + <0x00 0x3a080000 0x0 0x00040000>, /* DBI reg space (256K) */ + <0x1c 0x00000000 0x4 0x00000000>; /* Address Space (16G) */ + reg-names = "appl", "atu_dma", "dbi", "addr_space"; + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */ + interrupt-names = "intr"; + + clocks = <&bpmp TEGRA194_CLK_PEX1_CORE_5>; + clock-names = "core"; + + resets = <&bpmp TEGRA194_RESET_PEX1_CORE_5_APB>, + <&bpmp TEGRA194_RESET_PEX1_CORE_5>; + reset-names = "apb", "core"; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8A>; + pinctrl-names = "default"; + pinctrl-0 = <&clkreq_c5_bi_dir_state>; + + nvidia,bpmp = <&bpmp 5>; + + nvidia,aspm-cmrt-us = <60>; + nvidia,aspm-pwr-on-t-us = <20>; + nvidia,aspm-l0s-entrance-latency-us = <3>; + + vddio-pex-ctl-supply = <&vdd_1v8ao>; + + reset-gpios = <&gpio TEGRA194_MAIN_GPIO(GG, 1) GPIO_ACTIVE_LOW>; + + nvidia,refclk-select-gpios = <&gpio_aon TEGRA194_AON_GPIO(AA, 5) + GPIO_ACTIVE_HIGH>; + + num-lanes = <8>; + + phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>, + <&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>, + <&p2u_nvhs_6>, <&p2u_nvhs_7>; + + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4", + "p2u-5", "p2u-6", "p2u-7"; + }; + }; + + - | + #include <dt-bindings/clock/tegra234-clock.h> + #include <dt-bindings/gpio/tegra234-gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/tegra234-powergate.h> + #include <dt-bindings/reset/tegra234-reset.h> + + bus@0 { + #address-cells = <2>; + #size-cells = <2>; + ranges = <0x0 0x0 0x0 0x8 0x0>; + + pcie-ep@141a0000 { + compatible = "nvidia,tegra234-pcie-ep"; + power-domains = <&bpmp TEGRA234_POWER_DOMAIN_PCIEX8A>; + reg = <0x00 0x141a0000 0x0 0x00020000>, /* appl registers (128K) */ + <0x00 0x3a040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */ + <0x00 0x3a080000 0x0 0x00040000>, /* DBI reg space (256K) */ + <0x27 0x40000000 0x4 0x00000000>; /* Address Space (16G) */ + reg-names = "appl", "atu_dma", "dbi", "addr_space"; + + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */ + interrupt-names = "intr"; + + clocks = <&bpmp TEGRA234_CLK_PEX1_C5_CORE>; + clock-names = "core"; + + resets = <&bpmp TEGRA234_RESET_PEX1_CORE_5_APB>, + <&bpmp TEGRA234_RESET_PEX1_CORE_5>; + reset-names = "apb", "core"; + + nvidia,bpmp = <&bpmp 5>; + + nvidia,enable-ext-refclk; + nvidia,aspm-cmrt-us = <60>; + nvidia,aspm-pwr-on-t-us = <20>; + nvidia,aspm-l0s-entrance-latency-us = <3>; + + vddio-pex-ctl-supply = <&p3701_vdd_1v8_ls>; + + reset-gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>; + + nvidia,refclk-select-gpios = <&gpio_aon + TEGRA234_AON_GPIO(AA, 4) + GPIO_ACTIVE_HIGH>; + + num-lanes = <8>; + + phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>, + <&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>, + <&p2u_nvhs_6>, <&p2u_nvhs_7>; + + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4", + "p2u-5", "p2u-6", "p2u-7"; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt deleted file mode 100644 index 8e4f9bfb316d..000000000000 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt +++ /dev/null @@ -1,245 +0,0 @@ -NVIDIA Tegra PCIe controller (Synopsys DesignWare Core based) - -This PCIe controller is based on the Synopsis Designware PCIe IP -and thus inherits all the common properties defined in snps,dw-pcie.yaml and -snps,dw-pcie-ep.yaml. -Some of the controller instances are dual mode where in they can work either -in root port mode or endpoint mode but one at a time. - -Required properties: -- power-domains: A phandle to the node that controls power to the respective - PCIe controller and a specifier name for the PCIe controller. Following are - the specifiers for the different PCIe controllers - TEGRA194_POWER_DOMAIN_PCIEX8B: C0 - TEGRA194_POWER_DOMAIN_PCIEX1A: C1 - TEGRA194_POWER_DOMAIN_PCIEX1A: C2 - TEGRA194_POWER_DOMAIN_PCIEX1A: C3 - TEGRA194_POWER_DOMAIN_PCIEX4A: C4 - TEGRA194_POWER_DOMAIN_PCIEX8A: C5 - these specifiers are defined in - "include/dt-bindings/power/tegra194-powergate.h" file. -- reg: A list of physical base address and length pairs for each set of - controller registers. Must contain an entry for each entry in the reg-names - property. -- reg-names: Must include the following entries: - "appl": Controller's application logic registers - "config": As per the definition in snps,dw-pcie.yaml - "atu_dma": iATU and DMA registers. This is where the iATU (internal Address - Translation Unit) registers of the PCIe core are made available - for SW access. - "dbi": The aperture where root port's own configuration registers are - available -- 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 Tegra interrupt that is asserted for controller interrupts -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - core -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - apb - - core -- phys: Must contain a phandle to P2U PHY for each entry in phy-names. -- phy-names: Must include an entry for each active lane. - "p2u-N": where N ranges from 0 to one less than the total number of lanes -- nvidia,bpmp: Must contain a pair of phandle to BPMP controller node followed - by controller-id. Following are the controller ids for each controller. - 0: C0 - 1: C1 - 2: C2 - 3: C3 - 4: C4 - 5: C5 -- vddio-pex-ctl-supply: Regulator supply for PCIe side band signals - -RC mode: -- compatible: Tegra19x must contain "nvidia,tegra194-pcie" -- device_type: Must be "pci" for RC mode -- interrupt-names: Must include the following entries: - "msi": The Tegra interrupt that is asserted when an MSI is received -- bus-range: Range of bus numbers associated with this controller -- #address-cells: Address representation for root ports (must be 3) - - cell 0 specifies the bus and device numbers of the root port: - [23:16]: bus number - [15:11]: device number - - cell 1 denotes the upper 32 address bits and should be 0 - - cell 2 contains the lower 32 address bits and is used to translate to the - CPU address space -- #size-cells: Size representation for root ports (must be 2) -- ranges: Describes the translation of addresses for root ports and standard - PCI regions. The entries must be 7 cells each, where the first three cells - correspond to the address as described for the #address-cells property - above, the fourth and fifth cells are for the physical CPU address to - translate to and the sixth and seventh cells are as described for the - #size-cells property above. - - Entries setup the mapping for the standard I/O, memory and - prefetchable PCI regions. The first cell determines the type of region - that is setup: - - 0x81000000: I/O memory region - - 0x82000000: non-prefetchable memory region - - 0xc2000000: prefetchable memory region - Please refer to the standard PCI bus binding document for a more detailed - explanation. -- #interrupt-cells: Size representation for interrupts (must be 1) -- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties - Please refer to the standard PCI bus binding document for a more detailed - explanation. - -EP mode: -In Tegra194, Only controllers C0, C4 & C5 support EP mode. -- compatible: Tegra19x must contain "nvidia,tegra194-pcie-ep" -- reg-names: Must include the following entries: - "addr_space": Used to map remote RC address space -- reset-gpios: Must contain a phandle to a GPIO controller followed by - GPIO that is being used as PERST input signal. Please refer to pci.txt - document. - -Optional properties: -- pinctrl-names: A list of pinctrl state names. - It is mandatory for C5 controller and optional for other controllers. - - "default": Configures PCIe I/O for proper operation. -- pinctrl-0: phandle for the 'default' state of pin configuration. - It is mandatory for C5 controller and optional for other controllers. -- supports-clkreq: Refer to Documentation/devicetree/bindings/pci/pci.txt -- nvidia,update-fc-fixup: This is a boolean property and needs to be present to - improve performance when a platform is designed in such a way that it - satisfies at least one of the following conditions thereby enabling root - port to exchange optimum number of FC (Flow Control) credits with - downstream devices - 1. If C0/C4/C5 run at x1/x2 link widths (irrespective of speed and MPS) - 2. If C0/C1/C2/C3/C4/C5 operate at their respective max link widths and - a) speed is Gen-2 and MPS is 256B - b) speed is >= Gen-3 with any MPS -- nvidia,aspm-cmrt-us: Common Mode Restore Time for proper operation of ASPM - to be specified in microseconds -- nvidia,aspm-pwr-on-t-us: Power On time for proper operation of ASPM to be - specified in microseconds -- nvidia,aspm-l0s-entrance-latency-us: ASPM L0s entrance latency to be - specified in microseconds - -RC mode: -- vpcie3v3-supply: A phandle to the regulator node that supplies 3.3V to the slot - if the platform has one such slot. (Ex:- x16 slot owned by C5 controller - in p2972-0000 platform). -- vpcie12v-supply: A phandle to the regulator node that supplies 12V to the slot - if the platform has one such slot. (Ex:- x16 slot owned by C5 controller - in p2972-0000 platform). - -EP mode: -- nvidia,refclk-select-gpios: Must contain a phandle to a GPIO controller - followed by GPIO that is being used to enable REFCLK to controller from host - -NOTE:- On Tegra194's P2972-0000 platform, only C5 controller can be enabled to -operate in the endpoint mode because of the way the platform is designed. - -Examples: -========= - -Tegra194 RC mode: ------------------ - - pcie@14180000 { - compatible = "nvidia,tegra194-pcie"; - power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>; - reg = <0x00 0x14180000 0x0 0x00020000 /* appl registers (128K) */ - 0x00 0x38000000 0x0 0x00040000 /* configuration space (256K) */ - 0x00 0x38040000 0x0 0x00040000>; /* iATU_DMA reg space (256K) */ - reg-names = "appl", "config", "atu_dma"; - - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - num-lanes = <8>; - linux,pci-domain = <0>; - - pinctrl-names = "default"; - pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>; - - clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>; - clock-names = "core"; - - resets = <&bpmp TEGRA194_RESET_PEX0_CORE_0_APB>, - <&bpmp TEGRA194_RESET_PEX0_CORE_0>; - reset-names = "apb", "core"; - - interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */ - <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */ - interrupt-names = "intr", "msi"; - - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; - - nvidia,bpmp = <&bpmp 0>; - - supports-clkreq; - nvidia,aspm-cmrt-us = <60>; - nvidia,aspm-pwr-on-t-us = <20>; - nvidia,aspm-l0s-entrance-latency-us = <3>; - - bus-range = <0x0 0xff>; - ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000 /* downstream I/O (1MB) */ - 0x82000000 0x0 0x38200000 0x0 0x38200000 0x0 0x01E00000 /* non-prefetchable memory (30MB) */ - 0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */ - - vddio-pex-ctl-supply = <&vdd_1v8ao>; - vpcie3v3-supply = <&vdd_3v3_pcie>; - vpcie12v-supply = <&vdd_12v_pcie>; - - phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>, - <&p2u_hsio_5>; - phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3"; - }; - -Tegra194 EP mode: ------------------ - - pcie-ep@141a0000 { - compatible = "nvidia,tegra194-pcie-ep", "snps,dw-pcie-ep"; - power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8A>; - reg = <0x00 0x141a0000 0x0 0x00020000 /* appl registers (128K) */ - 0x00 0x3a040000 0x0 0x00040000 /* iATU_DMA reg space (256K) */ - 0x00 0x3a080000 0x0 0x00040000 /* DBI reg space (256K) */ - 0x1c 0x00000000 0x4 0x00000000>; /* Address Space (16G) */ - reg-names = "appl", "atu_dma", "dbi", "addr_space"; - - num-lanes = <8>; - num-ib-windows = <2>; - num-ob-windows = <8>; - - pinctrl-names = "default"; - pinctrl-0 = <&clkreq_c5_bi_dir_state>; - - clocks = <&bpmp TEGRA194_CLK_PEX1_CORE_5>; - clock-names = "core"; - - resets = <&bpmp TEGRA194_RESET_PEX1_CORE_5_APB>, - <&bpmp TEGRA194_RESET_PEX1_CORE_5>; - reset-names = "apb", "core"; - - interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */ - interrupt-names = "intr"; - - nvidia,bpmp = <&bpmp 5>; - - nvidia,aspm-cmrt-us = <60>; - nvidia,aspm-pwr-on-t-us = <20>; - nvidia,aspm-l0s-entrance-latency-us = <3>; - - vddio-pex-ctl-supply = <&vdd_1v8ao>; - - reset-gpios = <&gpio TEGRA194_MAIN_GPIO(GG, 1) GPIO_ACTIVE_LOW>; - - nvidia,refclk-select-gpios = <&gpio_aon TEGRA194_AON_GPIO(AA, 5) - GPIO_ACTIVE_HIGH>; - - phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>, - <&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>, - <&p2u_nvhs_6>, <&p2u_nvhs_7>; - - phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4", - "p2u-5", "p2u-6", "p2u-7"; - }; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml new file mode 100644 index 000000000000..75da3e8eecb9 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml @@ -0,0 +1,350 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/nvidia,tegra194-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra194 (and later) PCIe controller (Synopsys DesignWare Core based) + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Vidya Sagar <vidyas@nvidia.com> + +description: | + This PCIe controller is based on the Synopsys DesignWare PCIe IP and thus + inherits all the common properties defined in snps,dw-pcie.yaml. Some of + the controller instances are dual mode where in they can work either in + Root Port mode or Endpoint mode but one at a time. + + See nvidia,tegra194-pcie-ep.yaml for details on the Endpoint mode device + tree bindings. + +properties: + compatible: + enum: + - nvidia,tegra194-pcie + - nvidia,tegra234-pcie + + reg: + items: + - description: controller's application logic registers + - description: configuration registers + - description: iATU and DMA registers. This is where the iATU (internal + Address Translation Unit) registers of the PCIe core are made + available for software access. + - description: aperture where the Root Port's own configuration + registers are available. + + reg-names: + items: + - const: appl + - const: config + - const: atu_dma + - const: dbi + + interrupts: + items: + - description: controller interrupt + - description: MSI interrupt + + interrupt-names: + items: + - const: intr + - const: msi + + clocks: + items: + - description: module clock + + clock-names: + items: + - const: core + + resets: + items: + - description: APB bus interface reset + - description: module reset + + reset-names: + items: + - const: apb + - const: core + + phys: + minItems: 1 + maxItems: 8 + + phy-names: + minItems: 1 + items: + - const: p2u-0 + - const: p2u-1 + - const: p2u-2 + - const: p2u-3 + - const: p2u-4 + - const: p2u-5 + - const: p2u-6 + - const: p2u-7 + + power-domains: + maxItems: 1 + description: | + A phandle to the node that controls power to the respective PCIe + controller and a specifier name for the PCIe controller. + + Tegra194 specifiers defined in "include/dt-bindings/power/tegra194-powergate.h" + Tegra234 specifiers defined in "include/dt-bindings/power/tegra234-powergate.h" + + interconnects: + items: + - description: memory read client + - description: memory write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + dma-coherent: true + + nvidia,bpmp: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + Must contain a pair of phandles to BPMP controller node followed by + controller ID. Following are the controller IDs for each controller: + + Tegra194 + + 0: C0 + 1: C1 + 2: C2 + 3: C3 + 4: C4 + 5: C5 + + Tegra234 + + 0 : C0 + 1 : C1 + 2 : C2 + 3 : C3 + 4 : C4 + 5 : C5 + 6 : C6 + 7 : C7 + 8 : C8 + 9 : C9 + 10: C10 + + items: + - items: + - description: phandle to BPMP controller node + - description: PCIe controller ID + maximum: 10 + + nvidia,update-fc-fixup: + description: | + This is a boolean property and needs to be present to improve performance + when a platform is designed in such a way that it satisfies at least one + of the following conditions thereby enabling Root Port to exchange + optimum number of FC (Flow Control) credits with downstream devices: + + NOTE: This is applicable only for Tegra194. + + 1. If C0/C4/C5 run at x1/x2 link widths (irrespective of speed and MPS) + 2. If C0/C1/C2/C3/C4/C5 operate at their respective max link widths and + a) speed is Gen-2 and MPS is 256B + b) speed is >= Gen-3 with any MPS + + $ref: /schemas/types.yaml#/definitions/flag + + nvidia,aspm-cmrt-us: + description: Common Mode Restore Time for proper operation of ASPM to be + specified in microseconds + + nvidia,aspm-pwr-on-t-us: + description: Power On time for proper operation of ASPM to be specified in + microseconds + + nvidia,aspm-l0s-entrance-latency-us: + description: ASPM L0s entrance latency to be specified in microseconds + + vddio-pex-ctl-supply: + description: A phandle to the regulator supply for PCIe side band signals. + + vpcie3v3-supply: + description: A phandle to the regulator node that supplies 3.3V to the slot + if the platform has one such slot, e.g., x16 slot owned by C5 controller + in p2972-0000 platform. + + vpcie12v-supply: + description: A phandle to the regulator node that supplies 12V to the slot + if the platform has one such slot, e.g., x16 slot owned by C5 controller + in p2972-0000 platform. + + nvidia,enable-srns: + description: | + This boolean property needs to be present if the controller is + configured to operate in SRNS (Separate Reference Clocks with No + Spread-Spectrum Clocking). NOTE: This is applicable only for + Tegra234. + + $ref: /schemas/types.yaml#/definitions/flag + + nvidia,enable-ext-refclk: + description: | + This boolean property needs to be present if the controller is + configured to use the reference clocking coming in from an external + clock source instead of using the internal clock source. + + $ref: /schemas/types.yaml#/definitions/flag + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +unevaluatedProperties: false + +required: + - interrupts + - interrupt-names + - interrupt-map + - interrupt-map-mask + - clocks + - clock-names + - resets + - reset-names + - power-domains + - vddio-pex-ctl-supply + - num-lanes + - phys + - phy-names + - nvidia,bpmp + +examples: + - | + #include <dt-bindings/clock/tegra194-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/tegra194-powergate.h> + #include <dt-bindings/reset/tegra194-reset.h> + + bus@0 { + #address-cells = <2>; + #size-cells = <2>; + ranges = <0x0 0x0 0x0 0x8 0x0>; + + pcie@14180000 { + compatible = "nvidia,tegra194-pcie"; + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>; + reg = <0x0 0x14180000 0x0 0x00020000>, /* appl registers (128K) */ + <0x0 0x38000000 0x0 0x00040000>, /* configuration space (256K) */ + <0x0 0x38040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */ + <0x0 0x38080000 0x0 0x00040000>; /* DBI reg space (256K) */ + reg-names = "appl", "config", "atu_dma", "dbi"; + + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + num-lanes = <8>; + linux,pci-domain = <0>; + + pinctrl-names = "default"; + pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>; + + clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>; + clock-names = "core"; + + resets = <&bpmp TEGRA194_RESET_PEX0_CORE_0_APB>, + <&bpmp TEGRA194_RESET_PEX0_CORE_0>; + reset-names = "apb", "core"; + + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */ + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */ + interrupt-names = "intr", "msi"; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + + nvidia,bpmp = <&bpmp 0>; + + supports-clkreq; + nvidia,aspm-cmrt-us = <60>; + nvidia,aspm-pwr-on-t-us = <20>; + nvidia,aspm-l0s-entrance-latency-us = <3>; + + bus-range = <0x0 0xff>; + ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000>, /* downstream I/O */ + <0x82000000 0x0 0x38200000 0x0 0x38200000 0x0 0x01e00000>, /* non-prefetch memory */ + <0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory */ + + vddio-pex-ctl-supply = <&vdd_1v8ao>; + vpcie3v3-supply = <&vdd_3v3_pcie>; + vpcie12v-supply = <&vdd_12v_pcie>; + + phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>, + <&p2u_hsio_5>; + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3"; + }; + }; + + - | + #include <dt-bindings/clock/tegra234-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/tegra234-powergate.h> + #include <dt-bindings/reset/tegra234-reset.h> + + bus@0 { + #address-cells = <2>; + #size-cells = <2>; + ranges = <0x0 0x0 0x0 0x8 0x0>; + + pcie@14160000 { + compatible = "nvidia,tegra234-pcie"; + power-domains = <&bpmp TEGRA234_POWER_DOMAIN_PCIEX4BB>; + reg = <0x00 0x14160000 0x0 0x00020000>, /* appl registers (128K) */ + <0x00 0x36000000 0x0 0x00040000>, /* configuration space (256K) */ + <0x00 0x36040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */ + <0x00 0x36080000 0x0 0x00040000>; /* DBI reg space (256K) */ + reg-names = "appl", "config", "atu_dma", "dbi"; + + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + num-lanes = <4>; + num-viewport = <8>; + linux,pci-domain = <4>; + + clocks = <&bpmp TEGRA234_CLK_PEX0_C4_CORE>; + clock-names = "core"; + + resets = <&bpmp TEGRA234_RESET_PEX0_CORE_4_APB>, + <&bpmp TEGRA234_RESET_PEX0_CORE_4>; + reset-names = "apb", "core"; + + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */ + <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */ + interrupt-names = "intr", "msi"; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>; + + nvidia,bpmp = <&bpmp 4>; + + nvidia,aspm-cmrt-us = <60>; + nvidia,aspm-pwr-on-t-us = <20>; + nvidia,aspm-l0s-entrance-latency-us = <3>; + + bus-range = <0x0 0xff>; + ranges = <0x43000000 0x21 0x40000000 0x21 0x40000000 0x2 0xe8000000>, /* prefetchable */ + <0x02000000 0x0 0x40000000 0x24 0x28000000 0x0 0x08000000>, /* non-prefetchable */ + <0x01000000 0x0 0x36100000 0x00 0x36100000 0x0 0x00100000>; /* downstream I/O */ + + vddio-pex-ctl-supply = <&p3701_vdd_AO_1v8>; + + phys = <&p2u_hsio_4>, <&p2u_hsio_5>, <&p2u_hsio_6>, + <&p2u_hsio_7>; + phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3"; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt deleted file mode 100644 index aeba38f0a387..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt +++ /dev/null @@ -1,84 +0,0 @@ -Renesas AHB to PCI bridge -------------------------- - -This is the bridge used internally to connect the USB controllers to the -AHB. There is one bridge instance per USB port connected to the internal -OHCI and EHCI controllers. - -Required properties: -- compatible: "renesas,pci-r8a7742" for the R8A7742 SoC; - "renesas,pci-r8a7743" for the R8A7743 SoC; - "renesas,pci-r8a7744" for the R8A7744 SoC; - "renesas,pci-r8a7745" for the R8A7745 SoC; - "renesas,pci-r8a7790" for the R8A7790 SoC; - "renesas,pci-r8a7791" for the R8A7791 SoC; - "renesas,pci-r8a7793" for the R8A7793 SoC; - "renesas,pci-r8a7794" for the R8A7794 SoC; - "renesas,pci-rcar-gen2" for a generic R-Car Gen2 or - RZ/G1 compatible device. - - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: A list of physical regions to access the device: the first is - the operational registers for the OHCI/EHCI controllers and the - second is for the bridge configuration and control registers. -- interrupts: interrupt for the device. -- clocks: The reference to the device clock. -- bus-range: The PCI bus number range; as this is a single bus, the range - should be specified as the same value twice. -- #address-cells: must be 3. -- #size-cells: must be 2. -- #interrupt-cells: must be 1. -- interrupt-map: standard property used to define the mapping of the PCI - interrupts to the GIC interrupts. -- interrupt-map-mask: standard property that helps to define the interrupt - mapping. - -Optional properties: -- dma-ranges: a single range for the inbound memory region. If not supplied, - defaults to 1GiB at 0x40000000. Note there are hardware restrictions on the - allowed combinations of address and size. - -Example SoC configuration: - - pci0: pci@ee090000 { - compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2"; - clocks = <&mstp7_clks R8A7790_CLK_EHCI>; - reg = <0x0 0xee090000 0x0 0xc00>, - <0x0 0xee080000 0x0 0x1100>; - interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; - status = "disabled"; - - bus-range = <0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>; - interrupt-map-mask = <0xff00 0 0 0x7>; - interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH - 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH - 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>; - - usb@1,0 { - reg = <0x800 0 0 0 0>; - phys = <&usb0 0>; - phy-names = "usb"; - }; - - usb@2,0 { - reg = <0x1000 0 0 0 0>; - phys = <&usb0 0>; - phy-names = "usb"; - }; - }; - -Example board setup: - -&pci0 { - status = "okay"; - pinctrl-0 = <&usb0_pins>; - pinctrl-names = "default"; -}; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index 0b69b12b849e..7d29e2a45183 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -11,7 +11,7 @@ maintainers: - Stanimir Varbanov <svarbanov@mm-sol.com> description: | - Qualcomm PCIe root complex controller is bansed on the Synopsys DesignWare + Qualcomm PCIe root complex controller is based on the Synopsys DesignWare PCIe IP. properties: @@ -43,11 +43,12 @@ properties: maxItems: 5 interrupts: - maxItems: 1 + minItems: 1 + maxItems: 8 interrupt-names: - items: - - const: msi + minItems: 1 + maxItems: 8 # Common definitions for clocks, clock-names and reset. # Platform constraints are described later. @@ -614,7 +615,7 @@ allOf: - if: not: properties: - compatibles: + compatible: contains: enum: - qcom,pcie-msm8996 @@ -623,6 +624,50 @@ allOf: - resets - reset-names + # Newer chipsets support either 1 or 8 MSI vectors + # On older chipsets it's always 1 MSI vector + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-msm8996 + - qcom,pcie-sc7280 + - qcom,pcie-sc8180x + - qcom,pcie-sdm845 + - qcom,pcie-sm8150 + - qcom,pcie-sm8250 + - qcom,pcie-sm8450-pcie0 + - qcom,pcie-sm8450-pcie1 + then: + oneOf: + - properties: + interrupts: + maxItems: 1 + interrupt-names: + items: + - const: msi + - properties: + interrupts: + minItems: 8 + interrupt-names: + items: + - const: msi0 + - const: msi1 + - const: msi2 + - const: msi3 + - const: msi4 + - const: msi5 + - const: msi6 + - const: msi7 + else: + properties: + interrupts: + maxItems: 1 + interrupt-names: + items: + - const: msi + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml b/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml new file mode 100644 index 000000000000..0f18cceba3d5 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml @@ -0,0 +1,186 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/renesas,pci-rcar-gen2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas AHB to PCI bridge + +maintainers: + - Marek Vasut <marek.vasut+renesas@gmail.com> + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +description: | + This is the bridge used internally to connect the USB controllers to the + AHB. There is one bridge instance per USB port connected to the internal + OHCI and EHCI controllers. + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,pci-r8a7742 # RZ/G1H + - renesas,pci-r8a7743 # RZ/G1M + - renesas,pci-r8a7744 # RZ/G1N + - renesas,pci-r8a7745 # RZ/G1E + - renesas,pci-r8a7790 # R-Car H2 + - renesas,pci-r8a7791 # R-Car M2-W + - renesas,pci-r8a7793 # R-Car M2-N + - renesas,pci-r8a7794 # R-Car E2 + - const: renesas,pci-rcar-gen2 # R-Car Gen2 and RZ/G1 + - items: + - enum: + - renesas,pci-r9a06g032 # RZ/N1D + - const: renesas,pci-rzn1 # RZ/N1 + + reg: + items: + - description: Operational registers for the OHCI/EHCI controllers. + - description: Bridge configuration and control registers. + + interrupts: + maxItems: 1 + + clocks: true + + clock-names: true + + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + + bus-range: + description: | + The PCI bus number range; as this is a single bus, the range + should be specified as the same value twice. + + dma-ranges: + description: | + A single range for the inbound memory region. If not supplied, + defaults to 1GiB at 0x40000000. Note there are hardware restrictions on + the allowed combinations of address and size. + maxItems: 1 + +patternProperties: + 'usb@[0-1],0': + type: object + + description: + This a USB controller PCI device + + properties: + reg: + description: + Identify the correct bus, device and function number in the + form <bdf 0 0 0 0>. + + items: + minItems: 5 + maxItems: 5 + + phys: + description: + Reference to the USB phy + maxItems: 1 + + phy-names: + maxItems: 1 + + required: + - reg + - phys + - phy-names + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-map + - interrupt-map-mask + - clocks + - power-domains + - bus-range + - "#address-cells" + - "#size-cells" + - "#interrupt-cells" + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,pci-rzn1 + then: + properties: + clocks: + items: + - description: Internal bus clock (AHB) for HOST + - description: Internal bus clock (AHB) Power Management + - description: PCI clock for USB subsystem + clock-names: + items: + - const: hclkh + - const: hclkpm + - const: pciclk + required: + - clock-names + else: + properties: + clocks: + items: + - description: Device clock + clock-names: + items: + - const: pclk + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + pci@ee090000 { + compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2"; + device_type = "pci"; + reg = <0xee090000 0xc00>, + <0xee080000 0x1100>; + clocks = <&cpg CPG_MOD 703>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 703>; + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; + + bus-range = <0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x02000000 0 0xee080000 0xee080000 0 0x00010000>; + dma-ranges = <0x42000000 0 0x40000000 0x40000000 0 0x40000000>; + interrupt-map-mask = <0xf800 0 0 0x7>; + interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, + <0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, + <0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; + + usb@1,0 { + reg = <0x800 0 0 0 0>; + phys = <&usb0 0>; + phy-names = "usb"; + }; + + usb@2,0 { + reg = <0x1000 0 0 0 0>; + phys = <&usb0 0>; + phy-names = "usb"; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index c90e5e2d25f6..7287d395e1b6 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -34,8 +34,8 @@ properties: minItems: 2 maxItems: 5 items: - enum: [ dbi, dbi2, config, atu, app, elbi, mgmt, ctrl, parf, cfg, link, - ulreg, smu, mpu, apb, phy ] + enum: [ dbi, dbi2, config, atu, atu_dma, app, appl, elbi, mgmt, ctrl, + parf, cfg, link, ulreg, smu, mpu, apb, phy ] num-lanes: description: | diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml index cca395317a4c..24ddc2855b94 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -14,17 +14,23 @@ allOf: properties: compatible: - const: xlnx,versal-cpm-host-1.00 + enum: + - xlnx,versal-cpm-host-1.00 + - xlnx,versal-cpm5-host reg: items: - description: CPM system level control and status registers. - description: Configuration space region and bridge registers. + - description: CPM5 control and status registers. + minItems: 2 reg-names: items: - const: cpm_slcr - const: cfg + - const: cpm_csr + minItems: 2 interrupts: maxItems: 1 @@ -95,4 +101,34 @@ examples: interrupt-controller; }; }; + + cpm5_pcie: pcie@fcdd0000 { + compatible = "xlnx,versal-cpm5-host"; + device_type = "pci"; + #address-cells = <3>; + #interrupt-cells = <1>; + #size-cells = <2>; + interrupts = <0 72 4>; + interrupt-parent = <&gic>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc_1 0>, + <0 0 0 2 &pcie_intc_1 1>, + <0 0 0 3 &pcie_intc_1 2>, + <0 0 0 4 &pcie_intc_1 3>; + bus-range = <0x00 0xff>; + ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>, + <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>; + msi-map = <0x0 &its_gic 0x0 0x10000>; + reg = <0x00 0xfcdd0000 0x00 0x1000>, + <0x06 0x00000000 0x00 0x1000000>, + <0x00 0xfce20000 0x00 0x1000000>; + reg-names = "cpm_slcr", "cfg", "cpm_csr"; + + pcie_intc_1: interrupt-controller { + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/perf/arm,ccn.yaml b/Documentation/devicetree/bindings/perf/arm,ccn.yaml new file mode 100644 index 000000000000..0b0bb2091016 --- /dev/null +++ b/Documentation/devicetree/bindings/perf/arm,ccn.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/arm,ccn.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM CCN (Cache Coherent Network) Performance Monitors + +maintainers: + - Robin Murphy <robin.murphy@arm.com> + +properties: + compatible: + enum: + - arm,ccn-502 + - arm,ccn-504 + - arm,ccn-508 + - arm,ccn-512 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + ccn@20000000 { + compatible = "arm,ccn-504"; + reg = <0x20000000 0x1000000>; + interrupts = <0 181 4>; + }; +... diff --git a/Documentation/devicetree/bindings/perf/arm-ccn.txt b/Documentation/devicetree/bindings/perf/arm-ccn.txt deleted file mode 100644 index 1c53b5aa3317..000000000000 --- a/Documentation/devicetree/bindings/perf/arm-ccn.txt +++ /dev/null @@ -1,23 +0,0 @@ -* ARM CCN (Cache Coherent Network) - -Required properties: - -- compatible: (standard compatible string) should be one of: - "arm,ccn-502" - "arm,ccn-504" - "arm,ccn-508" - "arm,ccn-512" - -- reg: (standard registers property) physical address and size - (16MB) of the configuration registers block - -- interrupts: (standard interrupt property) single interrupt - generated by the control block - -Example: - - ccn@2000000000 { - compatible = "arm,ccn-504"; - reg = <0x20 0x00000000 0 0x1000000>; - interrupts = <0 181 4>; - }; diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml new file mode 100644 index 000000000000..7aa0c05d6ce4 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic G12A MIPI analog PHY + +maintainers: + - Neil Armstrong <narmstrong@baylibre.com> + +properties: + compatible: + const: amlogic,g12a-mipi-dphy-analog + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + phy@0 { + compatible = "amlogic,g12a-mipi-dphy-analog"; + reg = <0x0 0xc>; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml index 4d01f3124e1c..a90fa1baadab 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml @@ -16,7 +16,7 @@ description: |+ - compatible: Should be the following: "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon" - Refer to the the bindings described in + Refer to the bindings described in Documentation/devicetree/bindings/mfd/syscon.yaml properties: diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml index c50629bd1b51..f0e9ca8427bb 100644 --- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml @@ -11,8 +11,9 @@ maintainers: properties: compatible: - items: - - const: cdns,dphy + enum: + - cdns,dphy + - ti,j721e-dphy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8qm-lvds-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8qm-lvds-phy.yaml new file mode 100644 index 000000000000..8767e48c71a6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,imx8qm-lvds-phy.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,imx8qm-lvds-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mixel LVDS PHY for Freescale i.MX8qm SoC + +maintainers: + - Liu Ying <victor.liu@nxp.com> + +description: | + The Mixel LVDS PHY IP block is found on Freescale i.MX8qm SoC. + It converts two groups of four 7/10 bits of CMOS data into two + groups of four data lanes of LVDS data streams. A phase-locked + transmit clock is transmitted in parallel with each group of + data streams over a fifth LVDS link. Every cycle of the transmit + clock, 56/80 bits of input data are sampled and transmitted + through the two groups of LVDS data streams. Together with the + transmit clocks, the two groups of LVDS data streams form two + LVDS channels. + + The Mixel LVDS PHY found on Freescale i.MX8qm SoC is controlled + by Control and Status Registers(CSR) module in the SoC. The CSR + module, as a system controller, contains the PHY's registers. + +properties: + compatible: + enum: + - fsl,imx8qm-lvds-phy + - mixel,28fdsoi-lvds-1250-8ch-tx-pll + + "#phy-cells": + const: 1 + description: | + Cell allows setting the LVDS channel index of the PHY. + Index 0 is for LVDS channel0 and index 1 is for LVDS channel1. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - "#phy-cells" + - clocks + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/firmware/imx/rsrc.h> + phy { + compatible = "fsl,imx8qm-lvds-phy"; + #phy-cells = <1>; + clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_PHY>; + power-domains = <&pd IMX_SC_R_LVDS_0>; + }; diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml index 6e4d795f9b02..9c2a7345955d 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml @@ -24,6 +24,10 @@ properties: - enum: - mediatek,mt7623-mipi-tx - const: mediatek,mt2701-mipi-tx + - items: + - enum: + - mediatek,mt8365-mipi-tx + - const: mediatek,mt8183-mipi-tx - const: mediatek,mt2701-mipi-tx - const: mediatek,mt8173-mipi-tx - const: mediatek,mt8183-mipi-tx diff --git a/Documentation/devicetree/bindings/phy/mediatek,pcie-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,pcie-phy.yaml new file mode 100644 index 000000000000..422750cc4121 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,pcie-phy.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek PCIe PHY + +maintainers: + - Jianjun Wang <jianjun.wang@mediatek.com> + +description: | + The PCIe PHY supports physical layer functionality for PCIe Gen3 port. + +properties: + compatible: + const: mediatek,mt8195-pcie-phy + + reg: + maxItems: 1 + + reg-names: + items: + - const: sif + + "#phy-cells": + const: 0 + + nvmem-cells: + maxItems: 7 + description: + Phandles to nvmem cell that contains the efuse data, if unspecified, + default value is used. + + nvmem-cell-names: + items: + - const: glb_intr + - const: tx_ln0_pmos + - const: tx_ln0_nmos + - const: rx_ln0 + - const: tx_ln1_pmos + - const: tx_ln1_nmos + - const: rx_ln1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + phy@11e80000 { + compatible = "mediatek,mt8195-pcie-phy"; + #phy-cells = <0>; + reg = <0x11e80000 0x10000>; + reg-names = "sif"; + nvmem-cells = <&pciephy_glb_intr>, + <&pciephy_tx_ln0_pmos>, + <&pciephy_tx_ln0_nmos>, + <&pciephy_rx_ln0>, + <&pciephy_tx_ln1_pmos>, + <&pciephy_tx_ln1_nmos>, + <&pciephy_rx_ln1>; + nvmem-cell-names = "glb_intr", "tx_ln0_pmos", + "tx_ln0_nmos", "rx_ln0", + "tx_ln1_pmos", "tx_ln1_nmos", + "rx_ln1"; + power-domains = <&spm 2>; + }; diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 7b2e1bc119be..b3e409988c17 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -82,9 +82,11 @@ properties: - mediatek,mt8183-tphy - mediatek,mt8186-tphy - mediatek,mt8192-tphy + - mediatek,mt8365-tphy - const: mediatek,generic-tphy-v2 - items: - enum: + - mediatek,mt8188-tphy - mediatek,mt8195-tphy - const: mediatek,generic-tphy-v3 - const: mediatek,mt2701-u3phy diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt index c9f5c0caf8a9..c9e392c64a7c 100644 --- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt @@ -8,6 +8,7 @@ Required properties: * "fsl,vf610-usbphy" for Vybrid vf610 * "fsl,imx6sx-usbphy" for imx6sx * "fsl,imx7ulp-usbphy" for imx7ulp + * "fsl,imx8dxl-usbphy" for imx8dxl "fsl,imx23-usbphy" is still a fallback for other strings - reg: Should contain registers location and length - interrupts: Should contain phy interrupt diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml index 9a89d05efbda..4dc5205d893b 100644 --- a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml @@ -4,7 +4,7 @@ $id: "http://devicetree.org/schemas/phy/phy-tegra194-p2u.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: NVIDIA Tegra194 P2U binding +title: NVIDIA Tegra194 & Tegra234 P2U binding maintainers: - Thierry Reding <treding@nvidia.com> @@ -12,13 +12,17 @@ maintainers: description: > Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High Speed) each interfacing with 12 and 8 P2U instances respectively. + Tegra234 has three PHY bricks namely HSIO, NVHS and GBE (Gigabit Ethernet) + each interfacing with 8, 8 and 8 P2U instances respectively. A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's PIPE - interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe - lane. + interface and PHY of HSIO/NVHS/GBE bricks. Each P2U instance represents one + PCIe lane. properties: compatible: - const: nvidia,tegra194-p2u + enum: + - nvidia,tegra194-p2u + - nvidia,tegra234-p2u reg: maxItems: 1 @@ -28,6 +32,11 @@ properties: items: - const: ctl + nvidia,skip-sz-protect-en: + description: Should be present if two PCIe retimers are present between + the root port and its immediate downstream device. + type: boolean + '#phy-cells': const: 0 diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml index a5850ff529f8..cf9e9b8011cb 100644 --- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml @@ -41,6 +41,9 @@ properties: "#phy-cells": const: 0 + vdda-phy-supply: true + vdda-pll-supply: true + required: - compatible - reg @@ -65,5 +68,8 @@ examples: #clock-cells = <1>; #phy-cells = <0>; + + vdda-phy-supply = <&vdd_a_edp_0_1p2>; + vdda-pll-supply = <&vdd_a_edp_0_0p9>; }; ... diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml new file mode 100644 index 000000000000..fdb277edebeb --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/phy/qcom,hdmi-phy-other.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Adreno/Snapdragon HDMI phy + +maintainers: + - Rob Clark <robdclark@gmail.com> + +properties: + compatible: + enum: + - qcom,hdmi-phy-8660 + - qcom,hdmi-phy-8960 + - qcom,hdmi-phy-8974 + - qcom,hdmi-phy-8084 + + reg: + maxItems: 2 + + reg-names: + items: + - const: hdmi_phy + - const: hdmi_pll + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + + power-domains: + maxItems: 1 + + core-vdda-supply: + description: phandle to VDDA supply regulator + + vddio-supply: + description: phandle to VDD I/O supply regulator + + '#phy-cells': + const: 0 + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,hdmi-phy-8660 + - qcom,hdmi-phy-8960 + then: + properties: + clocks: + maxItems: 1 + clock-names: + items: + - const: slave_iface + vddio-supply: false + + - if: + properties: + compatible: + contains: + enum: + - qcom,hdmi-phy-8084 + - qcom,hdmi-phy-8974 + then: + properties: + clocks: + maxItems: 2 + clock-names: + items: + - const: iface + - const: alt_iface + +required: + - compatible + - clocks + - reg + - reg-names + - '#phy-cells' + +additionalProperties: false + +examples: + - | + hdmi_phy: phy@4a00400 { + compatible = "qcom,hdmi-phy-8960"; + reg-names = "hdmi_phy", + "hdmi_pll"; + reg = <0x4a00400 0x60>, + <0x4a00500 0x100>; + #phy-cells = <0>; + power-domains = <&mmcc 1>; + clock-names = "slave_iface"; + clocks = <&clk 21>; + core-vdda-supply = <&pm8921_hdmi_mvs>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml new file mode 100644 index 000000000000..eea2e02678ed --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/phy/qcom,hdmi-phy-qmp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Adreno/Snapdragon QMP HDMI phy + +maintainers: + - Rob Clark <robdclark@gmail.com> + +properties: + compatible: + enum: + - qcom,hdmi-phy-8996 + + reg: + maxItems: 6 + + reg-names: + items: + - const: hdmi_pll + - const: hdmi_tx_l0 + - const: hdmi_tx_l1 + - const: hdmi_tx_l2 + - const: hdmi_tx_l3 + - const: hdmi_phy + + clocks: + maxItems: 2 + + clock-names: + items: + - const: iface + - const: ref + + power-domains: + maxItems: 1 + + vcca-supply: + description: phandle to VCCA supply regulator + + vddio-supply: + description: phandle to VDD I/O supply regulator + + '#phy-cells': + const: 0 + +required: + - compatible + - clocks + - clock-names + - reg + - reg-names + - '#phy-cells' + +additionalProperties: false + +examples: + - | + hdmi-phy@9a0600 { + compatible = "qcom,hdmi-phy-8996"; + reg = <0x009a0600 0x1c4>, + <0x009a0a00 0x124>, + <0x009a0c00 0x124>, + <0x009a0e00 0x124>, + <0x009a1000 0x124>, + <0x009a1200 0x0c8>; + reg-names = "hdmi_pll", + "hdmi_tx_l0", + "hdmi_tx_l1", + "hdmi_tx_l2", + "hdmi_tx_l3", + "hdmi_phy"; + + clocks = <&mmcc 116>, + <&gcc 214>; + clock-names = "iface", + "ref"; + #phy-cells = <0>; + + vddio-supply = <&vreg_l12a_1p8>; + vcca-supply = <&vreg_l28a_0p925>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 8b850c5ab116..220788ce215f 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,ipq6018-qmp-pcie-phy - qcom,ipq6018-qmp-usb3-phy + - qcom,ipq8074-qmp-gen3-pcie-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy @@ -312,6 +313,7 @@ allOf: contains: enum: - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq8074-qmp-gen3-pcie-phy - qcom,ipq8074-qmp-pcie-phy then: properties: diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml index b8483f9edbfc..fe57c5373d18 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml @@ -34,7 +34,7 @@ properties: # must not be 0. minItems: 2 items: - - const: usb3-if # The funcional clock + - const: usb3-if # The functional clock - const: usb3s_clk # The usb3's external clock - const: usb_extal # The usb2's external clock diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml index 3e5f035de2e9..efc679c385ab 100644 --- a/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml @@ -8,7 +8,6 @@ title: Samsung Exynos SoC HDMI PHY maintainers: - Inki Dae <inki.dae@samsung.com> - - Joonyoung Shim <jy0922.shim@samsung.com> - Seung-Woo Kim <sw0312.kim@samsung.com> - Kyungmin Park <kyungmin.park@samsung.com> - Krzysztof Kozlowski <krzk@kernel.org> diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml index f6ed1a005e7a..8da99461e817 100644 --- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -17,6 +17,7 @@ properties: enum: - samsung,exynos7-ufs-phy - samsung,exynosautov9-ufs-phy + - tesla,fsd-ufs-phy reg: maxItems: 1 @@ -40,9 +41,17 @@ properties: - const: tx0_symbol_clk samsung,pmu-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' - description: phandle for PMU system controller interface, used to - control pmu registers bits for ufs m-phy + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + items: + minItems: 1 + items: + - description: phandle for PMU system controller interface, used to + control pmu registers bits for ufs m-phy + - description: offset of the pmu control register + description: + It can be phandle/offset pair. The second cell which can represent an + offset is optional. required: - "#phy-cells" diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index bfce850c2035..d19d65c870aa 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -46,6 +46,7 @@ properties: - allwinner,sun8i-v3s-pinctrl - allwinner,sun9i-a80-pinctrl - allwinner,sun9i-a80-r-pinctrl + - allwinner,sun20i-d1-pinctrl - allwinner,sun50i-a64-pinctrl - allwinner,sun50i-a64-r-pinctrl - allwinner,sun50i-a100-pinctrl @@ -80,9 +81,6 @@ properties: - const: hosc - const: losc - resets: - maxItems: 1 - gpio-controller: true interrupt-controller: true gpio-line-names: true @@ -127,20 +125,17 @@ patternProperties: additionalProperties: false - "^vcc-p[a-hlm]-supply$": + "^vcc-p[a-ilm]-supply$": description: Power supplies for pin banks. required: - "#gpio-cells" - - "#interrupt-cells" - compatible - reg - - interrupts - clocks - clock-names - gpio-controller - - interrupt-controller allOf: # FIXME: We should have the pin bank supplies here, but not a lot of @@ -149,6 +144,19 @@ allOf: - $ref: "pinctrl.yaml#" - if: + not: + properties: + compatible: + enum: + - allwinner,sun50i-h616-r-pinctrl + + then: + required: + - "#interrupt-cells" + - interrupts + - interrupt-controller + + - if: properties: compatible: enum: @@ -175,6 +183,18 @@ allOf: properties: compatible: enum: + - allwinner,sun20i-d1-pinctrl + + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + + - if: + properties: + compatible: + enum: - allwinner,sun9i-a80-pinctrl then: diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml index c689bea7ce6e..d3a8911728d0 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml @@ -16,7 +16,7 @@ description: |+ - compatible: Should be one of the following: "aspeed,ast2400-scu", "syscon", "simple-mfd" - Refer to the the bindings described in + Refer to the bindings described in Documentation/devicetree/bindings/mfd/syscon.yaml properties: diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 9db904a528ee..5d2c1b1fb7fd 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -17,7 +17,7 @@ description: |+ "aspeed,ast2500-scu", "syscon", "simple-mfd" "aspeed,g5-scu", "syscon", "simple-mfd" - Refer to the the bindings described in + Refer to the bindings described in Documentation/devicetree/bindings/mfd/syscon.yaml properties: diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index 3666ac5b6518..e92686d2f062 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -16,7 +16,7 @@ description: |+ - compatible: Should be one of the following: "aspeed,ast2600-scu", "syscon", "simple-mfd" - Refer to the the bindings described in + Refer to the bindings described in Documentation/devicetree/bindings/mfd/syscon.yaml properties: diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml new file mode 100644 index 000000000000..45ea565ce238 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,scu-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - Pinctrl bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + This binding uses the i.MX common pinctrl binding. + (Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt) + +allOf: + - $ref: pinctrl.yaml# + +properties: + compatible: + enum: + - fsl,imx8qm-iomuxc + - fsl,imx8qxp-iomuxc + - fsl,imx8dxl-iomuxc + +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 3 integers and represents the pin ID, the mux value + and pad setting for the pin. The first 2 integers - pin_id and mux_val - are + specified using a PIN_FUNC_ID macro, which can be found in + <include/dt-bindings/pinctrl/pads-imx8qxp.h>. The last integer is + the pad setting value like pull-up on this pin. Please refer to the + appropriate i.MX8 Reference Manual for detailed pad CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "pin_id" indicates the pin ID + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + +additionalProperties: false + +examples: + - | + pinctrl { + compatible = "fsl,imx8qxp-iomuxc"; + + pinctrl_lpuart0: lpuart0grp { + fsl,pins = < + 111 0 0x06000020 + 112 0 0x06000020 + >; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml index 47a56b83a610..7a11beb8f222 100644 --- a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml @@ -152,7 +152,7 @@ examples: pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uid>, <&pinmux_uid>; - uid { + button-uid { label = "UID"; linux,code = <102>; gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-dpaux-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-dpaux-padctl.txt deleted file mode 100644 index e0e886b73527..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-dpaux-padctl.txt +++ /dev/null @@ -1,59 +0,0 @@ -Device tree binding for NVIDIA Tegra DPAUX pad controller -======================================================== - -The Tegra Display Port Auxiliary (DPAUX) pad controller manages two pins -which can be assigned to either the DPAUX channel or to an I2C -controller. - -This document defines the device-specific binding for the DPAUX pad -controller. Refer to pinctrl-bindings.txt in this directory for generic -information about pin controller device tree bindings. Please refer to -the binding document ../display/tegra/nvidia,tegra20-host1x.txt for more -details on the DPAUX binding. - -Pin muxing: ------------ - -Child nodes contain the pinmux configurations following the conventions -from the pinctrl-bindings.txt document. - -Since only three configurations are possible, only three child nodes are -needed to describe the pin mux'ing options for the DPAUX pads. -Furthermore, given that the pad functions are only applicable to a -single set of pads, the child nodes only need to describe the pad group -the functions are being applied to rather than the individual pads. - -Required properties: -- groups: Must be "dpaux-io" -- function: Must be either "aux", "i2c" or "off". - -Example: --------- - - dpaux@545c0000 { - ... - - state_dpaux_aux: pinmux-aux { - groups = "dpaux-io"; - function = "aux"; - }; - - state_dpaux_i2c: pinmux-i2c { - groups = "dpaux-io"; - function = "i2c"; - }; - - state_dpaux_off: pinmux-off { - groups = "dpaux-io"; - function = "off"; - }; - }; - - ... - - i2c@7000d100 { - ... - pinctrl-0 = <&state_dpaux_i2c>; - pinctrl-1 = <&state_dpaux_off>; - pinctrl-names = "default", "idle"; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml index 8a2bb8608291..1eeb885ce0c6 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml @@ -28,6 +28,8 @@ properties: gpio-ranges: maxItems: 1 + gpio-line-names: true + reg: description: | Physical address base for gpio base registers. There are 8 different GPIO @@ -105,31 +107,8 @@ patternProperties: drive-strength: 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] + drive-strength-microamp: + enum: [125, 250, 500, 1000] bias-pull-down: oneOf: @@ -291,7 +270,7 @@ examples: pinmux = <PINMUX_GPIO127__FUNC_SCL0>, <PINMUX_GPIO128__FUNC_SDA0>; bias-pull-up = <MTK_PULL_SET_RSEL_001>; - mediatek,drive-strength-adv = <7>; + drive-strength-microamp = <1000>; }; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index c90a132fbc79..e0e943e5b874 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -80,46 +80,30 @@ patternProperties: 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 + drive-strength-microamp: + enum: [125, 250, 500, 1000] + + bias-pull-down: + oneOf: + - type: boolean + description: normal pull down. + - enum: [100, 101, 102, 103] + description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0_ + defines in dt-bindings/pinctrl/mt65xx.h. + - enum: [200, 201, 202, 203] + description: RSEL pull down type. See MTK_PULL_SET_RSEL_ + defines in dt-bindings/pinctrl/mt65xx.h. + + bias-pull-up: + oneOf: + - type: boolean + description: normal pull up. + - enum: [100, 101, 102, 103] + description: PUPD/R1/R0 pull up type. See MTK_PUPD_SET_R1R0_ + defines in dt-bindings/pinctrl/mt65xx.h. + - enum: [200, 201, 202, 203] + description: RSEL pull up type. See MTK_PULL_SET_RSEL_ + defines in dt-bindings/pinctrl/mt65xx.h. bias-disable: true diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index c5b755514c46..66fe17e9e4d3 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.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 8 GPIO @@ -49,7 +51,7 @@ properties: description: The interrupt outputs to sysirq. maxItems: 1 - mediatek,rsel_resistance_in_si_unit: + mediatek,rsel-resistance-in-si-unit: type: boolean description: | Identifying i2c pins pull up/down type which is RSEL. It can support @@ -98,31 +100,8 @@ patternProperties: drive-strength: 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] + drive-strength-microamp: + enum: [125, 250, 500, 1000] bias-pull-down: oneOf: @@ -142,7 +121,7 @@ patternProperties: "MTK_PUPD_SET_R1R0_11" define in mt8195. For pull down type is RSEL, it can add RSEL define & resistance value(ohm) to set different resistance by identifying property - "mediatek,rsel_resistance_in_si_unit". + "mediatek,rsel-resistance-in-si-unit". It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" @@ -161,7 +140,7 @@ patternProperties: }; An example of using si unit resistance value(ohm): &pio { - mediatek,rsel_resistance_in_si_unit; + mediatek,rsel-resistance-in-si-unit; } pincontroller { i2c0_pin { @@ -190,7 +169,7 @@ patternProperties: "MTK_PUPD_SET_R1R0_11" define in mt8195. For pull up type is RSEL, it can add RSEL define & resistance value(ohm) to set different resistance by identifying property - "mediatek,rsel_resistance_in_si_unit". + "mediatek,rsel-resistance-in-si-unit". It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" @@ -209,7 +188,7 @@ patternProperties: }; An example of using si unit resistance value(ohm): &pio { - mediatek,rsel_resistance_in_si_unit; + mediatek,rsel-resistance-in-si-unit; } pincontroller { i2c0-pins { @@ -302,7 +281,7 @@ examples: pinmux = <PINMUX_GPIO8__FUNC_SDA0>, <PINMUX_GPIO9__FUNC_SCL0>; bias-disable; - mediatek,drive-strength-adv = <7>; + drive-strength-microamp = <1000>; }; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml index b83c7f476e19..931e5c190ead 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml @@ -144,7 +144,7 @@ examples: #interrupt-cells = <2>; gpio-controller; #gpio-cells = <2>; - gpio-ranges = <&tlmm 0 80>; + gpio-ranges = <&tlmm 0 0 80>; serial3-pinmux { pins = "gpio44", "gpio45"; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml new file mode 100644 index 000000000000..e03530091478 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml @@ -0,0 +1,152 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,msm8909-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. MSM8909 TLMM block + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the MSM8909 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,msm8909-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-msm8909-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-msm8909-tlmm-state" + +$defs: + qcom-msm8909-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-7])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, + sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, qdsd_data1, + qdsd_data2, qdsd_data3 ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + enum: [ adsp_ext, atest_bbrx0, atest_bbrx1, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, atest_combodac, + atest_gpsadc0, atest_gpsadc1, atest_wlan0, atest_wlan1, + bimc_dte0, bimc_dte1, blsp_i2c1, blsp_i2c2, blsp_i2c3, + blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_spi1, blsp_spi1_cs1, + blsp_spi1_cs2, blsp_spi1_cs3, blsp_spi2, blsp_spi2_cs1, + blsp_spi2_cs2, blsp_spi2_cs3, blsp_spi3, blsp_spi3_cs1, + blsp_spi3_cs2, blsp_spi3_cs3, blsp_spi4, blsp_spi5, blsp_spi6, + blsp_uart1, blsp_uart2, blsp_uim1, blsp_uim2, cam_mclk, + cci_async, cci_timer0, cci_timer1, cci_timer2, cdc_pdm0, + dbg_out, dmic0_clk, dmic0_data, ebi0_wrcdc, ebi2_a, ebi2_lcd, + ext_lpass, gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, + gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gpio, + gsm0_tx, ldo_en, ldo_update, m_voc, mdp_vsync, modem_tsync, + nav_pps, nav_tsync, pa_indicator, pbs0, pbs1, pbs2, + pri_mi2s_data0_a, pri_mi2s_data0_b, pri_mi2s_data1_a, + pri_mi2s_data1_b, pri_mi2s_mclk_a, pri_mi2s_mclk_b, + pri_mi2s_sck_a, pri_mi2s_sck_b, pri_mi2s_ws_a, pri_mi2s_ws_b, + prng_rosc, pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a, + pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, + qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0, + qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, + qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_tracectl_a, + qdss_tracedata_a, qdss_tracedata_b, sd_write, sec_mi2s, + smb_int, ssbi0, ssbi1, uim1_clk, uim1_data, uim1_present, + uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, + uim3_clk, uim3_data, uim3_present, uim3_reset, uim_batt, + wcss_bt, wcss_fm, wcss_wlan ] + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pinctrl@1000000 { + compatible = "qcom,msm8909-tlmm"; + reg = <0x1000000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 117>; + interrupt-controller; + #interrupt-cells = <2>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio4"; + function = "blsp_uart1"; + bias-pull-up; + }; + + tx { + pins = "gpio5"; + function = "blsp_uart1"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 6f2efc3772cb..694898f382be 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -52,6 +52,7 @@ properties: - qcom,pmi8998-gpio - qcom,pmk8350-gpio - qcom,pmm8155au-gpio + - qcom,pmp8074-gpio - qcom,pmr735a-gpio - qcom,pmr735b-gpio - qcom,pms405-gpio @@ -158,6 +159,7 @@ allOf: compatible: contains: enum: + - qcom,pm8226-gpio - qcom,pm8350b-gpio - qcom,pm8950-gpio then: @@ -233,6 +235,7 @@ allOf: - qcom,pm8150b-gpio - qcom,pm8150l-gpio - qcom,pmc8180c-gpio + - qcom,pmp8074-gpio - qcom,pms405-gpio then: properties: @@ -415,6 +418,7 @@ $defs: - gpio1-gpio10 for pmi8994 - gpio1-gpio4 for pmk8350 - gpio1-gpio10 for pmm8155au + - gpio1-gpio12 for pmp8074 (holes on gpio1 and gpio12) - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml index d32ee32776e8..33d1d37fdf6d 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -19,6 +19,11 @@ properties: compatible: const: qcom,sc7280-lpass-lpi-pinctrl + qcom,adsp-bypass-mode: + description: + Tells ADSP is in bypass mode. + type: boolean + reg: minItems: 2 maxItems: 2 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml new file mode 100644 index 000000000000..3908807a8339 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6375-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM6375 TLMM block + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM6375 platform. + +allOf: + - $ref: "pinctrl.yaml#" + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm6375-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6375-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6375-tlmm-state" + +$defs: + qcom-sm6375-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-6])$" + - enum: [ ufs_reset, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, + sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, + atest_char2, atest_char3, atest_tsens, atest_tsens2, + atest_usb1, atest_usb10, atest_usb11, atest_usb12, + atest_usb13, atest_usb2, atest_usb20, atest_usb21, + atest_usb22, atest_usb23, audio_ref, btfm_slimbus, cam_mclk, + cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, + cci_timer3, cci_timer4, cri_trng, dbg_out, ddr_bist, + ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, dp_hot, edp_lcd, + gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0, gp_pdm1, gp_pdm2, gpio, + gps_tx, ibi_i3c, jitter_bist, ldo_en, ldo_update, lpass_ext, + m_voc, mclk, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, + mdp_vsync3, mi2s_0, mi2s_1, mi2s_2, mss_lte, nav_gpio, + nav_pps, pa_indicator, phase_flag0, phase_flag1, phase_flag10, + phase_flag11, phase_flag12, phase_flag13, phase_flag14, + phase_flag15, phase_flag16, phase_flag17, phase_flag18, + phase_flag19, phase_flag2, phase_flag20, phase_flag21, + phase_flag22, phase_flag23, phase_flag24, phase_flag25, + phase_flag26, phase_flag27, phase_flag28, phase_flag29, + phase_flag3, phase_flag30, phase_flag31, phase_flag4, + phase_flag5, phase_flag6, phase_flag7, phase_flag8, + phase_flag9, pll_bist, pll_bypassnl, pll_clk, pll_reset, + prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti, + qdss_gpio, qdss_gpio0, qdss_gpio1, qdss_gpio10, qdss_gpio11, + qdss_gpio12, qdss_gpio13, qdss_gpio14, qdss_gpio15, + qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6, + qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink0_enable, + qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request, + qlink1_wmss, qup00, qup01, qup02, qup10, qup11_f1, qup11_f2, + qup12, qup13_f1, qup13_f2, qup14, sd_write, sdc1_tb, sdc2_tb, + sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1, + tsense_pwm2, uim1_clk, uim1_data, uim1_present, uim1_reset, + uim2_clk, uim2_data, uim2_present, uim2_reset, usb2phy_ac, + usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, + wlan2_adc0, wlan2_adc1 ] + + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pinctrl@500000 { + compatible = "qcom,sm6375-tlmm"; + reg = <0x00500000 0x800000>; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 157>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio18"; + function = "qup13_f2"; + bias-pull-up; + }; + + tx { + pins = "gpio19"; + function = "qup13_f2"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index 2a57df75d832..4fc758fea7e6 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -45,6 +45,7 @@ properties: - renesas,pfc-r8a77995 # R-Car D3 - renesas,pfc-r8a779a0 # R-Car V3U - renesas,pfc-r8a779f0 # R-Car S4-8 + - renesas,pfc-r8a779g0 # R-Car V4H - renesas,pfc-sh73a0 # SH-Mobile AG5 reg: diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index 52df1b146174..997b74639112 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -47,6 +47,17 @@ properties: gpio-ranges: maxItems: 1 + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: + The first cell contains the global GPIO port index, constructed using the + RZG2L_GPIO() helper macro in <dt-bindings/pinctrl/rzg2l-pinctrl.h> and the + second cell is used to specify the flag. + E.g. "interrupts = <RZG2L_GPIO(43, 0) IRQ_TYPE_EDGE_FALLING>;" if P43_0 is + being used as an interrupt. + clocks: maxItems: 1 @@ -110,6 +121,8 @@ required: - gpio-controller - '#gpio-cells' - gpio-ranges + - interrupt-controller + - '#interrupt-cells' - clocks - power-domains - resets @@ -126,6 +139,8 @@ examples: gpio-controller; #gpio-cells = <2>; gpio-ranges = <&pinctrl 0 0 392>; + interrupt-controller; + #interrupt-cells = <2>; clocks = <&cpg CPG_MOD R9A07G044_GPIO_HCLK>; resets = <&cpg R9A07G044_GPIO_RSTN>, <&cpg R9A07G044_GPIO_PORT_RESETN>, diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml new file mode 100644 index 000000000000..eac6245db7dc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/renesas,rzv2m-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2M combined Pin and GPIO controller + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Phil Edworthy <phil.edworthy@renesas.com> + +description: + The Renesas RZ/V2M SoC features a combined Pin and GPIO controller. + Pin multiplexing and GPIO configuration is performed on a per-pin basis. + Each port features up to 16 pins, each of them configurable for GPIO function + (port mode) or in alternate function mode. + Up to 8 different alternate function modes exist for each single pin. + +properties: + compatible: + const: renesas,r9a09g011-pinctrl # RZ/V2M + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell contains the global GPIO port index, constructed using the + RZV2M_GPIO() helper macro in <dt-bindings/pinctrl/rzv2m-pinctrl.h> and the + second cell represents consumer flag as mentioned in ../gpio/gpio.txt + E.g. "RZV2M_GPIO(8, 1)" for P8_1. + + gpio-ranges: + maxItems: 1 + + interrupts: + description: INEXINT[0..38] corresponding to individual pin inputs. + maxItems: 39 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +additionalProperties: + anyOf: + - type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + description: + Pin controller client devices use pin configuration subnodes (children + and grandchildren) for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + phandle: true + pinmux: + description: + Values are constructed from GPIO port number, pin number, and + alternate function configuration number using the RZV2M_PORT_PINMUX() + helper macro in <dt-bindings/pinctrl/rzv2m-pinctrl.h>. + pins: true + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength-microamp: + # Superset of supported values + enum: [ 1600, 1800, 2000, 3200, 3800, 4000, 6400, 7800, 8000, + 9000, 9600, 11000, 12000, 13000, 18000 ] + slew-rate: + description: 0 is slow slew rate, 1 is fast slew rate + enum: [ 0, 1 ] + gpio-hog: true + gpios: true + output-high: true + output-low: true + line-name: true + + - type: object + properties: + phandle: true + + additionalProperties: + $ref: "#/additionalProperties/anyOf/0" + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - interrupts + - clocks + - power-domains + - resets + +examples: + - | + #include <dt-bindings/pinctrl/rzv2m-pinctrl.h> + #include <dt-bindings/clock/r9a09g011-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pinctrl: pinctrl@b6250000 { + compatible = "renesas,r9a09g011-pinctrl"; + reg = <0xb6250000 0x800>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 352>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>, + <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>; + clocks = <&cpg CPG_MOD R9A09G011_PFC_PCLK>; + resets = <&cpg R9A09G011_PFC_PRESETN>; + power-domains = <&cpg>; + + i2c2_pins: i2c2 { + pinmux = <RZV2M_PORT_PINMUX(3, 8, 2)>, /* SDA */ + <RZV2M_PORT_PINMUX(3, 9, 2)>; /* SCL */ + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 335ffc1353b5..d35dcc4f0242 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -59,6 +59,7 @@ properties: patternProperties: '^gpio@[0-9a-f]*$': type: object + additionalProperties: false properties: gpio-controller: true '#gpio-cells': @@ -68,8 +69,7 @@ patternProperties: maxItems: 1 clocks: maxItems: 1 - reset: - minItems: 1 + resets: maxItems: 1 gpio-ranges: minItems: 1 diff --git a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml index d8e75b3e64f1..15092fdd4b5b 100644 --- a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml @@ -288,11 +288,14 @@ required: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + examples: - | #include <dt-bindings/pinctrl/sppctl-sp7021.h> - pinctl@9c000100 { + pinctrl@9c000100 { compatible = "sunplus,sp7021-pctl"; reg = <0x9c000100 0x100>, <0x9c000300 0x100>, <0x9c0032e4 0x1c>, <0x9c000080 0x20>; diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml index 2722dc7bb03d..1e2b9b627b12 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -274,6 +274,10 @@ patternProperties: slew-rate: enum: [0, 1] + output-enable: + description: + This will internally disable the tri-state for MIO pins. + drive-strength: description: Selects the drive strength for MIO pins, in mA. diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml index f005abac7079..5390e988a934 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/amlogic,meson-ee-pwrc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/amlogic,meson-ee-pwrc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Everything-Else Power Domains @@ -17,7 +17,7 @@ description: |+ - compatible: Should be the following: "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon" - Refer to the the bindings described in + Refer to the bindings described in Documentation/devicetree/bindings/mfd/syscon.yaml properties: diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml index 86e5f6513bb3..eab21bb2050a 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml @@ -3,8 +3,8 @@ # Author: Jianxin Pan <jianxin.pan@amlogic.com> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/amlogic,meson-sec-pwrc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/amlogic,meson-sec-pwrc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Secure Power Domains diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml index 19a194980142..94d369eb85de 100644 --- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml @@ -10,7 +10,7 @@ maintainers: - Hector Martin <marcan@marcan.st> allOf: - - $ref: "power-domain.yaml#" + - $ref: power-domain.yaml# description: | Apple SoCs include PMGR blocks responsible for power management, diff --git a/Documentation/devicetree/bindings/power/brcm,bcm63xx-power.yaml b/Documentation/devicetree/bindings/power/brcm,bcm63xx-power.yaml index 63b15ac6dde4..d867bd6976d8 100644 --- a/Documentation/devicetree/bindings/power/brcm,bcm63xx-power.yaml +++ b/Documentation/devicetree/bindings/power/brcm,bcm63xx-power.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/brcm,bcm63xx-power.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/brcm,bcm63xx-power.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: BCM63xx power domain driver diff --git a/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml b/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml new file mode 100644 index 000000000000..1f72b18ca0fc --- /dev/null +++ b/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/fsl,scu-pd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - Power domain bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + Power domain bindings based on SCU Message Protocol + +allOf: + - $ref: power-domain.yaml# + +properties: + compatible: + items: + - enum: + - fsl,imx8qm-scu-pd + - fsl,imx8qxp-scu-pd + - const: fsl,scu-pd + + '#power-domain-cells': + const: 1 + +required: + - compatible + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + power-controller { + compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml index 135c6f722091..b448101fac43 100644 --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: + - mediatek,mt6795-power-controller - mediatek,mt8167-power-controller - mediatek,mt8173-power-controller - mediatek,mt8183-power-controller @@ -62,6 +63,7 @@ patternProperties: reg: description: | Power domain index. Valid values are defined in: + "include/dt-bindings/power/mt6795-power.h" - for MT8167 type power domain. "include/dt-bindings/power/mt8167-power.h" - for MT8167 type power domain. "include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain. "include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain. diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index ad77a6380f38..0ccca493251a 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -18,6 +18,7 @@ properties: enum: - qcom,mdm9607-rpmpd - qcom,msm8226-rpmpd + - qcom,msm8909-rpmpd - qcom,msm8916-rpmpd - qcom,msm8939-rpmpd - qcom,msm8953-rpmpd diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml b/Documentation/devicetree/bindings/power/renesas,apmu.yaml index d77fc88050c8..f2cc89e7f4e4 100644 --- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml +++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/renesas,apmu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/renesas,apmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Advanced Power Management Unit diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index 8d56bedd3390..0720b54881c2 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/renesas,rcar-sysc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/renesas,rcar-sysc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas R-Car and RZ/G System Controller diff --git a/Documentation/devicetree/bindings/power/reset/msm-poweroff.txt b/Documentation/devicetree/bindings/power/reset/msm-poweroff.txt deleted file mode 100644 index ce44ad357565..000000000000 --- a/Documentation/devicetree/bindings/power/reset/msm-poweroff.txt +++ /dev/null @@ -1,17 +0,0 @@ -MSM Restart Driver - -A power supply hold (ps-hold) bit is set to power the msm chipsets. -Clearing that bit allows us to restart/poweroff. The difference -between poweroff and restart is determined by unique power manager IC -settings. - -Required Properties: --compatible: "qcom,pshold" --reg: Specifies the physical address of the ps-hold register - -Example: - - restart@fc4ab000 { - compatible = "qcom,pshold"; - reg = <0xfc4ab000 0x4>; - }; diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml index 353f155df0f4..e7b436d2e757 100644 --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml @@ -30,11 +30,15 @@ properties: pwrkey: type: object - $ref: "../../input/qcom,pm8941-pwrkey.yaml#" + $ref: /schemas/input/qcom,pm8941-pwrkey.yaml# resin: type: object - $ref: "../../input/qcom,pm8941-pwrkey.yaml#" + $ref: /schemas/input/qcom,pm8941-pwrkey.yaml# + + watchdog: + type: object + $ref: /schemas/watchdog/qcom,pm8916-wdt.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pshold.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pshold.yaml new file mode 100644 index 000000000000..527962d54a8f --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/qcom,pshold.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/qcom,pshold.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoC restart and power off + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + A power supply hold (ps-hold) bit is set to power the Qualcomm chipsets. + Clearing that bit allows us to restart/power off. The difference between + power off and restart is determined by unique power manager IC settings. + +properties: + compatible: + const: qcom,pshold + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + reset-controller@fc4ab000 { + compatible = "qcom,pshold"; + reg = <0xfc4ab000 0x4>; + }; diff --git a/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml index 03bd1fa5a623..e9417557cd30 100644 --- a/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml +++ b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml @@ -16,7 +16,7 @@ description: | properties: compatible: - const: "regulator-poweroff" + const: regulator-poweroff cpu-supply: description: diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml index 68d7c14a7163..46de35861738 100644 --- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml +++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml @@ -15,7 +15,7 @@ description: | properties: compatible: - const: "xlnx,zynqmp-power" + const: xlnx,zynqmp-power interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml b/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml index 3f74bc19415d..5220d9cb16d8 100644 --- a/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/active-semi,act8945a-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/active-semi,act8945a-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Active-semi ACT8945A Charger Function diff --git a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml index 118cf484cc69..a3c00e078918 100644 --- a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq2415x.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq2415x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for TI bq2415x Li-Ion Charger diff --git a/Documentation/devicetree/bindings/power/supply/bq24190.yaml b/Documentation/devicetree/bindings/power/supply/bq24190.yaml index 0d7cbbdf808b..4884ec90e2b8 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24190.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24190.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq24190.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq24190.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for TI BQ2419x Li-Ion Battery Charger @@ -28,7 +28,7 @@ properties: maxItems: 1 usb-otg-vbus: - type: object + $ref: /schemas/regulator/regulator.yaml# description: | Regulator that is used to control the VBUS voltage direction for either USB host mode or for charging on the OTG port diff --git a/Documentation/devicetree/bindings/power/supply/bq24257.yaml b/Documentation/devicetree/bindings/power/supply/bq24257.yaml index 3a0f6cd9015a..c7406bef0fa8 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24257.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24257.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq24257.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq24257.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for bq24250, bq24251 and bq24257 Li-Ion Charger diff --git a/Documentation/devicetree/bindings/power/supply/bq24735.yaml b/Documentation/devicetree/bindings/power/supply/bq24735.yaml index 131be6782c4b..dd9176ce71b3 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24735.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24735.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq24735.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq24735.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for TI BQ24735 Li-Ion Battery Charger diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml index 813d6afde606..1a1b240034ef 100644 --- a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml @@ -2,14 +2,13 @@ # Copyright (C) 2020 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq2515x.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq2515x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI bq2515x 500-mA Linear charger family maintainers: - - Dan Murphy <dmurphy@ti.com> - - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + - Andrew Davis <afd@ti.com> description: | The BQ2515x family is a highly integrated battery charge management IC that diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml index 92ec7ed25668..82f382a7ffb3 100644 --- a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml @@ -2,13 +2,13 @@ # Copyright (C) 2020 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq256xx.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq256xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI bq256xx Switch Mode Buck Charger maintainers: - - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + - Andrew Davis <afd@ti.com> description: | The bq256xx devices are a family of highly-integrated battery charge diff --git a/Documentation/devicetree/bindings/power/supply/bq25890.yaml b/Documentation/devicetree/bindings/power/supply/bq25890.yaml index bf823b615439..204c0147188f 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25890.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq25890.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq25890.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq25890.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for bq25890, bq25892, bq25895 and bq25896 Li-Ion Charger diff --git a/Documentation/devicetree/bindings/power/supply/bq25980.yaml b/Documentation/devicetree/bindings/power/supply/bq25980.yaml index 8367a1fd4057..b687b8bcd705 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25980.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq25980.yaml @@ -2,14 +2,13 @@ # Copyright (C) 2020 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq25980.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq25980.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI BQ25980 Flash Charger maintainers: - - Dan Murphy <dmurphy@ti.com> - - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + - Andrew Davis <afd@ti.com> description: | The BQ25980, BQ25975, and BQ25960 are a series of flash chargers intended diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml index 6af41da3e055..65fc6049efc1 100644 --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/bq27xxx.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/bq27xxx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI BQ27XXX fuel gauge family diff --git a/Documentation/devicetree/bindings/power/supply/charger-manager.yaml b/Documentation/devicetree/bindings/power/supply/charger-manager.yaml index fbb2204769aa..5af1e0beaf29 100644 --- a/Documentation/devicetree/bindings/power/supply/charger-manager.yaml +++ b/Documentation/devicetree/bindings/power/supply/charger-manager.yaml @@ -50,6 +50,7 @@ properties: cm-battery-stat: description: battery status + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 0 # battery always present - 1 # no battery diff --git a/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml b/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml index 7153fd4ce55f..694bfdb5815c 100644 --- a/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/cpcap-battery.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/cpcap-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Motorola CPCAP PMIC battery diff --git a/Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml b/Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml index cb6353683d7b..7e6bf30a0107 100644 --- a/Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/cpcap-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/cpcap-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Motorola CPCAP PMIC charger diff --git a/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml b/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml index 96336b05d76d..b289388952bf 100644 --- a/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/dlg,da9150-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/dlg,da9150-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Dialog Semiconductor DA9150 Charger Power Supply bindings diff --git a/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml b/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml index 30c2fff7cf92..d47caf59d204 100644 --- a/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml +++ b/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/dlg,da9150-fuel-gauge.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/dlg,da9150-fuel-gauge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Dialog Semiconductor DA9150 Fuel-Gauge Power Supply bindings diff --git a/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml b/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml index 76c227a7cd5c..46527038bf22 100644 --- a/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml @@ -2,8 +2,8 @@ # Copyright 2019-2020 Artur Rojek %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/ingenic,battery.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/ingenic,battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Ingenic JZ47xx battery bindings diff --git a/Documentation/devicetree/bindings/power/supply/isp1704.yaml b/Documentation/devicetree/bindings/power/supply/isp1704.yaml index 4c91da70011d..7e3449ed70d4 100644 --- a/Documentation/devicetree/bindings/power/supply/isp1704.yaml +++ b/Documentation/devicetree/bindings/power/supply/isp1704.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/isp1704.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/isp1704.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for NXP ISP1704 USB Charger Detection diff --git a/Documentation/devicetree/bindings/power/supply/lego,ev3-battery.yaml b/Documentation/devicetree/bindings/power/supply/lego,ev3-battery.yaml index 518eabb63588..a99d989f1450 100644 --- a/Documentation/devicetree/bindings/power/supply/lego,ev3-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/lego,ev3-battery.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/lego,ev3-battery.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/lego,ev3-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: LEGO MINDSTORMS EV3 Battery diff --git a/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml b/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml index e2d8d2aebb73..76cedf95a12c 100644 --- a/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/lltc,lt3651-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/lltc,lt3651-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices LT3651 Charger Power Supply bindings diff --git a/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml b/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml index 043bf378040f..109b41a0d56c 100644 --- a/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml +++ b/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/lltc,ltc294x.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/lltc,ltc294x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for LTC2941, LTC2942, LTC2943 and LTC2944 battery fuel gauges diff --git a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml index 6d7aa97a6475..cfffaeef8b09 100644 --- a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml +++ b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020 Topic Embedded Products %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/ltc4162-l.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/ltc4162-l.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Linear Technology (Analog Devices) LTC4162-L Charger diff --git a/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml b/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml index 818647edf63d..c838efcf7e16 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/maxim,ds2760.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/maxim,ds2760.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim DS2760 DT bindings diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml index 0a41078ebd99..070ef6f96e60 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/maxim,max14656.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/maxim,max14656.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim MAX14656 DT bindings diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml index 6b4588a3253b..3a529326ecbd 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/maxim,max17040.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/maxim,max17040.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim 17040 fuel gauge series diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml index 971b53c58cc6..aff5d0792e0f 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/maxim,max17042.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/maxim,max17042.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim 17042 fuel gauge series diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml index 4828ca0842ae..a8d625f285f1 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/maxim,max8903.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/maxim,max8903.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim Semiconductor MAX8903 Battery Charger diff --git a/Documentation/devicetree/bindings/power/supply/nokia,n900-battery.yaml b/Documentation/devicetree/bindings/power/supply/nokia,n900-battery.yaml index 4a1489f2b28d..5178e6207271 100644 --- a/Documentation/devicetree/bindings/power/supply/nokia,n900-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/nokia,n900-battery.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/nokia,n900-battery.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/nokia,n900-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Nokia N900 battery diff --git a/Documentation/devicetree/bindings/power/supply/olpc-battery.yaml b/Documentation/devicetree/bindings/power/supply/olpc-battery.yaml index 0bd7bf3b8e1b..dd89e2532a07 100644 --- a/Documentation/devicetree/bindings/power/supply/olpc-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/olpc-battery.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/olpc-battery.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/olpc-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: OLPC Battery diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml b/Documentation/devicetree/bindings/power/supply/power-supply.yaml index 9a490fbd32e1..2f672e6e8d72 100644 --- a/Documentation/devicetree/bindings/power/supply/power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/power-supply.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/power-supply.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Power Supply Core Support diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml index caeff68c66d5..cbac55d3cb92 100644 --- a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml @@ -117,11 +117,18 @@ properties: be done externally to fully comply with the JEITA safety guidelines if this flag is set. + usb-charge-current-limit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 100000 + maximum: 2500000 + description: | + Default USB charge current limit in uA. + usb-otg-in-supply: description: Reference to the regulator supplying power to the USB_OTG_IN pin. otg-vbus: - type: object + $ref: /schemas/regulator/regulator.yaml# description: | This node defines a regulator used to control the direction of VBUS voltage. Specifically whether to supply voltage to VBUS for host mode operation of the OTG port, diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml index ae647d3355a2..756c16d1727d 100644 --- a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/richtek,rt5033-battery.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Richtek RT5033 PMIC Fuel Gauge diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml index e1c233462f29..bce15101318e 100644 --- a/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/richtek,rt9455.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/richtek,rt9455.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Binding for Richtek rt9455 battery charger diff --git a/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml b/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml index b62c2431f94e..eeb043f9bb4f 100644 --- a/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/sc2731-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/sc2731-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Spreadtrum SC2731 PMICs battery charger binding diff --git a/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml index e019cffd1f38..d90a838a1744 100644 --- a/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml +++ b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/sc27xx-fg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/sc27xx-fg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Spreadtrum SC27XX PMICs Fuel Gauge Unit Power Supply Bindings diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml index 4b8a00cec39c..525abdfb3e2d 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/stericsson,ab8500-btemp.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/stericsson,ab8500-btemp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AB8500 Battery Temperature Monitor diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml index 6799224f7fb4..10bbdcfc87b6 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/stericsson,ab8500-chargalg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/stericsson,ab8500-chargalg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AB8500 Charging Algorithm diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml index 9518eb7289d0..e33329b3af61 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/stericsson,ab8500-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/stericsson,ab8500-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AB8500 Charger diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml index 2ce408a7c0ae..6a724ca90e99 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2021 Sebastian Reichel %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/stericsson,ab8500-fg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/stericsson,ab8500-fg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AB8500 Fuel Gauge diff --git a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml index 20862cdfc116..2d552becbfe6 100644 --- a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/summit,smb347-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/summit,smb347-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Battery charger driver for SMB345, SMB347 and SMB358 @@ -82,7 +82,7 @@ properties: - 1 # SMB3XX_SYSOK_INOK_ACTIVE_HIGH usb-vbus: - $ref: "../../regulator/regulator.yaml#" + $ref: /schemas/regulator/regulator.yaml# type: object properties: diff --git a/Documentation/devicetree/bindings/power/supply/tps65090-charger.yaml b/Documentation/devicetree/bindings/power/supply/tps65090-charger.yaml index f2dd38bf078c..586745426341 100644 --- a/Documentation/devicetree/bindings/power/supply/tps65090-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/tps65090-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/tps65090-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/tps65090-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TPS65090 Frontend PMU with Switchmode Charger diff --git a/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml b/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml index 2c2fe883bb48..7ccf0cdffd3e 100644 --- a/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/tps65217-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/tps65217-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/tps65217-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TPS65217 Charger diff --git a/Documentation/devicetree/bindings/power/supply/twl4030-charger.yaml b/Documentation/devicetree/bindings/power/supply/twl4030-charger.yaml index fe3f32a0ea79..d8d3154f9cb1 100644 --- a/Documentation/devicetree/bindings/power/supply/twl4030-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/twl4030-charger.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/twl4030-charger.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/twl4030-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TWL4030 BCI (Battery Charger Interface) diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml index de6a23aee977..5c8369fd3ef7 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/x-powers,axp20x-ac-power-supply.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/x-powers,axp20x-ac-power-supply.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AXP20x AC power-supply diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml index d055428ae39f..e0b95ecbbebd 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/x-powers,axp20x-battery-power-supply.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/x-powers,axp20x-battery-power-supply.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AXP20x Battery power-supply diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml index 0c371b55c9e1..3ce648dd91bd 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/power/supply/x-powers,axp20x-usb-power-supply.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/power/supply/x-powers,axp20x-usb-power-supply.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: AXP20x USB power-supply diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt index d63ab1dec16d..801c66069121 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt @@ -5,7 +5,7 @@ Copyright 2013 Freescale Semiconductor Inc. Power Architecture CPUs in Freescale SOCs are represented in device trees as per the definition in the Devicetree Specification. -In addition to the the Devicetree Specification definitions, the properties +In addition to the Devicetree Specification definitions, the properties defined below may be present on CPU nodes. PROPERTIES diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt index d096cf461d81..4571c857dbe5 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt @@ -172,7 +172,7 @@ Interrupt controller (fsl,mpc5200-pic) node The mpc5200 pic binding splits hardware IRQ numbers into two levels. The split reflects the layout of the PIC hardware itself, which groups interrupts into one of three groups; CRIT, MAIN or PERP. Also, the -Bestcomm dma engine has it's own set of interrupt sources which are +Bestcomm dma engine has its own set of interrupt sources which are cascaded off of peripheral interrupt 0, which the driver interprets as a fourth group, SDMA. diff --git a/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt index 9d619e955576..d6658d3dd15e 100644 --- a/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt +++ b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt @@ -39,7 +39,7 @@ otherwise. The length of all the property arrays must be the same. - ibm,cpu-idle-state-flags: Array of unsigned 32-bit values containing the values of the - flags associated with the the aforementioned idle-states. The + flags associated with the aforementioned idle-states. The flag bits are as follows: 0x00000001 /* Decrementer would stop */ 0x00000002 /* Needs timebase restore */ diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml new file mode 100644 index 000000000000..ec1768291503 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/clk-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock based PWM controller + +maintainers: + - Nikita Travkin <nikita@trvn.ru> + +description: | + Some systems have clocks that can be exposed to external devices. + (e.g. by muxing them to GPIO pins) + It's often possible to control duty-cycle of such clocks which makes them + suitable for generating PWM signal. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: clk-pwm + + clocks: + description: Clock used to generate the signal. + maxItems: 1 + + "#pwm-cells": + const: 2 + +unevaluatedProperties: false + +required: + - compatible + - clocks + +examples: + - | + pwm { + compatible = "clk-pwm"; + #pwm-cells = <2>; + clocks = <&gcc 0>; + pinctrl-names = "default"; + pinctrl-0 = <&pwm_clk_flash_default>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index 033d1fc0f405..554c96b6d0c3 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -9,6 +9,8 @@ Required properties: - "mediatek,mt7628-pwm": found on mt7628 SoC. - "mediatek,mt7629-pwm": found on mt7629 SoC. - "mediatek,mt8183-pwm": found on mt8183 SoC. + - "mediatek,mt8195-pwm", "mediatek,mt8183-pwm": found on mt8195 SoC. + - "mediatek,mt8365-pwm": found on mt8365 SoC. - "mediatek,mt8516-pwm": found on mt8516 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 @@ -18,6 +20,7 @@ Required properties: has no clocks - "top": the top clock generator - "main": clock used by the PWM core + - "pwm1-3": the three per PWM clocks for mt8365 - "pwm1-8": the eight per PWM clocks for mt2712 - "pwm1-6": the six per PWM clocks for mt7622 - "pwm1-5": the five per PWM clocks for mt7623 diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml index 90727fdc1283..7023c597c3ed 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml @@ -15,6 +15,7 @@ properties: compatible: enum: - mps,mp5416 + - mps,mp5496 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index b539781e39aa..835b53302db8 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -47,12 +47,6 @@ properties: description: Properties for single LDO regulator. - properties: - regulator-name: - pattern: "^LDO[1-5]$" - description: - should be "LDO1", ..., "LDO5" - unevaluatedProperties: false "^BUCK[1-6]$": @@ -62,11 +56,6 @@ properties: Properties for single BUCK regulator. properties: - regulator-name: - pattern: "^BUCK[1-6]$" - description: - should be "BUCK1", ..., "BUCK6" - nxp,dvs-run-voltage: $ref: "/schemas/types.yaml#/definitions/uint32" minimum: 600000 diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt deleted file mode 100644 index 3d78d507e29f..000000000000 --- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt +++ /dev/null @@ -1,92 +0,0 @@ -Bindings for the Generic PWM Regulator -====================================== - -Currently supports 2 modes of operation: - -Voltage Table: When in this mode, a voltage table (See below) of - predefined voltage <=> duty-cycle values must be - provided via DT. Limitations are that the regulator can - only operate at the voltages supplied in the table. - Intermediary duty-cycle values which would normally - allow finer grained voltage selection are ignored and - rendered useless. Although more control is given to - the user if the assumptions made in continuous-voltage - mode do not reign true. - -Continuous Voltage: This mode uses the regulator's maximum and minimum - supplied voltages specified in the - regulator-{min,max}-microvolt properties to calculate - appropriate duty-cycle values. This allows for a much - more fine grained solution when compared with - voltage-table mode above. This solution does make an - assumption that a %50 duty-cycle value will cause the - regulator voltage to run at half way between the - supplied max_uV and min_uV values. - -Required properties: --------------------- -- compatible: Should be "pwm-regulator" - -- pwms: PWM specification (See: ../pwm/pwm.txt) - -Only required for Voltage Table Mode: -- voltage-table: Voltage and Duty-Cycle table consisting of 2 cells - First cell is voltage in microvolts (uV) - Second cell is duty-cycle in percent (%) - -Optional properties for Continuous mode: -- pwm-dutycycle-unit: Integer value encoding the duty cycle unit. If not - defined, <100> is assumed, meaning that - pwm-dutycycle-range contains values expressed in - percent. - -- pwm-dutycycle-range: Should contain 2 entries. The first entry is encoding - the dutycycle for regulator-min-microvolt and the - second one the dutycycle for regulator-max-microvolt. - Duty cycle values are expressed in pwm-dutycycle-unit. - If not defined, <0 100> is assumed. - -NB: To be clear, if voltage-table is provided, then the device will be used -in Voltage Table Mode. If no voltage-table is provided, then the device will -be used in Continuous Voltage Mode. - -Optional properties: --------------------- -- enable-gpios: GPIO to use to enable/disable the regulator - -Any property defined as part of the core regulator binding can also be used. -(See: ../regulator/regulator.txt) - -Continuous Voltage With Enable GPIO Example: - pwm_regulator { - compatible = "pwm-regulator"; - pwms = <&pwm1 0 8448 0>; - enable-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>; - regulator-min-microvolt = <1016000>; - regulator-max-microvolt = <1114000>; - regulator-name = "vdd_logic"; - /* unit == per-mille */ - pwm-dutycycle-unit = <1000>; - /* - * Inverted PWM logic, and the duty cycle range is limited - * to 30%-70%. - */ - pwm-dutycycle-range = <700 300>; /* */ - }; - -Voltage Table Example: - pwm_regulator { - compatible = "pwm-regulator"; - pwms = <&pwm1 0 8448 0>; - regulator-min-microvolt = <1016000>; - regulator-max-microvolt = <1114000>; - regulator-name = "vdd_logic"; - - /* Voltage Duty-Cycle */ - voltage-table = <1114000 0>, - <1095000 10>, - <1076000 20>, - <1056000 30>, - <1036000 40>, - <1016000 50>; - }; diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml new file mode 100644 index 000000000000..82b6f2fde422 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/pwm-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for the Generic PWM Regulator + +maintainers: + - Brian Norris <briannorris@chromium.org> + - Lee Jones <lee@kernel.org> + - Alexandre Courbot <acourbot@nvidia.com> + +description: | + Currently supports 2 modes of operation: + + Voltage Table: + When in this mode, a voltage table (See below) of predefined voltage <=> + duty-cycle values must be provided via DT. Limitations are that the + regulator can only operate at the voltages supplied in the table. + Intermediary duty-cycle values which would normally allow finer grained + voltage selection are ignored and rendered useless. Although more control + is given to the user if the assumptions made in continuous-voltage mode do + not reign true. + + Continuous Voltage: + This mode uses the regulator's maximum and minimum supplied voltages + specified in the regulator-{min,max}-microvolt properties to calculate + appropriate duty-cycle values. This allows for a much more fine grained + solution when compared with voltage-table mode above. This solution does + make an assumption that a %50 duty-cycle value will cause the regulator + voltage to run at half way between the supplied max_uV and min_uV values. + + If voltage-table is provided, then the device will be used in Voltage Table + Mode. If no voltage-table is provided, then the device will be used in + Continuous Voltage Mode. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + const: pwm-regulator + + pwms: + maxItems: 1 + + voltage-table: + description: Voltage and Duty-Cycle table. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: voltage in microvolts (uV) + - description: duty-cycle in percent (%) + + enable-gpios: + description: Regulator enable GPIO + maxItems: 1 + + # Optional properties for Continuous mode: + pwm-dutycycle-unit: + description: + Integer value encoding the duty cycle unit. If not + defined, <100> is assumed, meaning that + pwm-dutycycle-range contains values expressed in + percent. + default: 100 + + pwm-dutycycle-range: + description: + Should contain 2 entries. The first entry is encoding + the dutycycle for regulator-min-microvolt and the + second one the dutycycle for regulator-max-microvolt. + Duty cycle values are expressed in pwm-dutycycle-unit. + If not defined, <0 100> is assumed. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: the dutycycle for regulator-min-microvolt + - description: the dutycycle for regulator-max-microvolt + default: [ 0 100 ] + +required: + - compatible + - pwms + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + // Continuous Voltage With Enable GPIO Example: + regulator { + compatible = "pwm-regulator"; + pwms = <&pwm1 0 8448 0>; + enable-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>; + regulator-min-microvolt = <1016000>; + regulator-max-microvolt = <1114000>; + regulator-name = "vdd_logic"; + /* unit == per-mille */ + pwm-dutycycle-unit = <1000>; + /* + * Inverted PWM logic, and the duty cycle range is limited + * to 30%-70%. + */ + pwm-dutycycle-range = <700 300>; /* */ + }; + + - | + // Voltage Table Example: + regulator { + compatible = "pwm-regulator"; + pwms = <&pwm1 0 8448 0>; + regulator-min-microvolt = <1016000>; + regulator-max-microvolt = <1114000>; + regulator-name = "vdd_logic"; + + /* Voltage Duty-Cycle */ + voltage-table = <1114000 0>, + <1095000 10>, + <1076000 20>, + <1056000 30>, + <1036000 40>, + <1016000 50>; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 6a9a7eed466f..c233461cc980 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -30,6 +30,9 @@ description: For pm8841, s1, s2, s3, s4, s5, s6, s7, s8 + For pm8909, s1, s2, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, + l14, l15, l17, l18 + For pm8916, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18 @@ -78,6 +81,7 @@ properties: - qcom,rpm-mp5496-regulators - qcom,rpm-pm8226-regulators - qcom,rpm-pm8841-regulators + - qcom,rpm-pm8909-regulators - qcom,rpm-pm8916-regulators - qcom,rpm-pm8941-regulators - qcom,rpm-pm8950-regulators diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt deleted file mode 100644 index c2a39b121b1b..000000000000 --- a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt +++ /dev/null @@ -1,347 +0,0 @@ -Qualcomm SPMI Regulators - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,pm8004-regulators" - "qcom,pm8005-regulators" - "qcom,pm8226-regulators" - "qcom,pm8841-regulators" - "qcom,pm8916-regulators" - "qcom,pm8941-regulators" - "qcom,pm8950-regulators" - "qcom,pm8994-regulators" - "qcom,pmi8994-regulators" - "qcom,pm660-regulators" - "qcom,pm660l-regulators" - "qcom,pms405-regulators" - -- interrupts: - Usage: optional - Value type: <prop-encoded-array> - Definition: List of OCP interrupts. - -- interrupt-names: - Usage: required if 'interrupts' property present - Value type: <string-array> - Definition: List of strings defining the names of the - interrupts in the 'interrupts' property 1-to-1. - Supported values are "ocp-<regulator_name>", where - <regulator_name> corresponds to a voltage switch - type regulator. - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s4-supply: -- vdd_s5-supply: -- vdd_s6-supply: -- vdd_s7-supply: -- vdd_s8-supply: - Usage: optional (pm8841 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s4-supply: -- vdd_l1_l3-supply: -- vdd_l2-supply: -- vdd_l4_l5_l6-supply: -- vdd_l7-supply: -- vdd_l8_l11_l14_l15_l16-supply: -- vdd_l9_l10_l12_l13_l17_l18-supply: - Usage: optional (pm8916 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_l1_l3-supply: -- vdd_l2_lvs_1_2_3-supply: -- vdd_l4_l11-supply: -- vdd_l5_l7-supply: -- vdd_l6_l12_l14_l15-supply: -- vdd_l8_l16_l18_19-supply: -- vdd_l9_l10_l17_l22-supply: -- vdd_l13_l20_l23_l24-supply: -- vdd_l21-supply: -- vin_5vs-supply: - Usage: optional (pm8941 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s4-supply: -- vdd_s4-supply: -- vdd_s5-supply: -- vdd_s6-supply: -- vdd_l1_l19-supply: -- vdd_l2_l23-supply: -- vdd_l3-supply: -- vdd_l4_l5_l6_l7_l16-supply: -- vdd_l8_l11_l12_l17_l22-supply: -- vdd_l9_l10_l13_l14_l15_l18-supply: -- vdd_l20-supply: -- vdd_l21-supply: - Usage: optional (pm8950 only) - Value type: <phandle> - Definition: reference to regulator supplying the input pin, as - described in the data sheet - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s4-supply: -- vdd_s5-supply: -- vdd_s6-supply: -- vdd_s7-supply: -- vdd_s8-supply: -- vdd_s9-supply: -- vdd_s10-supply: -- vdd_s11-supply: -- vdd_s12-supply: -- vdd_l1-supply: -- vdd_l2_l26_l28-supply: -- vdd_l3_l11-supply: -- vdd_l4_l27_l31-supply: -- vdd_l5_l7-supply: -- vdd_l6_l12_l32-supply: -- vdd_l8_l16_l30-supply: -- vdd_l9_l10_l18_l22-supply: -- vdd_l13_l19_l23_l24-supply: -- vdd_l14_l15-supply: -- vdd_l17_l29-supply: -- vdd_l20_l21-supply: -- vdd_l25-supply: -- vdd_lvs_1_2-supply: - Usage: optional (pm8994 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_l1-supply: - Usage: optional (pmi8994 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_l1_l6_l7-supply: -- vdd_l2_l3-supply: -- vdd_l5-supply: -- vdd_l8_l9_l10_l11_l12_l13_l14-supply: -- vdd_l15_l16_l17_l18_l19-supply: -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s5-supply: -- vdd_s6-supply: - Usage: optional (pm660 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_l1_l9_l10-supply: -- vdd_l2-supply: -- vdd_l3_l5_l7_l8-supply: -- vdd_l4_l6-supply: -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s4-supply: -- vdd_s5-supply: - Usage: optional (pm660l only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- vdd_l1_l2-supply: -- vdd_l3_l8-supply: -- vdd_l4-supply: -- vdd_l5_l6-supply: -- vdd_l10_l11_l12_l13-supply: -- vdd_l7-supply: -- vdd_l9-supply: -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_s4-supply: -- vdd_s5-supply - Usage: optional (pms405 only) - Value type: <phandle> - Definition: Reference to regulator supplying the input pin, as - described in the data sheet. - -- qcom,saw-reg: - Usage: optional - Value type: <phandle> - Description: Reference to syscon node defining the SAW registers. - - -The regulator node houses sub-nodes for each regulator within the device. Each -sub-node is identified using the node's name, with valid values listed for each -of the PMICs below. - -pm8004: - s2, s5 - -pm8005: - s1, s2, s3, s4 - -pm8841: - s1, s2, s3, s4, s5, s6, s7, s8 - -pm8916: - s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, - l14, l15, l16, l17, l18 - -pm8941: - s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, - l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2, lvs3, - 5vs1, 5vs2 - -pm8994: - s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5, - l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, - l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2 - -pmi8994: - s1, s2, s3, l1 - -The content of each sub-node is defined by the standard binding for regulators - -see regulator.txt - with additional custom properties described below: - -- regulator-initial-mode: - Usage: optional - Value type: <u32> - Description: 2 = Set initial mode to auto mode (automatically select - between HPM and LPM); not available on boost type - regulators. - - 1 = Set initial mode to high power mode (HPM), also referred - to as NPM. HPM consumes more ground current than LPM, but - it can source significantly higher load current. HPM is not - available on boost type regulators. For voltage switch type - regulators, HPM implies that over current protection and - soft start are active all the time. - - 0 = Set initial mode to low power mode (LPM). - -- qcom,ocp-max-retries: - Usage: optional - Value type: <u32> - Description: Maximum number of times to try toggling a voltage switch - off and back on as a result of consecutive over current - events. - -- qcom,ocp-retry-delay: - Usage: optional - Value type: <u32> - Description: Time to delay in milliseconds between each voltage switch - toggle after an over current event takes place. - -- qcom,pin-ctrl-enable: - Usage: optional - Value type: <u32> - Description: Bit mask specifying which hardware pins should be used to - enable the regulator, if any; supported bits are: - 0 = ignore all hardware enable signals - BIT(0) = follow HW0_EN signal - BIT(1) = follow HW1_EN signal - BIT(2) = follow HW2_EN signal - BIT(3) = follow HW3_EN signal - -- qcom,pin-ctrl-hpm: - Usage: optional - Value type: <u32> - Description: Bit mask specifying which hardware pins should be used to - force the regulator into high power mode, if any; - supported bits are: - 0 = ignore all hardware enable signals - BIT(0) = follow HW0_EN signal - BIT(1) = follow HW1_EN signal - BIT(2) = follow HW2_EN signal - BIT(3) = follow HW3_EN signal - BIT(4) = follow PMIC awake state - -- qcom,vs-soft-start-strength: - Usage: optional - Value type: <u32> - Description: This property sets the soft start strength for voltage - switch type regulators; supported values are: - 0 = 0.05 uA - 1 = 0.25 uA - 2 = 0.55 uA - 3 = 0.75 uA - -- qcom,saw-slave: - Usage: optional - Value type: <boo> - Description: SAW controlled gang slave. Will not be configured. - -- qcom,saw-leader: - Usage: optional - Value type: <boo> - Description: SAW controlled gang leader. Will be configured as - SAW regulator. - -Example: - - regulators { - compatible = "qcom,pm8941-regulators"; - vdd_l1_l3-supply = <&s1>; - - s1: s1 { - regulator-min-microvolt = <1300000>; - regulator-max-microvolt = <1400000>; - }; - - ... - - l1: l1 { - regulator-min-microvolt = <1225000>; - regulator-max-microvolt = <1300000>; - }; - - .... - }; - -Example 2: - - saw3: syscon@9A10000 { - compatible = "syscon"; - reg = <0x9A10000 0x1000>; - }; - - ... - - spm-regulators { - compatible = "qcom,pm8994-regulators"; - qcom,saw-reg = <&saw3>; - s8 { - qcom,saw-slave; - }; - s9 { - qcom,saw-slave; - }; - s10 { - qcom,saw-slave; - }; - pm8994_s11_saw: s11 { - qcom,saw-leader; - regulator-always-on; - regulator-min-microvolt = <900000>; - regulator-max-microvolt = <1140000>; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml new file mode 100644 index 000000000000..8b7c4af4b551 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml @@ -0,0 +1,323 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/qcom,spmi-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SPMI Regulators + +maintainers: + - Robert Marko <robimarko@gmail.com> + +properties: + compatible: + enum: + - qcom,pm660-regulators + - qcom,pm660l-regulators + - qcom,pm8004-regulators + - qcom,pm8005-regulators + - qcom,pm8226-regulators + - qcom,pm8841-regulators + - qcom,pm8916-regulators + - qcom,pm8941-regulators + - qcom,pm8950-regulators + - qcom,pm8994-regulators + - qcom,pmi8994-regulators + - qcom,pmp8074-regulators + - qcom,pms405-regulators + + qcom,saw-reg: + description: Reference to syscon node defining the SAW registers + $ref: /schemas/types.yaml#/definitions/phandle + +patternProperties: + "^(5vs[1-2]|(l|s)[1-9][0-9]?|lvs[1-3])$": + description: List of regulators and its properties + type: object + $ref: regulator.yaml# + + properties: + qcom,ocp-max-retries: + description: + Maximum number of times to try toggling a voltage switch off and + back on as a result of consecutive over current events + $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,ocp-retry-delay: + description: + Time to delay in milliseconds between each voltage switch toggle + after an over current event takes place + $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,pin-ctrl-enable: + description: + Bit mask specifying which hardware pins should be used to enable the + regulator, if any. + Supported bits are + 0 = ignore all hardware enable signals + BIT(0) = follow HW0_EN signal + BIT(1) = follow HW1_EN signal + BIT(2) = follow HW2_EN signal + BIT(3) = follow HW3_EN signal + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + qcom,pin-ctrl-hpm: + description: + Bit mask specifying which hardware pins should be used to force the + regulator into high power mode, if any. + Supported bits are + 0 = ignore all hardware enable signals + BIT(0) = follow HW0_EN signal + BIT(1) = follow HW1_EN signal + BIT(2) = follow HW2_EN signal + BIT(3) = follow HW3_EN signal + BIT(4) = follow PMIC awake state + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + + qcom,vs-soft-start-strength: + description: + This property sets the soft start strength for voltage switch type + regulators. + Supported values are + 0 = 0.05 uA + 1 = 0.25 uA + 2 = 0.55 uA + 3 = 0.75 uA + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + + qcom,saw-slave: + description: SAW controlled gang slave. Will not be configured. + type: boolean + + qcom,saw-leader: + description: + SAW controlled gang leader. Will be configured as SAW regulator. + type: boolean + + unevaluatedProperties: false + +required: + - compatible + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,pm660-regulators + then: + properties: + vdd_l15_l16_l17_l18_l19-supply: true + vdd_l1_l6_l7-supply: true + vdd_l2_l3-supply: true + vdd_l5-supply: true + vdd_l8_l9_l10_l11_l12_l13_l14-supply: true + patternProperties: + "^vdd_s[1-6]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm660l-regulators + then: + properties: + vdd_l1_l9_l10-supply: true + vdd_l2-supply: true + vdd_l3_l5_l7_l8-supply: true + vdd_l4_l6-supply: true + patternProperties: + "^vdd_s[1-5]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8004-regulators + then: + patternProperties: + "^vdd_s[25]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8005-regulators + then: + patternProperties: + "^vdd_s[1-4]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8226-regulators + then: + properties: + vdd_l10_l11_l13-supply: true + vdd_l12_l14-supply: true + vdd_l15_l16_l17_l18-supply: true + vdd_l19_l20_l21_l22_l23_l28-supply: true + vdd_l1_l2_l4_l5-supply: true + vdd_l25-supply: true + vdd_l3_l24_l26-supply: true + vdd_l6_l7_l8_l9_l27-supply: true + vdd_lvs1-supply: true + patternProperties: + "^vdd_s[1-5]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8841-regulators + then: + patternProperties: + "^vdd_s[1-8]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8916-regulators + then: + properties: + vdd_l1_l3-supply: true + vdd_l4_l5_l6-supply: true + vdd_l8_l11_l14_l15_l16-supply: true + vdd_l9_l10_l12_l13_l17_l18-supply: true + patternProperties: + "^vdd_l[27]-supply$": true + "^vdd_s[1-4]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8941-regulators + then: + properties: + interrupts: + items: + - description: Over-current protection interrupt for 5V S1 + - description: Over-current protection interrupt for 5V S2 + interrupt-names: + items: + - const: ocp-5vs1 + - const: ocp-5vs2 + vdd_l13_l20_l23_l24-supply: true + vdd_l1_l3-supply: true + vdd_l21-supply: true + vdd_l2_lvs_1_2_3-supply: true + vdd_l4_l11-supply: true + vdd_l5_l7-supply: true + vdd_l6_l12_l14_l15-supply: true + vdd_l8_l16_l18_19-supply: true + vdd_l9_l10_l17_l22-supply: true + vin_5vs-supply: true + patternProperties: + "^vdd_s[1-3]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8950-regulators + then: + properties: + vdd_l1_l19-supply: true + vdd_l20-supply: true + vdd_l21-supply: true + vdd_l2_l23-supply: true + vdd_l3-supply: true + vdd_l4_l5_l6_l7_l16-supply: true + vdd_l8_l11_l12_l17_l22-supply: true + vdd_l9_l10_l13_l14_l15_l18-supply: true + patternProperties: + "^vdd_s[1-6]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8994-regulators + then: + properties: + vdd_l1-supply: true + vdd_l13_l19_l23_l24-supply: true + vdd_l14_l15-supply: true + vdd_l17_l29-supply: true + vdd_l20_l21-supply: true + vdd_l25-supply: true + vdd_l2_l26_l28-supply: true + vdd_l3_l11-supply: true + vdd_l4_l27_l31-supply: true + vdd_l5_l7-supply: true + vdd_l6_l12_l32-supply: true + vdd_l8_l16_l30-supply: true + vdd_l9_l10_l18_l22-supply: true + vdd_lvs_1_2-supply: true + patternProperties: + "^vdd_s[1-9][0-2]?-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pmi8994-regulators + then: + properties: + vdd_l1-supply: true + patternProperties: + "^vdd_s[1-3]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pmp8074-regulators + then: + properties: + vdd_l10_l11_l12_l13-supply: true + vdd_l1_l2-supply: true + vdd_l3_l8-supply: true + vdd_l5_l6_l15-supply: true + patternProperties: + "^vdd_l[479]-supply$": true + "^vdd_s[1-5]-supply$": true + - if: + properties: + compatible: + contains: + enum: + - qcom,pms405-regulators + then: + properties: + vdd_s3-supply: true + +unevaluatedProperties: false + +examples: + - | + regulators { + compatible = "qcom,pm8941-regulators"; + vdd_l1_l3-supply = <&s1>; + + s1: s1 { + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1400000>; + }; + + l1: l1 { + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1300000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index a9b66ececccf..6e8aa9eed3aa 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -23,6 +23,7 @@ properties: regulator-microvolt-offset: description: Offset applied to voltages to compensate for voltage drops + $ref: "/schemas/types.yaml#/definitions/uint32" regulator-min-microamp: description: smallest current consumers may set diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index eec3b9c4c713..7e091eaffc18 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -18,6 +18,7 @@ properties: enum: - mediatek,mt8183-scp - mediatek,mt8186-scp + - mediatek,mt8188-scp - mediatek,mt8192-scp - mediatek,mt8195-scp @@ -80,6 +81,7 @@ allOf: enum: - mediatek,mt8183-scp - mediatek,mt8186-scp + - mediatek,mt8188-scp then: properties: reg: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 947f94548d0e..3072af5f9d79 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -67,13 +67,28 @@ properties: minItems: 1 maxItems: 8 + interconnects: + maxItems: 1 + interrupts: minItems: 5 - maxItems: 6 + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt interrupt-names: minItems: 5 - maxItems: 6 + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack resets: minItems: 1 @@ -116,7 +131,6 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string-array description: The names of the state bits used for SMP2P output items: - const: stop @@ -134,13 +148,13 @@ properties: three offsets within syscon for q6, modem and nc halt registers. smd-edge: - type: object + $ref: /schemas/remoteproc/qcom,smd-edge.yaml# description: Qualcomm Shared Memory subnode which represents communication edge, channels and devices related to the ADSP. glink-edge: - type: object + $ref: /schemas/remoteproc/qcom,glink-edge.yaml# description: Qualcomm G-Link subnode which represents communication edge, channels and devices related to the ADSP. @@ -315,19 +329,9 @@ allOf: then: properties: interrupts: - items: - - description: Watchdog interrupt - - description: Fatal interrupt - - description: Ready interrupt - - description: Handover interrupt - - description: Stop acknowledge interrupt + maxItems: 5 interrupt-names: - items: - - const: wdog - - const: fatal - - const: ready - - const: handover - - const: stop-ack + maxItems: 5 - if: properties: @@ -345,21 +349,9 @@ allOf: then: properties: interrupts: - items: - - description: Watchdog interrupt - - description: Fatal interrupt - - description: Ready interrupt - - description: Handover interrupt - - description: Stop acknowledge interrupt - - description: Shutdown acknowledge interrupt + minItems: 6 interrupt-names: - items: - - const: wdog - - const: fatal - - const: ready - - const: handover - - const: stop-ack - - const: shutdown-ack + minItems: 6 - if: properties: @@ -379,6 +371,8 @@ allOf: - qcom,msm8226-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8998-adsp-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas then: properties: power-domains: @@ -447,19 +441,6 @@ allOf: compatible: contains: enum: - - qcom,sm8150-adsp-pas - - qcom,sm8150-cdsp-pas - then: - properties: - power-domains: - items: - - description: CX power domain - - - if: - properties: - compatible: - contains: - enum: - qcom,sc7280-mpss-pas - qcom,sdx55-mpss-pas - qcom,sm6350-mpss-pas @@ -594,11 +575,12 @@ allOf: examples: - | #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interrupt-controller/irq.h> adsp { compatible = "qcom,msm8974-adsp-pil"; - interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>, + interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, @@ -620,7 +602,7 @@ examples: qcom,smem-state-names = "stop"; smd-edge { - interrupts = <0 156 IRQ_TYPE_EDGE_RISING>; + interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>; qcom,ipc = <&apcs 8 8>; qcom,smd-edge = <1>; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml new file mode 100644 index 000000000000..fa69f7b21eed --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,glink-edge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm G-Link Edge communication channel nodes + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + Qualcomm G-Link subnode represents communication edge, channels and devices + related to the remote processor. + +properties: + $nodename: + const: "glink-edge" + + apr: + $ref: /schemas/soc/qcom/qcom,apr.yaml# + description: + Qualcomm APR/GPR (Asynchronous/Generic Packet Router) + + fastrpc: + type: object + description: + See Documentation/devicetree/bindings/misc/qcom,fastrpc.txt + + interrupts: + maxItems: 1 + + label: + description: The names of the state bits used for SMP2P output + + mboxes: + maxItems: 1 + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + ID of the shared memory used by GLINK for communication with remote + processor. + +required: + - interrupts + - label + - mboxes + - qcom,remote-pid + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + + remoteproc@8a00000 { + reg = <0x08a00000 0x10000>; + // ... + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP>; + + label = "wpss"; + qcom,remote-pid = <13>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index b677900b3aae..d0ebd16ee0e1 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -14,8 +14,6 @@ on the Qualcomm Hexagon core. "qcom,msm8974-mss-pil" "qcom,msm8996-mss-pil" "qcom,msm8998-mss-pil" - "qcom,sc7180-mss-pil" - "qcom,sc7280-mss-pil" "qcom,sdm845-mss-pil" - reg: @@ -37,7 +35,7 @@ on the Qualcomm Hexagon core. - interrupt-names: Usage: required Value type: <stringlist> - Definition: The interrupts needed depends on the the compatible + Definition: The interrupts needed depends on the compatible string: qcom,q6v5-pil: qcom,ipq8074-wcss-pil: @@ -47,8 +45,6 @@ on the Qualcomm Hexagon core. must be "wdog", "fatal", "ready", "handover", "stop-ack" qcom,msm8996-mss-pil: qcom,msm8998-mss-pil: - qcom,sc7180-mss-pil: - qcom,sc7280-mss-pil: qcom,sdm845-mss-pil: must be "wdog", "fatal", "ready", "handover", "stop-ack", "shutdown-ack" @@ -86,11 +82,6 @@ on the Qualcomm Hexagon core. qcom,msm8998-mss-pil: must be "iface", "bus", "mem", "xo", "gpll0_mss", "snoc_axi", "mnoc_axi", "qdss" - qcom,sc7180-mss-pil: - must be "iface", "bus", "xo", "snoc_axi", "mnoc_axi", - "nav" - qcom,sc7280-mss-pil: - must be "iface", "xo", "snoc_axi", "offline", "pka" qcom,sdm845-mss-pil: must be "iface", "bus", "mem", "xo", "gpll0_mss", "snoc_axi", "mnoc_axi", "prng" @@ -102,7 +93,7 @@ on the Qualcomm Hexagon core. reference to the list of 3 reset-controllers for the wcss sub-system reference to the list of 2 reset-controllers for the modem - sub-system on SC7180, SC7280, SDM845 SoCs + sub-system on SDM845 SoCs - reset-names: Usage: required @@ -111,7 +102,7 @@ on the Qualcomm Hexagon core. must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset" for the wcss sub-system must be "mss_restart", "pdc_reset" for the modem - sub-system on SC7180, SC7280, SDM845 SoCs + sub-system on SDM845 SoCs For devices where the mba and mpss sub-nodes are not specified, mba/mpss region should be referenced as follows: @@ -176,10 +167,6 @@ For the compatible string below the following supplies are required: qcom,msm8996-mss-pil: qcom,msm8998-mss-pil: must be "cx", "mx" - qcom,sc7180-mss-pil: - must be "cx", "mx", "mss" - qcom,sc7280-mss-pil: - must be "cx", "mss" qcom,sdm845-mss-pil: must be "cx", "mx", "mss" @@ -205,36 +192,6 @@ For the compatible string below the following supplies are required: Definition: a phandle reference to a syscon representing TCSR followed by the three offsets within syscon for q6, modem and nc halt registers. - a phandle reference to a syscon representing TCSR followed - by the four offsets within syscon for q6, modem, nc and vq6 - halt registers on SC7280 SoCs. - -For the compatible strings below the following phandle references are required: - "qcom,sc7180-mss-pil" -- qcom,spare-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: a phandle reference to a syscon representing TCSR followed - by the offset within syscon for conn_box_spare0 register - used by the modem sub-system running on SC7180 SoC. - -For the compatible strings below the following phandle references are required: - "qcom,sc7280-mss-pil" -- qcom,ext-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: two phandle references to syscons representing TCSR_REG and - TCSR register space followed by the two offsets within the syscon - to force_clk_en/rscc_disable and axim1_clk_off/crypto_clk_off - registers respectively. - -- qcom,qaccept-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: a phandle reference to a syscon representing TCSR followed - by the three offsets within syscon for mdm, cx and axi - qaccept registers used by the modem sub-system running on - SC7280 SoC. The Hexagon node must contain iommus property as described in ../iommu/iommu.txt on platforms which do not have TrustZone. @@ -257,29 +214,23 @@ related to the Hexagon. See ../soc/qcom/qcom,smd.yaml and The following example describes the resources needed to boot control the Hexagon, as it is found on MSM8974 boards. - modem-rproc@fc880000 { - compatible = "qcom,q6v5-pil"; - reg = <0xfc880000 0x100>, - <0xfc820000 0x020>; + remoteproc@fc880000 { + compatible = "qcom,msm8974-mss-pil"; + reg = <0xfc880000 0x100>, <0xfc820000 0x020>; reg-names = "qdsp6", "rmb"; - interrupts-extended = <&intc 0 24 1>, - <&modem_smp2p_in 0 0>, - <&modem_smp2p_in 1 0>, - <&modem_smp2p_in 2 0>, - <&modem_smp2p_in 3 0>; - interrupt-names = "wdog", - "fatal", - "ready", - "handover", - "stop-ack"; + interrupts-extended = <&intc GIC_SPI 24 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; clocks = <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>, <&gcc GCC_MSS_CFG_AHB_CLK>, - <&gcc GCC_BOOT_ROM_AHB_CLK>; - clock-names = "iface", "bus", "mem"; - - qcom,halt-regs = <&tcsr_mutex_block 0x1180 0x1200 0x1280>; + <&gcc GCC_BOOT_ROM_AHB_CLK>, + <&xo_board>; + clock-names = "iface", "bus", "mem", "xo"; resets = <&gcc GCC_MSS_RESTART>; reset-names = "mss_restart"; @@ -289,6 +240,8 @@ Hexagon, as it is found on MSM8974 boards. mx-supply = <&pm8841_s1>; pll-supply = <&pm8941_l12>; + qcom,halt-regs = <&tcsr_mutex_block 0x1180 0x1200 0x1280>; + qcom,smem-states = <&modem_smp2p_out 0>; qcom,smem-state-names = "stop"; @@ -299,4 +252,13 @@ Hexagon, as it is found on MSM8974 boards. mpss { memory-region = <&mpss_region>; }; + + smd-edge { + interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>; + + qcom,ipc = <&apcs 8 12>; + qcom,smd-edge = <0>; + + label = "modem"; + }; }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml index 31413cfe10db..06f5f93f62a9 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml @@ -90,7 +90,6 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output items: - const: stop diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml new file mode 100644 index 000000000000..e76c861165dd --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml @@ -0,0 +1,245 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sc7180-mss-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7180 MSS Peripheral Image Loader + +maintainers: + - Sibi Sankar <quic_sibis@quicinc.com> + +description: + This document describes the hardware for a component that loads and boots firmware + on the Qualcomm Technology Inc. SC7180 Modem Hexagon Core. + +properties: + compatible: + enum: + - qcom,sc7180-mss-pil + + reg: + items: + - description: MSS QDSP6 registers + - description: RMB registers + + reg-names: + items: + - const: qdsp6 + - const: rmb + + iommus: + items: + - description: MSA Stream 1 + - description: MSA Stream 2 + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + clocks: + items: + - description: GCC MSS IFACE clock + - description: GCC MSS BUS clock + - description: GCC MSS NAV clock + - description: GCC MSS SNOC_AXI clock + - description: GCC MSS MFAB_AXIS clock + - description: RPMH XO clock + + clock-names: + items: + - const: iface + - const: bus + - const: nav + - const: snoc_axi + - const: mnoc_axi + - const: xo + + power-domains: + items: + - description: CX power domain + - description: MX power domain + - description: MSS power domain + + power-domain-names: + items: + - const: cx + - const: mx + - const: mss + + resets: + items: + - description: AOSS restart + - description: PDC reset + + reset-names: + items: + - const: mss_restart + - const: pdc_reset + + memory-region: + items: + - description: MBA reserved region + - description: modem reserved region + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string-array + items: + - description: Name of MBA firmware + - description: Name of modem firmware + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Halt registers are used to halt transactions of various sub-components + within MSS. + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the Q6 halt register + - description: offset to the modem halt register + - description: offset to the nc halt register + + qcom,spare-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Spare registers are multipurpose registers used for errata + handling. + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the conn_box_spare0 register + + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + description: The names of the state bits used for SMP2P output + const: stop + + glink-edge: + $ref: qcom,glink-edge.yaml# + description: + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the DSP. + + properties: + interrupts: + items: + - description: IRQ from MSS to GLINK + + mboxes: + items: + - description: Mailbox for communication between APPS and MSS + + label: + const: modem + + apr: false + fastrpc: false + +required: + - compatible + - reg + - reg-names + - iommus + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + - qcom,spare-regs + - memory-region + - qcom,qmp + - qcom,smem-states + - qcom,smem-state-names + - glink-edge + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/reset/qcom,sdm845-aoss.h> + #include <dt-bindings/reset/qcom,sdm845-pdc.h> + + remoteproc_mpss: remoteproc@4080000 { + compatible = "qcom,sc7180-mss-pil"; + reg = <0x04080000 0x10000>, <0x04180000 0x48>; + reg-names = "qdsp6", "rmb"; + + iommus = <&apps_smmu 0x461 0x0>, <&apps_smmu 0x444 0x3>; + + interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&gcc GCC_MSS_CFG_AHB_CLK>, + <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>, + <&gcc GCC_MSS_NAV_AXI_CLK>, + <&gcc GCC_MSS_SNOC_AXI_CLK>, + <&gcc GCC_MSS_MFAB_AXIS_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "bus", "nav", "snoc_axi", + "mnoc_axi", "xo"; + + power-domains = <&rpmhpd SC7180_CX>, + <&rpmhpd SC7180_MX>, + <&rpmhpd SC7180_MSS>; + power-domain-names = "cx", "mx", "mss"; + + memory-region = <&mba_mem>, <&mpss_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&modem_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + resets = <&aoss_reset AOSS_CC_MSS_RESTART>, + <&pdc_reset PDC_MODEM_SYNC_RESET>; + reset-names = "mss_restart", "pdc_reset"; + + qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>; + qcom,spare-regs = <&tcsr_regs 0xb3e4>; + + glink-edge { + interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>; + mboxes = <&apss_shared 12>; + qcom,remote-pid = <1>; + label = "modem"; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml new file mode 100644 index 000000000000..da1a5de3d38b --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml @@ -0,0 +1,266 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-mss-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7280 MSS Peripheral Image Loader + +maintainers: + - Sibi Sankar <quic_sibis@quicinc.com> + +description: + This document describes the hardware for a component that loads and boots firmware + on the Qualcomm Technology Inc. SC7280 Modem Hexagon Core. + +properties: + compatible: + enum: + - qcom,sc7280-mss-pil + + reg: + items: + - description: MSS QDSP6 registers + - description: RMB registers + + reg-names: + items: + - const: qdsp6 + - const: rmb + + iommus: + items: + - description: MSA Stream 1 + - description: MSA Stream 2 + + interconnects: + items: + - description: Path leading to system memory + + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + clocks: + items: + - description: GCC MSS IFACE clock + - description: GCC MSS OFFLINE clock + - description: GCC MSS SNOC_AXI clock + - description: RPMH PKA clock + - description: RPMH XO clock + + clock-names: + items: + - const: iface + - const: offline + - const: snoc_axi + - const: pka + - const: xo + + power-domains: + items: + - description: CX power domain + - description: MSS power domain + + power-domain-names: + items: + - const: cx + - const: mss + + resets: + items: + - description: AOSS restart + - description: PDC reset + + reset-names: + items: + - const: mss_restart + - const: pdc_reset + + memory-region: + items: + - description: MBA reserved region + - description: modem reserved region + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string-array + items: + - description: Name of MBA firmware + - description: Name of modem firmware + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Halt registers are used to halt transactions of various sub-components + within MSS. + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the Q6 halt register + - description: offset to the modem halt register + - description: offset to the nc halt register + - description: offset to the vq6 halt register + + qcom,ext-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: EXT registers are used for various power related functionality + items: + - items: + - description: phandle to TCSR_REG registers + - description: offset to the force_clk_en register + - description: offset to the rscc_disable register + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the axim1_clk_off register + - description: offset to the crypto_clk_off register + + qcom,qaccept-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: QACCEPT registers are used to bring up/down Q-channels + items: + - items: + - description: phandle to TCSR_MUTEX registers + - description: offset to the mdm qaccept register + - description: offset to the cx qaccept register + - description: offset to the axi qaccept register + + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + description: The names of the state bits used for SMP2P output + const: stop + + glink-edge: + $ref: qcom,glink-edge.yaml# + description: + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the DSP. + + properties: + interrupts: + items: + - description: IRQ from MSS to GLINK + + mboxes: + items: + - description: Mailbox for communication between APPS and MSS + + label: + const: modem + + apr: false + fastrpc: false + +required: + - compatible + - reg + - reg-names + - iommus + - interconnects + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + - qcom,ext-regs + - qcom,qaccept-regs + - memory-region + - qcom,qmp + - qcom,smem-states + - qcom,smem-state-names + - glink-edge + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/reset/qcom,sdm845-aoss.h> + #include <dt-bindings/reset/qcom,sdm845-pdc.h> + + remoteproc_mpss: remoteproc@4080000 { + compatible = "qcom,sc7280-mss-pil"; + reg = <0x04080000 0x10000>, <0x04180000 0x48>; + reg-names = "qdsp6", "rmb"; + + iommus = <&apps_smmu 0x124 0x0>, <&apps_smmu 0x488 0x7>; + + interconnects = <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>; + + interrupts-extended = <&intc GIC_SPI 264 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&gcc GCC_MSS_CFG_AHB_CLK>, + <&gcc GCC_MSS_OFFLINE_AXI_CLK>, + <&gcc GCC_MSS_SNOC_AXI_CLK>, + <&rpmhcc RPMH_PKA_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "offline", "snoc_axi", "pka", "xo"; + + power-domains = <&rpmhpd SC7280_CX>, + <&rpmhpd SC7280_MSS>; + power-domain-names = "cx", "mss"; + + memory-region = <&mba_mem>, <&mpss_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&modem_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + resets = <&aoss_reset AOSS_CC_MSS_RESTART>, + <&pdc_reset PDC_MODEM_SYNC_RESET>; + reset-names = "mss_restart", "pdc_reset"; + + qcom,halt-regs = <&tcsr_mutex 0x23000 0x25000 0x28000 0x33000>; + qcom,ext-regs = <&tcsr 0x10000 0x10004>, <&tcsr_mutex 0x26004 0x26008>; + qcom,qaccept-regs = <&tcsr_mutex 0x23030 0x23040 0x23020>; + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_MPSS + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_MPSS + IPCC_MPROC_SIGNAL_GLINK_QMP>; + label = "modem"; + qcom,remote-pid = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml index d99a729d2710..3f06d66cbe47 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml @@ -76,7 +76,7 @@ properties: - const: pdc_sync memory-region: - $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 description: Reference to the reserved-memory for the Hexagon core firmware-name: @@ -102,13 +102,12 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output const: stop glink-edge: - type: object - description: | + $ref: qcom,glink-edge.yaml# + description: Qualcomm G-Link subnode which represents communication edge, channels and devices related to the ADSP. @@ -122,21 +121,11 @@ properties: - description: Mailbox for communication between APPS and WPSS label: - description: The names of the state bits used for SMP2P output items: - const: wpss - qcom,remote-pid: - $ref: /schemas/types.yaml#/definitions/uint32 - description: ID of the shared memory used by GLINK for communication with WPSS - - required: - - interrupts - - mboxes - - label - - qcom,remote-pid - - additionalProperties: false + apr: false + fastrpc: false required: - compatible diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml index 1535bbbe25da..20df83a96ef3 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml @@ -90,7 +90,6 @@ properties: - description: Stop the modem qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string description: The names of the state bits used for SMP2P output items: - const: stop diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml new file mode 100644 index 000000000000..06eebf791e32 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,smd-edge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SMD Edge communication channel nodes + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + Qualcomm SMD subnode represents a remote subsystem or a remote processor of + some sort - or in SMD language an "edge". The name of the edges are not + important. + See also Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml + +properties: + $nodename: + const: "smd-edge" + + interrupts: + maxItems: 1 + + label: + description: + Name of the edge, used for debugging and identification purposes. The + node name will be used if this is not present. + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client. + + qcom,ipc: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to a syscon node representing the APCS registers + - description: u32 representing offset to the register within the syscon + - description: u32 representing the ipc bit within the register + description: + Three entries specifying the outgoing ipc bit used for signaling the + remote processor. + + qcom,smd-edge: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier of the remote processor in the smd channel allocation + table. + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The identifier for the remote processor as known by the rest of the + system. + +required: + - interrupts + - qcom,smd-edge + +oneOf: + - required: + - mboxes + - required: + - qcom,ipc + +additionalProperties: true + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + + remoteproc { + // ... + + smd-edge { + interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>; + + qcom,ipc = <&apcs 8 8>; + qcom,smd-edge = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml index d7c3a78e37e6..cd55d80137f7 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml @@ -36,17 +36,18 @@ properties: enum: - ti,am3356-pru # for AM335x SoC family (AM3356+ SoCs only) - ti,am4376-pru # for AM437x SoC family (AM4376+ SoCs only) + - ti,am5728-pru # for AM57xx SoC family + - ti,am625-pru # for PRUs in K3 AM62x SoC family - ti,am642-pru # for PRUs in K3 AM64x SoC family - ti,am642-rtu # for RTUs in K3 AM64x SoC family - ti,am642-tx-pru # for Tx_PRUs in K3 AM64x SoC family - - ti,am5728-pru # for AM57xx SoC family - - ti,k2g-pru # for 66AK2G SoC family - ti,am654-pru # for PRUs in K3 AM65x SoC family - ti,am654-rtu # for RTUs in K3 AM65x SoC family - ti,am654-tx-pru # for Tx_PRUs in K3 AM65x SR2.0 SoCs - ti,j721e-pru # for PRUs in K3 J721E SoC family - ti,j721e-rtu # for RTUs in K3 J721E SoC family - ti,j721e-tx-pru # for Tx_PRUs in K3 J721E SoC family + - ti,k2g-pru # for 66AK2G SoC family reg: items: diff --git a/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml new file mode 100644 index 000000000000..98465d26949e --- /dev/null +++ b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/atmel,at91sam9260-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel/Microchip System Reset Controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: | + The system reset controller can be used to reset the CPU. In case of + SAMA7G5 it can also reset some devices (e.g. USB PHYs). + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at91sam9260-rstc + - atmel,at91sam9g45-rstc + - atmel,sama5d3-rstc + - microchip,sam9x60-rstc + - microchip,sama7g5-rstc + - items: + - const: atmel,sama5d3-rstc + - const: atmel,at91sam9g45-rstc + + reg: + minItems: 1 + items: + - description: base registers for system reset control + - description: registers for device specific reset control + + clocks: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - clocks + +allOf: + - if: + properties: + compatible: + contains: + enum: + - microchip,sama7g5-rstc + then: + required: + - "#reset-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + + reset-controller@fffffd00 { + compatible = "atmel,at91sam9260-rstc"; + reg = <0xfffffd00 0x10>; + clocks = <&pmc PMC_TYPE_CORE PMC_SLOW>; + }; diff --git a/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml index fa5e4ea6400e..d82e65e37cc0 100644 --- a/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml +++ b/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: nuvoton,npcm750-reset + enum: + - nuvoton,npcm750-reset # Poleg NPCM7XX SoC + - nuvoton,npcm845-reset # Arbel NPCM8XX SoC reg: maxItems: 1 @@ -19,6 +21,10 @@ properties: '#reset-cells': const: 2 + nuvoton,sysgcr: + $ref: /schemas/types.yaml#/definitions/phandle + description: a phandle to access GCR registers. + nuvoton,sw-reset-number: $ref: /schemas/types.yaml#/definitions/uint32 minimum: 1 @@ -31,6 +37,7 @@ required: - compatible - reg - '#reset-cells' + - nuvoton,sysgcr additionalProperties: false @@ -41,6 +48,7 @@ examples: compatible = "nuvoton,npcm750-reset"; reg = <0xf0801000 0x70>; #reset-cells = <2>; + nuvoton,sysgcr = <&gcr>; nuvoton,sw-reset-number = <2>; }; diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml index 86c2569ced97..731b8ce01525 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml @@ -17,6 +17,7 @@ properties: compatible: items: - enum: + - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC} - renesas,r9a07g054-usbphy-ctrl # RZ/V2L - const: renesas,rzg2l-usbphy-ctrl diff --git a/Documentation/devicetree/bindings/reset/sunplus,reset.yaml b/Documentation/devicetree/bindings/reset/sunplus,reset.yaml new file mode 100644 index 000000000000..f24646ba9761 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/sunplus,reset.yaml @@ -0,0 +1,38 @@ +# 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/reset/sunplus,reset.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Sunplus SoC Reset Controller + +maintainers: + - Qin Jian <qinjian@cqplus1.com> + +properties: + compatible: + const: sunplus,sp7021-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#reset-cells" + +additionalProperties: false + +examples: + - | + rstc: reset@9c000054 { + compatible = "sunplus,sp7021-reset"; + reg = <0x9c000054 0x28>; + #reset-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml new file mode 100644 index 000000000000..afc835eda0ef --- /dev/null +++ b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/ti,tps380x-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS380x reset controller node bindings + +maintainers: + - Marco Felsch <kernel@pengutronix.de> + +description: | + The TPS380x family [1] of supervisory circuits monitor supply voltages to + provide circuit initialization and timing supervision. The devices assert a + RESET signal if the voltage drops below a preset threshold or upon a manual + reset input (MR). The RESET output remains asserted for the factory + programmed delay after the voltage return above its threshold or after the + manual reset input is released. + + [1] https://www.ti.com/product/TPS3801 + +properties: + compatible: + enum: + - ti,tps3801 + + reset-gpios: + maxItems: 1 + description: Reference to the GPIO connected to the MR pin. + + "#reset-cells": + const: 0 + +required: + - compatible + - reset-gpios + - "#reset-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + reset: reset-controller { + compatible = "ti,tps3801"; + #reset-cells = <0>; + reset-gpios = <&gpio3 2 GPIO_ACTIVE_LOW>; + }; +... diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index d632ac76532e..873dd12f6e89 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -63,6 +63,11 @@ properties: - riscv,sv48 - riscv,none + riscv,cbom-block-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The blocksize in bytes for the Zicbom cache operations. + riscv,isa: description: Identifies the specific RISC-V instruction set architecture diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index e2d330bd4608..69cdab18d629 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -46,7 +46,7 @@ properties: const: 2 cache-sets: - const: 1024 + enum: [1024, 2048] cache-size: const: 2097152 @@ -84,6 +84,8 @@ then: description: | Must contain entries for DirError, DataError and DataFail signals. maxItems: 3 + cache-sets: + const: 1024 else: properties: @@ -91,6 +93,8 @@ else: description: | Must contain entries for DirError, DataError, DataFail, DirFail signals. minItems: 4 + cache-sets: + const: 2048 additionalProperties: false diff --git a/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml b/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml new file mode 100644 index 000000000000..8c102b70d735 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/fsl,scu-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - RTC bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + const: fsl,imx8qxp-sc-rtc + +required: + - compatible + +additionalProperties: false + +examples: + - | + rtc { + compatible = "fsl,imx8qxp-sc-rtc"; + }; diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml index 9593840a4a2b..60f9027e8299 100644 --- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml +++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml @@ -32,6 +32,7 @@ properties: - 11000 trickle-voltage-millivolt: + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 1750 - 3000 diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml new file mode 100644 index 000000000000..7a1857f5caa8 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nuvoton,nct3018y.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NUVOTON NCT3018Y Real Time Clock + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Medad CChien <ctcchien@nuvoton.com> + - Mia Lin <mimi05633@gmail.com> + +properties: + compatible: + const: nuvoton,nct3018y + + reg: + maxItems: 1 + + start-year: true + + reset-source: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@6f { + compatible = "nuvoton,nct3018y"; + reg = <0x6f>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt deleted file mode 100644 index 217b7cd06c11..000000000000 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt +++ /dev/null @@ -1,32 +0,0 @@ -* NXP PCF85063 Real Time Clock - -Required properties: -- compatible: Should one of contain: - "nxp,pca85073a", - "nxp,pcf85063", - "nxp,pcf85063a", - "nxp,pcf85063tp", - "microcrystal,rv8263" -- reg: I2C address for chip. - -Optional property: -- quartz-load-femtofarads: The capacitive load of the quartz(x-tal), - expressed in femto Farad (fF). Valid values are 7000 and 12500. - Default value (if no value is specified) is 7000fF. - -Optional child node: -- clock: Provide this if the square wave pin is used as boot-enabled fixed clock. - -Example: - -pcf85063: rtc@51 { - compatible = "nxp,pcf85063"; - reg = <0x51>; - quartz-load-femtofarads = <12500>; - - clock { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - }; -}; diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml new file mode 100644 index 000000000000..2f892f8640d1 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nxp,pcf85063.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCF85063 Real Time Clock + +maintainers: + - Alexander Stein <alexander.stein@ew.tq-group.com> + +properties: + compatible: + enum: + - microcrystal,rv8263 + - nxp,pcf85063 + - nxp,pcf85063a + - nxp,pcf85063tp + - nxp,pca85073a + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + interrupts: + maxItems: 1 + + quartz-load-femtofarads: + description: + The capacitive load of the quartz(x-tal). + enum: [7000, 12500] + default: 7000 + + clock: + $ref: /schemas/clock/fixed-clock.yaml + description: + Provide this if the square wave pin is used as boot-enabled + fixed clock. + + wakeup-source: true + +allOf: + - $ref: rtc.yaml# + - if: + properties: + compatible: + contains: + enum: + - microcrystal,rv8263 + then: + properties: + quartz-load-femtofarads: false + - if: + properties: + compatible: + contains: + enum: + - nxp,pcf85063 + then: + properties: + quartz-load-femtofarads: + const: 7000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@51 { + compatible = "nxp,pcf85063a"; + reg = <0x51>; + quartz-load-femtofarads = <12500>; + + clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml index 6fa7d9fc2dc7..23ab5bb4f395 100644 --- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm PM8xxx PMIC RTC device maintainers: - - Satya Priya <skakit@codeaurora.org> + - Satya Priya <quic_c_skakit@quicinc.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt b/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt deleted file mode 100644 index 36f610bb051e..000000000000 --- a/Documentation/devicetree/bindings/rtc/rtc-ds1307.txt +++ /dev/null @@ -1,52 +0,0 @@ -Dallas DS1307 and compatible RTC - -Required properties: -- compatible: should be one of: - "dallas,ds1307", - "dallas,ds1308", - "dallas,ds1337", - "dallas,ds1338", - "dallas,ds1339", - "dallas,ds1388", - "dallas,ds1340", - "dallas,ds1341", - "maxim,ds3231", - "st,m41t0", - "st,m41t00", - "st,m41t11", - "microchip,mcp7940x", - "microchip,mcp7941x", - "pericom,pt7c4338", - "epson,rx8025", - "isil,isl12057" - "epson,rx8130" -- reg: I2C bus address of the device - -Optional properties: -- interrupts: rtc alarm interrupt. -- clock-output-names: From common clock binding to override the default output - clock name -- wakeup-source: Enables wake up of host system on alarm -- trickle-resistor-ohms : ds1339, ds1340 and ds 1388 only - Selected resistor for trickle charger - Possible values are 250, 2000, 4000 - Should be given if trickle charger should be enabled -- aux-voltage-chargeable: ds1339, ds1340, ds1388 and rx8130 only - Tells whether the battery/supercap of the RTC (if any) is - chargeable or not. - Possible values are 0 (not chargeable), 1 (chargeable) - -Deprecated properties: -- trickle-diode-disable : ds1339, ds1340 and ds1388 only - Do not use internal trickle charger diode - Should be given if internal trickle charger diode should be disabled - (superseded by aux-voltage-chargeable) - -Example: - ds1339: rtc@68 { - compatible = "dallas,ds1339"; - reg = <0x68>; - interrupt-parent = <&gpio4>; - interrupts = <20 0>; - trickle-resistor-ohms = <250>; - }; diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml b/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml new file mode 100644 index 000000000000..98d10e680144 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/rtc-ds1307.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dallas DS1307 and compatible RTC + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +properties: + compatible: + oneOf: + - enum: + - dallas,ds1307 + - dallas,ds1308 + - dallas,ds1337 + - dallas,ds1338 + - dallas,ds1339 + - dallas,ds1388 + - dallas,ds1340 + - dallas,ds1341 + - maxim,ds3231 + - st,m41t0 + - st,m41t00 + - st,m41t11 + - microchip,mcp7940x + - microchip,mcp7941x + - pericom,pt7c4338 + - epson,rx8025 + - isil,isl12057 + - epson,rx8130 + + - items: + - enum: + - st,m41t00 + - const: dallas,ds1338 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + maxItems: 2 + + "#clock-cells": + const: 1 + + clock-output-names: + description: From common clock binding to override the default output clock name. + + wakeup-source: + description: Enables wake up of host system on alarm. + + vcc-supply: true + +allOf: + - $ref: rtc.yaml + - if: + properties: + compatible: + contains: + enum: + - dallas,ds1339 + - dallas,ds1340 + - dallas,ds1388 + then: + properties: + trickle-resistor-ohms: + description: Selected resistor for trickle charger. Should be specified if trickle + charger should be enabled. + enum: [ 250, 2000, 4000 ] + + trickle-diode-disable: + description: Do not use internal trickle charger diode. Should be given if internal + trickle charger diode should be disabled (superseded by aux-voltage-chargeable) + deprecated: true + +unevaluatedProperties: false + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@68 { + compatible = "dallas,ds1337"; + reg = <0x68>; + interrupt-parent = <&gpio4>; + interrupts = <20 0>; + trickle-resistor-ohms = <250>; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt index 55a0c8874c03..7212076a8f1b 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt @@ -14,6 +14,8 @@ For MediaTek PMIC wrapper bus bindings, see: Required properties: - compatible: Should be one of follows "mediatek,mt6323-rtc": for MT6323 PMIC + "mediatek,mt6358-rtc": for MT6358 PMIC + "mediatek,mt6366-rtc", "mediatek,mt6358-rtc": for MT6366 PMIC "mediatek,mt6397-rtc": for MT6397 PMIC Example: diff --git a/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml new file mode 100644 index 000000000000..d995ef04a6eb --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/ti,k3-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments K3 Real Time Clock + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + This RTC appears in the AM62x family of SoCs. + +allOf: + - $ref: "rtc.yaml#" + +properties: + compatible: + enum: + - ti,am62-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: VBUS Interface clock + - description: 32k Clock source (external or internal). + + clock-names: + items: + - const: vbus + - const: osc32k + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + rtc@2b1f0000 { + compatible = "ti,am62-rtc"; + reg = <0x2b1f0000 0x100>; + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&bar 0>; + clocks = <&foo 0>, <&foo 1>; + clock-names = "vbus", "osc32k"; + wakeup-source; + }; diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index 13925bb78ec7..d9fc120c61cc 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -30,6 +30,8 @@ properties: - dallas,ds1672 # Extremely Accurate I²C RTC with Integrated Crystal and SRAM - dallas,ds3232 + # EM Microelectronic EM3027 RTC + - emmicro,em3027 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE - epson,rx8010 # I2C-BUS INTERFACE REAL TIME CLOCK MODULE diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml index bdb72d3ddf2a..7ed0230f6c67 100644 --- a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml @@ -23,8 +23,15 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + + clock-names: + items: + - const: rtc + interrupts: - minItems: 2 + maxItems: 2 interrupt-names: items: @@ -39,6 +46,7 @@ properties: minimum: 0x1 maximum: 0x1FFFFF default: 0x198233 + deprecated: true required: - compatible @@ -61,5 +69,7 @@ examples: interrupts = <0 26 4>, <0 27 4>; interrupt-names = "alarm", "sec"; calibration = <0x198233>; + clock-names = "rtc"; + clocks = <&rtc_clk>; }; }; diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 5f6b113d378f..6258f5f59b19 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -62,6 +62,7 @@ properties: - const: mrvl,pxa-uart - const: nuvoton,wpcm450-uart - const: nuvoton,npcm750-uart + - const: nuvoton,npcm845-uart - const: nvidia,tegra20-uart - const: nxp,lpc3220-uart - items: diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt deleted file mode 100644 index 4f8d8fde0c1c..000000000000 --- a/Documentation/devicetree/bindings/serial/efm32-uart.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Energymicro efm32 UART - -Required properties: -- compatible : Should be "energymicro,efm32-uart" -- reg : Address and length of the register set -- interrupts : Should contain uart interrupt - -Optional properties: -- energymicro,location : Decides the location of the USART I/O pins. - Allowed range : [0 .. 5] - Default: 0 - -Example: - -uart@4000c400 { - compatible = "energymicro,efm32-uart"; - reg = <0x4000c400 0x400>; - interrupts = <15>; - energymicro,location = <0>; -}; diff --git a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml new file mode 100644 index 000000000000..4ff27d6d4d5b --- /dev/null +++ b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/mediatek,uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Universal Asynchronous Receiver/Transmitter (UART) + +maintainers: + - Matthias Brugger <matthias.bgg@gmail.com> + +allOf: + - $ref: serial.yaml# + +description: | + The MediaTek UART is based on the basic 8250 UART and compatible + with 16550A, with enhancements for high speed baud rates and + support for DMA. + +properties: + compatible: + oneOf: + - const: mediatek,mt6577-uart + - items: + - enum: + - mediatek,mt2701-uart + - mediatek,mt2712-uart + - mediatek,mt6580-uart + - mediatek,mt6582-uart + - mediatek,mt6589-uart + - mediatek,mt6755-uart + - mediatek,mt6765-uart + - mediatek,mt6779-uart + - mediatek,mt6795-uart + - mediatek,mt6797-uart + - mediatek,mt7622-uart + - mediatek,mt7623-uart + - mediatek,mt7629-uart + - mediatek,mt7986-uart + - mediatek,mt8127-uart + - mediatek,mt8135-uart + - mediatek,mt8173-uart + - mediatek,mt8183-uart + - mediatek,mt8186-uart + - mediatek,mt8192-uart + - mediatek,mt8195-uart + - mediatek,mt8516-uart + - const: mediatek,mt6577-uart + + reg: + description: The base address of the UART register bank + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: The clock the baudrate is derived from + - description: The bus clock for register accesses + + clock-names: + minItems: 1 + items: + - const: baud + - const: bus + + dmas: + items: + - description: phandle to TX DMA + - description: phandle to RX DMA + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + description: + The UART interrupt and optionally the RX in-band wakeup interrupt. + minItems: 1 + items: + - const: uart + - const: wakeup + + pinctrl-0: true + pinctrl-1: true + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: sleep + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + serial@11006000 { + compatible = "mediatek,mt6589-uart", "mediatek,mt6577-uart"; + reg = <0x11006000 0x400>; + interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 52 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "uart", "wakeup"; + clocks = <&uart_clk>, <&bus_clk>; + clock-names = "baud", "bus"; + pinctrl-0 = <&uart_pin>; + pinctrl-1 = <&uart_pin_sleep>; + pinctrl-names = "default", "sleep"; + }; diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt deleted file mode 100644 index 113b5d6a2245..000000000000 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ /dev/null @@ -1,59 +0,0 @@ -* MediaTek Universal Asynchronous Receiver/Transmitter (UART) - -Required properties: -- compatible should contain: - * "mediatek,mt2701-uart" for MT2701 compatible UARTS - * "mediatek,mt2712-uart" for MT2712 compatible UARTS - * "mediatek,mt6580-uart" for MT6580 compatible UARTS - * "mediatek,mt6582-uart" for MT6582 compatible UARTS - * "mediatek,mt6589-uart" for MT6589 compatible UARTS - * "mediatek,mt6755-uart" for MT6755 compatible UARTS - * "mediatek,mt6765-uart" for MT6765 compatible UARTS - * "mediatek,mt6779-uart" for MT6779 compatible UARTS - * "mediatek,mt6795-uart" for MT6795 compatible UARTS - * "mediatek,mt6797-uart" for MT6797 compatible UARTS - * "mediatek,mt7622-uart" for MT7622 compatible UARTS - * "mediatek,mt7623-uart" for MT7623 compatible UARTS - * "mediatek,mt7629-uart" for MT7629 compatible UARTS - * "mediatek,mt7986-uart", "mediatek,mt6577-uart" for MT7986 compatible UARTS - * "mediatek,mt8127-uart" for MT8127 compatible UARTS - * "mediatek,mt8135-uart" for MT8135 compatible UARTS - * "mediatek,mt8173-uart" for MT8173 compatible UARTS - * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS - * "mediatek,mt8186-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS - * "mediatek,mt8192-uart", "mediatek,mt6577-uart" for MT8192 compatible UARTS - * "mediatek,mt8195-uart", "mediatek,mt6577-uart" for MT8195 compatible UARTS - * "mediatek,mt8516-uart" for MT8516 compatible UARTS - * "mediatek,mt6577-uart" for MT6577 and all of the above - -- reg: The base address of the UART register bank. - -- interrupts: - index 0: an interrupt specifier for the UART controller itself - index 1: optional, an interrupt specifier with edge sensitivity on Rx pin to - support Rx in-band wake up. If one would like to use this feature, - one must create an addtional pinctrl to reconfigure Rx pin to normal - GPIO before suspend. - -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: - - "baud": The clock the baudrate is derived from - - "bus": The bus clock for register accesses (optional) - -For compatibility with older device trees an unnamed clock is used for the -baud clock if the baudclk does not exist. Do not use this for new designs. - -Example: - - uart0: serial@11006000 { - compatible = "mediatek,mt6589-uart", "mediatek,mt6577-uart"; - reg = <0x11006000 0x400>; - interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 52 IRQ_TYPE_EDGE_FALLING>; - clocks = <&uart_clk>, <&bus_clk>; - clock-names = "baud", "bus"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&uart_pin>; - pinctrl-1 = <&uart_pin_sleep>; - }; diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml index 87180d95cd4c..1957b9d782e8 100644 --- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml @@ -57,6 +57,7 @@ properties: - items: - enum: - renesas,hscif-r8a779a0 # R-Car V3U + - renesas,hscif-r8a779f0 # R-Car S4-8 - renesas,hscif-r8a779g0 # R-Car V4H - const: renesas,rcar-gen4-hscif # R-Car Gen4 - const: renesas,hscif # generic HSCIF compatible UART diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml index f2c9c9fe6aa7..90a1bab40f05 100644 --- a/Documentation/devicetree/bindings/serial/rs485.yaml +++ b/Documentation/devicetree/bindings/serial/rs485.yaml @@ -22,12 +22,12 @@ properties: - description: Delay between rts signal and beginning of data sent in milliseconds. It corresponds to the delay before sending data. default: 0 - maximum: 1000 + maximum: 100 - description: Delay between end of data sent and rts signal in milliseconds. It corresponds to the delay after sending data and actual release of the line. default: 0 - maximum: 1000 + maximum: 100 rs485-rts-active-low: description: drive RTS low when sending (default is high). diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 12137fe80acf..dc74643ae72e 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -33,7 +33,9 @@ properties: - rockchip,rk3368-uart - rockchip,rk3399-uart - rockchip,rk3568-uart + - rockchip,rk3588-uart - rockchip,rv1108-uart + - rockchip,rv1126-uart - const: snps,dw-apb-uart - items: - enum: diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.txt b/Documentation/devicetree/bindings/serio/ps2-gpio.txt deleted file mode 100644 index 7b7bc9cdf986..000000000000 --- a/Documentation/devicetree/bindings/serio/ps2-gpio.txt +++ /dev/null @@ -1,23 +0,0 @@ -Device-Tree binding for ps/2 gpio device - -Required properties: - - compatible = "ps2-gpio" - - data-gpios: the data pin - - clk-gpios: the clock pin - - interrupts: Should trigger on the falling edge of the clock line. - -Optional properties: - - write-enable: Indicates whether write function is provided - to serio device. Possibly providing the write fn will not work, because - of the tough timing requirements. - -Example nodes: - -ps2@0 { - compatible = "ps2-gpio"; - interrupt-parent = <&gpio>; - interrupts = <23 IRQ_TYPE_EDGE_FALLING>; - data-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; - clk-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>; - write-enable; -}; diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.yaml b/Documentation/devicetree/bindings/serio/ps2-gpio.yaml new file mode 100644 index 000000000000..a63d9172346f --- /dev/null +++ b/Documentation/devicetree/bindings/serio/ps2-gpio.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serio/ps2-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for GPIO based PS/2 + +maintainers: + - Danilo Krummrich <danilokrummrich@dk-develop.de> + +properties: + compatible: + const: ps2-gpio + + data-gpios: + description: + the gpio used for the data signal - this should be flagged as + active high using open drain with (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN) + from <dt-bindings/gpio/gpio.h> since the signal is open drain by + definition + maxItems: 1 + + clk-gpios: + description: + the gpio used for the clock signal - this should be flagged as + active high using open drain with (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN) + from <dt-bindings/gpio/gpio.h> since the signal is open drain by + definition + maxItems: 1 + + interrupts: + description: + The given interrupt should trigger on the falling edge of the clock line. + maxItems: 1 + + write-enable: + type: boolean + description: + Indicates whether write function is provided to serio device. Possibly + providing the write function will not work, because of the tough timing + requirements. + +required: + - compatible + - data-gpios + - clk-gpios + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + ps2 { + compatible = "ps2-gpio"; + interrupt-parent = <&gpio>; + interrupts = <23 IRQ_TYPE_EDGE_FALLING>; + data-gpios = <&gpio 24 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + clk-gpios = <&gpio 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + write-enable; + }; diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt deleted file mode 100644 index 72ff033565e5..000000000000 --- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt +++ /dev/null @@ -1,46 +0,0 @@ -BCM2835 PM (Power domains, watchdog) - -The PM block controls power domains and some reset lines, and includes -a watchdog timer. This binding supersedes the brcm,bcm2835-pm-wdt -binding which covered some of PM's register range and functionality. - -Required properties: - -- compatible: Should be "brcm,bcm2835-pm" -- reg: Specifies base physical address and size of the two - register ranges ("PM" and "ASYNC_BRIDGE" in that - order) -- clocks: a) v3d: The V3D clock from CPRMAN - b) peri_image: The PERI_IMAGE clock from CPRMAN - c) h264: The H264 clock from CPRMAN - d) isp: The ISP clock from CPRMAN -- #reset-cells: Should be 1. This property follows the reset controller - bindings[1]. -- #power-domain-cells: Should be 1. This property follows the power domain - bindings[2]. - -Optional properties: - -- timeout-sec: Contains the watchdog timeout in seconds -- system-power-controller: Whether the watchdog is controlling the - system power. This node follows the power controller bindings[3]. - -[1] Documentation/devicetree/bindings/reset/reset.txt -[2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/power/power-controller.txt - -Example: - -pm { - compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; - #power-domain-cells = <1>; - #reset-cells = <1>; - reg = <0x7e100000 0x114>, - <0x7e00a000 0x24>; - clocks = <&clocks BCM2835_CLOCK_V3D>, - <&clocks BCM2835_CLOCK_PERI_IMAGE>, - <&clocks BCM2835_CLOCK_H264>, - <&clocks BCM2835_CLOCK_ISP>; - clock-names = "v3d", "peri_image", "h264", "isp"; - system-power-controller; -}; diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml new file mode 100644 index 000000000000..e28ef198a801 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/bcm/brcm,bcm2835-pm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BCM2835 PM (Power domains, watchdog) + +description: | + The PM block controls power domains and some reset lines, and includes a + watchdog timer. + +maintainers: + - Nicolas Saenz Julienne <nsaenz@kernel.org> + +allOf: + - $ref: /schemas/watchdog/watchdog.yaml# + +properties: + compatible: + items: + - enum: + - brcm,bcm2835-pm + - brcm,bcm2711-pm + - const: brcm,bcm2835-pm-wdt + + reg: + minItems: 2 + maxItems: 3 + + reg-names: + minItems: 2 + items: + - const: pm + - const: asb + - const: rpivid_asb + + "#power-domain-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + minItems: 4 + maxItems: 4 + + clock-names: + items: + - const: v3d + - const: peri_image + - const: h264 + - const: isp + + system-power-controller: + type: boolean + + timeout-sec: true + +required: + - compatible + - reg + - "#power-domain-cells" + - "#reset-cells" + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + + watchdog@7e100000 { + compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; + #power-domain-cells = <1>; + #reset-cells = <1>; + reg = <0x7e100000 0x114>, + <0x7e00a000 0x24>; + reg-names = "pm", "asb"; + clocks = <&clocks BCM2835_CLOCK_V3D>, + <&clocks BCM2835_CLOCK_PERI_IMAGE>, + <&clocks BCM2835_CLOCK_H264>, + <&clocks BCM2835_CLOCK_ISP>; + clock-names = "v3d", "peri_image", "h264", "isp"; + system-power-controller; + }; diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml index 31e4d3c339bf..d0a4bc3b03e9 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - mediatek,mt6779-devapc + - mediatek,mt8186-devapc reg: description: The base address of devapc register bank diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml index 3fdad71210b4..627dcc3e8b32 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/mediatek/mediatek,mutex.yaml# +$id: http://devicetree.org/schemas/soc/mediatek/mediatek,mutex.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Mediatek mutex @@ -55,6 +55,18 @@ properties: include/dt-bindings/gce/<chip>-gce.h of each chips. $ref: /schemas/types.yaml#/definitions/uint32-array + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + description: The register of client driver can be configured by gce with + 4 arguments defined in this property. Each GCE subsys id is mapping to + a client defined in the header include/dt-bindings/gce/<chip>-gce.h. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml new file mode 100644 index 000000000000..d911fa2d40ef --- /dev/null +++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Smart Voltage Scaling (SVS) Device Tree Bindings + +maintainers: + - Roger Lu <roger.lu@mediatek.com> + - Matthias Brugger <matthias.bgg@gmail.com> + - Kevin Hilman <khilman@kernel.org> + +description: |+ + The SVS engine is a piece of hardware which has several + controllers(banks) for calculating suitable voltage to + different power domains(CPU/GPU/CCI) according to + chip process corner, temperatures and other factors. Then DVFS + driver could apply SVS bank voltage to PMIC/Buck. + +properties: + compatible: + enum: + - mediatek,mt8183-svs + - mediatek,mt8192-svs + + reg: + maxItems: 1 + description: Address range of the MTK SVS controller. + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: Main clock for MTK SVS controller to work. + + clock-names: + const: main + + nvmem-cells: + minItems: 1 + description: + Phandle to the calibration data provided by a nvmem device. + items: + - description: SVS efuse for SVS controller + - description: Thermal efuse for SVS controller + + nvmem-cell-names: + items: + - const: svs-calibration-data + - const: t-calibration-data + + resets: + maxItems: 1 + + reset-names: + items: + - const: svs_rst + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - nvmem-cells + - nvmem-cell-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + svs@1100b000 { + compatible = "mediatek,mt8183-svs"; + reg = <0 0x1100b000 0 0x1000>; + interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>; + clocks = <&infracfg CLK_INFRA_THERM>; + clock-names = "main"; + nvmem-cells = <&svs_calibration>, <&thermal_calibration>; + nvmem-cell-names = "svs-calibration-data", "t-calibration-data"; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml index 597d67fba92f..33748a061898 100644 --- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/microchip/atmel,at91rm9200-tcb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/microchip/atmel,at91rm9200-tcb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Atmel Timer Counter Block @@ -75,7 +75,7 @@ patternProperties: "^pwm@[0-2]$": description: The timer block channels that are used as PWMs. - $ref: ../../pwm/pwm.yaml# + $ref: /schemas/pwm/pwm.yaml# type: object properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml index b0dae51e1d42..04ffee3a7c59 100644 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/microchip/microchip,mpfs-sys-controller.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-sys-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) system controller diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index e2e173dfada7..a4eeb7e158e5 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -13,7 +13,7 @@ description: This binding describes the hardware component responsible for side channel requests to the always-on subsystem (AOSS), used for certain power management requests that is not handled by the standard RPMh interface. Each client in the - SoC has it's own block of message RAM and IRQ for communication with the AOSS. + SoC has its own block of message RAM and IRQ for communication with the AOSS. The protocol used to communicate in the message RAM is known as Qualcomm Messaging Protocol (QMP) @@ -33,6 +33,7 @@ properties: - qcom,sm8150-aoss-qmp - qcom,sm8250-aoss-qmp - qcom,sm8350-aoss-qmp + - qcom,sm8450-aoss-qmp - const: qcom,aoss-qmp reg: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml index f5ecf4a8c377..4a50f1d27724 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml @@ -65,33 +65,22 @@ properties: qcom,tcs-config: $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 4 + maxItems: 4 items: - - items: - - description: TCS type - enum: [ 0, 1, 2, 3 ] - - description: Number of TCS - - items: - - description: TCS type - enum: [ 0, 1, 2, 3 ] - - description: Number of TCS - - items: - - description: TCS type - enum: [ 0, 1, 2, 3] - - description: Numbe r of TCS - - items: - - description: TCS type - enum: [ 0, 1, 2, 3 ] - - description: Number of TCS + items: + - description: | + TCS type:: + - ACTIVE_TCS + - SLEEP_TCS + - WAKE_TCS + - CONTROL_TCS + enum: [ 0, 1, 2, 3 ] + - description: Number of TCS description: | The tuple defining the configuration of TCS. Must have two cells which describe each TCS type. The order of the TCS must match the hardware configuration. - Cell 1 (TCS Type):: TCS types to be specified:: - - ACTIVE_TCS - - SLEEP_TCS - - WAKE_TCS - - CONTROL_TCS - Cell 2 (Number of TCS):: <u32> qcom,tcs-offset: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index f0f1bf06aea6..09d5bfa920f2 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -34,6 +34,7 @@ properties: - qcom,rpm-apq8084 - qcom,rpm-ipq6018 - qcom,rpm-msm8226 + - qcom,rpm-msm8909 - qcom,rpm-msm8916 - qcom,rpm-msm8936 - qcom,rpm-msm8953 @@ -51,6 +52,9 @@ properties: $ref: /schemas/clock/qcom,rpmcc.yaml# unevaluatedProperties: false + power-controller: + $ref: /schemas/power/qcom,rpmpd.yaml# + qcom,smd-channels: $ref: /schemas/types.yaml#/definitions/string-array description: Channel name used for the RPM communication @@ -88,12 +92,33 @@ examples: qcom,ipc = <&apcs 8 0>; qcom,smd-edge = <15>; - rpm-requests { - compatible = "qcom,rpm-msm8974"; - qcom,smd-channels = "rpm_requests"; + rpm-requests { + compatible = "qcom,rpm-msm8916"; + qcom,smd-channels = "rpm_requests"; + + clock-controller { + compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; + #clock-cells = <1>; + clocks = <&xo_board>; + clock-names = "xo"; + }; - /* Regulator nodes to follow */ + power-controller { + compatible = "qcom,msm8916-rpmpd"; + #power-domain-cells = <1>; + operating-points-v2 = <&rpmpd_opp_table>; + + rpmpd_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-1 { + opp-level = <1>; + }; + opp-2 { + opp-level = <2>; + }; + }; }; }; - }; -... + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml index bca07bb13ebf..9b3efe97f47c 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml @@ -21,51 +21,13 @@ properties: patternProperties: "^.*-edge|rpm$": - type: object + $ref: /schemas/remoteproc/qcom,smd-edge.yaml# description: Each subnode of the SMD node represents a remote subsystem or a remote processor of some sort - or in SMD language an "edge". The name of the edges are not important. properties: - interrupts: - maxItems: 1 - - label: - $ref: /schemas/types.yaml#/definitions/string - description: - Name of the edge, used for debugging and identification purposes. The - node name will be used if this is not present. - - mboxes: - maxItems: 1 - description: - Reference to the mailbox representing the outgoing doorbell in APCS for - this client. - - qcom,ipc: - $ref: /schemas/types.yaml#/definitions/phandle-array - items: - - items: - - description: phandle to a syscon node representing the APCS registers - - description: u32 representing offset to the register within the syscon - - description: u32 representing the ipc bit within the register - description: - Three entries specifying the outgoing ipc bit used for signaling the - remote processor. - - qcom,smd-edge: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - The identifier of the remote processor in the smd channel allocation - table. - - qcom,remote-pid: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - The identifier for the remote processor as known by the rest of the - system. - rpm-requests: type: object description: @@ -89,17 +51,7 @@ patternProperties: additionalProperties: true - required: - - interrupts - - qcom,smd-edge - - oneOf: - - required: - - mboxes - - required: - - qcom,ipc - - additionalProperties: false + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml index 07d2d5398345..f433e6e0a19f 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml @@ -22,6 +22,7 @@ properties: - qcom,sdm660-silver-saw2-v4.1-l2 - qcom,msm8998-gold-saw2-v4.1-l2 - qcom,msm8998-silver-saw2-v4.1-l2 + - qcom,msm8909-saw2-v3.0-cpu - qcom,msm8916-saw2-v3.0-cpu - qcom,msm8226-saw2-v2.1-cpu - qcom,msm8974-saw2-v2.1-cpu diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml index d891ecfb2691..5320504bb5e0 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml @@ -77,7 +77,6 @@ properties: Should reference the tx-enable and tx-rings-empty SMEM states. qcom,smem-state-names: - $ref: /schemas/types.yaml#/definitions/string-array items: - const: tx-enable - const: tx-rings-empty diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index c30a6437030d..13bb8dfcefe6 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -49,9 +49,6 @@ properties: reg: maxItems: 1 - assigned-clock-parents: true - assigned-clocks: true - '#clock-cells': const: 1 @@ -77,14 +74,20 @@ properties: Must be identical to the that of the parent interrupt controller. const: 3 + reboot-mode: + $ref: /schemas/power/reset/syscon-reboot-mode.yaml + type: object + description: + Reboot mode to alter bootloader behavior for the next boot + syscon-poweroff: - $ref: "../../power/reset/syscon-poweroff.yaml#" + $ref: /schemas/power/reset/syscon-poweroff.yaml# type: object description: Node for power off method syscon-reboot: - $ref: "../../power/reset/syscon-reboot.yaml#" + $ref: /schemas/power/reset/syscon-reboot.yaml# type: object description: Node for reboot method diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index fde886a8cf43..60b49562ff69 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -22,8 +22,12 @@ properties: pattern: "^usi@[0-9a-f]+$" compatible: - enum: - - samsung,exynos850-usi # for USIv2 (Exynos850, ExynosAutoV9) + oneOf: + - items: + - const: samsung,exynosautov9-usi + - const: samsung,exynos850-usi + - enum: + - samsung,exynos850-usi reg: true diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 64461d432004..847873289f25 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -65,10 +65,11 @@ properties: - ti,am4376-pruss0 # for AM437x SoC family and PRUSS unit 0 - ti,am4376-pruss1 # for AM437x SoC family and PRUSS unit 1 - ti,am5728-pruss # for AM57xx SoC family - - ti,k2g-pruss # for 66AK2G SoC family + - ti,am625-pruss # for K3 AM62x SoC family + - ti,am642-icssg # for K3 AM64x SoC family - ti,am654-icssg # for K3 AM65x SoC family - ti,j721e-icssg # for K3 J721E SoC family - - ti,am642-icssg # for K3 AM64x SoC family + - ti,k2g-pruss # for 66AK2G SoC family reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.yaml b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml index b80454ad97da..847b83398d3d 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau1977.yaml +++ b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml @@ -32,8 +32,6 @@ properties: reset-gpios: maxItems: 1 - spi-max-frequency: true - AVDD-supply: description: Analog power support for the device. @@ -52,7 +50,10 @@ required: - compatible - AVDD-supply -additionalProperties: false +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/sound/adi,max98396.yaml b/Documentation/devicetree/bindings/sound/adi,max98396.yaml index ec4c10c2598a..8d2ef991db40 100644 --- a/Documentation/devicetree/bindings/sound/adi,max98396.yaml +++ b/Documentation/devicetree/bindings/sound/adi,max98396.yaml @@ -24,6 +24,21 @@ properties: maxItems: 1 description: I2C address of the device. + avdd-supply: + description: A 1.8V supply that powers up the AVDD pin. + + dvdd-supply: + description: A 1.2V supply that powers up the DVDD pin. + + dvddio-supply: + description: A 1.2V or 1.8V supply that powers up the VDDIO pin. + + pvdd-supply: + description: A 3.0V to 20V supply that powers up the PVDD pin. + + vbat-supply: + description: A 3.3V to 5.5V supply that powers up the VBAT pin. + adi,vmon-slot-no: description: slot number of the voltage sense monitor $ref: "/schemas/types.yaml#/definitions/uint32" @@ -36,13 +51,22 @@ properties: $ref: "/schemas/types.yaml#/definitions/uint32" minimum: 0 maximum: 15 - default: 0 + default: 1 adi,spkfb-slot-no: description: slot number of speaker DSP monitor $ref: "/schemas/types.yaml#/definitions/uint32" minimum: 0 maximum: 15 + default: 2 + + adi,bypass-slot-no: + description: + Selects the PCM data input channel that is routed to the speaker + audio processing bypass path. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 15 default: 0 adi,interleave-mode: @@ -72,6 +96,10 @@ examples: max98396: amplifier@39 { compatible = "adi,max98396"; reg = <0x39>; + dvdd-supply = <®ulator_1v2>; + dvddio-supply = <®ulator_1v8>; + avdd-supply = <®ulator_1v8>; + pvdd-supply = <®ulator_pvdd>; adi,vmon-slot-no = <0>; adi,imon-slot-no = <1>; reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml index 3b764415c9ab..66859eb8f79a 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml @@ -21,6 +21,11 @@ properties: description: Regulator for the headphone amplifier + allwinner,internal-bias-resistor: + description: + Enable the internal 2.2K bias resistor between HBIAS and MICDET pins + type: boolean + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml b/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml new file mode 100644 index 000000000000..43d04702ac2d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,sama5d2-classd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel ClassD Amplifier + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: + The Audio Class D Amplifier (CLASSD) is a digital input, Pulse Width + Modulated (PWM) output stereo Class D amplifier. + +properties: + compatible: + const: atmel,sama5d2-classd + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: tx + + clocks: + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: gclk + + atmel,model: + $ref: /schemas/types.yaml#/definitions/string + default: CLASSD + description: The user-visible name of this sound complex. + + atmel,pwm-type: + $ref: /schemas/types.yaml#/definitions/string + enum: + - single + - diff + default: single + description: PWM modulation type. + + atmel,non-overlap-time: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 5 + - 10 + - 15 + - 20 + default: 10 + description: + Set non-overlapping time, the unit is nanosecond(ns). + Non-overlapping will be disabled if not specified. + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + classd: sound@fc048000 { + compatible = "atmel,sama5d2-classd"; + reg = <0xfc048000 0x100>; + interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>; + dmas = <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) + | AT91_XDMAC_DT_PERID(47))>; + dma-names = "tx"; + clocks = <&classd_clk>, <&classd_gclk>; + clock-names = "pclk", "gclk"; + assigned-clocks = <&classd_gclk>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_classd_default>; + atmel,model = "classd @ SAMA5D2-Xplained"; + atmel,pwm-type = "diff"; + atmel,non-overlap-time = <10>; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel,sama5d2-i2s.yaml b/Documentation/devicetree/bindings/sound/atmel,sama5d2-i2s.yaml new file mode 100644 index 000000000000..0cd1ff89baed --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,sama5d2-i2s.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,sama5d2-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel I2S controller + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: + Atmel I2S (Inter-IC Sound Controller) bus is the standard + interface for connecting audio devices, such as audio codecs. + +properties: + compatible: + const: atmel,sama5d2-i2s + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral clock + - description: Generated clock (Optional) + - description: I2S mux clock (Optional). Set + with gclk when Master Mode is required. + minItems: 1 + + clock-names: + items: + - const: pclk + - const: gclk + - const: muxclk + minItems: 1 + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2s@f8050000 { + compatible = "atmel,sama5d2-i2s"; + reg = <0xf8050000 0x300>; + interrupts = <54 IRQ_TYPE_LEVEL_HIGH 7>; + dmas = <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | + AT91_XDMAC_DT_PERID(31))>, + <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | + AT91_XDMAC_DT_PERID(32))>; + dma-names = "tx", "rx"; + clocks = <&i2s0_clk>, <&i2s0_gclk>, <&i2s0muxck>; + clock-names = "pclk", "gclk", "muxclk"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2s0_default>; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel,sama5d2-pdmic.yaml b/Documentation/devicetree/bindings/sound/atmel,sama5d2-pdmic.yaml new file mode 100644 index 000000000000..f320b561f24c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,sama5d2-pdmic.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,sama5d2-pdmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel PDMIC decoder + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: + Atmel Pulse Density Modulation Interface Controller + (PDMIC) peripheral is a mono PDM decoder module + that decodes an incoming PDM sample stream. + +properties: + compatible: + const: atmel,sama5d2-pdmic + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: peripheral clock + - description: generated clock + + clock-names: + items: + - const: pclk + - const: gclk + + dmas: + maxItems: 1 + + dma-names: + const: rx + + atmel,mic-min-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The minimal frequency that the microphone supports. + + atmel,mic-max-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The maximal frequency that the microphone supports. + + atmel,model: + $ref: /schemas/types.yaml#/definitions/string + default: PDMIC + description: The user-visible name of this sound card. + + atmel,mic-offset: + $ref: /schemas/types.yaml#/definitions/int32 + default: 0 + description: The offset that should be added. + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + - clock-names + - clocks + - atmel,mic-min-freq + - atmel,mic-max-freq + +additionalProperties: false + +examples: + - | + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pdmic: sound@f8018000 { + compatible = "atmel,sama5d2-pdmic"; + reg = <0xf8018000 0x124>; + interrupts = <48 IRQ_TYPE_LEVEL_HIGH 7>; + dmas = <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) + | AT91_XDMAC_DT_PERID(50))>; + dma-names = "rx"; + clocks = <&pdmic_clk>, <&pdmic_gclk>; + clock-names = "pclk", "gclk"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pdmic_default>; + atmel,model = "PDMIC@sama5d2_xplained"; + atmel,mic-min-freq = <1000000>; + atmel,mic-max-freq = <3246000>; + atmel,mic-offset = <0x0>; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt b/Documentation/devicetree/bindings/sound/atmel-classd.txt deleted file mode 100644 index 898551076382..000000000000 --- a/Documentation/devicetree/bindings/sound/atmel-classd.txt +++ /dev/null @@ -1,55 +0,0 @@ -* Atmel ClassD driver under ALSA SoC architecture - -Required properties: -- compatible - Should be "atmel,sama5d2-classd". -- reg - Should contain ClassD registers location and length. -- interrupts - Should contain the IRQ line for the ClassD. -- dmas - One DMA specifiers as described in atmel-dma.txt and dma.txt files. -- dma-names - Must be "tx". -- clock-names - Tuple listing input clock names. - Required elements: "pclk" and "gclk". -- clocks - Please refer to clock-bindings.txt. -- assigned-clocks - Should be <&classd_gclk>. - -Optional properties: -- pinctrl-names, pinctrl-0 - Please refer to pinctrl-bindings.txt. -- atmel,model - The user-visible name of this sound complex. - The default value is "CLASSD". -- atmel,pwm-type - PWM modulation type, "single" or "diff". - The default value is "single". -- atmel,non-overlap-time - Set non-overlapping time, the unit is nanosecond(ns). - There are four values, - <5>, <10>, <15>, <20>, the default value is <10>. - Non-overlapping will be disabled if not specified. - -Example: -classd: classd@fc048000 { - compatible = "atmel,sama5d2-classd"; - reg = <0xfc048000 0x100>; - interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>; - dmas = <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) - | AT91_XDMAC_DT_PERID(47))>; - dma-names = "tx"; - clocks = <&classd_clk>, <&classd_gclk>; - clock-names = "pclk", "gclk"; - assigned-clocks = <&classd_gclk>; - - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_classd_default>; - atmel,model = "classd @ SAMA5D2-Xplained"; - atmel,pwm-type = "diff"; - atmel,non-overlap-time = <10>; -}; diff --git a/Documentation/devicetree/bindings/sound/atmel-i2s.txt b/Documentation/devicetree/bindings/sound/atmel-i2s.txt deleted file mode 100644 index 40549f496a81..000000000000 --- a/Documentation/devicetree/bindings/sound/atmel-i2s.txt +++ /dev/null @@ -1,46 +0,0 @@ -* Atmel I2S controller - -Required properties: -- compatible: Should be "atmel,sama5d2-i2s". -- reg: Should be the physical base address of the controller and the - length of memory mapped region. -- interrupts: Should contain the interrupt for the controller. -- dmas: Should be one per channel name listed in the dma-names property, - as described in atmel-dma.txt and dma.txt files. -- dma-names: Two dmas have to be defined, "tx" and "rx". - This IP also supports one shared channel for both rx and tx; - if this mode is used, one "rx-tx" name must be used. -- clocks: Must contain an entry for each entry in clock-names. - Please refer to clock-bindings.txt. -- clock-names: Should be one of each entry matching the clocks phandles list: - - "pclk" (peripheral clock) Required. - - "gclk" (generated clock) Optional (1). - - "muxclk" (I2S mux clock) Optional (1). - -Optional properties: -- pinctrl-0: Should specify pin control groups used for this controller. -- princtrl-names: Should contain only one value - "default". - - -(1) : Only the peripheral clock is required. The generated clock and the I2S - mux clock are optional and should only be set together, when Master Mode - is required. - -Example: - - i2s@f8050000 { - compatible = "atmel,sama5d2-i2s"; - reg = <0xf8050000 0x300>; - interrupts = <54 IRQ_TYPE_LEVEL_HIGH 7>; - dmas = <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | - AT91_XDMAC_DT_PERID(31))>, - <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | - AT91_XDMAC_DT_PERID(32))>; - dma-names = "tx", "rx"; - clocks = <&i2s0_clk>, <&i2s0_gclk>, <&i2s0muxck>; - clock-names = "pclk", "gclk", "muxclk"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_i2s0_default>; - }; diff --git a/Documentation/devicetree/bindings/sound/atmel-pdmic.txt b/Documentation/devicetree/bindings/sound/atmel-pdmic.txt deleted file mode 100644 index e0875f17c229..000000000000 --- a/Documentation/devicetree/bindings/sound/atmel-pdmic.txt +++ /dev/null @@ -1,55 +0,0 @@ -* Atmel PDMIC driver under ALSA SoC architecture - -Required properties: -- compatible - Should be "atmel,sama5d2-pdmic". -- reg - Should contain PDMIC registers location and length. -- interrupts - Should contain the IRQ line for the PDMIC. -- dmas - One DMA specifiers as described in atmel-dma.txt and dma.txt files. -- dma-names - Must be "rx". -- clock-names - Required elements: - - "pclk" peripheral clock - - "gclk" generated clock -- clocks - Must contain an entry for each required entry in clock-names. - Please refer to clock-bindings.txt. -- atmel,mic-min-freq - The minimal frequency that the micphone supports. -- atmel,mic-max-freq - The maximal frequency that the micphone supports. - -Optional properties: -- pinctrl-names, pinctrl-0 - Please refer to pinctrl-bindings.txt. -- atmel,model - The user-visible name of this sound card. - The default value is "PDMIC". -- atmel,mic-offset - The offset that should be added. - The range is from -32768 to 32767. - The default value is 0. - -Example: - pdmic@f8018000 { - compatible = "atmel,sama5d2-pdmic"; - reg = <0xf8018000 0x124>; - interrupts = <48 IRQ_TYPE_LEVEL_HIGH 7>; - dmas = <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) - | AT91_XDMAC_DT_PERID(50))>; - dma-names = "rx"; - clocks = <&pdmic_clk>, <&pdmic_gclk>; - clock-names = "pclk", "gclk"; - - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_pdmic_default>; - atmel,model = "PDMIC @ sama5d2_xplained"; - atmel,mic-min-freq = <1000000>; - atmel,mic-max-freq = <3246000>; - atmel,mic-offset = <0x0>; - }; diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt index 0720857089a7..8facbce53db8 100644 --- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt +++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt @@ -16,7 +16,7 @@ Board connectors: * Line In Jack wm8731 pins: -cf Documentation/devicetree/bindings/sound/wm8731.txt +cf Documentation/devicetree/bindings/sound/wlf,wm8731.yaml Example: sound { diff --git a/Documentation/devicetree/bindings/sound/da9055.txt b/Documentation/devicetree/bindings/sound/da9055.txt index ed1b7cc6f249..75c6338b6ae2 100644 --- a/Documentation/devicetree/bindings/sound/da9055.txt +++ b/Documentation/devicetree/bindings/sound/da9055.txt @@ -2,7 +2,7 @@ DA9055 provides Audio CODEC support (I2C only). -The Audio CODEC device in DA9055 has it's own I2C address which is configurable, +The Audio CODEC device in DA9055 has its own I2C address which is configurable, so the device is instantiated separately from the PMIC (MFD) device. For details on accompanying PMIC I2C device, see the following: diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt b/Documentation/devicetree/bindings/sound/designware-i2s.txt deleted file mode 100644 index 6a536d570e29..000000000000 --- a/Documentation/devicetree/bindings/sound/designware-i2s.txt +++ /dev/null @@ -1,35 +0,0 @@ -DesignWare I2S controller - -Required properties: - - compatible : Must be "snps,designware-i2s" - - reg : Must contain the I2S core's registers location and length - - clocks : Pairs of phandle and specifier referencing the controller's - clocks. The controller expects one clock: the clock used as the sampling - rate reference clock sample. - - clock-names : "i2sclk" for the sample rate reference clock. - - dmas: Pairs of phandle and specifier for the DMA channels that are used by - the core. The core expects one or two dma channels: one for transmit and - one for receive. - - dma-names : "tx" for the transmit channel, "rx" for the receive channel. - -Optional properties: - - interrupts: The interrupt line number for the I2S controller. Add this - parameter if the I2S controller that you are using does not support DMA. - -For more details on the 'dma', 'dma-names', 'clock' and 'clock-names' -properties please check: - * resource-names.txt - * clock/clock-bindings.txt - * dma/dma.txt - -Example: - - soc_i2s: i2s@7ff90000 { - compatible = "snps,designware-i2s"; - reg = <0x0 0x7ff90000 0x0 0x1000>; - clocks = <&scpi_i2sclk 0>; - clock-names = "i2sclk"; - #sound-dai-cells = <0>; - dmas = <&dma0 5>; - dma-names = "tx"; - }; diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.txt b/Documentation/devicetree/bindings/sound/fsl,micfil.txt deleted file mode 100644 index 1ea05d4996c7..000000000000 --- a/Documentation/devicetree/bindings/sound/fsl,micfil.txt +++ /dev/null @@ -1,33 +0,0 @@ -NXP MICFIL Digital Audio Interface (MICFIL). - -The MICFIL digital interface provides a 16-bit audio signal from a PDM -microphone bitstream in a configurable output sampling rate. - -Required properties: - - - compatible : Compatible list, contains "fsl,imx8mm-micfil" - or "fsl,imx8mp-micfil" - - - reg : Offset and length of the register set for the device. - - - interrupts : Contains the micfil interrupts. - - - clocks : Must contain an entry for each entry in clock-names. - - - clock-names : Must include the "ipg_clk" for register access and - "ipg_clk_app" for internal micfil clock. - - - dmas : Generic dma devicetree binding as described in - Documentation/devicetree/bindings/dma/dma.txt. - -Example: -micfil: micfil@30080000 { - compatible = "fsl,imx8mm-micfil"; - reg = <0x0 0x30080000 0x0 0x10000>; - interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clk IMX8MM_CLK_PDM_IPG>, - <&clk IMX8MM_CLK_PDM_ROOT>; - clock-names = "ipg_clk", "ipg_clk_app"; - dmas = <&sdma2 24 26 0x80000000>; -}; diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml new file mode 100644 index 000000000000..64d57758ee67 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,micfil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP MICFIL Digital Audio Interface (MICFIL) + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +description: | + The MICFIL digital interface provides a 16-bit or 24-bit audio signal + from a PDM microphone bitstream in a configurable output sampling rate. + +properties: + compatible: + enum: + - fsl,imx8mm-micfil + - fsl,imx8mp-micfil + + reg: + maxItems: 1 + + interrupts: + items: + - description: Digital Microphone interface interrupt + - description: Digital Microphone interface error interrupt + - description: voice activity detector event interrupt + - description: voice activity detector error interrupt + + dmas: + items: + - description: DMA controller phandle and request line for RX + + dma-names: + items: + - const: rx + + clocks: + items: + - description: The ipg clock for register access + - description: internal micfil clock + - description: PLL clock source for 8kHz series + - description: PLL clock source for 11kHz series + - description: External clock 3 + minItems: 2 + + clock-names: + items: + - const: ipg_clk + - const: ipg_clk_app + - const: pll8k + - const: pll11k + - const: clkext3 + minItems: 2 + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx8mm-clock.h> + micfil: audio-controller@30080000 { + compatible = "fsl,imx8mm-micfil"; + reg = <0x30080000 0x10000>; + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MM_CLK_PDM_IPG>, + <&clk IMX8MM_CLK_PDM_ROOT>; + clock-names = "ipg_clk", "ipg_clk_app"; + dmas = <&sdma2 24 25 0>; + dma-names = "rx"; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,mqs.txt b/Documentation/devicetree/bindings/sound/fsl,mqs.txt index 40353fc30255..d66284b8bef2 100644 --- a/Documentation/devicetree/bindings/sound/fsl,mqs.txt +++ b/Documentation/devicetree/bindings/sound/fsl,mqs.txt @@ -2,7 +2,7 @@ fsl,mqs audio CODEC Required properties: - compatible : Must contain one of "fsl,imx6sx-mqs", "fsl,codec-mqs" - "fsl,imx8qm-mqs", "fsl,imx8qxp-mqs". + "fsl,imx8qm-mqs", "fsl,imx8qxp-mqs", "fsl,imx93-mqs". - clocks : A list of phandles + clock-specifiers, one for each entry in clock-names - clock-names : "mclk" - must required. diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index f226ec13167a..1d64e8337aa4 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -58,6 +58,8 @@ properties: slave of the Shared Peripheral Bus and when two or more bus masters (CPU, DMA or DSP) try to access it. This property is optional depending on the SoC design. + - description: PLL clock source for 8kHz series rate, optional. + - description: PLL clock source for 11khz series rate, optional. minItems: 9 clock-names: @@ -72,6 +74,8 @@ properties: - const: rxtx6 - const: rxtx7 - const: spba + - const: pll8k + - const: pll11k minItems: 9 big-endian: diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index c71c5861d787..fbdefc3fade7 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -21,6 +21,9 @@ Required properties: - clock-names : Must include the "bus" for register access and "mclk1", "mclk2", "mclk3" for bit clock and frame clock providing. + "pll8k", "pll11k" are optional, they are the clock + source for root clock, one is for 8kHz series rates + another one is for 11kHz series rates. - dmas : Generic dma devicetree binding as described in Documentation/devicetree/bindings/dma/dma.txt. @@ -49,6 +52,14 @@ Required properties: receive data by following their own bit clocks and frame sync clocks separately. + - fsl,dataline : configure the dataline. it has 3 value for each configuration + first one means the type: I2S(1) or PDM(2) + second one is dataline mask for 'rx' + third one is dataline mask for 'tx'. + for example: fsl,dataline = <1 0xff 0xff 2 0xff 0x11>; + it means I2S type rx mask is 0xff, tx mask is 0xff, PDM type + rx mask is 0xff, tx mask is 0x11 (dataline 1 and 4 enabled). + Optional properties: - big-endian : Boolean property, required if all the SAI diff --git a/Documentation/devicetree/bindings/sound/mt6358.txt b/Documentation/devicetree/bindings/sound/mt6358.txt index 59a73ffdf1d3..fbe9e55c68f5 100644 --- a/Documentation/devicetree/bindings/sound/mt6358.txt +++ b/Documentation/devicetree/bindings/sound/mt6358.txt @@ -7,7 +7,9 @@ Must be a child node of PMIC wrapper. Required properties: -- compatible : "mediatek,mt6358-sound". +- compatible - "string" - One of: + "mediatek,mt6358-sound" + "mediatek,mt6366-sound" - Avdd-supply : power source of AVDD Optional properties: diff --git a/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml new file mode 100644 index 000000000000..88f82d096443 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml @@ -0,0 +1,175 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8186-afe-pcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek AFE PCM controller for mt8186 + +maintainers: + - Jiaxin Yu <jiaxin.yu@mediatek.com> + +properties: + compatible: + const: mediatek,mt8186-sound + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: audiosys + + mediatek,apmixedsys: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek apmixedsys controller + + mediatek,infracfg: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek infracfg controller + + mediatek,topckgen: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek topckgen controller + + clocks: + items: + - description: audio infra sys clock + - description: audio infra 26M clock + - description: audio top mux + - description: audio intbus mux + - description: mainpll 136.5M clock + - description: faud1 mux + - description: apll1 clock + - description: faud2 mux + - description: apll2 clock + - description: audio engen1 mux + - description: apll1_d8 22.5792M clock + - description: audio engen2 mux + - description: apll2_d8 24.576M clock + - description: i2s0 mclk mux + - description: i2s1 mclk mux + - description: i2s2 mclk mux + - description: i2s4 mclk mux + - description: tdm mclk mux + - description: i2s0_mck divider + - description: i2s1_mck divider + - description: i2s2_mck divider + - description: i2s4_mck divider + - description: tdm_mck divider + - description: audio hires mux + - description: 26M clock + + clock-names: + items: + - const: aud_infra_clk + - const: mtkaif_26m_clk + - const: top_mux_audio + - const: top_mux_audio_int + - const: top_mainpll_d2_d4 + - const: top_mux_aud_1 + - const: top_apll1_ck + - const: top_mux_aud_2 + - const: top_apll2_ck + - const: top_mux_aud_eng1 + - const: top_apll1_d8 + - const: top_mux_aud_eng2 + - const: top_apll2_d8 + - const: top_i2s0_m_sel + - const: top_i2s1_m_sel + - const: top_i2s2_m_sel + - const: top_i2s4_m_sel + - const: top_tdm_m_sel + - const: top_apll12_div0 + - const: top_apll12_div1 + - const: top_apll12_div2 + - const: top_apll12_div4 + - const: top_apll12_div_tdm + - const: top_mux_audio_h + - const: top_clk26m_clk + +required: + - compatible + - interrupts + - resets + - reset-names + - mediatek,apmixedsys + - mediatek,infracfg + - mediatek,topckgen + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + afe: mt8186-afe-pcm@11210000 { + compatible = "mediatek,mt8186-sound"; + reg = <0x11210000 0x2000>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>; + resets = <&watchdog 17>; //MT8186_TOPRGU_AUDIO_SW_RST + reset-names = "audiosys"; + mediatek,apmixedsys = <&apmixedsys>; + mediatek,infracfg = <&infracfg>; + mediatek,topckgen = <&topckgen>; + clocks = <&infracfg_ao 44>, //CLK_INFRA_AO_AUDIO + <&infracfg_ao 54>, //CLK_INFRA_AO_AUDIO_26M_BCLK + <&topckgen 15>, //CLK_TOP_AUDIO + <&topckgen 16>, //CLK_TOP_AUD_INTBUS + <&topckgen 70>, //CLK_TOP_MAINPLL_D2_D4 + <&topckgen 17>, //CLK_TOP_AUD_1 + <&apmixedsys 12>, //CLK_APMIXED_APLL1 + <&topckgen 18>, //CLK_TOP_AUD_2 + <&apmixedsys 13>, //CLK_APMIXED_APLL2 + <&topckgen 19>, //CLK_TOP_AUD_ENGEN1 + <&topckgen 101>, //CLK_TOP_APLL1_D8 + <&topckgen 20>, //CLK_TOP_AUD_ENGEN2 + <&topckgen 104>, //CLK_TOP_APLL2_D8 + <&topckgen 63>, //CLK_TOP_APLL_I2S0_MCK_SEL + <&topckgen 64>, //CLK_TOP_APLL_I2S1_MCK_SEL + <&topckgen 65>, //CLK_TOP_APLL_I2S2_MCK_SEL + <&topckgen 66>, //CLK_TOP_APLL_I2S4_MCK_SEL + <&topckgen 67>, //CLK_TOP_APLL_TDMOUT_MCK_SEL + <&topckgen 131>, //CLK_TOP_APLL12_CK_DIV0 + <&topckgen 132>, //CLK_TOP_APLL12_CK_DIV1 + <&topckgen 133>, //CLK_TOP_APLL12_CK_DIV2 + <&topckgen 134>, //CLK_TOP_APLL12_CK_DIV4 + <&topckgen 135>, //CLK_TOP_APLL12_CK_DIV_TDMOUT_M + <&topckgen 44>, //CLK_TOP_AUDIO_H + <&clk26m>; + clock-names = "aud_infra_clk", + "mtkaif_26m_clk", + "top_mux_audio", + "top_mux_audio_int", + "top_mainpll_d2_d4", + "top_mux_aud_1", + "top_apll1_ck", + "top_mux_aud_2", + "top_apll2_ck", + "top_mux_aud_eng1", + "top_apll1_d8", + "top_mux_aud_eng2", + "top_apll2_d8", + "top_i2s0_m_sel", + "top_i2s1_m_sel", + "top_i2s2_m_sel", + "top_i2s4_m_sel", + "top_tdm_m_sel", + "top_apll12_div0", + "top_apll12_div1", + "top_apll12_div2", + "top_apll12_div4", + "top_apll12_div_tdm", + "top_mux_audio_h", + "top_clk26m_clk"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml new file mode 100644 index 000000000000..513cd28b2027 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8186-mt6366-da7219-max98357.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8186 with MT6366, DA7219 and MAX98357 ASoC sound card driver + +maintainers: + - Jiaxin Yu <jiaxin.yu@mediatek.com> + +description: + This binding describes the MT8186 sound card. + +properties: + compatible: + enum: + - mediatek,mt8186-mt6366-da7219-max98357-sound + + mediatek,platform: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8186 ASoC platform. + + headset-codec: + type: object + additionalProperties: false + properties: + sound-dai: + maxItems: 1 + required: + - sound-dai + + playback-codecs: + type: object + additionalProperties: false + properties: + sound-dai: + items: + - description: phandle of dp codec + - description: phandle of l channel speaker codec + - description: phandle of r channel speaker codec + minItems: 2 + required: + - sound-dai + +additionalProperties: false + +required: + - compatible + - mediatek,platform + - headset-codec + - playback-codecs + +examples: + - | + + sound: mt8186-sound { + compatible = "mediatek,mt8186-mt6366-da7219-max98357-sound"; + mediatek,platform = <&afe>; + pinctrl-names = "aud_clk_mosi_off", + "aud_clk_mosi_on"; + pinctrl-0 = <&aud_clk_mosi_off>; + pinctrl-1 = <&aud_clk_mosi_on>; + + headset-codec { + sound-dai = <&da7219>; + }; + + playback-codecs { + sound-dai = <&anx_bridge_dp>, + <&max98357a>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml new file mode 100644 index 000000000000..059a7629b2d3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8186-mt6366-rt1019-rt5682s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8186 with MT6366, RT1019 and RT5682S ASoC sound card driver + +maintainers: + - Jiaxin Yu <jiaxin.yu@mediatek.com> + +description: + This binding describes the MT8186 sound card. + +properties: + compatible: + enum: + - mediatek,mt8186-mt6366-rt1019-rt5682s-sound + + mediatek,platform: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8186 ASoC platform. + + headset-codec: + type: object + additionalProperties: false + properties: + sound-dai: + maxItems: 1 + required: + - sound-dai + + playback-codecs: + type: object + additionalProperties: false + properties: + sound-dai: + items: + - description: phandle of dp codec + - description: phandle of l channel speaker codec + - description: phandle of r channel speaker codec + minItems: 2 + required: + - sound-dai + +additionalProperties: false + +required: + - compatible + - mediatek,platform + - headset-codec + - playback-codecs + +examples: + - | + + sound: mt8186-sound { + compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound"; + mediatek,platform = <&afe>; + pinctrl-names = "aud_clk_mosi_off", + "aud_clk_mosi_on"; + pinctrl-0 = <&aud_clk_mosi_off>; + pinctrl-1 = <&aud_clk_mosi_on>; + + headset-codec { + sound-dai = <&rt5682s>; + }; + + playback-codecs { + sound-dai = <&it6505dptx>, + <&rt1019p>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nau8821.txt b/Documentation/devicetree/bindings/sound/nau8821.txt index 6c3baf7a5f21..7c84e7c7327a 100644 --- a/Documentation/devicetree/bindings/sound/nau8821.txt +++ b/Documentation/devicetree/bindings/sound/nau8821.txt @@ -34,7 +34,7 @@ Optional properties: - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms - nuvoton,dmic-clk-threshold: the ADC threshold of DMIC clock. - + - nuvoton,key_enable: Headset button detection switch. Example: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml index 6df6f858038c..47b6e712e4fb 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml @@ -110,6 +110,10 @@ patternProperties: type: object $ref: nvidia,tegra186-asrc.yaml# + '^processing-engine@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-ope.yaml# + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml new file mode 100644 index 000000000000..5b9198602fc6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-mbdrc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 MBDRC + +description: + The Multi Band Dynamic Range Compressor (MBDRC) is part of Output + Processing Engine (OPE) which interfaces with Audio Hub (AHUB) via + Audio Client Interface (ACIF). MBDRC can be used as a traditional + single full band or a dual band or a multi band dynamic processor. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + compatible: + oneOf: + - const: nvidia,tegra210-mbdrc + - items: + - enum: + - nvidia,tegra234-mbdrc + - nvidia,tegra194-mbdrc + - nvidia,tegra186-mbdrc + - const: nvidia,tegra210-mbdrc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + dynamic-range-compressor@702d8200 { + compatible = "nvidia,tegra210-mbdrc"; + reg = <0x702d8200 0x200>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml new file mode 100644 index 000000000000..9dc9ba590fa3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-ope.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 OPE + +description: + The Output Processing Engine (OPE) is one of the AHUB client. It has + PEQ (Parametric Equalizer) and MBDRC (Multi Band Dynamic Range Compressor) + sub blocks for data processing. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + compatible: + oneOf: + - const: nvidia,tegra210-ope + - items: + - enum: + - nvidia,tegra234-ope + - nvidia,tegra194-ope + - nvidia,tegra186-ope + - const: nvidia,tegra210-ope + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + + sound-name-prefix: + pattern: "^OPE[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: + OPE ACIF (Audio Client Interface) input port. This is connected + to corresponding ACIF output port on AHUB (Audio Hub). + + port@1: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: + OPE ACIF output port. This is connected to corresponding ACIF + input port on AHUB. + +patternProperties: + '^equalizer@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-peq.yaml# + + '^dynamic-range-compressor@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-mbdrc.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + processing-engine@702d8000 { + compatible = "nvidia,tegra210-ope"; + reg = <0x702d8000 0x100>; + sound-name-prefix = "OPE1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml new file mode 100644 index 000000000000..1e373c49d639 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-peq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 PEQ + +description: + The Parametric Equalizer (PEQ) is a cascade of biquad filters with + each filter tuned based on certain parameters. It can be used to + equalize the irregularities in the speaker frequency response. + PEQ sits inside Output Processing Engine (OPE) which interfaces + with Audio Hub (AHUB) via Audio Client Interface (ACIF). + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + compatible: + oneOf: + - const: nvidia,tegra210-peq + - items: + - enum: + - nvidia,tegra234-peq + - nvidia,tegra194-peq + - nvidia,tegra186-peq + - const: nvidia,tegra210-peq + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + equalizer@702d8100 { + compatible = "nvidia,tegra210-peq"; + reg = <0x702d8100 0x100>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index b9b1dba40856..7f2e68ff6d34 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -15,6 +15,7 @@ allOf: properties: compatible: enum: + - nxp,tfa9890 - nxp,tfa9895 - nxp,tfa9897 diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml index e9a533080b32..ef18a572a1ff 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml @@ -25,12 +25,12 @@ properties: - qcom,sc7280-lpass-cpu reg: - minItems: 2 + minItems: 1 maxItems: 6 description: LPAIF core registers reg-names: - minItems: 2 + minItems: 1 maxItems: 6 clocks: @@ -42,12 +42,12 @@ properties: maxItems: 10 interrupts: - minItems: 2 + minItems: 1 maxItems: 4 description: LPAIF DMA buffer interrupt interrupt-names: - minItems: 2 + minItems: 1 maxItems: 4 qcom,adsp: diff --git a/Documentation/devicetree/bindings/sound/qcom,sdm845.txt b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt deleted file mode 100644 index de4c604641da..000000000000 --- a/Documentation/devicetree/bindings/sound/qcom,sdm845.txt +++ /dev/null @@ -1,91 +0,0 @@ -* Qualcomm Technologies Inc. SDM845 ASoC sound card driver - -This binding describes the SDM845 sound card, which uses qdsp for audio. - -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be one of this - "qcom,sdm845-sndcard" - "qcom,db845c-sndcard" - "lenovo,yoga-c630-sndcard" - -- audio-routing: - Usage: Optional - Value type: <stringlist> - Definition: A list of the connections between audio components. - Each entry is a pair of strings, the first being the - connection's sink, the second being the connection's - source. Valid names could be power supplies, MicBias - of codec and the jacks on the board. - -- model: - Usage: required - Value type: <stringlist> - Definition: The user-visible name of this sound card. - -- aux-devs - Usage: optional - Value type: <array of phandles> - Definition: A list of phandles for auxiliary devices (e.g. analog - amplifiers) that do not appear directly within the DAI - links. Should be connected to another audio component - using "audio-routing". - -= dailinks -Each subnode of sndcard represents either a dailink, and subnodes of each -dailinks would be cpu/codec/platform dais. - -- link-name: - Usage: required - Value type: <string> - Definition: User friendly name for dai link - -= CPU, PLATFORM, CODEC dais subnodes -- cpu: - Usage: required - Value type: <subnode> - Definition: cpu dai sub-node - -- codec: - Usage: required - Value type: <subnode> - Definition: codec dai sub-node - -- platform: - Usage: Optional - Value type: <subnode> - Definition: platform dai sub-node - -- sound-dai: - Usage: required - Value type: <phandle> - Definition: dai phandle/s and port of CPU/CODEC/PLATFORM node. - -Example: - -audio { - compatible = "qcom,sdm845-sndcard"; - model = "sdm845-snd-card"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pri_mi2s_active &pri_mi2s_ws_active>; - pinctrl-1 = <&pri_mi2s_sleep &pri_mi2s_ws_sleep>; - - mm1-dai-link { - link-name = "MultiMedia1"; - cpu { - sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>; - }; - }; - - pri-mi2s-dai-link { - link-name = "PRI MI2S Playback"; - cpu { - sound-dai = <&q6afedai PRIMARY_MI2S_RX>; - }; - - platform { - sound-dai = <&q6routing>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 4ecd4080bb96..e6e27d09783e 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -16,8 +16,11 @@ description: properties: compatible: enum: + - lenovo,yoga-c630-sndcard - qcom,apq8016-sbc-sndcard + - qcom,db845c-sndcard - qcom,msm8916-qdsp6-sndcard + - qcom,sdm845-sndcard - qcom,sm8250-sndcard - qcom,qrb5165-rb5-sndcard diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml index 9b225dbf8b79..8ca19f2b0b3d 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml @@ -127,7 +127,7 @@ properties: gpio@42: type: object - $ref: ../gpio/qcom,wcd934x-gpio.yaml# + $ref: /schemas/gpio/qcom,wcd934x-gpio.yaml# patternProperties: "^.*@[0-9a-f]+$": diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml new file mode 100644 index 000000000000..6113f65f2990 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wsa883x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for The Qualcomm WSA8830/WSA8832/WSA8835 + smart speaker amplifier + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + WSA883X is the Qualcomm Aqstic smart speaker amplifier + Their primary operating mode uses a SoundWire digital audio + interface. This binding is for SoundWire interface. + +properties: + compatible: + const: sdw10217020200 + + reg: + maxItems: 1 + + powerdown-gpios: + description: GPIO spec for Powerdown/Shutdown line to use + maxItems: 1 + + vdd-supply: + description: VDD Supply for the Codec + + '#thermal-sensor-cells': + const: 0 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + - vdd-supply + - powerdown-gpios + - "#thermal-sensor-cells" + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + soundwire-controller@3250000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x3250000 0x2000>; + + speaker@0,1 { + compatible = "sdw10217020200"; + reg = <0 1>; + powerdown-gpios = <&tlmm 1 0>; + vdd-supply = <&vreg_s10b_1p8>; + #thermal-sensor-cells = <0>; + #sound-dai-cells = <0>; + }; + + speaker@0,2 { + compatible = "sdw10217020200"; + reg = <0 2>; + powerdown-gpios = <&tlmm 89 0>; + vdd-supply = <&vreg_s10b_1p8>; + #thermal-sensor-cells = <0>; + #sound-dai-cells = <0>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml index 7e8d252f7bca..0d9840375132 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -13,6 +13,7 @@ properties: compatible: items: - enum: + - renesas,r9a07g043-ssi # RZ/G2UL - renesas,r9a07g044-ssi # RZ/G2{L,LC} - renesas,r9a07g054-ssi # RZ/V2L - const: renesas,rz-ssi @@ -50,7 +51,7 @@ properties: minItems: 1 maxItems: 2 description: - The first cell represents a phandle to dmac + The first cell represents a phandle to dmac. The second cell specifies the encoded MID/RID values of the SSI port connected to the DMA client and the slave channel configuration parameters. diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml index 5ea16b8ef93f..7e36e389e976 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml @@ -61,6 +61,13 @@ properties: - const: tx - const: rx + pinctrl-names: + oneOf: + - const: default + - items: + - const: bclk_on + - const: bclk_off + power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml index e762c320b574..2bc7f00ce4a2 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -47,6 +47,7 @@ properties: description: The bias voltage to be used in mVolts. The voltage can take values from 1.25V to 3V by 250mV steps. If this node is not mentioned or the value is unknown, then the value is set to 1.25V. + $ref: "/schemas/types.yaml#/definitions/uint32" enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ] lrclk-strength: diff --git a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml new file mode 100644 index 000000000000..4b0795819064 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/snps,designware-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DesignWare I2S controller + +maintainers: + - Jose Abreu <joabreu@synopsys.com> + +properties: + compatible: + oneOf: + - items: + - const: canaan,k210-i2s + - const: snps,designware-i2s + - enum: + - snps,designware-i2s + + reg: + maxItems: 1 + + interrupts: + description: | + The interrupt line number for the I2S controller. Add this + parameter if the I2S controller that you are using does not + support DMA. + maxItems: 1 + + clocks: + description: Sampling rate reference clock + maxItems: 1 + + clock-names: + const: i2sclk + + resets: + maxItems: 1 + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + minItems: 1 + + dma-names: + items: + - const: tx + - const: rx + minItems: 1 + +if: + properties: + compatible: + contains: + const: canaan,k210-i2s + +then: + properties: + "#sound-dai-cells": + const: 1 + +else: + properties: + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + +oneOf: + - required: + - dmas + - dma-names + - required: + - interrupts + +unevaluatedProperties: false + +examples: + - | + soc_i2s: i2s@7ff90000 { + compatible = "snps,designware-i2s"; + reg = <0x7ff90000 0x1000>; + clocks = <&scpi_i2sclk 0>; + clock-names = "i2sclk"; + #sound-dai-cells = <0>; + dmas = <&dma0 5>; + dma-names = "tx"; + }; diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml index 5f7dd5d6cbca..30f6b029ac08 100644 --- a/Documentation/devicetree/bindings/sound/tas2562.yaml +++ b/Documentation/devicetree/bindings/sound/tas2562.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: Texas Instruments TAS2562 Smart PA maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The TAS2562 is a mono, digital input Class-D audio amplifier optimized for diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index 2ad17b361db0..ee698614862e 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments TLV320ADCX140 Quad Channel Analog-to-Digital Converter maintainers: - - Dan Murphy <dmurphy@ti.com> + - Andrew Davis <afd@ti.com> description: | The TLV320ADCX140 are multichannel (4-ch analog recording or 8-ch digital @@ -68,9 +68,9 @@ properties: array is defined as <PDMIN1 PDMIN2 PDMIN3 PDMIN4>. 0 - (default) Odd channel is latched on the negative edge and even - channel is latched on the the positive edge. + channel is latched on the positive edge. 1 - Odd channel is latched on the positive edge and even channel is - latched on the the negative edge. + latched on the negative edge. PDMIN1 - PDMCLK latching edge used for channel 1 and 2 data PDMIN2 - PDMCLK latching edge used for channel 3 and 4 data diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml index e7220e8b49f0..15795f63b5a3 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml @@ -52,10 +52,6 @@ properties: DCVDD-supply: description: Digital core supply regulator for the DCVDD pin. - spi-max-frequency: true - -additionalProperties: false - required: - reg - compatible @@ -64,6 +60,11 @@ required: - DBVDD-supply - DCVDD-supply +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + examples: - | spi { diff --git a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml new file mode 100644 index 000000000000..d85d54024b2e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml @@ -0,0 +1,75 @@ +# 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/spi/atmel,at91rm9200-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel SPI device + +maintainers: + - Tudor Ambarus <tudor.ambarus@microchip.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + oneOf: + - const: atmel,at91rm9200-spi + - items: + - const: microchip,sam9x60-spi + - const: atmel,at91rm9200-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + contains: + const: spi_clk + + clocks: + maxItems: 1 + + atmel,fifo-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum number of data the RX and TX FIFOs can store for FIFO + capable SPI controllers. + enum: [ 16, 32 ] + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi1: spi@fffcc000 { + compatible = "atmel,at91rm9200-spi"; + reg = <0xfffcc000 0x4000>; + interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&spi1_clk>; + clock-names = "spi_clk"; + cs-gpios = <&pioB 3 GPIO_ACTIVE_HIGH>; + atmel,fifo-size = <32>; + + mmc@0 { + compatible = "mmc-spi-slot"; + reg = <0>; + gpios = <&pioC 4 GPIO_ACTIVE_HIGH>; /* CD */ + spi-max-frequency = <25000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml index 553601a441a7..510b82c177c0 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml @@ -10,7 +10,7 @@ description: See spi-peripheral-props.yaml for more info. maintainers: - - Pratyush Yadav <p.yadav@ti.com> + - Vaishnav Achath <vaishnav.a@ti.com> properties: # cdns,qspi-nor.yaml diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index 0a537fa3a641..4707294d8f59 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence Quad SPI controller maintainers: - - Pratyush Yadav <p.yadav@ti.com> + - Vaishnav Achath <vaishnav.a@ti.com> allOf: - $ref: spi-controller.yaml# diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt deleted file mode 100644 index e0fa61a1be0c..000000000000 --- a/Documentation/devicetree/bindings/spi/efm32-spi.txt +++ /dev/null @@ -1,39 +0,0 @@ -* Energy Micro EFM32 SPI - -Required properties: -- #address-cells: see spi-bus.txt -- #size-cells: see spi-bus.txt -- compatible: should be "energymicro,efm32-spi" -- reg: Offset and length of the register set for the controller -- interrupts: pair specifying rx and tx irq -- clocks: phandle to the spi clock -- cs-gpios: see spi-bus.txt - -Recommended properties : -- energymicro,location: Value to write to the ROUTE register's LOCATION - bitfield to configure the pinmux for the device, see - datasheet for values. - If this property is not provided, keeping what is - already configured in the hardware, so its either the - reset default 0 or whatever the bootloader did. - -Example: - -spi1: spi@4000c400 { /* USART1 */ - #address-cells = <1>; - #size-cells = <0>; - compatible = "energymicro,efm32-spi"; - reg = <0x4000c400 0x400>; - interrupts = <15 16>; - clocks = <&cmu 20>; - cs-gpios = <&gpio 51 1>; // D3 - energymicro,location = <1>; - - ks8851@0 { - compatible = "ks8851"; - spi-max-frequency = <6000000>; - reg = <0>; - interrupt-parent = <&boardfpga>; - interrupts = <4>; - }; -}; diff --git a/Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml b/Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml new file mode 100644 index 000000000000..7797c3123b7e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/hpe,gxp-spifi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HPE GXP spi controller flash interface + +maintainers: + - Nick Hawkins <nick.hawkins@hpe.com> + - Jean-Marie Verdun <verdun@hpe.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: hpe,gxp-spifi + + reg: + items: + - description: cfg registers + - description: data registers + - description: mapped memory + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + + spi@200 { + compatible = "hpe,gxp-spifi"; + reg = <0x200 0x80>, <0xc000 0x100>, <0x38000000 0x800000>; + interrupts = <20>; + interrupt-parent = <&vic0>; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + }; + + flash@1 { + reg = <1>; + compatible = "jedec,spi-nor"; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index 94ef0552bd42..8d2a6c084eab 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -18,6 +18,7 @@ properties: - items: - enum: - mediatek,mt7629-spi + - mediatek,mt8365-spi - const: mediatek,mt7622-spi - items: - enum: @@ -33,6 +34,7 @@ properties: - items: - enum: - mediatek,mt7986-spi-ipm + - mediatek,mt8188-spi-ipm - const: mediatek,spi-ipm - items: - enum: diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index 41e60fe4b09f..970b1119898b 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -23,6 +23,10 @@ allOf: properties: compatible: oneOf: + - enum: + - mediatek,mt8173-nor + - mediatek,mt8186-nor + - mediatek,mt8192-nor - items: - enum: - mediatek,mt2701-nor @@ -30,13 +34,13 @@ properties: - mediatek,mt7622-nor - mediatek,mt7623-nor - mediatek,mt7629-nor - - mediatek,mt8186-nor - - mediatek,mt8192-nor - mediatek,mt8195-nor - - enum: - - mediatek,mt8173-nor - - items: - const: mediatek,mt8173-nor + - items: + - enum: + - mediatek,mt8188-nor + - const: mediatek,mt8186-nor + reg: maxItems: 1 @@ -64,7 +68,6 @@ properties: required: - compatible - reg - - interrupts - clocks - clock-names diff --git a/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt b/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt index a388005842ad..c63ce4cc0a80 100644 --- a/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt +++ b/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt @@ -6,8 +6,13 @@ The NPCM7XX supports three FIU modules, FIU0 and FIUx supports two chip selects, FIU3 support four chip select. +The NPCM8XX supports four FIU modules, +FIU0 and FIUx supports two chip selects, +FIU1 and FIU3 supports four chip selects. + Required properties: - - compatible : "nuvoton,npcm750-fiu" for the NPCM7XX BMC + - compatible : "nuvoton,npcm750-fiu" for Poleg NPCM7XX BMC + "nuvoton,npcm845-fiu" for Arbel NPCM8XX BMC - #address-cells : should be 1. - #size-cells : should be 0. - reg : the first contains the register location and length, @@ -30,6 +35,12 @@ Aliases: fiu1 represent fiu 3 controller fiu2 represent fiu x controller + In the NPCM8XX BMC: + fiu0 represent fiu 0 controller + fiu1 represent fiu 1 controller + fiu2 represent fiu 3 controller + fiu3 represent fiu x controller + Example: fiu3: spi@c00000000 { compatible = "nuvoton,npcm750-fiu"; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml new file mode 100644 index 000000000000..24e0c2181d25 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad-peripheral-props.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/nvidia,tegra210-quad-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral properties for Tegra Quad SPI Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jonathan Hunter <jonathanh@nvidia.com> + +properties: + nvidia,tx-clk-tap-delay: + description: + Delays the clock going out to device with this tap value. + Tap value varies based on platform design trace lengths from Tegra + QSPI to corresponding slave device. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + + nvidia,rx-clk-tap-delay: + description: + Delays the clock coming in from the device with this tap value. + Tap value varies based on platform design trace lengths from Tegra + QSPI to corresponding slave device. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + +unevaluatedProperties: true + diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml index 0296edd1de22..6b733e5c1163 100644 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml @@ -20,6 +20,7 @@ properties: - nvidia,tegra186-qspi - nvidia,tegra194-qspi - nvidia,tegra234-qspi + - nvidia,tegra241-qspi reg: maxItems: 1 @@ -57,27 +58,6 @@ patternProperties: spi-tx-bus-width: enum: [1, 2, 4] - nvidia,tx-clk-tap-delay: - description: - Delays the clock going out to device with this tap value. - Tap value varies based on platform design trace lengths from Tegra - QSPI to corresponding slave device. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 31 - - nvidia,rx-clk-tap-delay: - description: - Delays the clock coming in from the device with this tap value. - Tap value varies based on platform design trace lengths from Tegra - QSPI to corresponding slave device. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 255 - - required: - - reg - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml index 78ceb9d67754..2e20ca313ec1 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml @@ -45,12 +45,15 @@ properties: - const: rx interconnects: - maxItems: 2 + minItems: 2 + maxItems: 3 interconnect-names: + minItems: 2 items: - const: qup-core - const: qup-config + - const: qup-memory interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml index a50f24f9359d..e0a465d70b0a 100644 --- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -20,7 +20,9 @@ properties: - samsung,s3c2443-spi # for S3C2443, S3C2416 and S3C2450 - samsung,s3c6410-spi - samsung,s5pv210-spi # for S5PV210 and S5PC110 + - samsung,exynos4210-spi - samsung,exynos5433-spi + - samsung,exynosautov9-spi - tesla,fsd-spi - const: samsung,exynos7-spi deprecated: true @@ -85,7 +87,9 @@ allOf: properties: compatible: contains: - const: samsung,exynos5433-spi + enum: + - samsung,exynos5433-spi + - samsung,exynosautov9-spi then: properties: clocks: diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index d7e08b03e204..37c3c272407d 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -61,6 +61,8 @@ properties: - const: snps,dw-apb-ssi - description: Intel Keem Bay SPI Controller const: intel,keembay-ssi + - description: Intel Thunder Bay SPI Controller + const: intel,thunderbay-ssi - description: Baikal-T1 SPI Controller const: baikal,bt1-ssi - description: Baikal-T1 System Boot SPI Controller @@ -124,9 +126,16 @@ properties: rx-sample-delay-ns: default: 0 - description: Default value of the rx-sample-delay-ns property. + description: | + Default value of the rx-sample-delay-ns property. This value will be used if the property is not explicitly defined - for a SPI slave device. See below. + for a SPI slave device. + + SPI Rx sample delay offset, unit is nanoseconds. + The delay from the default sample time before the actual sample of the + rxd input signal occurs. The "rx_sample_delay" is an optional feature + of the designware controller, and the upper limit is also subject to + controller configuration. patternProperties: "^.*@[0-9a-f]+$": @@ -136,19 +145,6 @@ patternProperties: minimum: 0 maximum: 3 - spi-rx-bus-width: - const: 1 - - spi-tx-bus-width: - const: 1 - - rx-sample-delay-ns: - description: SPI Rx sample delay offset, unit is nanoseconds. - The delay from the default sample time before the actual - sample of the rxd input signal occurs. The "rx_sample_delay" - is an optional feature of the designware controller, and the - upper limit is also subject to controller configuration. - unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml index 9787be21318e..82d0ca5c00f3 100644 --- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml +++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml @@ -49,6 +49,13 @@ properties: enum: [ 0, 1 ] default: 0 +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index ebb4d5f1cf4f..655713fba7e2 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -95,6 +95,17 @@ patternProperties: type: object $ref: spi-peripheral-props.yaml + properties: + spi-cpha: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires shifted clock phase (CPHA) mode. + + spi-cpol: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires inverse clock polarity (CPOL) mode. + required: - compatible - reg @@ -139,9 +150,9 @@ examples: }; flash@2 { - compatible = "jedec,spi-nor"; - spi-max-frequency = <50000000>; - reg = <2>, <3>; - stacked-memories = /bits/ 64 <0x10000000 0x10000000>; + compatible = "jedec,spi-nor"; + spi-max-frequency = <50000000>; + reg = <2>, <3>; + stacked-memories = /bits/ 64 <0x10000000 0x10000000>; }; }; diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml index 5e32928c4fc3..a4abe1588005 100644 --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml @@ -16,7 +16,7 @@ description: their own separate schema that should be referenced from here. maintainers: - - Pratyush Yadav <p.yadav@ti.com> + - Mark Brown <broonie@kernel.org> properties: reg: @@ -34,16 +34,6 @@ properties: description: The device requires 3-wire mode. - spi-cpha: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires shifted clock phase (CPHA) mode. - - spi-cpol: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires inverse clock polarity (CPOL) mode. - spi-cs-high: $ref: /schemas/types.yaml#/definitions/flag description: @@ -71,6 +61,11 @@ properties: description: Delay, in microseconds, after a read transfer. + rx-sample-delay-ns: + description: SPI Rx sample delay offset, unit is nanoseconds. + The delay from the default sample time before the actual + sample of the rxd input signal occurs. + spi-tx-bus-width: description: Bus width to the SPI bus used for write transfers. @@ -112,5 +107,6 @@ properties: allOf: - $ref: cdns,qspi-nor-peripheral-props.yaml# - $ref: samsung,spi-peripheral-props.yaml# + - $ref: nvidia,tegra210-quad-peripheral-props.yaml# additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml index ea72c8001256..fafde1c06be6 100644 --- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml @@ -30,6 +30,13 @@ properties: clocks: maxItems: 2 +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/spi/spi_atmel.txt b/Documentation/devicetree/bindings/spi/spi_atmel.txt deleted file mode 100644 index 5bb4a8f1df7a..000000000000 --- a/Documentation/devicetree/bindings/spi/spi_atmel.txt +++ /dev/null @@ -1,36 +0,0 @@ -Atmel SPI device - -Required properties: -- compatible : should be "atmel,at91rm9200-spi" or "microchip,sam9x60-spi". -- reg: Address and length of the register set for the device -- interrupts: Should contain spi interrupt -- cs-gpios: chipselects (optional for SPI controller version >= 2 with the - Chip Select Active After Transfer feature). -- clock-names: tuple listing input clock names. - Required elements: "spi_clk" -- clocks: phandles to input clocks. - -Optional properties: -- atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO - capable SPI controllers. - -Example: - -spi1: spi@fffcc000 { - compatible = "atmel,at91rm9200-spi"; - reg = <0xfffcc000 0x4000>; - interrupts = <13 4 5>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&spi1_clk>; - clock-names = "spi_clk"; - cs-gpios = <&pioB 3 0>; - atmel,fifo-size = <32>; - - mmc-slot@0 { - compatible = "mmc-spi-slot"; - reg = <0>; - gpios = <&pioC 4 0>; /* CD */ - spi-max-frequency = <25000000>; - }; -}; diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml new file mode 100644 index 000000000000..e9199190198d --- /dev/null +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sram/qcom,imem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm IMEM memory region + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + Qualcomm IMEM is dedicated memory region for various debug features and DMA + transactions. + +properties: + compatible: + items: + - enum: + - qcom,apq8064-imem + - qcom,msm8974-imem + - qcom,qcs404-imem + - qcom,sc7180-imem + - qcom,sc7280-imem + - qcom,sdm630-imem + - qcom,sdm845-imem + - qcom,sdx55-imem + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + reboot-mode: + $ref: /schemas/power/reset/syscon-reboot-mode.yaml# + +patternProperties: + "^pil-reloc@[0-9a-f]+$": + $ref: /schemas/remoteproc/qcom,pil-info.yaml# + description: Peripheral image loader relocation region + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@146bf000 { + compatible = "qcom,sdm845-imem", "syscon", "simple-mfd"; + reg = <0 0x146bf000 0 0x1000>; + ranges = <0 0 0x146bf000 0x1000>; + + #address-cells = <1>; + #size-cells = <1>; + + pil-reloc@94c { + compatible = "qcom,pil-reloc-info"; + reg = <0x94c 0xc8>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml index 930188bc5e6a..071f2d676196 100644 --- a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml @@ -72,10 +72,10 @@ patternProperties: examples: - | - #include <dt-bindings/clock/qcom,rpmcc.h> - #include <dt-bindings/clock/qcom,mmcc-msm8974.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/clock/qcom,mmcc-msm8974.h> - ocmem: ocmem@fdd00000 { + sram@fdd00000 { compatible = "qcom,msm8974-ocmem"; reg = <0xfdd00000 0x2000>, @@ -93,6 +93,6 @@ examples: ranges = <0 0xfec00000 0x100000>; gmu-sram@0 { - reg = <0x0 0x100000>; + reg = <0x0 0x100000>; }; - }; + }; diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml index 1ab5070c751d..89a2c32c0ab2 100644 --- a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml @@ -16,7 +16,7 @@ description: |+ - compatible: Should be one of the following: "brcm,bcm2711-avs-monitor", "syscon", "simple-mfd" - Refer to the the bindings described in + Refer to the bindings described in Documentation/devicetree/bindings/mfd/syscon.yaml properties: diff --git a/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml b/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml new file mode 100644 index 000000000000..f9e4b3c8d0ee --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/fsl,scu-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - Thermal bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + +allOf: + - $ref: thermal-sensor.yaml# + +properties: + compatible: + items: + - const: fsl,imx8qxp-sc-thermal + - const: fsl,imx-sc-thermal + + '#thermal-sensor-cells': + const: 1 + +required: + - compatible + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + thermal-sensor { + compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal"; + #thermal-sensor-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt index db880e7ed713..aea4a2a178b9 100644 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt @@ -96,7 +96,7 @@ critical trip point is reported back to the thermal framework to implement software shutdown. - the "hot" type trip points will be set to SOC_THERM hardware as the throttle -temperature. Once the the temperature of this thermal zone is higher +temperature. Once the temperature of this thermal zone is higher than it, it will trigger the HW throttle event. Example : diff --git a/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml b/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml new file mode 100644 index 000000000000..5f08b6e59b8a --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/qcom,spmi-temp-alarm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QPNP PMIC Temperature Alarm + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + QPNP temperature alarm peripherals are found inside of Qualcomm PMIC chips + that utilize the Qualcomm SPMI implementation. These peripherals provide an + interrupt signal and status register to identify high PMIC die temperature. + +allOf: + - $ref: thermal-sensor.yaml# + +properties: + compatible: + const: qcom,spmi-temp-alarm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + io-channels: + items: + - description: ADC channel, which reports chip die temperature + + io-channel-names: + items: + - const: thermal + + '#thermal-sensor-cells': + const: 0 + +required: + - compatible + - reg + - interrupts + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pmic { + #address-cells = <1>; + #size-cells = <0>; + + pm8350_temp_alarm: temperature-sensor@a00 { + compatible = "qcom,spmi-temp-alarm"; + reg = <0xa00>; + interrupts = <0x1 0xa 0x0 IRQ_TYPE_EDGE_BOTH>; + #thermal-sensor-cells = <0>; + }; + }; + + thermal-zones { + pm8350_thermal: pm8350c-thermal { + polling-delay-passive = <100>; + polling-delay = <0>; + thermal-sensors = <&pm8350_temp_alarm>; + + trips { + pm8350_trip0: trip0 { + temperature = <95000>; + hysteresis = <0>; + type = "passive"; + }; + + pm8350_crit: pm8350c-crit { + temperature = <115000>; + hysteresis = <0>; + type = "critical"; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt deleted file mode 100644 index 2d5b2ad03314..000000000000 --- a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt +++ /dev/null @@ -1,51 +0,0 @@ -Qualcomm QPNP PMIC Temperature Alarm - -QPNP temperature alarm peripherals are found inside of Qualcomm PMIC chips -that utilize the Qualcomm SPMI implementation. These peripherals provide an -interrupt signal and status register to identify high PMIC die temperature. - -Required properties: -- compatible: Should contain "qcom,spmi-temp-alarm". -- reg: Specifies the SPMI address. -- interrupts: PMIC temperature alarm interrupt. -- #thermal-sensor-cells: Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. - -Optional properties: -- io-channels: Should contain IIO channel specifier for the ADC channel, - which report chip die temperature. -- io-channel-names: Should contain "thermal". - -Example: - - pm8941_temp: thermal-alarm@2400 { - compatible = "qcom,spmi-temp-alarm"; - reg = <0x2400>; - interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>; - #thermal-sensor-cells = <0>; - - io-channels = <&pm8941_vadc VADC_DIE_TEMP>; - io-channel-names = "thermal"; - }; - - thermal-zones { - pm8941 { - polling-delay-passive = <250>; - polling-delay = <1000>; - - thermal-sensors = <&pm8941_temp>; - - trips { - stage1 { - temperature = <105000>; - hysteresis = <2000>; - type = "passive"; - }; - stage2 { - temperature = <125000>; - hysteresis = <2000>; - type = "critical"; - }; - }; - }; - }; - diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml index 1368d90da0e8..0f05f5c886c5 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml @@ -8,9 +8,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas R-Car Gen3 Thermal Sensor description: - On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal - sensors (THS) which are the analog circuits for measuring temperature (Tj) - inside the LSI. + On most R-Car Gen3 and later SoCs, the thermal sensor controllers (TSC) + control the thermal sensors (THS) which are the analog circuits for + measuring temperature (Tj) inside the LSI. maintainers: - Niklas Söderlund <niklas.soderlund@ragnatech.se> @@ -27,6 +27,7 @@ properties: - renesas,r8a77965-thermal # R-Car M3-N - renesas,r8a77980-thermal # R-Car V3H - renesas,r8a779a0-thermal # R-Car V3U + - renesas,r8a779f0-thermal # R-Car S4-8 reg: true @@ -57,31 +58,38 @@ required: - "#thermal-sensor-cells" if: - not: - properties: - compatible: - contains: - enum: - - renesas,r8a779a0-thermal + properties: + compatible: + contains: + enum: + - renesas,r8a779a0-thermal then: properties: reg: - minItems: 2 items: + - description: TSC0 registers - description: TSC1 registers - description: TSC2 registers - description: TSC3 registers - required: - - interrupts + - description: TSC4 registers else: properties: reg: + minItems: 2 items: - - description: TSC0 registers - description: TSC1 registers - description: TSC2 registers - description: TSC3 registers - - description: TSC4 registers + if: + not: + properties: + compatible: + contains: + enum: + - renesas,r8a779f0-thermal + then: + required: + - interrupts additionalProperties: false diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml index 927de79ab4b5..119998d10ff4 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml @@ -42,7 +42,7 @@ properties: description: Address ranges of the thermal registers. If more then one range is given the first one must be the common registers followed by each sensor - according the the datasheet. + according to the datasheet. minItems: 1 maxItems: 4 diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 2d34f3ccb257..8d2c6d74b605 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -214,6 +214,7 @@ patternProperties: - polling-delay - polling-delay-passive - thermal-sensors + - trips additionalProperties: false diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml index 53fd24bdc34e..3711872b6b99 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml @@ -20,6 +20,7 @@ properties: - allwinner,suniv-f1c100s-timer - items: - enum: + - allwinner,sun20i-d1-timer - allwinner,sun50i-a64-timer - allwinner,sun50i-h6-timer - allwinner,sun50i-h616-timer diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml index d541cf2067bc..0a01e4f5eddb 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml @@ -113,7 +113,7 @@ properties: patternProperties: "^watchdog@[a-f0-9]+$": type: object - $ref: ../watchdog/watchdog.yaml# + $ref: /schemas/watchdog/watchdog.yaml# properties: compatible: oneOf: @@ -145,7 +145,7 @@ patternProperties: "^pwm@[a-f0-9]+$": type: object - $ref: ../pwm/pwm.yaml# + $ref: /schemas/pwm/pwm.yaml# properties: compatible: oneOf: diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index 6f1f9dba6e88..f1c848af91d3 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -1,7 +1,8 @@ MediaTek Timers --------------- -MediaTek SoCs have two different timers on different platforms, +MediaTek SoCs have different timers on different platforms, +- CPUX (ARM/ARM64 System Timer) - GPT (General Purpose Timer) - SYST (System Timer) @@ -29,6 +30,9 @@ Required properties: * "mediatek,mt7629-timer" for MT7629 compatible timers (SYST) * "mediatek,mt6765-timer" for MT6765 and all above compatible timers (SYST) + For those SoCs that use CPUX + * "mediatek,mt6795-systimer" for MT6795 compatible timers (CPUX) + - reg: Should contain location and length for timer register. - clocks: Should contain system clock. diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml index 0cbc26a72151..737af78ad70c 100644 --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml @@ -8,12 +8,14 @@ title: Nuvoton NPCM7xx timer maintainers: - Jonathan Neuschäfer <j.neuschaefer@gmx.net> + - Tomer Maimon <tmaimon77@gmail.com> properties: compatible: enum: - nuvoton,wpcm450-timer # for Hermon WPCM450 - nuvoton,npcm750-timer # for Poleg NPCM750 + - nuvoton,npcm845-timer # for Arbel NPCM845 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml new file mode 100644 index 000000000000..db8b5595540f --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/timer/nvidia,tegra186-timer.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra186 timer + +maintainers: + - Thierry Reding <treding@nvidia.com> + +description: > + The Tegra timer provides 29-bit timer counters and a 32-bit timestamp + counter. Each NV timer selects its timing reference signal from the 1 MHz + reference generated by USEC, TSC or either clk_m or OSC. Each TMR can be + programmed to generate one-shot, periodic, or watchdog interrupts. + + +properties: + compatible: + oneOf: + - const: nvidia,tegra186-timer + description: > + The Tegra186 timer provides ten 29-bit timer counters. + - const: nvidia,tegra234-timer + description: > + The Tegra234 timer provides sixteen 29-bit timer counters. + + reg: + maxItems: 1 + + interrupts: true + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra186-timer + then: + properties: + interrupts: + maxItems: 10 + description: > + One per each timer channels 0 through 9. + + - if: + properties: + compatible: + contains: + const: nvidia,tegra234-timer + then: + properties: + interrupts: + maxItems: 16 + description: > + One per each timer channels 0 through 15. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + timer@3010000 { + compatible = "nvidia,tegra186-timer"; + reg = <0x03010000 0x000e0000>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + timer@2080000 { + compatible = "nvidia,tegra234-timer"; + reg = <0x02080000 0x00121000>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml index 53dd6d9f518f..bde6c9b66bf4 100644 --- a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml @@ -80,7 +80,6 @@ properties: - renesas,r8a77980-cmt0 # 32-bit CMT0 on R-Car V3H - renesas,r8a77990-cmt0 # 32-bit CMT0 on R-Car E3 - renesas,r8a77995-cmt0 # 32-bit CMT0 on R-Car D3 - - renesas,r8a779a0-cmt0 # 32-bit CMT0 on R-Car V3U - const: renesas,rcar-gen3-cmt0 # 32-bit CMT0 on R-Car Gen3 and RZ/G2 - items: @@ -97,9 +96,20 @@ properties: - renesas,r8a77980-cmt1 # 48-bit CMT on R-Car V3H - renesas,r8a77990-cmt1 # 48-bit CMT on R-Car E3 - renesas,r8a77995-cmt1 # 48-bit CMT on R-Car D3 - - renesas,r8a779a0-cmt1 # 48-bit CMT on R-Car V3U - const: renesas,rcar-gen3-cmt1 # 48-bit CMT on R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r8a779a0-cmt0 # 32-bit CMT0 on R-Car V3U + - renesas,r8a779f0-cmt0 # 32-bit CMT0 on R-Car S4-8 + - const: renesas,rcar-gen4-cmt0 # 32-bit CMT0 on R-Car Gen4 + + - items: + - enum: + - renesas,r8a779a0-cmt1 # 48-bit CMT on R-Car V3U + - renesas,r8a779f0-cmt1 # 48-bit CMT on R-Car S4-8 + - const: renesas,rcar-gen4-cmt1 # 48-bit CMT on R-Car Gen4 + reg: maxItems: 1 @@ -135,6 +145,7 @@ allOf: enum: - renesas,rcar-gen2-cmt0 - renesas,rcar-gen3-cmt0 + - renesas,rcar-gen4-cmt0 then: properties: interrupts: @@ -148,6 +159,7 @@ allOf: enum: - renesas,rcar-gen2-cmt1 - renesas,rcar-gen3-cmt1 + - renesas,rcar-gen4-cmt1 then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml b/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml new file mode 100644 index 000000000000..901848d298ec --- /dev/null +++ b/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2022 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/timer/st,nomadik-mtu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ST Microelectronics Nomadik Multi-Timer Unit MTU Timer + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: This timer is found in the ST Microelectronics Nomadik + SoCs STn8800, STn8810 and STn8815 as well as in ST-Ericsson DB8500. + +properties: + compatible: + items: + - const: st,nomadik-mtu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: The first clock named TIMCLK clocks the actual timers and + the second clock clocks the digital interface to the interconnect. + maxItems: 2 + + clock-names: + items: + - const: timclk + - const: apb_pclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mfd/dbx500-prcmu.h> + timer@a03c6000 { + compatible = "st,nomadik-mtu"; + reg = <0xa03c6000 0x1000>; + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&prcmu_clk PRCMU_TIMCLK>, <&prcc_pclk 6 6>; + clock-names = "timclk", "apb_pclk"; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 6aafa71806a3..61746755c107 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -41,6 +41,8 @@ properties: - adi,adp5585-02 # Analog Devices ADP5589 Keypad Decoder and I/O Expansion - adi,adp5589 + # Analog Devices LT7182S Dual Channel 6A, 20V PolyPhase Step-Down Silent Switcher + - adi,lt7182s # AMS iAQ-Core VOC Sensor - ams,iaq-core # i2c serial eeprom (24cxx) @@ -93,8 +95,6 @@ properties: - dh,dhcom-board # DA9053: flexible system level PMIC with multicore support - dlg,da9053 - # DA9063: system PMIC for quad-core application processors - - dlg,da9063 # DMARD05: 3-axis I2C Accelerometer - domintech,dmard05 # DMARD06: 3-axis I2C Accelerometer @@ -139,6 +139,8 @@ properties: - infineon,slb9635tt # Infineon SLB9645 I2C TPM (new protocol, max 400khz) - infineon,slb9645tt + # Infineon SLB9673 I2C TPM 2.0 + - infineon,slb9673 # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor - infineon,tlv493d-a1b6 # Infineon Multi-phase Digital VR Controller xdpe11280 diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index dcd32c10205a..f2d6298d926c 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -26,6 +26,7 @@ properties: - qcom,msm8994-ufshc - qcom,msm8996-ufshc - qcom,msm8998-ufshc + - qcom,sc8280xp-ufshc - qcom,sdm845-ufshc - qcom,sm6350-ufshc - qcom,sm8150-ufshc @@ -98,6 +99,7 @@ allOf: contains: enum: - qcom,msm8998-ufshc + - qcom,sc8280xp-ufshc - qcom,sm8250-ufshc - qcom,sm8350-ufshc - qcom,sm8450-ufshc diff --git a/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml new file mode 100644 index 000000000000..f04f9f61fa9f --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/renesas,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car UFS Host Controller + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + const: renesas,r8a779f0-ufs + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: fck + - const: ref_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a779f0-sysc.h> + + ufs: ufs@e686000 { + compatible = "renesas,r8a779f0-ufs"; + reg = <0xe6860000 0x100>; + interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>; + clock-names = "fck", "ref_clk"; + freq-table-hz = <200000000 200000000>, <38400000 38400000>; + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>; + resets = <&cpg 1514>; + }; diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index c949eb617313..2c715eec48b8 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -21,6 +21,7 @@ properties: - samsung,exynos7-ufs - samsung,exynosautov9-ufs - samsung,exynosautov9-ufs-vh + - tesla,fsd-ufs reg: items: diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml index 933fa356d2ce..e5dbf4169bc9 100644 --- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml @@ -20,6 +20,7 @@ properties: - items: - enum: - allwinner,sun8i-a83t-musb + - allwinner,sun20i-d1-musb - allwinner,sun50i-h6-musb - const: allwinner,sun8i-a33-musb - items: diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml b/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml new file mode 100644 index 000000000000..ee436308e5dc --- /dev/null +++ b/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/analogix,anx7411.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix ANX7411 Type-C controller bindings + +maintainers: + - Xin Ji <xji@analogixsemi.com> + +properties: + compatible: + enum: + - analogix,anx7411 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + connector: + type: object + $ref: ../connector/usb-connector.yaml + description: + Properties for usb c connector. + + properties: + compatible: + const: usb-c-connector + + power-role: true + + data-role: true + + try-power-role: true + + required: + - compatible + +required: + - compatible + - reg + - connector + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + typec@2c { + compatible = "analogix,anx7411"; + reg = <0x2c>; + interrupts = <8 IRQ_TYPE_EDGE_FALLING>; + interrupt-parent = <&gpio0>; + + typec_con: connector { + compatible = "usb-c-connector"; + power-role = "dual"; + data-role = "dual"; + try-power-role = "source"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + typec_con_ep: endpoint { + remote-endpoint = <&usbotg_hs_ep>; + }; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml b/Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml new file mode 100644 index 000000000000..c3b6be3d8002 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 Facebook Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/aspeed,ast2600-udc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED USB 2.0 Device Controller + +maintainers: + - Neal Liu <neal_liu@aspeedtech.com> + +description: |+ + The ASPEED USB 2.0 Device Controller implements 1 control endpoint and + 4 generic endpoints for AST260x. + + Supports independent DMA channel for each generic endpoint. + Supports 32/256 stages descriptor mode for all generic endpoints. + +properties: + compatible: + enum: + - aspeed,ast2600-udc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/aspeed-clock.h> + udc: usb@1e6a2000 { + compatible = "aspeed,ast2600-udc"; + reg = <0x1e6a2000 0x300>; + interrupts = <9>; + clocks = <&syscon ASPEED_CLK_GATE_USBPORT2CLK>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usb2bd_default>; + }; diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index f512f0290728..12183ef47ee4 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -87,6 +87,9 @@ Required properties: "atmel,at91sam9g45-udc" "atmel,sama5d3-udc" "microchip,sam9x60-udc" + "microchip,lan9662-udc" + For "microchip,lan9662-udc" the fallback "atmel,sama5d3-udc" + is required. - reg: Address and length of the register set for the device - interrupts: Should contain usba interrupt - clocks: Should reference the peripheral and host clocks diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 8d22a9843ba5..1bfbc6ef16eb 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: usb-drd.yaml# + - $ref: usb-hcd.yaml# properties: compatible: @@ -161,6 +162,8 @@ properties: property is used. $ref: /schemas/graph.yaml#/properties/port + tpl-support: true + dependencies: port: [ usb-role-switch ] role-switch-default-mode: [ usb-role-switch ] diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 1e84e1b7ab27..079f7cff0c24 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -38,6 +38,7 @@ properties: - allwinner,sun8i-h3-ehci - allwinner,sun8i-r40-ehci - allwinner,sun9i-a80-ehci + - allwinner,sun20i-d1-ehci - aspeed,ast2400-ehci - aspeed,ast2500-ehci - aspeed,ast2600-ehci @@ -130,11 +131,6 @@ properties: Set this flag to indicate that the hardware sometimes turns on the OC bit when an over-current isn't actually present. - companion: - $ref: /schemas/types.yaml#/definitions/phandle - description: - Phandle of a companion. - phys: minItems: 1 maxItems: 3 @@ -155,7 +151,7 @@ required: - reg - interrupts -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index bb6bbd5f129d..180361b79f52 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -28,6 +28,7 @@ properties: - allwinner,sun8i-h3-ohci - allwinner,sun8i-r40-ohci - allwinner,sun9i-a80-ohci + - allwinner,sun20i-d1-ohci - brcm,bcm3384-ohci - brcm,bcm63268-ohci - brcm,bcm6328-ohci diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 084d7135b2d9..b0e58b15b9ae 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -31,6 +31,7 @@ properties: - mediatek,mt8173-xhci - mediatek,mt8183-xhci - mediatek,mt8186-xhci + - mediatek,mt8188-xhci - mediatek,mt8192-xhci - mediatek,mt8195-xhci - const: mediatek,mtk-xhci @@ -57,6 +58,7 @@ properties: - description: optional, wakeup interrupt used to support runtime PM interrupt-names: + minItems: 1 items: - const: host - const: wakeup @@ -113,6 +115,9 @@ properties: vbus-supply: description: Regulator of USB VBUS5v + resets: + maxItems: 1 + usb3-lpm-capable: true usb2-lpm-disable: true diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 37b02a841dc4..b019d490170d 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -24,6 +24,7 @@ properties: - mediatek,mt2712-mtu3 - mediatek,mt8173-mtu3 - mediatek,mt8183-mtu3 + - mediatek,mt8188-mtu3 - mediatek,mt8192-mtu3 - mediatek,mt8195-mtu3 - const: mediatek,mtu3 @@ -107,6 +108,9 @@ properties: maximum-speed: enum: [super-speed-plus, super-speed, high-speed, full-speed] + resets: + maxItems: 1 + "#address-cells": enum: [1, 2] diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 749e1963ddbb..cd2f7cb6745a 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -24,6 +24,7 @@ properties: - qcom,qcs404-dwc3 - qcom,sc7180-dwc3 - qcom,sc7280-dwc3 + - qcom,sc8280xp-dwc3 - qcom,sdm660-dwc3 - qcom,sdm845-dwc3 - qcom,sdx55-dwc3 @@ -32,6 +33,7 @@ properties: - qcom,sm6115-dwc3 - qcom,sm6125-dwc3 - qcom,sm6350-dwc3 + - qcom,sm6375-dwc3 - qcom,sm8150-dwc3 - qcom,sm8250-dwc3 - qcom,sm8350-dwc3 @@ -66,11 +68,11 @@ properties: - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host mode. Its frequency should be 19.2MHz. minItems: 1 - maxItems: 6 + maxItems: 9 clock-names: minItems: 1 - maxItems: 6 + maxItems: 9 assigned-clocks: items: @@ -93,20 +95,12 @@ properties: - const: apps-usb interrupts: - items: - - description: The interrupt that is asserted - when a wakeup event is received on USB2 bus. - - description: The interrupt that is asserted - when a wakeup event is received on USB3 bus. - - description: Wakeup event on DM line. - - description: Wakeup event on DP line. + minItems: 1 + maxItems: 4 interrupt-names: - items: - - const: hs_phy_irq - - const: ss_phy_irq - - const: dm_hs_phy_irq - - const: dp_hs_phy_irq + minItems: 1 + maxItems: 4 qcom,select-utmi-as-pipe-clk: description: @@ -115,12 +109,17 @@ properties: HS/FS/LS modes are supported. type: boolean + wakeup-source: true + # Required child node: patternProperties: "^usb@[0-9a-f]+$": $ref: snps,dwc3.yaml# + properties: + wakeup-source: false + required: - compatible - reg @@ -254,6 +253,28 @@ allOf: compatible: contains: enum: + - qcom,sc8280xp-dwc3 + then: + properties: + clocks: + maxItems: 9 + clock-names: + items: + - const: cfg_noc + - const: core + - const: iface + - const: sleep + - const: mock_utmi + - const: noc_aggr + - const: noc_aggr_north + - const: noc_aggr_south + - const: noc_sys + + - if: + properties: + compatible: + contains: + enum: - qcom,sdm660-dwc3 then: properties: @@ -311,6 +332,115 @@ allOf: - const: mock_utmi - const: xo + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq4019-dwc3 + - qcom,ipq6018-dwc3 + - qcom,ipq8064-dwc3 + - qcom,ipq8074-dwc3 + - qcom,msm8994-dwc3 + - qcom,qcs404-dwc3 + - qcom,sc7180-dwc3 + - qcom,sdm845-dwc3 + - qcom,sdx55-dwc3 + - qcom,sdx65-dwc3 + - qcom,sm4250-dwc3 + - qcom,sm6115-dwc3 + - qcom,sm6125-dwc3 + - qcom,sm6350-dwc3 + - qcom,sm8150-dwc3 + - qcom,sm8250-dwc3 + - qcom,sm8350-dwc3 + - qcom,sm8450-dwc3 + then: + properties: + interrupts: + items: + - description: The interrupt that is asserted + when a wakeup event is received on USB2 bus. + - description: The interrupt that is asserted + when a wakeup event is received on USB3 bus. + - description: Wakeup event on DM line. + - description: Wakeup event on DP line. + interrupt-names: + items: + - const: hs_phy_irq + - const: ss_phy_irq + - const: dm_hs_phy_irq + - const: dp_hs_phy_irq + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8953-dwc3 + - qcom,msm8996-dwc3 + - qcom,msm8998-dwc3 + then: + properties: + interrupts: + maxItems: 2 + interrupt-names: + items: + - const: hs_phy_irq + - const: ss_phy_irq + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm660-dwc3 + then: + properties: + interrupts: + minItems: 1 + maxItems: 2 + interrupt-names: + minItems: 1 + items: + - const: hs_phy_irq + - const: ss_phy_irq + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7280-dwc3 + then: + properties: + interrupts: + minItems: 3 + maxItems: 4 + interrupt-names: + minItems: 3 + items: + - const: hs_phy_irq + - const: dp_hs_phy_irq + - const: dm_hs_phy_irq + - const: ss_phy_irq + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8280xp-dwc3 + then: + properties: + interrupts: + maxItems: 4 + interrupt-names: + items: + - const: pwr_event + - const: dp_hs_phy_irq + - const: dm_hs_phy_irq + - const: ss_phy_irq additionalProperties: false diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml index 04ee255eb4f0..50f2b505bdeb 100644 --- a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml +++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml @@ -25,13 +25,13 @@ properties: description: phandle to the regulator that provides power to the hub. - companion-hub: + peer-hub: $ref: '/schemas/types.yaml#/definitions/phandle' description: - phandle to the companion hub on the controller. + phandle to the peer hub on the controller. required: - - companion-hub + - peer-hub - compatible - reg @@ -49,7 +49,7 @@ examples: compatible = "usbbda,5411"; reg = <1>; vdd-supply = <&pp3300_hub>; - companion-hub = <&hub_3_0>; + peer-hub = <&hub_3_0>; }; /* 3.0 hub on port 2 */ @@ -57,6 +57,6 @@ examples: compatible = "usbbda,411"; reg = <2>; vdd-supply = <&pp3300_hub>; - companion-hub = <&hub_2_0>; + peer-hub = <&hub_2_0>; }; }; diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index d41265ba8ce2..1779d08ba1c0 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -343,6 +343,11 @@ properties: This port is used with the 'usb-role-switch' property to connect the dwc3 to type C connector. + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable USB remote wakeup. + unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml b/Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml new file mode 100644 index 000000000000..1cb68cabe17d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/st,typec-stm32g0.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/st,typec-stm32g0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32G0 USB Type-C PD controller + +description: | + The STM32G0 MCU can be programmed to control Type-C connector(s) through I2C + typically using the UCSI protocol over I2C, with a dedicated alert + (interrupt) pin. + +maintainers: + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> + +properties: + compatible: + const: st,stm32g0-typec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + connector: + type: object + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + + firmware-name: + description: | + Should contain the name of the default firmware image + file located on the firmware search path + + wakeup-source: true + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - connector + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + typec@53 { + compatible = "st,stm32g0-typec"; + reg = <0x53>; + /* Alert pin on GPIO PE12 */ + interrupts = <12 IRQ_TYPE_EDGE_FALLING>; + interrupt-parent = <&gpioe>; + + /* Example with one type-C connector */ + connector { + compatible = "usb-c-connector"; + label = "USB-C"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + con_usb_c_ep: endpoint { + remote-endpoint = <&usb_ep>; + }; + }; + }; + }; + }; + }; + + usb { + usb-role-switch; + port { + usb_ep: endpoint { + remote-endpoint = <&con_usb_c_ep>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml new file mode 100644 index 000000000000..e04fbd8ab0b7 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for the TI USB8041 USB 3.0 hub controller + +maintainers: + - Alexander Stein <alexander.stein@ew.tq-group.com> + +allOf: + - $ref: usb-device.yaml# + +properties: + compatible: + enum: + - usb451,8140 + - usb451,8142 + + reg: true + + reset-gpios: + items: + - description: GPIO specifier for GRST# pin. + + vdd-supply: + description: + VDD power supply to the hub + + peer-hub: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the peer hub on the controller. + +required: + - compatible + - reg + - peer-hub + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + usb { + dr_mode = "host"; + #address-cells = <1>; + #size-cells = <0>; + + /* 2.0 hub on port 1 */ + hub_2_0: hub@1 { + compatible = "usb451,8142"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + }; + + /* 3.0 hub on port 2 */ + hub_3_0: hub@2 { + compatible = "usb451,8140"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 0496773a3c4d..2f0151e9f6be 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -141,6 +141,8 @@ patternProperties: description: ASIX Electronics Corporation "^aspeed,.*": description: ASPEED Technology Inc. + "^asrock,.*": + description: ASRock Inc. "^asus,.*": description: AsusTek Computer Inc. "^atheros,.*": @@ -198,12 +200,14 @@ patternProperties: description: Broadcom Corporation "^bsh,.*": description: BSH Hausgeraete GmbH + "^bticino,.*": + description: Bticino International "^buffalo,.*": description: Buffalo, Inc. "^bur,.*": description: B&R Industrial Automation GmbH - "^bticino,.*": - description: Bticino International + "^bytedance,.*": + description: ByteDance Ltd. "^calamp,.*": description: CalAmp Corp. "^calaosystems,.*": @@ -308,6 +312,8 @@ patternProperties: description: Dell Inc. "^delta,.*": description: Delta Electronics, Inc. + "^densitron,.*": + description: Densitron Technologies Ltd "^denx,.*": description: Denx Software Engineering "^devantech,.*": @@ -350,6 +356,8 @@ patternProperties: description: Embedded Artists AB "^ebang,.*": description: Zhejiang Ebang Communication Co., Ltd + "^ebbg,.*": + description: EBBG "^ebs-systart,.*": description: EBS-SYSTART GmbH "^ebv,.*": @@ -510,6 +518,8 @@ patternProperties: description: Haoyu Microelectronic Co. Ltd. "^hardkernel,.*": description: Hardkernel Co., Ltd + "^hechuang,.*": + description: Shenzhen Hechuang Intelligent Co. "^hideep,.*": description: HiDeep Inc. "^himax,.*": @@ -547,6 +557,8 @@ patternProperties: description: Shenzhen Hugsun Technology Co. Ltd. "^hwacom,.*": description: HwaCom Systems Inc. + "^hxt,.*": + description: HXT Semiconductor "^hycon,.*": description: Hycon Technology Corp. "^hydis,.*": @@ -581,6 +593,8 @@ patternProperties: description: Infineon Technologies "^inforce,.*": description: Inforce Computing + "^ingrasys,.*": + description: Ingrasys Technology Inc. "^ivo,.*": description: InfoVision Optoelectronics Kunshan Co. Ltd. "^ingenic,.*": @@ -601,6 +615,8 @@ patternProperties: description: Inter Control Group "^invensense,.*": description: InvenSense Inc. + "^inventec,.*": + description: Inventec "^inversepath,.*": description: Inverse Path "^iom,.*": @@ -795,6 +811,8 @@ patternProperties: description: MiraMEMS Sensing Technology Co., Ltd. "^mitsubishi,.*": description: Mitsubishi Electric Corporation + "^mixel,.*": + description: Mixel, Inc. "^miyoo,.*": description: Miyoo "^mntre,.*": @@ -1013,6 +1031,8 @@ patternProperties: description: Shenzhen QiShenglong Industrialist Co., Ltd. "^qnap,.*": description: QNAP Systems, Inc. + "^quanta,.*": + description: Quanta Computer Inc. "^radxa,.*": description: Radxa "^raidsonic,.*": @@ -1101,6 +1121,8 @@ patternProperties: description: SGX Sensortech "^sharp,.*": description: Sharp Corporation + "^shift,.*": + description: SHIFT GmbH "^shimafuji,.*": description: Shimafuji Electric, Inc. "^shiratech,.*": diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml index 10c22b5bd16a..0aa8433f0a5e 100644 --- a/Documentation/devicetree/bindings/virtio/mmio.yaml +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -33,6 +33,10 @@ properties: description: Required for devices making accesses thru an IOMMU. maxItems: 1 + wakeup-source: + type: boolean + description: Required for setting irq of a virtio_mmio device as wakeup source. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml index ca9e1beff76b..6ecd429f76b5 100644 --- a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml +++ b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml @@ -55,7 +55,7 @@ examples: compatible = "faraday,ftwdt010"; reg = <0x41000000 0x1000>; interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; - timeout-secs = <5>; + timeout-sec = <5>; }; - | watchdog: watchdog@98500000 { diff --git a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml new file mode 100644 index 000000000000..f84c45d687d7 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/fsl,scu-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX SCU Client Device Node - Watchdog bindings based on SCU Message Protocol + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: i.MX SCU Client Device Node + Client nodes are maintained as children of the relevant IMX-SCU device node. + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + items: + - const: fsl,imx8qxp-sc-wdt + - const: fsl,imx-sc-wdt + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + watchdog { + compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt"; + timeout-sec = <60>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt index 9059f54dc023..866a958b8a2b 100644 --- a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt @@ -6,7 +6,8 @@ expiry. Required properties: - compatible : "nuvoton,npcm750-wdt" for NPCM750 (Poleg), or - "nuvoton,wpcm450-wdt" for WPCM450 (Hermon). + "nuvoton,wpcm450-wdt" for WPCM450 (Hermon), or + "nuvoton,npcm845-wdt" for NPCM845 (Arbel). - reg : Offset and length of the register set for the device. - interrupts : Contain the timer interrupt with flags for falling edge. diff --git a/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.txt b/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.txt deleted file mode 100644 index 6fb984f31982..000000000000 --- a/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.txt +++ /dev/null @@ -1,28 +0,0 @@ -QCOM PM8916 watchdog timer controller - -This pm8916 watchdog timer controller must be under pm8916-pon node. - -Required properties: -- compatible: should be "qcom,pm8916-wdt" - -Optional properties : -- interrupts : Watchdog pre-timeout (bark) interrupt. -- timeout-sec : Watchdog timeout value in seconds. - -Example: - - pm8916_0: pm8916@0 { - compatible = "qcom,pm8916", "qcom,spmi-pmic"; - reg = <0x0 SPMI_USID>; - - pon@800 { - compatible = "qcom,pm8916-pon"; - reg = <0x800>; - - watchdog { - compatible = "qcom,pm8916-wdt"; - interrupts = <0x0 0x8 6 IRQ_TYPE_EDGE_RISING>; - timeout-sec = <10>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml new file mode 100644 index 000000000000..568eb8480fc3 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/qcom,pm8916-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PM8916 watchdog timer controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + const: qcom,pm8916-wdt + + interrupts: + maxItems: 1 + +required: + - compatible + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/spmi/spmi.h> + + pmic@0 { + compatible = "qcom,pm8916", "qcom,spmi-pmic"; + reg = <0x0 SPMI_USID>; + #address-cells = <1>; + #size-cells = <0>; + + pon@800 { + compatible = "qcom,pm8916-pon"; + reg = <0x800>; + mode-bootloader = <0x2>; + mode-recovery = <0x1>; + + watchdog { + compatible = "qcom,pm8916-wdt"; + interrupts = <0x0 0x8 6 IRQ_TYPE_EDGE_RISING>; + timeout-sec = <60>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 2bd6b4a52637..d8ac0be36e6c 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -24,6 +24,7 @@ properties: - qcom,apss-wdt-sc8280xp - qcom,apss-wdt-sdm845 - qcom,apss-wdt-sdx55 + - qcom,apss-wdt-sdx65 - qcom,apss-wdt-sm6350 - qcom,apss-wdt-sm8150 - qcom,apss-wdt-sm8250 diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml index 11b220a5e0f6..099245fe7b10 100644 --- a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml @@ -29,6 +29,7 @@ properties: - realtek,rtl8380-wdt - realtek,rtl8390-wdt - realtek,rtl9300-wdt + - realtek,rtl9310-wdt reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst index 5465eced2af1..1ad081de2dd0 100644 --- a/Documentation/devicetree/bindings/writing-bindings.rst +++ b/Documentation/devicetree/bindings/writing-bindings.rst @@ -53,7 +53,7 @@ Properties - DO use common property unit suffixes for properties with scientific units. Recommended suffixes are listed at - https://github.com/devicetree-org/dt-schema/blob/master/schemas/property-units.yaml + https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml - DO define properties in terms of constraints. How many entries? What are possible values? What is the order? diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index a7cb2afd7990..9c779bd7a751 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -1,3 +1,5 @@ +.. title:: Kernel-doc comments + =========================== Writing kernel-doc comments =========================== diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 2ff1ab4158d4..1228b85f6f77 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -132,7 +132,8 @@ format-specific subdirectories under ``Documentation/output``. To generate documentation, Sphinx (``sphinx-build``) must obviously be installed. For prettier HTML output, the Read the Docs Sphinx theme (``sphinx_rtd_theme``) is used if available. For PDF output you'll also need -``XeLaTeX`` and ``convert(1)`` from ImageMagick (https://www.imagemagick.org). +``XeLaTeX`` and ``convert(1)`` from ImageMagick +(https://www.imagemagick.org).\ [#ink]_ All of these are widely available and packaged in distributions. To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make @@ -150,8 +151,19 @@ If the theme is not available, it will fall-back to the classic one. The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable. +There is another make variable ``SPHINXDIRS``, which is useful when test +building a subset of documentation. For example, you can build documents +under ``Documentation/doc-guide`` by running +``make SPHINXDIRS=doc-guide htmldocs``. +The documentation section of ``make help`` will show you the list of +subdirectories you can specify. + To remove the generated documentation, run ``make cleandocs``. +.. [#ink] Having ``inkscape(1)`` from Inkscape (https://inkscape.org) + as well would improve the quality of images embedded in PDF + documents, especially for kernel releases 5.18 and later. + Writing Documentation ===================== diff --git a/Documentation/driver-api/aperture.rst b/Documentation/driver-api/aperture.rst new file mode 100644 index 000000000000..d173f4e7a7d9 --- /dev/null +++ b/Documentation/driver-api/aperture.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Managing Ownership of the Framebuffer Aperture +============================================== + +.. kernel-doc:: drivers/video/aperture.c + :doc: overview + +.. kernel-doc:: include/linux/aperture.h + :internal: + +.. kernel-doc:: drivers/video/aperture.c + :export: diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index db476bb170b6..5149ecdc53c7 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -362,6 +362,14 @@ CXL Core .. kernel-doc:: drivers/cxl/core/mbox.c :doc: cxl mbox +CXL Regions +----------- +.. kernel-doc:: drivers/cxl/core/region.c + :doc: cxl core region + +.. kernel-doc:: drivers/cxl/core/region.c + :identifiers: + External Interfaces =================== diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index 1e0f1f85d10e..ceac2a300e32 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -162,16 +162,6 @@ Currently, the types available are: - The device is able to do memory to memory copies -- - DMA_MEMCPY_SG - - - The device supports memory to memory scatter-gather transfers. - - - Even though a plain memcpy can look like a particular case of a - scatter-gather transfer, with a single chunk to copy, it's a distinct - transaction type in the mem2mem transfer case. This is because some very - simple devices might be able to do contiguous single-chunk memory copies, - but have no support for more complex SG transfers. - - No matter what the overall size of the combined chunks for source and destination is, only as many bytes as the smallest of the two will be transmitted. That means the number and size of the scatter-gather buffers in diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 2d39967bafcc..55272942e721 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -277,7 +277,6 @@ GPIO devm_gpiochip_add_data() devm_gpio_request() devm_gpio_request_one() - devm_gpio_free() I2C devm_i2c_new_dummy_device() diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst index 1d1688cbc078..803cd574bbd7 100644 --- a/Documentation/driver-api/firmware/core.rst +++ b/Documentation/driver-api/firmware/core.rst @@ -13,4 +13,5 @@ documents these features. direct-fs-lookup fallback-mechanisms lookup-order + firmware-usage-guidelines diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst new file mode 100644 index 000000000000..fdcfce42c6d2 --- /dev/null +++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst @@ -0,0 +1,44 @@ +=================== +Firmware Guidelines +=================== + +Users switching to a newer kernel should *not* have to install newer +firmware files to keep their hardware working. At the same time updated +firmware files must not cause any regressions for users of older kernel +releases. + +Drivers that use firmware from linux-firmware should follow the rules in +this guide. (Where there is limited control of the firmware, +i.e. company doesn't support Linux, firmwares sourced from misc places, +then of course these rules will not apply strictly.) + +* Firmware files shall be designed in a way that it allows checking for + firmware ABI version changes. It is recommended that firmware files be + versioned with at least a major/minor version. It is suggested that + the firmware files in linux-firmware be named with some device + specific name, and just the major version. The firmware version should + be stored in the firmware header, or as an exception, as part of the + firmware file name, in order to let the driver detact any non-ABI + fixes/changes. The firmware files in linux-firmware should be + overwritten with the newest compatible major version. Newer major + version firmware shall remain compatible with all kernels that load + that major number. + +* If the kernel support for the hardware is normally inactive, or the + hardware isn't available for public consumption, this can + be ignored, until the first kernel release that enables that hardware. + This means no major version bumps without the kernel retaining + backwards compatibility for the older major versions. Minor version + bumps should not introduce new features that newer kernels depend on + non-optionally. + +* If a security fix needs lockstep firmware and kernel fixes in order to + be successful, then all supported major versions in the linux-firmware + repo that are required by currently supported stable/LTS kernels, + should be updated with the security fix. The kernel patches should + detect if the firmware is new enough to declare if the security issue + is fixed. All communications around security fixes should point at + both the firmware and kernel fixes. If a security fix requires + deprecating old major versions, then this should only be done as a + last option, and be stated clearly in all communications. + diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index 42c01f396dce..49c0a9512653 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -79,12 +79,27 @@ do the programming sequence for this particular FPGA. These ops return 0 for success or negative error codes otherwise. The programming sequence is:: - 1. .write_init - 2. .write or .write_sg (may be called once or multiple times) - 3. .write_complete - -The .write_init function will prepare the FPGA to receive the image data. The -buffer passed into .write_init will be at most .initial_header_size bytes long; + 1. .parse_header (optional, may be called once or multiple times) + 2. .write_init + 3. .write or .write_sg (may be called once or multiple times) + 4. .write_complete + +The .parse_header function will set header_size and data_size to +struct fpga_image_info. Before parse_header call, header_size is initialized +with initial_header_size. If flag skip_header of fpga_manager_ops is true, +.write function will get image buffer starting at header_size offset from the +beginning. If data_size is set, .write function will get data_size bytes of +the image buffer, otherwise .write will get data up to the end of image buffer. +This will not affect .write_sg, .write_sg will still get whole image in +sg_table form. If FPGA image is already mapped as a single contiguous buffer, +whole buffer will be passed into .parse_header. If image is in scatter-gather +form, core code will buffer up at least .initial_header_size before the first +call of .parse_header, if it is not enough, .parse_header should set desired +size into info->header_size and return -EAGAIN, then it will be called again +with greater part of image buffer on the input. + +The .write_init function will prepare the FPGA to receive the image data. The +buffer passed into .write_init will be at least info->header_size bytes long; if the whole bitstream is not immediately available then the core code will buffer up at least this much before starting. diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst index 72bcf5f5e3a2..de6fc79ad6f0 100644 --- a/Documentation/driver-api/gpio/consumer.rst +++ b/Documentation/driver-api/gpio/consumer.rst @@ -114,7 +114,7 @@ For a function using multiple GPIOs all of those can be obtained with one call:: This function returns a struct gpio_descs which contains an array of descriptors. It also contains a pointer to a gpiolib private structure which, -if passed back to get/set array functions, may speed up I/O proocessing:: +if passed back to get/set array functions, may speed up I/O processing:: struct gpio_descs { struct gpio_array *info; diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 70ff43ac4fcc..6baaeab79534 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -119,7 +119,7 @@ GPIO lines with debounce support Debouncing is a configuration set to a pin indicating that it is connected to a mechanical switch or button, or similar that may bounce. Bouncing means the line is pulled high/low quickly at very short intervals for mechanical -reasons. This can result in the value being unstable or irqs fireing repeatedly +reasons. This can result in the value being unstable or irqs firing repeatedly unless the line is debounced. Debouncing in practice involves setting up a timer when something happens on @@ -219,7 +219,7 @@ use a trick: when a line is set as output, if the line is flagged as open drain, and the IN output value is low, it will be driven low as usual. But if the IN output value is set to high, it will instead *NOT* be driven high, instead it will be switched to input, as input mode is high impedance, thus -achieveing an "open drain emulation" of sorts: electrically the behaviour will +achieving an "open drain emulation" of sorts: electrically the behaviour will be identical, with the exception of possible hardware glitches when switching the mode of the line. @@ -642,7 +642,7 @@ In this case the typical set-up will look like this: As you can see pretty similar, but you do not supply a parent handler for the IRQ, instead a parent irqdomain, an fwnode for the hardware and -a funcion .child_to_parent_hwirq() that has the purpose of looking up +a function .child_to_parent_hwirq() that has the purpose of looking up the parent hardware irq from a child (i.e. this gpio chip) hardware irq. As always it is good to look at examples in the kernel tree for advice on how to find the required pieces. diff --git a/Documentation/driver-api/gpio/using-gpio.rst b/Documentation/driver-api/gpio/using-gpio.rst index 64c8d3f76c3a..894d88855d73 100644 --- a/Documentation/driver-api/gpio/using-gpio.rst +++ b/Documentation/driver-api/gpio/using-gpio.rst @@ -44,7 +44,7 @@ These devices will appear on the system as ``/dev/gpiochip0`` thru found in the kernel tree ``tools/gpio`` subdirectory. For structured and managed applications, we recommend that you make use of the -libgpiod_ library. This provides helper abstractions, command line utlities +libgpiod_ library. This provides helper abstractions, command line utilities and arbitration for multiple simultaneous consumers on the same GPIO chip. .. _libgpiod: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst index 41983e04d2a0..f2d617265546 100644 --- a/Documentation/driver-api/hte/tegra194-hte.rst +++ b/Documentation/driver-api/hte/tegra194-hte.rst @@ -25,8 +25,7 @@ and userspace consumers. The kernel space consumers can directly talk to HTE subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV framework to HTE subsystem. -.. kernel-doc:: drivers/gpio/gpiolib.c - :functions: gpiod_enable_hw_timestamp_ns gpiod_disable_hw_timestamp_ns +See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns(). For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which @@ -37,7 +36,7 @@ LIC (Legacy Interrupt Controller) IRQ GTE This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ lines which this instance can add timestamps to in real time. The hte -devicetree binding described at ``Documentation/devicetree/bindings/hte/`` +devicetree binding described at ``Documentation/devicetree/bindings/timestamp`` provides an example of how a consumer can request an IRQ line. Since it is a one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ number that they are interested in. There is no userspace consumer support for diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index a6d525cd9fc4..d3a58f77328e 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -27,6 +27,7 @@ available subsections can be seen below. component message-based infiniband + aperture frame-buffer regulator reset diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst index 02481a2513b9..84aa7cdb5341 100644 --- a/Documentation/driver-api/media/mc-core.rst +++ b/Documentation/driver-api/media/mc-core.rst @@ -186,8 +186,9 @@ is required and the graph structure can be freed normally. Helper functions can be used to find a link between two given pads, or a pad connected to another pad through an enabled link -:c:func:`media_entity_find_link()` and -:c:func:`media_entity_remote_pad()`. +(:c:func:`media_entity_find_link()`, :c:func:`media_pad_remote_pad_first()`, +:c:func:`media_entity_remote_source_pad_unique()` and +:c:func:`media_pad_remote_pad_unique()`). Use count and power handling ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index cf3b52bdbfb9..6f8d79926aa5 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -243,6 +243,12 @@ notifier callback is called. After all subdevices have been located the .complete() callback is called. When a subdevice is removed from the system the .unbind() method is called. All three callbacks are optional. +Drivers can store any type of custom data in their driver-specific +:c:type:`v4l2_async_subdev` wrapper. If any of that data requires special +handling when the structure is freed, drivers must implement the ``.destroy()`` +notifier callback. The framework will call it right before freeing the +:c:type:`v4l2_async_subdev`. + Calling subdev operations ~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index 7ef83fd3917b..23c6b956cd90 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -25,10 +25,10 @@ Console Support --------------- The serial core provides a few helper functions. This includes identifing -the correct port structure (via uart_get_console) and decoding command line -arguments (uart_parse_options). +the correct port structure (via uart_get_console()) and decoding command line +arguments (uart_parse_options()). -There is also a helper function (uart_console_write) which performs a +There is also a helper function (uart_console_write()) which performs a character by character write, translating newlines to CRLF sequences. Driver writers are recommended to use this function rather than implementing their own version. @@ -39,7 +39,7 @@ Locking It is the responsibility of the low level hardware driver to perform the necessary locking using port->lock. There are some exceptions (which -are described in the uart_ops listing below.) +are described in the struct uart_ops listing below.) There are two locks. A per-port spinlock, and an overall semaphore. @@ -63,442 +63,20 @@ commonly referred to as the port mutex. uart_ops -------- -The uart_ops structure is the main interface between serial_core and the -hardware specific driver. It contains all the methods to control the -hardware. - - tx_empty(port) - This function tests whether the transmitter fifo and shifter - for the port described by 'port' is empty. If it is empty, - this function should return TIOCSER_TEMT, otherwise return 0. - If the port does not support this operation, then it should - return TIOCSER_TEMT. - - Locking: none. - - Interrupts: caller dependent. - - This call must not sleep - - set_mctrl(port, mctrl) - This function sets the modem control lines for port described - by 'port' to the state described by mctrl. The relevant bits - of mctrl are: - - - TIOCM_RTS RTS signal. - - TIOCM_DTR DTR signal. - - TIOCM_OUT1 OUT1 signal. - - TIOCM_OUT2 OUT2 signal. - - TIOCM_LOOP Set the port into loopback mode. - - If the appropriate bit is set, the signal should be driven - active. If the bit is clear, the signal should be driven - inactive. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - get_mctrl(port) - Returns the current state of modem control inputs. The state - of the outputs should not be returned, since the core keeps - track of their state. The state information should include: - - - TIOCM_CAR state of DCD signal - - TIOCM_CTS state of CTS signal - - TIOCM_DSR state of DSR signal - - TIOCM_RI state of RI signal - - The bit is set if the signal is currently driven active. If - the port does not support CTS, DCD or DSR, the driver should - indicate that the signal is permanently active. If RI is - not available, the signal should not be indicated as active. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - stop_tx(port) - Stop transmitting characters. This might be due to the CTS - line becoming inactive or the tty layer indicating we want - to stop transmission due to an XOFF character. - - The driver should stop transmitting characters as soon as - possible. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - start_tx(port) - Start transmitting characters. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - throttle(port) - Notify the serial driver that input buffers for the line discipline are - close to full, and it should somehow signal that no more characters - should be sent to the serial port. - This will be called only if hardware assisted flow control is enabled. - - Locking: serialized with .unthrottle() and termios modification by the - tty layer. - - unthrottle(port) - Notify the serial driver that characters can now be sent to the serial - port without fear of overrunning the input buffers of the line - disciplines. - - This will be called only if hardware assisted flow control is enabled. - - Locking: serialized with .throttle() and termios modification by the - tty layer. - - send_xchar(port,ch) - Transmit a high priority character, even if the port is stopped. - This is used to implement XON/XOFF flow control and tcflow(). If - the serial driver does not implement this function, the tty core - will append the character to the circular buffer and then call - start_tx() / stop_tx() to flush the data out. - - Do not transmit if ch == '\0' (__DISABLED_CHAR). - - Locking: none. - - Interrupts: caller dependent. - - stop_rx(port) - Stop receiving characters; the port is in the process of - being closed. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - enable_ms(port) - Enable the modem status interrupts. - - This method may be called multiple times. Modem status - interrupts should be disabled when the shutdown method is - called. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - break_ctl(port,ctl) - Control the transmission of a break signal. If ctl is - nonzero, the break signal should be transmitted. The signal - should be terminated when another call is made with a zero - ctl. - - Locking: caller holds tty_port->mutex - - startup(port) - Grab any interrupt resources and initialise any low level driver - state. Enable the port for reception. It should not activate - RTS nor DTR; this will be done via a separate call to set_mctrl. - - This method will only be called when the port is initially opened. - - Locking: port_sem taken. - - Interrupts: globally disabled. - - shutdown(port) - Disable the port, disable any break condition that may be in - effect, and free any interrupt resources. It should not disable - RTS nor DTR; this will have already been done via a separate - call to set_mctrl. - - Drivers must not access port->state once this call has completed. - - This method will only be called when there are no more users of - this port. - - Locking: port_sem taken. - - Interrupts: caller dependent. - - flush_buffer(port) - Flush any write buffers, reset any DMA state and stop any - ongoing DMA transfers. - - This will be called whenever the port->state->xmit circular - buffer is cleared. - - Locking: port->lock taken. - - Interrupts: locally disabled. - - This call must not sleep - - set_termios(port,termios,oldtermios) - Change the port parameters, including word length, parity, stop - bits. Update read_status_mask and ignore_status_mask to indicate - the types of events we are interested in receiving. Relevant - termios->c_cflag bits are: - - CSIZE - - word size - CSTOPB - - 2 stop bits - PARENB - - parity enable - PARODD - - odd parity (when PARENB is in force) - CREAD - - enable reception of characters (if not set, - still receive characters from the port, but - throw them away. - CRTSCTS - - if set, enable CTS status change reporting - CLOCAL - - if not set, enable modem status change - reporting. - - Relevant termios->c_iflag bits are: - - INPCK - - enable frame and parity error events to be - passed to the TTY layer. - BRKINT / PARMRK - - both of these enable break events to be - passed to the TTY layer. - - IGNPAR - - ignore parity and framing errors - IGNBRK - - ignore break errors, If IGNPAR is also - set, ignore overrun errors as well. - - The interaction of the iflag bits is as follows (parity error - given as an example): - - =============== ======= ====== ============================= - Parity error INPCK IGNPAR - =============== ======= ====== ============================= - n/a 0 n/a character received, marked as - TTY_NORMAL - None 1 n/a character received, marked as - TTY_NORMAL - Yes 1 0 character received, marked as - TTY_PARITY - Yes 1 1 character discarded - =============== ======= ====== ============================= - - Other flags may be used (eg, xon/xoff characters) if your - hardware supports hardware "soft" flow control. - - Locking: caller holds tty_port->mutex - - Interrupts: caller dependent. - - This call must not sleep - - set_ldisc(port,termios) - Notifier for discipline change. See ../tty/tty_ldisc.rst. - - Locking: caller holds tty_port->mutex - - pm(port,state,oldstate) - Perform any power management related activities on the specified - port. State indicates the new state (defined by - enum uart_pm_state), oldstate indicates the previous state. - - This function should not be used to grab any resources. - - This will be called when the port is initially opened and finally - closed, except when the port is also the system console. This - will occur even if CONFIG_PM is not set. - - Locking: none. - - Interrupts: caller dependent. - - type(port) - Return a pointer to a string constant describing the specified - port, or return NULL, in which case the string 'unknown' is - substituted. - - Locking: none. - - Interrupts: caller dependent. - - release_port(port) - Release any memory and IO region resources currently in use by - the port. - - Locking: none. - - Interrupts: caller dependent. - - request_port(port) - Request any memory and IO region resources required by the port. - If any fail, no resources should be registered when this function - returns, and it should return -EBUSY on failure. - - Locking: none. - - Interrupts: caller dependent. - - config_port(port,type) - Perform any autoconfiguration steps required for the port. `type` - contains a bit mask of the required configuration. UART_CONFIG_TYPE - indicates that the port requires detection and identification. - port->type should be set to the type found, or PORT_UNKNOWN if - no port was detected. - - UART_CONFIG_IRQ indicates autoconfiguration of the interrupt signal, - which should be probed using standard kernel autoprobing techniques. - This is not necessary on platforms where ports have interrupts - internally hard wired (eg, system on a chip implementations). - - Locking: none. - - Interrupts: caller dependent. - - verify_port(port,serinfo) - Verify the new serial port information contained within serinfo is - suitable for this port type. - - Locking: none. - - Interrupts: caller dependent. - - ioctl(port,cmd,arg) - Perform any port specific IOCTLs. IOCTL commands must be defined - using the standard numbering system found in <asm/ioctl.h> - - Locking: none. - - Interrupts: caller dependent. - - poll_init(port) - Called by kgdb to perform the minimal hardware initialization needed - to support poll_put_char() and poll_get_char(). Unlike ->startup() - this should not request interrupts. - - Locking: tty_mutex and tty_port->mutex taken. - - Interrupts: n/a. - - poll_put_char(port,ch) - Called by kgdb to write a single character directly to the serial - port. It can and should block until there is space in the TX FIFO. - - Locking: none. - - Interrupts: caller dependent. - - This call must not sleep - - poll_get_char(port) - Called by kgdb to read a single character directly from the serial - port. If data is available, it should be returned; otherwise - the function should return NO_POLL_CHAR immediately. - - Locking: none. - - Interrupts: caller dependent. - - This call must not sleep +.. kernel-doc:: include/linux/serial_core.h + :identifiers: uart_ops Other functions --------------- -uart_update_timeout(port,cflag,baud) - Update the FIFO drain timeout, port->timeout, according to the - number of bits, parity, stop bits and baud rate. - - Locking: caller is expected to take port->lock - - Interrupts: n/a - -uart_get_baud_rate(port,termios,old,min,max) - Return the numeric baud rate for the specified termios, taking - account of the special 38400 baud "kludge". The B0 baud rate - is mapped to 9600 baud. - - If the baud rate is not within min..max, then if old is non-NULL, - the original baud rate will be tried. If that exceeds the - min..max constraint, 9600 baud will be returned. termios will - be updated to the baud rate in use. - - Note: min..max must always allow 9600 baud to be selected. - - Locking: caller dependent. - - Interrupts: n/a - -uart_get_divisor(port,baud) - Return the divisor (baud_base / baud) for the specified baud - rate, appropriately rounded. - - If 38400 baud and custom divisor is selected, return the - custom divisor instead. - - Locking: caller dependent. - - Interrupts: n/a - -uart_match_port(port1,port2) - This utility function can be used to determine whether two - uart_port structures describe the same port. - - Locking: n/a - - Interrupts: n/a - -uart_write_wakeup(port) - A driver is expected to call this function when the number of - characters in the transmit buffer have dropped below a threshold. - - Locking: port->lock should be held. - - Interrupts: n/a - -uart_register_driver(drv) - Register a uart driver with the core driver. We in turn register - with the tty layer, and initialise the core driver per-port state. - - drv->port should be NULL, and the per-port structures should be - registered using uart_add_one_port after this call has succeeded. - - Locking: none - - Interrupts: enabled - -uart_unregister_driver() - Remove all references to a driver from the core driver. The low - level driver must have removed all its ports via the - uart_remove_one_port() if it registered them with uart_add_one_port(). - - Locking: none - - Interrupts: enabled - -**uart_suspend_port()** - -**uart_resume_port()** - -**uart_add_one_port()** - -**uart_remove_one_port()** +.. kernel-doc:: drivers/tty/serial/serial_core.c + :identifiers: uart_update_timeout uart_get_baud_rate uart_get_divisor + uart_match_port uart_write_wakeup uart_register_driver + uart_unregister_driver uart_suspend_port uart_resume_port + uart_add_one_port uart_remove_one_port uart_console_write + uart_parse_earlycon uart_parse_options uart_set_options + uart_get_lsr_info uart_handle_dcd_change uart_handle_cts_change + uart_try_toggle_sysrq uart_get_console Other notes ----------- @@ -519,31 +97,7 @@ Modem control lines via GPIO Some helpers are provided in order to set/get modem control lines via GPIO. -mctrl_gpio_init(port, idx): - This will get the {cts,rts,...}-gpios from device tree if they are - present and request them, set direction etc, and return an - allocated structure. `devm_*` functions are used, so there's no need - to call mctrl_gpio_free(). - As this sets up the irq handling make sure to not handle changes to the - gpio input lines in your driver, too. - -mctrl_gpio_free(dev, gpios): - This will free the requested gpios in mctrl_gpio_init(). - As `devm_*` functions are used, there's generally no need to call - this function. - -mctrl_gpio_to_gpiod(gpios, gidx) - This returns the gpio_desc structure associated to the modem line - index. - -mctrl_gpio_set(gpios, mctrl): - This will sets the gpios according to the mctrl state. - -mctrl_gpio_get(gpios, mctrl): - This will update mctrl with the gpios values. - -mctrl_gpio_enable_ms(gpios): - Enables irqs and handling of changes to the ms lines. - -mctrl_gpio_disable_ms(gpios): - Disables irqs and handling of changes to the ms lines. +.. kernel-doc:: drivers/tty/serial/serial_mctrl_gpio.c + :identifiers: mctrl_gpio_init mctrl_gpio_free mctrl_gpio_to_gpiod + mctrl_gpio_set mctrl_gpio_get mctrl_gpio_enable_ms + mctrl_gpio_disable_ms diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst index 6bc824f948f9..6ebad75c74ed 100644 --- a/Documentation/driver-api/serial/serial-rs485.rst +++ b/Documentation/driver-api/serial/serial-rs485.rst @@ -38,10 +38,14 @@ RS485 Serial Communications the values given by the device tree. Any driver for devices capable of working both as RS232 and RS485 should - implement the rs485_config callback in the uart_port structure. The - serial_core calls rs485_config to do the device specific part in response - to TIOCSRS485 and TIOCGRS485 ioctls (see below). The rs485_config callback - receives a pointer to struct serial_rs485. + implement the rs485_config callback and provide rs485_supported in the + uart_port structure. The serial core calls rs485_config to do the device + specific part in response to TIOCSRS485 ioctl (see below). The rs485_config + callback receives a pointer to a sanitizated serial_rs485 structure. The + serial_rs485 userspace provides is sanitized before calling rs485_config + using rs485_supported that indicates what RS485 features the driver supports + for the uart_port. TIOCGRS485 ioctl can be used to read back the + serial_rs485 structure matching to the current configuration. 4. Usage from user-level ======================== @@ -95,7 +99,31 @@ RS485 Serial Communications /* Error handling. See errno. */ } -5. References +5. Multipoint Addressing +======================== + + The Linux kernel provides addressing mode for multipoint RS-485 serial + communications line. The addressing mode is enabled with SER_RS485_ADDRB + flag in serial_rs485. Struct serial_rs485 has two additional flags and + fields for enabling receive and destination addresses. + + Address mode flags: + - SER_RS485_ADDRB: Enabled addressing mode (sets also ADDRB in termios). + - SER_RS485_ADDR_RECV: Receive (filter) address enabled. + - SER_RS485_ADDR_DEST: Set destination address. + + Address fields (enabled with corresponding SER_RS485_ADDR_* flag): + - addr_recv: Receive address. + - addr_dest: Destination address. + + Once a receive address is set, the communication can occur only with the + particular device and other peers are filtered out. It is left up to the + receiver side to enforce the filtering. Receive address will be cleared + if SER_RS485_ADDR_RECV is not set. + + Note: not all devices supporting RS485 support multipoint addressing. + +6. References ============= [1] include/uapi/linux/serial.h diff --git a/Documentation/driver-api/surface_aggregator/client.rst b/Documentation/driver-api/surface_aggregator/client.rst index e519d374c378..27f95abdbe99 100644 --- a/Documentation/driver-api/surface_aggregator/client.rst +++ b/Documentation/driver-api/surface_aggregator/client.rst @@ -17,6 +17,8 @@ .. |SSAM_DEVICE| replace:: :c:func:`SSAM_DEVICE` .. |ssam_notifier_register| replace:: :c:func:`ssam_notifier_register` .. |ssam_notifier_unregister| replace:: :c:func:`ssam_notifier_unregister` +.. |ssam_device_notifier_register| replace:: :c:func:`ssam_device_notifier_register` +.. |ssam_device_notifier_unregister| replace:: :c:func:`ssam_device_notifier_unregister` .. |ssam_request_sync| replace:: :c:func:`ssam_request_sync` .. |ssam_event_mask| replace:: :c:type:`enum ssam_event_mask <ssam_event_mask>` @@ -312,7 +314,9 @@ Handling Events To receive events from the SAM EC, an event notifier must be registered for the desired event via |ssam_notifier_register|. The notifier must be unregistered via |ssam_notifier_unregister| once it is not required any -more. +more. For |ssam_device| type clients, the |ssam_device_notifier_register| and +|ssam_device_notifier_unregister| wrappers should be preferred as they properly +handle hot-removal of client devices. Event notifiers are registered by providing (at minimum) a callback to call in case an event has been received, the registry specifying how the event diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index eded8719180f..f47dca6645aa 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -1,3 +1,4 @@ +.. SPDX-License-Identifier: GPL-2.0-only .. include:: <isonum.txt> ===================== @@ -8,9 +9,6 @@ VFIO Mediated devices :Author: Neo Jia <cjia@nvidia.com> :Author: Kirti Wankhede <kwankhede@nvidia.com> -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License version 2 as -published by the Free Software Foundation. Virtual Function I/O (VFIO) Mediated devices[1] @@ -114,11 +112,11 @@ to register and unregister itself with the core driver: * Register:: - extern int mdev_register_driver(struct mdev_driver *drv); + int mdev_register_driver(struct mdev_driver *drv); * Unregister:: - extern void mdev_unregister_driver(struct mdev_driver *drv); + void mdev_unregister_driver(struct mdev_driver *drv); The mediated bus driver's probe function should create a vfio_device on top of the mdev_device and connect it to an appropriate implementation of @@ -127,8 +125,8 @@ vfio_device_ops. When a driver wants to add the GUID creation sysfs to an existing device it has probe'd to then it should call:: - extern int mdev_register_device(struct device *dev, - struct mdev_driver *mdev_driver); + int mdev_register_device(struct device *dev, + struct mdev_driver *mdev_driver); This will provide the 'mdev_supported_types/XX/create' files which can then be used to trigger the creation of a mdev_device. The created mdev_device will be @@ -136,7 +134,7 @@ attached to the specified driver. When the driver needs to remove itself it calls:: - extern void mdev_unregister_device(struct device *dev); + void mdev_unregister_device(struct device *dev); Which will unbind and destroy all the created mdevs and remove the sysfs files. @@ -262,10 +260,10 @@ Translation APIs for Mediated Devices The following APIs are provided for translating user pfn to host pfn in a VFIO driver:: - int vfio_pin_pages(struct vfio_device *device, unsigned long *user_pfn, - int npage, int prot, unsigned long *phys_pfn); + int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova, + int npage, int prot, struct page **pages); - int vfio_unpin_pages(struct vfio_device *device, unsigned long *user_pfn, + void vfio_unpin_pages(struct vfio_device *device, dma_addr_t iova, int npage); These functions call back into the back-end IOMMU module by using the pin_pages diff --git a/Documentation/driver-api/vme.rst b/Documentation/driver-api/vme.rst index def139c13410..c0b475369de0 100644 --- a/Documentation/driver-api/vme.rst +++ b/Documentation/driver-api/vme.rst @@ -290,8 +290,8 @@ The function :c:func:`vme_bus_num` returns the bus ID of the provided bridge. VME API ------- -.. kernel-doc:: include/linux/vme.h +.. kernel-doc:: drivers/staging/vme_user/vme.h :internal: -.. kernel-doc:: drivers/vme/vme.c +.. kernel-doc:: drivers/staging/vme_user/vme.c :export: diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index eb9c2d9a4f5f..17779a2772e5 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -169,6 +169,13 @@ configuration of fault-injection capabilities. default is 'N', setting it to 'Y' will disable disconnect injection on the RPC server. +- /sys/kernel/debug/fail_sunrpc/ignore-cache-wait: + + Format: { 'Y' | 'N' } + + default is 'N', setting it to 'Y' will disable cache wait + injection on the RPC server. + - /sys/kernel/debug/fail_function/inject: Format: { 'function-name' | '!function-name' | '' } diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt index 502c1d409648..0b3ba2415fac 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -27,5 +27,5 @@ | sparc: | TODO | | um: | ok | | x86: | ok | - | xtensa: | TODO | + | xtensa: | ok | ----------------------- diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt index afb90bebded2..0a91f5ce34a9 100644 --- a/Documentation/features/debug/kcov/arch-support.txt +++ b/Documentation/features/debug/kcov/arch-support.txt @@ -27,5 +27,5 @@ | sparc: | TODO | | um: | ok | | x86: | ok | - | xtensa: | TODO | + | xtensa: | ok | ----------------------- diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index c9e0a16290e6..e59071a49090 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -1,7 +1,7 @@ # -# Feature name: context-tracking -# Kconfig: HAVE_CONTEXT_TRACKING -# description: arch supports context tracking for NO_HZ_FULL +# Feature name: user-context-tracking +# Kconfig: HAVE_CONTEXT_TRACKING_USER +# description: arch supports user context tracking for NO_HZ_FULL # ----------------------- | arch |status| diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt index b01bf7bca3e6..6bd78eb4dc6e 100644 --- a/Documentation/features/vm/ioremap_prot/arch-support.txt +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -9,7 +9,7 @@ | alpha: | TODO | | arc: | ok | | arm: | TODO | - | arm64: | TODO | + | arm64: | ok | | csky: | TODO | | hexagon: | TODO | | ia64: | TODO | diff --git a/Documentation/filesystems/ext2.rst b/Documentation/filesystems/ext2.rst index 154101cf0e4f..92aae683e16a 100644 --- a/Documentation/filesystems/ext2.rst +++ b/Documentation/filesystems/ext2.rst @@ -59,8 +59,6 @@ acl Enable POSIX Access Control Lists support (requires CONFIG_EXT2_FS_POSIX_ACL). noacl Don't support POSIX ACLs. -nobh Do not attach buffer_heads to file pagecache. - quota, usrquota Enable user disk quota support (requires CONFIG_QUOTA). diff --git a/Documentation/filesystems/ext4/blockmap.rst b/Documentation/filesystems/ext4/blockmap.rst index 2bd990402a5c..cc596541ce79 100644 --- a/Documentation/filesystems/ext4/blockmap.rst +++ b/Documentation/filesystems/ext4/blockmap.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +---------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| i.i_block Offset | Where It Points | +| i.i_block Offset | Where It Points | +=====================+==============================================================================================================================================================================================================================+ | 0 to 11 | Direct map to file blocks 0 to 11. | +---------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index ad8dc8c040a2..d0c09663dae8 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -336,6 +336,11 @@ discard_unit=%s Control discard unit, the argument can be "block", "segment" default, it is helpful for large sized SMR or ZNS devices to reduce memory cost by getting rid of fs metadata supports small discard. +memory=%s Control memory mode. This supports "normal" and "low" modes. + "low" mode is introduced to support low memory devices. + Because of the nature of low memory devices, in this mode, f2fs + will try to save memory sometimes by sacrificing performance. + "normal" mode is the default mode and same as before. ======================== ============================================================ Debugfs Entries @@ -818,10 +823,11 @@ Compression implementation Instead, the main goal is to reduce data writes to flash disk as much as possible, resulting in extending disk life time as well as relaxing IO congestion. Alternatively, we've added ioctl(F2FS_IOC_RELEASE_COMPRESS_BLOCKS) - interface to reclaim compressed space and show it to user after putting the - immutable bit. Immutable bit, after release, it doesn't allow writing/mmaping - on the file, until reserving compressed space via - ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or truncating filesize to zero. + interface to reclaim compressed space and show it to user after setting a + special flag to the inode. Once the compressed space is released, the flag + will block writing data to the file until either the compressed space is + reserved via ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or the file size is + truncated to zero. Compress metadata layout:: @@ -830,12 +836,12 @@ Compress metadata layout:: | cluster 1 | cluster 2 | ......... | cluster N | +-----------------------------------------------+ . . . . - . . . . + . . . . . Compressed Cluster . . Normal Cluster . +----------+---------+---------+---------+ +---------+---------+---------+---------+ |compr flag| block 1 | block 2 | block 3 | | block 1 | block 2 | block 3 | block 4 | +----------+---------+---------+---------+ +---------+---------+---------+---------+ - . . + . . . . . . +-------------+-------------+----------+----------------------------+ diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 2e9aaa295125..5ba5817c17c2 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -337,6 +337,7 @@ Currently, the following pairs of encryption modes are supported: - AES-256-XTS for contents and AES-256-CTS-CBC for filenames - AES-128-CBC for contents and AES-128-CTS-CBC for filenames - Adiantum for both contents and filenames +- AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only) If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair. @@ -357,6 +358,17 @@ To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast implementations of ChaCha and NHPoly1305 should be enabled, e.g. CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM. +AES-256-HCTR2 is another true wide-block encryption mode that is intended for +use on CPUs with dedicated crypto instructions. AES-256-HCTR2 has the property +that a bitflip in the plaintext changes the entire ciphertext. This property +makes it desirable for filename encryption since initialization vectors are +reused within a directory. For more details on AES-256-HCTR2, see the paper +"Length-preserving encryption with HCTR2" +(https://eprint.iacr.org/2021/1441.pdf). To use AES-256-HCTR2, +CONFIG_CRYPTO_HCTR2 must be enabled. Also, fast implementations of XCTR and +POLYVAL should be enabled, e.g. CRYPTO_POLYVAL_ARM64_CE and +CRYPTO_AES_ARM64_CE_BLK for ARM64. + New encryption modes can be added relatively easily, without changes to individual filesystems. However, authenticated encryption (AE) modes are not currently supported because of the difficulty of dealing @@ -404,11 +416,11 @@ alternatively has the file's nonce (for `DIRECT_KEY policies`_) or inode number (for `IV_INO_LBLK_64 policies`_) included in the IVs. Thus, IV reuse is limited to within a single directory. -With CTS-CBC, the IV reuse means that when the plaintext filenames -share a common prefix at least as long as the cipher block size (16 -bytes for AES), the corresponding encrypted filenames will also share -a common prefix. This is undesirable. Adiantum does not have this -weakness, as it is a wide-block encryption mode. +With CTS-CBC, the IV reuse means that when the plaintext filenames share a +common prefix at least as long as the cipher block size (16 bytes for AES), the +corresponding encrypted filenames will also share a common prefix. This is +undesirable. Adiantum and HCTR2 do not have this weakness, as they are +wide-block encryption modes. All supported filenames encryption modes accept any plaintext length >= 16 bytes; cipher block alignment is not required. However, diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 756f2c215ba1..cb8e7573882a 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -11,9 +11,9 @@ Introduction fs-verity (``fs/verity/``) is a support layer that filesystems can hook into to support transparent integrity and authenticity protection -of read-only files. Currently, it is supported by the ext4 and f2fs -filesystems. Like fscrypt, not too much filesystem-specific code is -needed to support fs-verity. +of read-only files. Currently, it is supported by the ext4, f2fs, and +btrfs filesystems. Like fscrypt, not too much filesystem-specific +code is needed to support fs-verity. fs-verity is similar to `dm-verity <https://www.kernel.org/doc/Documentation/device-mapper/verity.txt>`_ @@ -473,9 +473,9 @@ files being swapped around. Filesystem support ================== -fs-verity is currently supported by the ext4 and f2fs filesystems. -The CONFIG_FS_VERITY kconfig option must be enabled to use fs-verity -on either filesystem. +fs-verity is supported by several filesystems, described below. The +CONFIG_FS_VERITY kconfig option must be enabled to use fs-verity on +any of these filesystems. ``include/linux/fsverity.h`` declares the interface between the ``fs/verity/`` support layer and filesystems. Briefly, filesystems @@ -544,6 +544,13 @@ Currently, f2fs verity only supports a Merkle tree block size of 4096. Also, f2fs doesn't support enabling verity on files that currently have atomic or volatile writes pending. +btrfs +----- + +btrfs supports fs-verity since Linux v5.15. Verity-enabled inodes are +marked with a RO_COMPAT inode flag, and the verity metadata is stored +in separate btree items. + Implementation details ====================== @@ -622,14 +629,14 @@ workqueue, and then the workqueue work does the decryption or verification. Finally, pages where no decryption or verity error occurred are marked Uptodate, and the pages are unlocked. -Files on ext4 and f2fs may contain holes. Normally, ``->readahead()`` -simply zeroes holes and sets the corresponding pages Uptodate; no bios -are issued. To prevent this case from bypassing fs-verity, these -filesystems use fsverity_verify_page() to verify hole pages. +On many filesystems, files can contain holes. Normally, +``->readahead()`` simply zeroes holes and sets the corresponding pages +Uptodate; no bios are issued. To prevent this case from bypassing +fs-verity, these filesystems use fsverity_verify_page() to verify hole +pages. -ext4 and f2fs disable direct I/O on verity files, since otherwise -direct I/O would bypass fs-verity. (They also do the same for -encrypted files.) +Filesystems also disable direct I/O on verity files, since otherwise +direct I/O would bypass fs-verity. Userspace utility ================= @@ -648,7 +655,7 @@ Tests To test fs-verity, use xfstests. For example, using `kvm-xfstests <https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md>`_:: - kvm-xfstests -c ext4,f2fs -g verity + kvm-xfstests -c ext4,f2fs,btrfs -g verity FAQ === @@ -771,15 +778,15 @@ weren't already directly answered in other parts of this document. e.g. magically trigger construction of a Merkle tree. :Q: Does fs-verity support remote filesystems? -:A: Only ext4 and f2fs support is implemented currently, but in - principle any filesystem that can store per-file verity metadata - can support fs-verity, regardless of whether it's local or remote. - Some filesystems may have fewer options of where to store the - verity metadata; one possibility is to store it past the end of - the file and "hide" it from userspace by manipulating i_size. The - data verification functions provided by ``fs/verity/`` also assume - that the filesystem uses the Linux pagecache, but both local and - remote filesystems normally do so. +:A: So far all filesystems that have implemented fs-verity support are + local filesystems, but in principle any filesystem that can store + per-file verity metadata can support fs-verity, regardless of + whether it's local or remote. Some filesystems may have fewer + options of where to store the verity metadata; one possibility is + to store it past the end of the file and "hide" it from userspace + by manipulating i_size. The data verification functions provided + by ``fs/verity/`` also assume that the filesystem uses the Linux + pagecache, but both local and remote filesystems normally do so. :Q: Why is anything filesystem-specific at all? Shouldn't fs-verity be implemented entirely at the VFS level? diff --git a/Documentation/filesystems/fuse.rst b/Documentation/filesystems/fuse.rst index 8120c3c0cb4e..1e31e87aee68 100644 --- a/Documentation/filesystems/fuse.rst +++ b/Documentation/filesystems/fuse.rst @@ -279,7 +279,7 @@ How are requirements fulfilled? the filesystem or not. Note that the *ptrace* check is not strictly necessary to - prevent B/2/i, it is enough to check if mount owner has enough + prevent C/2/i, it is enough to check if mount owner has enough privilege to send signal to the process accessing the filesystem, since *SIGSTOP* can be used to get a similar effect. @@ -288,10 +288,29 @@ I think these limitations are unacceptable? If a sysadmin trusts the users enough, or can ensure through other measures, that system processes will never enter non-privileged -mounts, it can relax the last limitation with a 'user_allow_other' -config option. If this config option is set, the mounting user can -add the 'allow_other' mount option which disables the check for other -users' processes. +mounts, it can relax the last limitation in several ways: + + - With the 'user_allow_other' config option. If this config option is + set, the mounting user can add the 'allow_other' mount option which + disables the check for other users' processes. + + User namespaces have an unintuitive interaction with 'allow_other': + an unprivileged user - normally restricted from mounting with + 'allow_other' - could do so in a user namespace where they're + privileged. If any process could access such an 'allow_other' mount + this would give the mounting user the ability to manipulate + processes in user namespaces where they're unprivileged. For this + reason 'allow_other' restricts access to users in the same userns + or a descendant. + + - With the 'allow_sys_admin_access' module option. If this option is + set, super user's processes have unrestricted access to mounts + irrespective of allow_other setting or user namespace of the + mounting user. + +Note that both of these relaxations expose the system to potential +information leak or *DoS* as described in points B and C/2/i-ii in the +preceding section. Kernel - userspace interface ============================ diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index c0fe711f14d3..4bb2627026ec 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -252,9 +252,8 @@ prototypes:: bool (*release_folio)(struct folio *, gfp_t); void (*free_folio)(struct folio *); int (*direct_IO)(struct kiocb *, struct iov_iter *iter); - bool (*isolate_page) (struct page *, isolate_mode_t); - int (*migratepage)(struct address_space *, struct page *, struct page *); - void (*putback_page) (struct page *); + int (*migrate_folio)(struct address_space *, struct folio *dst, + struct folio *src, enum migrate_mode); 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 *); @@ -280,9 +279,7 @@ invalidate_folio: yes exclusive release_folio: yes free_folio: yes direct_IO: -isolate_page: yes -migratepage: yes (both) -putback_page: yes +migrate_folio: yes (both) launder_folio: yes is_partially_uptodate: yes error_remove_page: yes diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 4d19b19bcc08..73a4176144b3 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -301,7 +301,7 @@ through which it can issue requests and negotiate:: void (*issue_read)(struct netfs_io_subrequest *subreq); bool (*is_still_valid)(struct netfs_io_request *rreq); int (*check_write_begin)(struct file *file, loff_t pos, unsigned len, - struct folio *folio, void **_fsdata); + struct folio **foliop, void **_fsdata); void (*done)(struct netfs_io_request *rreq); }; @@ -381,8 +381,10 @@ The operations are as follows: allocated/grabbed the folio to be modified to allow the filesystem to flush conflicting state before allowing it to be modified. - It should return 0 if everything is now fine, -EAGAIN if the folio should be - regrabbed and any other error code to abort the operation. + It may unlock and discard the folio it was given and set the caller's folio + pointer to NULL. It should return 0 if everything is now fine (``*foliop`` + left set) or the op should be retried (``*foliop`` cleared) and any other + error code to abort the operation. * ``done`` diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 7da6c30ed596..4c76fda07645 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -607,7 +607,7 @@ can be removed. User xattr ---------- -The the "-o userxattr" mount option forces overlayfs to use the +The "-o userxattr" mount option forces overlayfs to use the "user.overlay." xattr namespace instead of "trusted.overlay.". This is useful for unprivileged mounting of overlayfs. diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 2e0e4f0e0c6f..aee9aaf9f3df 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -914,3 +914,11 @@ Calling conventions for file_open_root() changed; now it takes struct path * instead of passing mount and dentry separately. For callers that used to pass <mnt, mnt->mnt_root> pair (i.e. the root of given mount), a new helper is provided - file_open_root_mnt(). In-tree users adjusted. + +--- + +**mandatory** + +no_llseek is gone; don't set .llseek to that - just leave it NULL instead. +Checks for "does that file have llseek(2), or should it fail with ESPIPE" +should be done by looking at FMODE_LSEEK in file->f_mode. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 1bc91fb8c321..e7aafc82be99 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -448,6 +448,7 @@ Memory Area, or VMA) there is a series of lines such as the following:: MMUPageSize: 4 kB Rss: 892 kB Pss: 374 kB + Pss_Dirty: 0 kB Shared_Clean: 892 kB Shared_Dirty: 0 kB Private_Clean: 0 kB @@ -479,7 +480,9 @@ dirty shared and private pages in the mapping. The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. So if a process has 1000 pages all to itself, and 1000 shared with one other -process, its PSS will be 1500. +process, its PSS will be 1500. "Pss_Dirty" is the portion of PSS which +consists of dirty pages. ("Pss_Clean" is not included, but it can be +calculated by subtracting "Pss_Dirty" from "Pss".) Note that even a page which is part of a MAP_SHARED mapping, but has only a single pte mapped, i.e. is currently used by only one process, is accounted @@ -514,8 +517,10 @@ replaced by copy-on-write) part of the underlying shmem object out on swap. "SwapPss" shows proportional swap share of this mapping. Unlike "Swap", this does not take into account swapped out page of underlying shmem objects. "Locked" indicates whether the mapping is locked in memory or not. + "THPeligible" indicates whether the mapping is eligible for allocating THP -pages - 1 if true, 0 otherwise. It just shows the current status. +pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise. +It just shows the current status. "VmFlags" field deserves a separate description. This member represents the kernel flags associated with the particular virtual memory area in two letter @@ -1109,7 +1114,7 @@ CommitLimit yield a CommitLimit of 7.3G. For more details, see the memory overcommit documentation - in vm/overcommit-accounting. + in mm/overcommit-accounting. Committed_AS The amount of memory presently allocated on the system. The committed memory is a sum of all of the memory which diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 08069ecd49a6..6cd6953e175b 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -737,12 +737,8 @@ cache in your filesystem. The following members are defined: bool (*release_folio)(struct folio *, gfp_t); void (*free_folio)(struct folio *); ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter); - /* isolate a page for migration */ - bool (*isolate_page) (struct page *, isolate_mode_t); - /* migrate the contents of a page to the specified target */ - int (*migratepage) (struct page *, struct page *); - /* put migration-failed page back to right list */ - void (*putback_page) (struct page *); + int (*migrate_folio)(struct mapping *, struct folio *dst, + struct folio *src, enum migrate_mode); int (*launder_folio) (struct folio *); bool (*is_partially_uptodate) (struct folio *, size_t from, @@ -774,13 +770,38 @@ cache in your filesystem. The following members are defined: See the file "Locking" for more details. ``read_folio`` - called by the VM to read a folio from backing store. The folio - will be locked when read_folio is called, and should be unlocked - and marked uptodate once the read completes. If ->read_folio - discovers that it cannot perform the I/O at this time, it can - unlock the folio and return AOP_TRUNCATED_PAGE. In this case, - the folio will be looked up again, relocked and if that all succeeds, - ->read_folio will be called again. + Called by the page cache to read a folio from the backing store. + The 'file' argument supplies authentication information to network + filesystems, and is generally not used by block based filesystems. + It may be NULL if the caller does not have an open file (eg if + the kernel is performing a read for itself rather than on behalf + of a userspace process with an open file). + + If the mapping does not support large folios, the folio will + contain a single page. The folio will be locked when read_folio + is called. If the read completes successfully, the folio should + be marked uptodate. The filesystem should unlock the folio + once the read has completed, whether it was successful or not. + The filesystem does not need to modify the refcount on the folio; + the page cache holds a reference count and that will not be + released until the folio is unlocked. + + Filesystems may implement ->read_folio() synchronously. + In normal operation, folios are read through the ->readahead() + method. Only if this fails, or if the caller needs to wait for + the read to complete will the page cache call ->read_folio(). + Filesystems should not attempt to perform their own readahead + in the ->read_folio() operation. + + If the filesystem cannot perform the read at this time, it can + unlock the folio, do whatever action it needs to ensure that the + read will succeed in the future and return AOP_TRUNCATED_PAGE. + In this case, the caller should look up the folio, lock it, + and call ->read_folio again. + + Callers may invoke the ->read_folio() method directly, but using + read_mapping_folio() will take care of locking, waiting for the + read to complete and handle cases such as AOP_TRUNCATED_PAGE. ``writepages`` called by the VM to write out pages associated with the @@ -905,20 +926,12 @@ cache in your filesystem. The following members are defined: data directly between the storage and the application's address space. -``isolate_page`` - Called by the VM when isolating a movable non-lru page. If page - is successfully isolated, VM marks the page as PG_isolated via - __SetPageIsolated. - -``migrate_page`` +``migrate_folio`` This is used to compact the physical memory usage. If the VM - wants to relocate a page (maybe off a memory card that is - signalling imminent failure) it will pass a new page and an old - page to this function. migrate_page should transfer any private - data across and update any references that it has to the page. - -``putback_page`` - Called by the VM when isolated page's migration fails. + wants to relocate a folio (maybe from a memory device that is + signalling imminent failure) it will pass a new folio and an old + folio to this function. migrate_folio should transfer any private + data across and update any references that it has to the folio. ``launder_folio`` Called before freeing a folio - it writes back the dirty folio. diff --git a/Documentation/filesystems/xfs-delayed-logging-design.rst b/Documentation/filesystems/xfs-delayed-logging-design.rst index 464405d2801e..4ef419f54663 100644 --- a/Documentation/filesystems/xfs-delayed-logging-design.rst +++ b/Documentation/filesystems/xfs-delayed-logging-design.rst @@ -1,29 +1,314 @@ .. SPDX-License-Identifier: GPL-2.0 -========================== -XFS Delayed Logging Design -========================== - -Introduction to Re-logging in XFS -================================= - -XFS logging is a combination of logical and physical logging. Some objects, -such as inodes and dquots, are logged in logical format where the details -logged are made up of the changes to in-core structures rather than on-disk -structures. Other objects - typically buffers - have their physical changes -logged. The reason for these differences is to reduce the amount of log space -required for objects that are frequently logged. Some parts of inodes are more -frequently logged than others, and inodes are typically more frequently logged -than any other object (except maybe the superblock buffer) so keeping the -amount of metadata logged low is of prime importance. - -The reason that this is such a concern is that XFS allows multiple separate -modifications to a single object to be carried in the log at any given time. -This allows the log to avoid needing to flush each change to disk before -recording a new change to the object. XFS does this via a method called -"re-logging". Conceptually, this is quite simple - all it requires is that any -new change to the object is recorded with a *new copy* of all the existing -changes in the new transaction that is written to the log. +================== +XFS Logging Design +================== + +Preamble +======== + +This document describes the design and algorithms that the XFS journalling +subsystem is based on. This document describes the design and algorithms that +the XFS journalling subsystem is based on so that readers may familiarize +themselves with the general concepts of how transaction processing in XFS works. + +We begin with an overview of transactions in XFS, followed by describing how +transaction reservations are structured and accounted, and then move into how we +guarantee forwards progress for long running transactions with finite initial +reservations bounds. At this point we need to explain how relogging works. With +the basic concepts covered, the design of the delayed logging mechanism is +documented. + + +Introduction +============ + +XFS uses Write Ahead Logging for ensuring changes to the filesystem metadata +are atomic and recoverable. For reasons of space and time efficiency, the +logging mechanisms are varied and complex, combining intents, logical and +physical logging mechanisms to provide the necessary recovery guarantees the +filesystem requires. + +Some objects, such as inodes and dquots, are logged in logical format where the +details logged are made up of the changes to in-core structures rather than +on-disk structures. Other objects - typically buffers - have their physical +changes logged. Long running atomic modifications have individual changes +chained together by intents, ensuring that journal recovery can restart and +finish an operation that was only partially done when the system stopped +functioning. + +The reason for these differences is to keep the amount of log space and CPU time +required to process objects being modified as small as possible and hence the +logging overhead as low as possible. Some items are very frequently modified, +and some parts of objects are more frequently modified than others, so keeping +the overhead of metadata logging low is of prime importance. + +The method used to log an item or chain modifications together isn't +particularly important in the scope of this document. It suffices to know that +the method used for logging a particular object or chaining modifications +together are different and are dependent on the object and/or modification being +performed. The logging subsystem only cares that certain specific rules are +followed to guarantee forwards progress and prevent deadlocks. + + +Transactions in XFS +=================== + +XFS has two types of high level transactions, defined by the type of log space +reservation they take. These are known as "one shot" and "permanent" +transactions. Permanent transaction reservations can take reservations that span +commit boundaries, whilst "one shot" transactions are for a single atomic +modification. + +The type and size of reservation must be matched to the modification taking +place. This means that permanent transactions can be used for one-shot +modifications, but one-shot reservations cannot be used for permanent +transactions. + +In the code, a one-shot transaction pattern looks somewhat like this:: + + tp = xfs_trans_alloc(<reservation>) + <lock items> + <join item to transaction> + <do modification> + xfs_trans_commit(tp); + +As items are modified in the transaction, the dirty regions in those items are +tracked via the transaction handle. Once the transaction is committed, all +resources joined to it are released, along with the remaining unused reservation +space that was taken at the transaction allocation time. + +In contrast, a permanent transaction is made up of multiple linked individual +transactions, and the pattern looks like this:: + + tp = xfs_trans_alloc(<reservation>) + xfs_ilock(ip, XFS_ILOCK_EXCL) + + loop { + xfs_trans_ijoin(tp, 0); + <do modification> + xfs_trans_log_inode(tp, ip); + xfs_trans_roll(&tp); + } + + xfs_trans_commit(tp); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + +While this might look similar to a one-shot transaction, there is an important +difference: xfs_trans_roll() performs a specific operation that links two +transactions together:: + + ntp = xfs_trans_dup(tp); + xfs_trans_commit(tp); + xfs_log_reserve(ntp); + +This results in a series of "rolling transactions" where the inode is locked +across the entire chain of transactions. Hence while this series of rolling +transactions is running, nothing else can read from or write to the inode and +this provides a mechanism for complex changes to appear atomic from an external +observer's point of view. + +It is important to note that a series of rolling transactions in a permanent +transaction does not form an atomic change in the journal. While each +individual modification is atomic, the chain is *not atomic*. If we crash half +way through, then recovery will only replay up to the last transactional +modification the loop made that was committed to the journal. + +This affects long running permanent transactions in that it is not possible to +predict how much of a long running operation will actually be recovered because +there is no guarantee of how much of the operation reached stale storage. Hence +if a long running operation requires multiple transactions to fully complete, +the high level operation must use intents and deferred operations to guarantee +recovery can complete the operation once the first transactions is persisted in +the on-disk journal. + + +Transactions are Asynchronous +============================= + +In XFS, all high level transactions are asynchronous by default. This means that +xfs_trans_commit() does not guarantee that the modification has been committed +to stable storage when it returns. Hence when a system crashes, not all the +completed transactions will be replayed during recovery. + +However, the logging subsystem does provide global ordering guarantees, such +that if a specific change is seen after recovery, all metadata modifications +that were committed prior to that change will also be seen. + +For single shot operations that need to reach stable storage immediately, or +ensuring that a long running permanent transaction is fully committed once it is +complete, we can explicitly tag a transaction as synchronous. This will trigger +a "log force" to flush the outstanding committed transactions to stable storage +in the journal and wait for that to complete. + +Synchronous transactions are rarely used, however, because they limit logging +throughput to the IO latency limitations of the underlying storage. Instead, we +tend to use log forces to ensure modifications are on stable storage only when +a user operation requires a synchronisation point to occur (e.g. fsync). + + +Transaction Reservations +======================== + +It has been mentioned a number of times now that the logging subsystem needs to +provide a forwards progress guarantee so that no modification ever stalls +because it can't be written to the journal due to a lack of space in the +journal. This is achieved by the transaction reservations that are made when +a transaction is first allocated. For permanent transactions, these reservations +are maintained as part of the transaction rolling mechanism. + +A transaction reservation provides a guarantee that there is physical log space +available to write the modification into the journal before we start making +modifications to objects and items. As such, the reservation needs to be large +enough to take into account the amount of metadata that the change might need to +log in the worst case. This means that if we are modifying a btree in the +transaction, we have to reserve enough space to record a full leaf-to-root split +of the btree. As such, the reservations are quite complex because we have to +take into account all the hidden changes that might occur. + +For example, a user data extent allocation involves allocating an extent from +free space, which modifies the free space trees. That's two btrees. Inserting +the extent into the inode's extent map might require a split of the extent map +btree, which requires another allocation that can modify the free space trees +again. Then we might have to update reverse mappings, which modifies yet +another btree which might require more space. And so on. Hence the amount of +metadata that a "simple" operation can modify can be quite large. + +This "worst case" calculation provides us with the static "unit reservation" +for the transaction that is calculated at mount time. We must guarantee that the +log has this much space available before the transaction is allowed to proceed +so that when we come to write the dirty metadata into the log we don't run out +of log space half way through the write. + +For one-shot transactions, a single unit space reservation is all that is +required for the transaction to proceed. For permanent transactions, however, we +also have a "log count" that affects the size of the reservation that is to be +made. + +While a permanent transaction can get by with a single unit of space +reservation, it is somewhat inefficient to do this as it requires the +transaction rolling mechanism to re-reserve space on every transaction roll. We +know from the implementation of the permanent transactions how many transaction +rolls are likely for the common modifications that need to be made. + +For example, and inode allocation is typically two transactions - one to +physically allocate a free inode chunk on disk, and another to allocate an inode +from an inode chunk that has free inodes in it. Hence for an inode allocation +transaction, we might set the reservation log count to a value of 2 to indicate +that the common/fast path transaction will commit two linked transactions in a +chain. Each time a permanent transaction rolls, it consumes an entire unit +reservation. + +Hence when the permanent transaction is first allocated, the log space +reservation is increases from a single unit reservation to multiple unit +reservations. That multiple is defined by the reservation log count, and this +means we can roll the transaction multiple times before we have to re-reserve +log space when we roll the transaction. This ensures that the common +modifications we make only need to reserve log space once. + +If the log count for a permanent transaction reaches zero, then it needs to +re-reserve physical space in the log. This is somewhat complex, and requires +an understanding of how the log accounts for space that has been reserved. + + +Log Space Accounting +==================== + +The position in the log is typically referred to as a Log Sequence Number (LSN). +The log is circular, so the positions in the log are defined by the combination +of a cycle number - the number of times the log has been overwritten - and the +offset into the log. A LSN carries the cycle in the upper 32 bits and the +offset in the lower 32 bits. The offset is in units of "basic blocks" (512 +bytes). Hence we can do realtively simple LSN based math to keep track of +available space in the log. + +Log space accounting is done via a pair of constructs called "grant heads". The +position of the grant heads is an absolute value, so the amount of space +available in the log is defined by the distance between the position of the +grant head and the current log tail. That is, how much space can be +reserved/consumed before the grant heads would fully wrap the log and overtake +the tail position. + +The first grant head is the "reserve" head. This tracks the byte count of the +reservations currently held by active transactions. It is a purely in-memory +accounting of the space reservation and, as such, actually tracks byte offsets +into the log rather than basic blocks. Hence it technically isn't using LSNs to +represent the log position, but it is still treated like a split {cycle,offset} +tuple for the purposes of tracking reservation space. + +The reserve grant head is used to accurately account for exact transaction +reservations amounts and the exact byte count that modifications actually make +and need to write into the log. The reserve head is used to prevent new +transactions from taking new reservations when the head reaches the current +tail. It will block new reservations in a FIFO queue and as the log tail moves +forward it will wake them in order once sufficient space is available. This FIFO +mechanism ensures no transaction is starved of resources when log space +shortages occur. + +The other grant head is the "write" head. Unlike the reserve head, this grant +head contains an LSN and it tracks the physical space usage in the log. While +this might sound like it is accounting the same state as the reserve grant head +- and it mostly does track exactly the same location as the reserve grant head - +there are critical differences in behaviour between them that provides the +forwards progress guarantees that rolling permanent transactions require. + +These differences when a permanent transaction is rolled and the internal "log +count" reaches zero and the initial set of unit reservations have been +exhausted. At this point, we still require a log space reservation to continue +the next transaction in the sequeunce, but we have none remaining. We cannot +sleep during the transaction commit process waiting for new log space to become +available, as we may end up on the end of the FIFO queue and the items we have +locked while we sleep could end up pinning the tail of the log before there is +enough free space in the log to fulfil all of the pending reservations and +then wake up transaction commit in progress. + +To take a new reservation without sleeping requires us to be able to take a +reservation even if there is no reservation space currently available. That is, +we need to be able to *overcommit* the log reservation space. As has already +been detailed, we cannot overcommit physical log space. However, the reserve +grant head does not track physical space - it only accounts for the amount of +reservations we currently have outstanding. Hence if the reserve head passes +over the tail of the log all it means is that new reservations will be throttled +immediately and remain throttled until the log tail is moved forward far enough +to remove the overcommit and start taking new reservations. In other words, we +can overcommit the reserve head without violating the physical log head and tail +rules. + +As a result, permanent transactions only "regrant" reservation space during +xfs_trans_commit() calls, while the physical log space reservation - tracked by +the write head - is then reserved separately by a call to xfs_log_reserve() +after the commit completes. Once the commit completes, we can sleep waiting for +physical log space to be reserved from the write grant head, but only if one +critical rule has been observed:: + + Code using permanent reservations must always log the items they hold + locked across each transaction they roll in the chain. + +"Re-logging" the locked items on every transaction roll ensures that the items +attached to the transaction chain being rolled are always relocated to the +physical head of the log and so do not pin the tail of the log. If a locked item +pins the tail of the log when we sleep on the write reservation, then we will +deadlock the log as we cannot take the locks needed to write back that item and +move the tail of the log forwards to free up write grant space. Re-logging the +locked items avoids this deadlock and guarantees that the log reservation we are +making cannot self-deadlock. + +If all rolling transactions obey this rule, then they can all make forwards +progress independently because nothing will block the progress of the log +tail moving forwards and hence ensuring that write grant space is always +(eventually) made available to permanent transactions no matter how many times +they roll. + + +Re-logging Explained +==================== + +XFS allows multiple separate modifications to a single object to be carried in +the log at any given time. This allows the log to avoid needing to flush each +change to disk before recording a new change to the object. XFS does this via a +method called "re-logging". Conceptually, this is quite simple - all it requires +is that any new change to the object is recorded with a *new copy* of all the +existing changes in the new transaction that is written to the log. That is, if we have a sequence of changes A through to F, and the object was written to disk after change D, we would see in the log the following series @@ -42,16 +327,13 @@ transaction:: In other words, each time an object is relogged, the new transaction contains the aggregation of all the previous changes currently held only in the log. -This relogging technique also allows objects to be moved forward in the log so -that an object being relogged does not prevent the tail of the log from ever -moving forward. This can be seen in the table above by the changing -(increasing) LSN of each subsequent transaction - the LSN is effectively a -direct encoding of the location in the log of the transaction. +This relogging technique allows objects to be moved forward in the log so that +an object being relogged does not prevent the tail of the log from ever moving +forward. This can be seen in the table above by the changing (increasing) LSN +of each subsequent transaction, and it's the technique that allows us to +implement long-running, multiple-commit permanent transactions. -This relogging is also used to implement long-running, multiple-commit -transactions. These transaction are known as rolling transactions, and require -a special log reservation known as a permanent transaction reservation. A -typical example of a rolling transaction is the removal of extents from an +A typical example of a rolling transaction is the removal of extents from an inode which can only be done at a rate of two extents per transaction because of reservation size limitations. Hence a rolling extent removal transaction keeps relogging the inode and btree buffers as they get modified in each @@ -67,12 +349,13 @@ the log over and over again. Worse is the fact that objects tend to get dirtier as they get relogged, so each subsequent transaction is writing more metadata into the log. -Another feature of the XFS transaction subsystem is that most transactions are -asynchronous. That is, they don't commit to disk until either a log buffer is -filled (a log buffer can hold multiple transactions) or a synchronous operation -forces the log buffers holding the transactions to disk. This means that XFS is -doing aggregation of transactions in memory - batching them, if you like - to -minimise the impact of the log IO on transaction throughput. +It should now also be obvious how relogging and asynchronous transactions go +hand in hand. That is, transactions don't get written to the physical journal +until either a log buffer is filled (a log buffer can hold multiple +transactions) or a synchronous operation forces the log buffers holding the +transactions to disk. This means that XFS is doing aggregation of transactions +in memory - batching them, if you like - to minimise the impact of the log IO on +transaction throughput. The limitation on asynchronous transaction throughput is the number and size of log buffers made available by the log manager. By default there are 8 log diff --git a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst index 8b2d8d0864c2..70442bc2521e 100644 --- a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst +++ b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst @@ -21,7 +21,9 @@ specific type) associated with it. In the ACPI _DSD context it is an element of the sub-package following the generic Device Properties UUID in the _DSD return package as specified in the -Device Properties UUID definition document [1]_. +section titled "Well-Known _DSD UUIDs and Data Structure Formats" sub-section +"Device Properties UUID" in _DSD (Device Specific Data) Implementation Guide +document [1]_. It also may be regarded as the definition of a key and the associated data type that can be returned by _DSD in the Device Properties UUID sub-package for a @@ -36,7 +38,9 @@ Property subsets are nested collections of properties. Each of them is associated with an additional key (name) allowing the subset to be referred to as a whole (and to be treated as a separate entity). The canonical representation of property subsets is via the mechanism specified in the -Hierarchical Properties Extension UUID definition document [2]_. +section titled "Well-Known _DSD UUIDs and Data Structure Formats" sub-section +"Hierarchical Data Extension UUID" in _DSD (Device Specific Data) +Implementation Guide document [1]_. Property sets may be hierarchical. That is, a property set may contain multiple property subsets that each may contain property subsets of its @@ -96,5 +100,4 @@ contents. References ========== -.. [1] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf -.. [2] https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf +.. [1] https://github.com/UEFI/DSD-Guide diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst index 55e2331a6438..d6b61d22f525 100644 --- a/Documentation/firmware-guide/acpi/apei/einj.rst +++ b/Documentation/firmware-guide/acpi/apei/einj.rst @@ -168,7 +168,7 @@ An error injection example:: 0x00000008 Memory Correctable 0x00000010 Memory Uncorrectable non-fatal # echo 0x12345000 > param1 # Set memory address for injection - # echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page + # echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page # echo 0x8 > error_type # Choose correctable memory error # echo 1 > error_inject # Inject now diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index db924d37f93e..326896e9800d 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -75,7 +75,7 @@ we have a dedicated glossary for Display Core at PSP Platform Security Processor - RCL + RLC RunList Controller SDMA diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst index 8aeb0186c9ef..997231b6adcf 100644 --- a/Documentation/gpu/amdgpu/thermal.rst +++ b/Documentation/gpu/amdgpu/thermal.rst @@ -63,3 +63,44 @@ gpu_metrics .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: gpu_metrics + +GFXOFF +====== + +GFXOFF is a feature found in most recent GPUs that saves power at runtime. The +card's RLC (RunList Controller) firmware powers off the gfx engine +dynamically when there is no workload on gfx or compute pipes. GFXOFF is on by +default on supported GPUs. + +Userspace can interact with GFXOFF through a debugfs interface: + +``amdgpu_gfxoff`` +----------------- + +Use it to enable/disable GFXOFF, and to check if it's current enabled/disabled:: + + $ xxd -l1 -p /sys/kernel/debug/dri/0/amdgpu_gfxoff + 01 + +- Write 0 to disable it, and 1 to enable it. +- Read 0 means it's disabled, 1 it's enabled. + +If it's enabled, that means that the GPU is free to enter into GFXOFF mode as +needed. Disabled means that it will never enter GFXOFF mode. + +``amdgpu_gfxoff_status`` +------------------------ + +Read it to check current GFXOFF's status of a GPU:: + + $ xxd -l1 -p /sys/kernel/debug/dri/0/amdgpu_gfxoff_status + 02 + +- 0: GPU is in GFXOFF state, the gfx engine is powered down. +- 1: Transition out of GFXOFF state +- 2: Not in GFXOFF state +- 3: Transition into GFXOFF state + +If GFXOFF is enabled, the value will be transitioning around [0, 3], always +getting into 0 when possible. When it's disabled, it's always at 2. Returns +``-EINVAL`` if it's not supported. diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 38afed24a75c..5fd20a306718 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -207,6 +207,38 @@ Utilities :internal: +Unit testing +============ + +KUnit +----- + +KUnit (Kernel unit testing framework) provides a common framework for unit tests +within the Linux kernel. + +This section covers the specifics for the DRM subsystem. For general information +about KUnit, please refer to Documentation/dev-tools/kunit/start.rst. + +How to run the tests? +~~~~~~~~~~~~~~~~~~~~~ + +In order to facilitate running the test suite, a configuration file is present +in ``drivers/gpu/drm/tests/.kunitconfig``. It can be used by ``kunit.py`` as +follows: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \ + --kconfig_add CONFIG_VIRTIO_UML=y \ + --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y + +.. note:: + The configuration included in ``.kunitconfig`` should be as generic as + possible. + ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not + included in it because they are only required for User Mode Linux. + + Legacy Support Code =================== diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 6c9f166a8d6f..92c5117368d7 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -105,6 +105,27 @@ object belong to this client, in the respective memory region. Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes. +- drm-cycles-<str> <uint> + +Engine identifier string must be the same as the one specified in the +drm-engine-<str> tag and shall contain the number of busy cycles for the given +engine. + +Values are not required to be constantly monotonic if it makes the driver +implementation easier, but are required to catch up with the previously reported +larger value within a reasonable period. Upon observing a value lower than what +was previously read, userspace is expected to stay with that larger previous +value until a monotonic update is seen. + +- drm-maxfreq-<str> <uint> [Hz|MHz|KHz] + +Engine identifier string must be the same as the one specified in the +drm-engine-<str> tag and shall contain the maximum frequency for the given +engine. Taken together with drm-cycles-<str>, this can be used to calculate +percentage utilization of the engine, whereas drm-engine-<str> only reflects +time active without considering what frequency the engine is operating as a +percentage of it's maximum frequency. + =============================== Driver specific implementations =============================== diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 54060cd6c419..4e59db1cfb00 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -246,6 +246,18 @@ Display State Buffer .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c :internal: +GT Programming +============== + +Multicast/Replicated (MCR) Registers +------------------------------------ + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c + :doc: GT Multicast/Replicated (MCR) Register Support + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c + :internal: + Memory Management and Command Submission ======================================== diff --git a/Documentation/gpu/rfc/i915_small_bar.h b/Documentation/gpu/rfc/i915_small_bar.h new file mode 100644 index 000000000000..6003c81d5aa4 --- /dev/null +++ b/Documentation/gpu/rfc/i915_small_bar.h @@ -0,0 +1,189 @@ +/** + * struct __drm_i915_memory_region_info - Describes one region as known to the + * driver. + * + * Note this is using both struct drm_i915_query_item and struct drm_i915_query. + * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS + * at &drm_i915_query_item.query_id. + */ +struct __drm_i915_memory_region_info { + /** @region: The class:instance pair encoding */ + struct drm_i915_gem_memory_class_instance region; + + /** @rsvd0: MBZ */ + __u32 rsvd0; + + /** + * @probed_size: Memory probed by the driver + * + * Note that it should not be possible to ever encounter a zero value + * here, also note that no current region type will ever return -1 here. + * Although for future region types, this might be a possibility. The + * same applies to the other size fields. + */ + __u64 probed_size; + + /** + * @unallocated_size: Estimate of memory remaining + * + * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting. + * Without this (or if this is an older kernel) the value here will + * always equal the @probed_size. Note this is only currently tracked + * for I915_MEMORY_CLASS_DEVICE regions (for other types the value here + * will always equal the @probed_size). + */ + __u64 unallocated_size; + + union { + /** @rsvd1: MBZ */ + __u64 rsvd1[8]; + struct { + /** + * @probed_cpu_visible_size: Memory probed by the driver + * that is CPU accessible. + * + * This will be always be <= @probed_size, and the + * remainder (if there is any) will not be CPU + * accessible. + * + * On systems without small BAR, the @probed_size will + * always equal the @probed_cpu_visible_size, since all + * of it will be CPU accessible. + * + * Note this is only tracked for + * I915_MEMORY_CLASS_DEVICE regions (for other types the + * value here will always equal the @probed_size). + * + * Note that if the value returned here is zero, then + * this must be an old kernel which lacks the relevant + * small-bar uAPI support (including + * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on + * such systems we should never actually end up with a + * small BAR configuration, assuming we are able to load + * the kernel module. Hence it should be safe to treat + * this the same as when @probed_cpu_visible_size == + * @probed_size. + */ + __u64 probed_cpu_visible_size; + + /** + * @unallocated_cpu_visible_size: Estimate of CPU + * visible memory remaining + * + * Note this is only tracked for + * I915_MEMORY_CLASS_DEVICE regions (for other types the + * value here will always equal the + * @probed_cpu_visible_size). + * + * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable + * accounting. Without this the value here will always + * equal the @probed_cpu_visible_size. Note this is only + * currently tracked for I915_MEMORY_CLASS_DEVICE + * regions (for other types the value here will also + * always equal the @probed_cpu_visible_size). + * + * If this is an older kernel the value here will be + * zero, see also @probed_cpu_visible_size. + */ + __u64 unallocated_cpu_visible_size; + }; + }; +}; + +/** + * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added + * extension support using struct i915_user_extension. + * + * Note that new buffer flags should be added here, at least for the stuff that + * is immutable. Previously we would have two ioctls, one to create the object + * with gem_create, and another to apply various parameters, however this + * creates some ambiguity for the params which are considered immutable. Also in + * general we're phasing out the various SET/GET ioctls. + */ +struct __drm_i915_gem_create_ext { + /** + * @size: Requested size for the object. + * + * The (page-aligned) allocated size for the object will be returned. + * + * Note that for some devices we have might have further minimum + * page-size restrictions (larger than 4K), like for device local-memory. + * However in general the final size here should always reflect any + * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS + * extension to place the object in device local-memory. The kernel will + * always select the largest minimum page-size for the set of possible + * placements as the value to use when rounding up the @size. + */ + __u64 size; + + /** + * @handle: Returned handle for the object. + * + * Object handles are nonzero. + */ + __u32 handle; + + /** + * @flags: Optional flags. + * + * Supported values: + * + * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that + * the object will need to be accessed via the CPU. + * + * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and only + * strictly required on configurations where some subset of the device + * memory is directly visible/mappable through the CPU (which we also + * call small BAR), like on some DG2+ systems. Note that this is quite + * undesirable, but due to various factors like the client CPU, BIOS etc + * it's something we can expect to see in the wild. See + * &__drm_i915_memory_region_info.probed_cpu_visible_size for how to + * determine if this system applies. + * + * Note that one of the placements MUST be I915_MEMORY_CLASS_SYSTEM, to + * ensure the kernel can always spill the allocation to system memory, + * if the object can't be allocated in the mappable part of + * I915_MEMORY_CLASS_DEVICE. + * + * Also note that since the kernel only supports flat-CCS on objects + * that can *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore + * don't support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with + * flat-CCS. + * + * Without this hint, the kernel will assume that non-mappable + * I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the + * kernel can still migrate the object to the mappable part, as a last + * resort, if userspace ever CPU faults this object, but this might be + * expensive, and so ideally should be avoided. + * + * On older kernels which lack the relevant small-bar uAPI support (see + * also &__drm_i915_memory_region_info.probed_cpu_visible_size), + * usage of the flag will result in an error, but it should NEVER be + * possible to end up with a small BAR configuration, assuming we can + * also successfully load the i915 kernel module. In such cases the + * entire I915_MEMORY_CLASS_DEVICE region will be CPU accessible, and as + * such there are zero restrictions on where the object can be placed. + */ +#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0) + __u32 flags; + + /** + * @extensions: The chain of extensions to apply to this object. + * + * This will be useful in the future when we need to support several + * different extensions, and we need to apply more than one when + * creating the object. See struct i915_user_extension. + * + * If we don't supply any extensions then we get the same old gem_create + * behaviour. + * + * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see + * struct drm_i915_gem_create_ext_memory_regions. + * + * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see + * struct drm_i915_gem_create_ext_protected_content. + */ +#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0 +#define I915_GEM_CREATE_EXT_PROTECTED_CONTENT 1 + __u64 extensions; +}; diff --git a/Documentation/gpu/rfc/i915_small_bar.rst b/Documentation/gpu/rfc/i915_small_bar.rst new file mode 100644 index 000000000000..d6c03ce3b862 --- /dev/null +++ b/Documentation/gpu/rfc/i915_small_bar.rst @@ -0,0 +1,47 @@ +========================== +I915 Small BAR RFC Section +========================== +Starting from DG2 we will have resizable BAR support for device local-memory(i.e +I915_MEMORY_CLASS_DEVICE), but in some cases the final BAR size might still be +smaller than the total probed_size. In such cases, only some subset of +I915_MEMORY_CLASS_DEVICE will be CPU accessible(for example the first 256M), +while the remainder is only accessible via the GPU. + +I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS flag +---------------------------------------------- +New gem_create_ext flag to tell the kernel that a BO will require CPU access. +This becomes important when placing an object in I915_MEMORY_CLASS_DEVICE, where +underneath the device has a small BAR, meaning only some portion of it is CPU +accessible. Without this flag the kernel will assume that CPU access is not +required, and prioritize using the non-CPU visible portion of +I915_MEMORY_CLASS_DEVICE. + +.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h + :functions: __drm_i915_gem_create_ext + +probed_cpu_visible_size attribute +--------------------------------- +New struct__drm_i915_memory_region attribute which returns the total size of the +CPU accessible portion, for the particular region. This should only be +applicable for I915_MEMORY_CLASS_DEVICE. We also report the +unallocated_cpu_visible_size, alongside the unallocated_size. + +Vulkan will need this as part of creating a separate VkMemoryHeap with the +VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set, to represent the CPU visible portion, +where the total size of the heap needs to be known. It also wants to be able to +give a rough estimate of how memory can potentially be allocated. + +.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h + :functions: __drm_i915_memory_region_info + +Error Capture restrictions +-------------------------- +With error capture we have two new restrictions: + + 1) Error capture is best effort on small BAR systems; if the pages are not + CPU accessible, at the time of capture, then the kernel is free to skip + trying to capture them. + + 2) On discrete and newer integrated platforms we now reject error capture + on recoverable contexts. In the future the kernel may want to blit during + error capture, when for example something is not currently CPU accessible. diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h new file mode 100644 index 000000000000..8a8fcd4fceac --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.h @@ -0,0 +1,291 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2022 Intel Corporation + */ + +/** + * DOC: I915_PARAM_VM_BIND_VERSION + * + * VM_BIND feature version supported. + * See typedef drm_i915_getparam_t param. + * + * Specifies the VM_BIND feature version supported. + * The following versions of VM_BIND have been defined: + * + * 0: No VM_BIND support. + * + * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created + * previously with VM_BIND, the ioctl will not support unbinding multiple + * mappings or splitting them. Similarly, VM_BIND calls will not replace + * any existing mappings. + * + * 2: The restrictions on unbinding partial or multiple mappings is + * lifted, Similarly, binding will replace any mappings in the given range. + * + * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind. + */ +#define I915_PARAM_VM_BIND_VERSION 57 + +/** + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND + * + * Flag to opt-in for VM_BIND mode of binding during VM creation. + * See struct drm_i915_gem_vm_control flags. + * + * The older execbuf2 ioctl will not support VM_BIND mode of operation. + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any + * execlist (See struct drm_i915_gem_execbuffer3 for more details). + */ +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0) + +/* VM_BIND related ioctls */ +#define DRM_I915_GEM_VM_BIND 0x3d +#define DRM_I915_GEM_VM_UNBIND 0x3e +#define DRM_I915_GEM_EXECBUFFER3 0x3f + +#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind) +#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind) +#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3) + +/** + * struct drm_i915_gem_timeline_fence - An input or output timeline fence. + * + * The operation will wait for input fence to signal. + * + * The returned output fence will be signaled after the completion of the + * operation. + */ +struct drm_i915_gem_timeline_fence { + /** @handle: User's handle for a drm_syncobj to wait on or signal. */ + __u32 handle; + + /** + * @flags: Supported flags are: + * + * I915_TIMELINE_FENCE_WAIT: + * Wait for the input fence before the operation. + * + * I915_TIMELINE_FENCE_SIGNAL: + * Return operation completion fence as output. + */ + __u32 flags; +#define I915_TIMELINE_FENCE_WAIT (1 << 0) +#define I915_TIMELINE_FENCE_SIGNAL (1 << 1) +#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL << 1)) + + /** + * @value: A point in the timeline. + * Value must be 0 for a binary drm_syncobj. A Value of 0 for a + * timeline drm_syncobj is invalid as it turns a drm_syncobj into a + * binary one. + */ + __u64 value; +}; + +/** + * struct drm_i915_gem_vm_bind - VA to object mapping to bind. + * + * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU + * virtual address (VA) range to the section of an object that should be bound + * in the device page table of the specified address space (VM). + * The VA range specified must be unique (ie., not currently bound) and can + * be mapped to whole object or a section of the object (partial binding). + * Multiple VA mappings can be created to the same section of the object + * (aliasing). + * + * The @start, @offset and @length must be 4K page aligned. However the DG2 + * and XEHPSDV has 64K page size for device local memory and has compact page + * table. On those platforms, for binding device local-memory objects, the + * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix + * the local memory 64K page and the system memory 4K page bindings in the same + * 2M range. + * + * Error code -EINVAL will be returned if @start, @offset and @length are not + * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code + * -ENOSPC will be returned if the VA range specified can't be reserved. + * + * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently + * are not ordered. Furthermore, parts of the VM_BIND operation can be done + * asynchronously, if valid @fence is specified. + */ +struct drm_i915_gem_vm_bind { + /** @vm_id: VM (address space) id to bind */ + __u32 vm_id; + + /** @handle: Object handle */ + __u32 handle; + + /** @start: Virtual Address start to bind */ + __u64 start; + + /** @offset: Offset in object to bind */ + __u64 offset; + + /** @length: Length of mapping to bind */ + __u64 length; + + /** + * @flags: Supported flags are: + * + * I915_GEM_VM_BIND_CAPTURE: + * Capture this mapping in the dump upon GPU error. + * + * Note that @fence carries its own flags. + */ + __u64 flags; +#define I915_GEM_VM_BIND_CAPTURE (1 << 0) + + /** + * @fence: Timeline fence for bind completion signaling. + * + * Timeline fence is of format struct drm_i915_gem_timeline_fence. + * + * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag + * is invalid, and an error will be returned. + * + * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence + * is not requested and binding is completed synchronously. + */ + struct drm_i915_gem_timeline_fence fence; + + /** + * @extensions: Zero-terminated chain of extensions. + * + * For future extensions. See struct i915_user_extension. + */ + __u64 extensions; +}; + +/** + * struct drm_i915_gem_vm_unbind - VA to object mapping to unbind. + * + * This structure is passed to VM_UNBIND ioctl and specifies the GPU virtual + * address (VA) range that should be unbound from the device page table of the + * specified address space (VM). VM_UNBIND will force unbind the specified + * range from device page table without waiting for any GPU job to complete. + * It is UMDs responsibility to ensure the mapping is no longer in use before + * calling VM_UNBIND. + * + * If the specified mapping is not found, the ioctl will simply return without + * any error. + * + * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently + * are not ordered. Furthermore, parts of the VM_UNBIND operation can be done + * asynchronously, if valid @fence is specified. + */ +struct drm_i915_gem_vm_unbind { + /** @vm_id: VM (address space) id to bind */ + __u32 vm_id; + + /** @rsvd: Reserved, MBZ */ + __u32 rsvd; + + /** @start: Virtual Address start to unbind */ + __u64 start; + + /** @length: Length of mapping to unbind */ + __u64 length; + + /** + * @flags: Currently reserved, MBZ. + * + * Note that @fence carries its own flags. + */ + __u64 flags; + + /** + * @fence: Timeline fence for unbind completion signaling. + * + * Timeline fence is of format struct drm_i915_gem_timeline_fence. + * + * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag + * is invalid, and an error will be returned. + * + * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence + * is not requested and unbinding is completed synchronously. + */ + struct drm_i915_gem_timeline_fence fence; + + /** + * @extensions: Zero-terminated chain of extensions. + * + * For future extensions. See struct i915_user_extension. + */ + __u64 extensions; +}; + +/** + * struct drm_i915_gem_execbuffer3 - Structure for DRM_I915_GEM_EXECBUFFER3 + * ioctl. + * + * DRM_I915_GEM_EXECBUFFER3 ioctl only works in VM_BIND mode and VM_BIND mode + * only works with this ioctl for submission. + * See I915_VM_CREATE_FLAGS_USE_VM_BIND. + */ +struct drm_i915_gem_execbuffer3 { + /** + * @ctx_id: Context id + * + * Only contexts with user engine map are allowed. + */ + __u32 ctx_id; + + /** + * @engine_idx: Engine index + * + * An index in the user engine map of the context specified by @ctx_id. + */ + __u32 engine_idx; + + /** + * @batch_address: Batch gpu virtual address/es. + * + * For normal submission, it is the gpu virtual address of the batch + * buffer. For parallel submission, it is a pointer to an array of + * batch buffer gpu virtual addresses with array size equal to the + * number of (parallel) engines involved in that submission (See + * struct i915_context_engines_parallel_submit). + */ + __u64 batch_address; + + /** @flags: Currently reserved, MBZ */ + __u64 flags; + + /** @rsvd1: Reserved, MBZ */ + __u32 rsvd1; + + /** @fence_count: Number of fences in @timeline_fences array. */ + __u32 fence_count; + + /** + * @timeline_fences: Pointer to an array of timeline fences. + * + * Timeline fences are of format struct drm_i915_gem_timeline_fence. + */ + __u64 timeline_fences; + + /** @rsvd2: Reserved, MBZ */ + __u64 rsvd2; + + /** + * @extensions: Zero-terminated chain of extensions. + * + * For future extensions. See struct i915_user_extension. + */ + __u64 extensions; +}; + +/** + * struct drm_i915_gem_create_ext_vm_private - Extension to make the object + * private to the specified VM. + * + * See struct drm_i915_gem_create_ext. + */ +struct drm_i915_gem_create_ext_vm_private { +#define I915_GEM_CREATE_EXT_VM_PRIVATE 2 + /** @base: Extension link. See struct i915_user_extension. */ + struct i915_user_extension base; + + /** @vm_id: Id of the VM to which the object is private */ + __u32 vm_id; +}; diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index 000000000000..9a1dcdf2799e --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,245 @@ +========================================== +I915 VM_BIND feature design and use cases +========================================== + +VM_BIND feature +================ +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuf calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuf mode). + +The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for +signaling the completion of bind/unbind operation. + +VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are +not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done +asynchronously, when valid out fence is specified. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* Support for userptr gem objects (no special uapi is required for this). + +TLB flush consideration +------------------------ +The i915 driver flushes the TLB for each submission and when an object's +pages are released. The VM_BIND/UNBIND operation will not do any additional +TLB flush. Any VM_BIND mapping added will be in the working set for subsequent +submissions on that VM and will not be in the working set for currently running +batches (which would require additional TLB flushes, which is not supported). + +Execbuf ioctl in VM_BIND mode +------------------------------- +A VM in VM_BIND mode will not support older execbuf mode of binding. +The execbuf ioctl handling in VM_BIND mode differs significantly from the +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any +execlist. Hence, no support for implicit sync. It is expected that the below +work will be able to support requirements of object dependency setting in all +use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) + +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through +VM_BIND call) at the time of execbuf3 call are deemed required for that +submission. + +The execbuf3 ioctl directly specifies the batch addresses instead of as +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not +support many of the older features like in/out/submit fences, fence array, +default gem context and many more (See struct drm_i915_gem_execbuffer3). + +In VM_BIND mode, VA allocation is completely managed by the user instead of +the i915 driver. Hence all VA assignment, eviction are not applicable in +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not +be using the i915_vma active reference tracking. It will instead use dma-resv +object for that (See `VM_BIND dma_resv usage`_). + +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA +evictions, vma lookup table, implicit sync, vma active reference tracking etc., +are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling +should be in a separate file and only functionalities common to these ioctls +can be the shared code where possible. + +VM_PRIVATE objects +------------------- +By default, BOs can be mapped on multiple VMs and can also be dma-buf +exported. Hence these BOs are referred to as Shared BOs. +During each execbuf submission, the request fence must be added to the +dma-resv fence list of all shared BOs mapped on the VM. + +VM_BIND feature introduces an optimization where user can create BO which +is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during +BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on +the VM they are private to and can't be dma-buf exported. +All private BOs of a VM share the dma-resv object. Hence during each execbuf +submission, they need only one dma-resv fence list updated. Thus, the fast +path (where required mappings are already bound) submission latency is O(1) +w.r.t the number of VM private BOs. + +VM_BIND locking hirarchy +------------------------- +The locking design here supports the older (execlist based) execbuf mode, the +newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future +system allocator support (See `Shared Virtual Memory (SVM) support`_). +The older execbuf mode and the newer VM_BIND mode without page faults manages +residency of backing storage using dma_fence. The VM_BIND mode with page faults +and the system allocator support do not use any dma_fence at all. + +VM_BIND locking order is as below. + +1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in + vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the + mapping. + + In future, when GPU page faults are supported, we can potentially use a + rwsem instead, so that multiple page fault handlers can take the read side + lock to lookup the mapping and hence can run in parallel. + The older execbuf mode of binding do not need this lock. + +2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to + be held while binding/unbinding a vma in the async worker and while updating + dma-resv fence list of an object. Note that private BOs of a VM will all + share a dma-resv object. + + The future system allocator support will use the HMM prescribed locking + instead. + +3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of + invalidated vmas (due to eviction and userptr invalidation) etc. + +When GPU page faults are supported, the execbuf path do not take any of these +locks. There we will simply smash the new batch buffer address into the ring and +then tell the scheduler run that. The lock taking only happens from the page +fault handler, where we take lock-A in read mode, whichever lock-B we need to +find the backing storage (dma_resv lock for gem objects, and hmm/core mm for +system allocator) and some additional locks (lock-D) for taking care of page +table races. Page fault mode should not need to ever manipulate the vm lists, +so won't ever need lock-C. + +VM_BIND LRU handling +--------------------- +We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid +performance degradation. We will also need support for bulk LRU movement of +VM_BIND objects to avoid additional latencies in execbuf path. + +The page table pages are similar to VM_BIND mapped objects (See +`Evictable page table allocations`_) and are maintained per VM and needs to +be pinned in memory when VM is made active (ie., upon an execbuf call with +that VM). So, bulk LRU movement of page table pages is also needed. + +VM_BIND dma_resv usage +----------------------- +Fences needs to be added to all VM_BIND mapped objects. During each execbuf +submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent +over sync (See enum dma_resv_usage). One can override it with either +DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object +dependency setting. + +Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for +DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch +check. Instead, the execbuf3 out fence should be used for end of batch check +(See struct drm_i915_gem_execbuffer3). + +Also, in VM_BIND mode, use dma-resv apis for determining object activeness +(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the +older i915_vma active reference tracking which is deprecated. This should be +easier to get it working with the current TTM backend. + +Mesa use case +-------------- +VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris), +hence improving performance of CPU-bound applications. It also allows us to +implement Vulkan's Sparse Resources. With increasing GPU hardware performance, +reducing CPU overhead becomes more impactful. + + +Other VM_BIND use cases +======================== + +Long running Compute contexts +------------------------------ +Usage of dma-fence expects that they complete in reasonable amount of time. +Compute on the other hand can be long running. Hence it is appropriate for +compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage +must be limited to in-kernel consumption only. + +Where GPU page faults are not available, kernel driver upon buffer invalidation +will initiate a suspend (preemption) of long running context, finish the +invalidation, revalidate the BO and then resume the compute context. This is +done by having a per-context preempt fence which is enabled when someone tries +to wait on it and triggers the context preemption. + +User/Memory Fence +~~~~~~~~~~~~~~~~~~ +User/Memory fence is a <address, value> pair. To signal the user fence, the +specified value will be written at the specified virtual address and wakeup the +waiting process. User fence can be signaled either by the GPU or kernel async +worker (like upon bind completion). User can wait on a user fence with a new +user fence wait ioctl. + +Here is some prior work on this: +https://patchwork.freedesktop.org/patch/349417/ + +Low Latency Submission +~~~~~~~~~~~~~~~~~~~~~~~ +Allows compute UMD to directly submit GPU jobs instead of through execbuf +ioctl. This is made possible by VM_BIND is not being synchronized against +execbuf. VM_BIND allows bind/unbind of mappings required for the directly +submitted jobs. + +Debugger +--------- +With debug event interface user space process (debugger) is able to keep track +of and act upon resources created by another process (debugged) and attached +to GPU via vm_bind interface. + +GPU page faults +---------------- +GPU page faults when supported (in future), will only be supported in the +VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of +binding will require using dma-fence to ensure residency, the GPU page faults +mode when supported, will not use any dma-fence as residency is purely managed +by installing and removing/invalidating page table entries. + +Page level hints settings +-------------------------- +VM_BIND allows any hints setting per mapping instead of per BO. Possible hints +include placement and atomicity. Sub-BO level placement hint will be even more +relevant with upcoming GPU on-demand page fault support. + +Page level Cache/CLOS settings +------------------------------- +VM_BIND allows cache/CLOS settings per mapping instead of per BO. + +Evictable page table allocations +--------------------------------- +Make pagetable allocations evictable and manage them similar to VM_BIND +mapped objects. Page table pages are similar to persistent mappings of a +VM (difference here are that the page table pages will not have an i915_vma +structure and after swapping pages back in, parent page link needs to be +updated). + +Shared Virtual Memory (SVM) support +------------------------------------ +VM_BIND interface can be used to map system memory directly (without gem BO +abstraction) using the HMM interface. SVM is only supported with GPU page +faults enabled. + +VM_BIND UAPI +============= + +.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 91e93a705230..476719771eef 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -23,3 +23,11 @@ host such documentation: .. toctree:: i915_scheduler.rst + +.. toctree:: + + i915_small_bar.rst + +.. toctree:: + + i915_vm_bind.rst diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 10bfb50908d1..513b20ccef1e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -617,6 +617,17 @@ Contact: Javier Martinez Canillas <javierm@redhat.com> Level: Intermediate +Convert Kernel Selftests (kselftest) to KUnit tests when appropriate +-------------------------------------------------------------------- + +Many of the `Kselftest <https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html>`_ +tests in DRM could be converted to Kunit tests instead, since that framework +is more suitable for unit testing. + +Contact: Javier Martinez Canillas <javierm@redhat.com> + +Level: Starter + Enable trinity for DRM ---------------------- diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 9c873c3912cc..973e2d43108b 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -102,12 +102,6 @@ Debugging: - kms_plane: some test cases are failing due to timeout on capturing CRC; -- kms_flip: when running test cases in sequence, some successful individual - test cases are failing randomly; when individually, some successful test - cases display in the log the following error:: - - [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4 - Virtual hardware (vblank-less) mode: - VKMS already has support for vblanks simulated via hrtimers, which can be diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst index 717e28226cde..33649a1e3a05 100644 --- a/Documentation/hwmon/aquacomputer_d5next.rst +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -9,6 +9,7 @@ Supported devices: * Aquacomputer Farbwerk RGB controller * Aquacomputer Farbwerk 360 RGB controller * Aquacomputer Octo fan controller +* Aquacomputer Quadro fan controller Author: Aleksa Savic @@ -33,6 +34,9 @@ better suited for userspace tools. The Octo exposes four temperature sensors and eight PWM controllable fans, along with their speed (in RPM), power, voltage and current. +The Quadro exposes four temperature sensors, a flow sensor and four PWM controllable +fans, along with their speed (in RPM), power, voltage and current. + The Farbwerk and Farbwerk 360 expose four temperature sensors. Depending on the device, not all sysfs and debugfs entries will be available. @@ -45,13 +49,14 @@ the kernel and supports hotswapping. Sysfs entries ------------- -================ ============================================= +================ ============================================== temp[1-4]_input Temperature sensors (in millidegrees Celsius) -fan[1-2]_input Pump/fan speed (in RPM) -power[1-2]_input Pump/fan power (in micro Watts) -in[0-2]_input Pump/fan voltage (in milli Volts) -curr[1-2]_input Pump/fan current (in milli Amperes) -================ ============================================= +fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h) +power[1-8]_input Pump/fan power (in micro Watts) +in[0-7]_input Pump/fan voltage (in milli Volts) +curr[1-8]_input Pump/fan current (in milli Amperes) +pwm[1-8] Fan PWM (0 - 255) +================ ============================================== Debugfs entries --------------- diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index 78ca69eda877..02f4ad314a1e 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -13,12 +13,16 @@ Supported boards: * ROG CROSSHAIR VIII FORMULA * ROG CROSSHAIR VIII HERO * ROG CROSSHAIR VIII IMPACT + * ROG MAXIMUS XI HERO + * ROG MAXIMUS XI HERO (WI-FI) * ROG STRIX B550-E GAMING * ROG STRIX B550-I GAMING * ROG STRIX X570-E GAMING * ROG STRIX X570-E GAMING WIFI II * ROG STRIX X570-F GAMING * ROG STRIX X570-I GAMING + * ROG STRIX Z690-A GAMING WIFI D4 + * ROG ZENITH II EXTREME Authors: - Eugene Shalygin <eugene.shalygin@gmail.com> diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index e5d85e40972c..d8f1d6859b96 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -46,6 +46,9 @@ temp[1-10]_input RO Temperature reading in milli-degrees temp[1-10]_label RO Temperature sensor label. =============================== ======= ======================================= +Due to the nature of the SMM interface, each pwmX attribute controls +fan number X. + Disabling automatic BIOS fan control ------------------------------------ diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index a72c16872ec2..f7113b0f8b2a 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -109,6 +109,7 @@ Hardware Monitoring Kernel Drivers lm95234 lm95245 lochnagar + lt7182s ltc2992 ltc2945 ltc2947 diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 05391fb4042d..23af17a0ab44 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -3,6 +3,14 @@ Kernel driver lm90 Supported chips: + * National Semiconductor LM84 + + Prefix: 'lm84' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the National Semiconductor website + * National Semiconductor LM90 Prefix: 'lm90' @@ -43,6 +51,30 @@ Supported chips: http://www.national.com/mpf/LM/LM86.html + * Analog Devices ADM1020 + + Prefix: 'adm1020' + + Addresses scanned: I2C 0x4c - 0x4e + + Datasheet: Publicly available at the Analog Devices website + + * Analog Devices ADM1021 + + Prefix: 'adm1021' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the Analog Devices website + + * Analog Devices ADM1021A/ADM1023 + + Prefix: 'adm1023' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the Analog Devices website + * Analog Devices ADM1032 Prefix: 'adm1032' @@ -73,6 +105,36 @@ Supported chips: https://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A + * Analog Devices ADT7481 + + Prefix: 'adt7481' + + Addresses scanned: I2C 0x4b and 0x4c + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7481 + + * Analog Devices ADT7482 + + Prefix: 'adt7482' + + Addresses scanned: I2C 0x4c + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7482 + + * Analog Devices ADT7483A + + Prefix: 'adt7483a' + + Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b, 0x4c, 0x4d, 0x4e + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7483A + * ON Semiconductor NCT1008 Prefix: 'nct1008' @@ -83,6 +145,72 @@ Supported chips: https://www.onsemi.com/PowerSolutions/product.do?id=NCT1008 + * ON Semiconductor NCT210 + + Prefix: 'adm1021' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=NCT210 + + * ON Semiconductor NCT214 + + Prefix: 'nct214' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=NCT214 + + * ON Semiconductor NCT218 + + Prefix: 'nct218' + + Addresses scanned: I2C 0x4c - 0x4d + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=NCT218 + + * ON Semiconductor NCT72 + + Prefix: 'nct72' + + Addresses scanned: I2C 0x4c - 0x4d + + Datasheet: Publicly available at the ON Semiconductor website + + https://www.onsemi.com/PowerSolutions/product.do?id=NCT72 + + * Maxim MAX1617 + + Prefix: 'max1617' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the Maxim website + + * Maxim MAX1617A + + Prefix: 'max1617a' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the Maxim website + + * Maxim MAX6642 + + Prefix: 'max6642' + + Addresses scanned: I2C 0x48-0x4f + + Datasheet: Publicly available at the Maxim website + + http://datasheets.maxim-ic.com/en/ds/MAX6642.pdf + * Maxim MAX6646 Prefix: 'max6646' @@ -105,7 +233,7 @@ Supported chips: * Maxim MAX6648 - Prefix: 'max6646' + Prefix: 'max6648' Addresses scanned: I2C 0x4c @@ -191,7 +319,7 @@ Supported chips: * Maxim MAX6692 - Prefix: 'max6646' + Prefix: 'max6648' Addresses scanned: I2C 0x4c @@ -275,6 +403,46 @@ Supported chips: https://www.ti.com/lit/gpn/tmp461 + * Philips NE1617, NE1617A + + Prefix: 'max1617' (probably detected as a max1617) + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheets: Publicly available at the Philips website + + * Philips NE1618 + + Prefix: 'ne1618' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheets: Publicly available at the Philips website + + * Genesys Logic GL523SM + + Prefix: 'gl523sm' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: + + * TI THMC10 + + Prefix: 'thmc10' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the TI website + + * Onsemi MC1066 + + Prefix: 'mc1066' + + Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e + + Datasheet: Publicly available at the Onsemi website + Author: Jean Delvare <jdelvare@suse.de> @@ -285,6 +453,12 @@ The LM90 is a digital temperature sensor. It senses its own temperature as well as the temperature of up to one external diode. It is compatible with many other devices, many of which are supported by this driver. +The family of chips supported by this driver is derived from MAX1617. +This chip as well as various compatible chips support a local and a remote +temperature sensor with 8 bit accuracy. Later chips provide improved accuracy +and other additional features such as hysteresis and temperature offset +registers. + Note that there is no easy way to differentiate between the MAX6657, MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only supported by this driver if the chip is located at address 0x4d or 0x4e, @@ -292,15 +466,31 @@ or if the chip type is explicitly selected as max6659. The MAX6680 and MAX6681 only differ in their pinout, therefore they obviously can't (and don't need to) be distinguished. -The specificity of this family of chipsets over the ADM1021/LM84 -family is that it features critical limits with hysteresis, and an -increased resolution of the remote temperature measurement. - The different chipsets of the family are not strictly identical, although very similar. For reference, here comes a non-exhaustive list of specific features: +LM84: + * 8 bit sensor resolution + +ADM1020, ADM1021, GL523SM, MAX1617, NE1617, NE1617A, THMC10: + * 8 bit sensor resolution + * Low temperature limits + +NCT210, NE1618: + * 11 bit sensor resolution for remote temperature sensor + * Low temperature limits + +ADM1021A, ADM1023: + * Temperature offset register for remote temperature sensor + * 11 bit resolution for remote temperature sensor + * Low temperature limits + LM90: + * 11 bit resolution for remote temperature sensor + * Temperature offset register for remote temperature sensor + * Low and critical temperature limits + * Configurable conversion rate * Filter and alert configuration register at 0xBF. * ALERT is triggered by temperatures over critical limits. @@ -322,8 +512,31 @@ ADM1032: ADT7461, ADT7461A, NCT1008: * Extended temperature range (breaks compatibility) * Lower resolution for remote temperature + * SMBus PEC support for Write Byte and Receive Byte transactions. + * 10 bit temperature resolution + +ADT7481, ADT7482, ADT7483: + * Temperature offset register + * SMBus PEC support + * 10 bit temperature resolution for external sensors + * Two remote sensors + * Selectable address (ADT7483) + +MAX6642: + * No critical limit register + * Conversion rate not configurable + * Better local resolution (10 bit) + * 10 bit external sensor resolution + +MAX6646, MAX6647, MAX6649: + * Better local resolution + * Extended range unsigned external temperature + +MAX6648, MAX6692: + * Better local resolution + * Unsigned temperature -MAX6654: +MAX6654, MAX6690: * Better local resolution * Selectable address * Remote sensor type selection @@ -423,6 +636,6 @@ two transactions will typically mean twice as much delay waiting for transaction completion, effectively doubling the register cache refresh time. I guess reliability comes at a price, but it's quite expensive this time. -So, as not everyone might enjoy the slowdown, PEC can be disabled through -sysfs. Just write 0 to the "pec" file and PEC will be disabled. Write 1 -to that file to enable PEC again. +So, as not everyone might enjoy the slowdown, PEC is disabled by default and +can be enabled through sysfs. Just write 1 to the "pec" file and PEC will be +enabled. Write 0 to that file to disable PEC again. diff --git a/Documentation/hwmon/lt7182s.rst b/Documentation/hwmon/lt7182s.rst new file mode 100644 index 000000000000..f7268311b191 --- /dev/null +++ b/Documentation/hwmon/lt7182s.rst @@ -0,0 +1,92 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver lt7182s +===================== + +Supported chips: + + * ADI LT7182S + + Prefix: 'lt7182s' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt7182s.html + +Author: Guenter Roeck <linux@roeck-us.net> + + +Description +----------- + +LT7182S is a Dual Channel 6A, 20V PolyPhase Step-Down Silent Switcher with +Digital Power System Management support. + + +Usage Notes +----------- + +This driver does not probe for PMBus devices. You will have to instantiate +devices explicitly. + +Example: the following commands will load the driver for a LT7182S +at address 0x4f on I2C bus #4:: + + # modprobe lt7182s + # echo lt7182s 0x4f > /sys/bus/i2c/devices/i2c-4/new_device + +It can also be instantiated by declaring an entry in device tree. + + +Sysfs attributes +---------------- + +======================= ==================================== +curr[1-2]_label "iin[12]" +curr[1-2]_input Measured input current +curr[1-2]_max Maximum input current +curr[1-2]_max_alarm Current high alarm + +curr[3-4]_label "iout[1-2]" +curr[3-4]_input Measured output current +curr[3-4]_highest Highest measured output current +curr[3-4]_max Maximum output current +curr[3-4]_max_alarm Output current high alarm + +in[1-2]_label "vin[12]" +in[1-2]_input Measured input voltage +in[1-2]_highest Highest measured input voltage +in[1-2]_crit Critical maximum input voltage +in[1-2]_crit_alarm Input voltage critical high alarm +in[1-2]_min Minimum input voltage +in[1-2]_min_alarm Input voltage low alarm +in[1-2]_rated_min Rated minimum input voltage +in[1-2]_rated_max Rated maximum input voltage +in1_reset_history Write to reset history for all attributes + +in[3-5]_label "vmon[1-3]" +in[3-5]_input Measured voltage on ITH1/ITH2/EXTVCC pins + Only available if enabled with MFR_ADC_CONTROL_LT7182S + command. + +in[3-4|6-7]_label "vout[1-2]" +in[3-4|6-7]_input Measured output voltage +in[3-4|6-7]_highest Highest measured output voltage +in[3-4|6-7]_lcrit Critical minimum output voltage +in[3-4|6-7]_lcrit_alarm Output voltage critical low alarm +in[3-4|6-7]_min Minimum output voltage +in[3-4|6-7]_max_alarm Output voltage low alarm +in[3-4|6-7]_max Maximum output voltage +in[3-4|6-7]_max_alarm Output voltage high alarm +in[3-4|6-7]_crit Critical maximum output voltage +in[3-4|6-7]_crit_alarm Output voltage critical high alarm + +power[1-2]_label "pout[1-2]" +power[1-2]_input Measured output power + +temp1_input Measured temperature +temp1_crit Critical high temperature +temp1_crit_alarm Chip temperature critical high alarm +temp1_max Maximum temperature +temp1_max_alarm Chip temperature high alarm +======================= ==================================== diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst index e7e0c9ef10be..84c5a4e40c40 100644 --- a/Documentation/hwmon/pmbus-core.rst +++ b/Documentation/hwmon/pmbus-core.rst @@ -121,6 +121,15 @@ Specifically, it provides the following information. non-standard PMBus commands to standard commands, or to augment standard command return values with device specific information. +PEC Support +=========== + +Many PMBus devices support SMBus PEC (Packet Error Checking). If supported +by both the I2C adapter and by the PMBus chip, it is by default enabled. +If PEC is supported, the PMBus core driver adds an attribute named 'pec' to +the I2C device. This attribute can be used to control PEC support in the +communication with the PMBus chip. + API functions ============= diff --git a/Documentation/hwmon/submitting-patches.rst b/Documentation/hwmon/submitting-patches.rst index 9a218ea996d8..d953ee763c96 100644 --- a/Documentation/hwmon/submitting-patches.rst +++ b/Documentation/hwmon/submitting-patches.rst @@ -12,7 +12,6 @@ increase the chances of your change being accepted. * It should be unnecessary to mention, but please read and follow: - Documentation/process/submit-checklist.rst - - Documentation/process/submitting-drivers.rst - Documentation/process/submitting-patches.rst - Documentation/process/coding-style.rst diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst index cad59170b2ad..ab9e850e8fe0 100644 --- a/Documentation/i2c/busses/i2c-i801.rst +++ b/Documentation/i2c/busses/i2c-i801.rst @@ -46,6 +46,7 @@ Supported adapters: * Intel Emmitsburg (PCH) * Intel Alder Lake (PCH) * Intel Raptor Lake (PCH) + * Intel Meteor Lake (SOC) Datasheets: Publicly available at the Intel website diff --git a/Documentation/i2c/i2c-protocol.rst b/Documentation/i2c/i2c-protocol.rst index b2092f8f815d..df0febfe6410 100644 --- a/Documentation/i2c/i2c-protocol.rst +++ b/Documentation/i2c/i2c-protocol.rst @@ -2,7 +2,8 @@ The I2C Protocol ================ -This document describes the I2C protocol. Or will, when it is finished :-) +This document is an overview of the basic I2C transactions and the kernel +APIs to perform them. Key to symbols ============== @@ -12,13 +13,9 @@ S Start condition P Stop condition Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0. A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit -Addr (7 bits) I2C 7 bit address. Note that this can be expanded as usual to +Addr (7 bits) I2C 7 bit address. Note that this can be expanded to get a 10 bit I2C address. -Comm (8 bits) Command byte, a data byte which often selects a register on - the device. -Data (8 bits) A plain data byte. Sometimes, I write DataLow, DataHigh - for 16 bit data. -Count (8 bits) A data byte containing the length of a block operation. +Data (8 bits) A plain data byte. [..] Data sent by I2C device, as opposed to data sent by the host adapter. diff --git a/Documentation/i2c/i2c-sysfs.rst b/Documentation/i2c/i2c-sysfs.rst index 6b68b95cd427..78c54c658fa1 100644 --- a/Documentation/i2c/i2c-sysfs.rst +++ b/Documentation/i2c/i2c-sysfs.rst @@ -51,11 +51,10 @@ Google Pixel 3 phone for example:: ``i2c-2`` is an I2C bus whose number is 2, and ``2-0049`` is an I2C device on bus 2 address 0x49 bound with a kernel driver. -Terminologies -============= +Terminology +=========== -First, let us define a couple of terminologies to avoid confusions in the later -sections. +First, let us define some terms to avoid confusion in later sections. (Physical) I2C Bus Controller ----------------------------- @@ -100,9 +99,7 @@ Caveat This may be a confusing part for people who only know about the physical I2C design of a board. It is actually possible to rename the I2C bus physical number to a different number in logical I2C bus level in Device Tree Source (DTS) under -section ``aliases``. See -`arch/arm/boot/dts/nuvoton-npcm730-gsj.dts -<../../arch/arm/boot/dts/nuvoton-npcm730-gsj.dts>`_ +section ``aliases``. See ``arch/arm/boot/dts/nuvoton-npcm730-gsj.dts`` for an example of DTS file. Best Practice: **(To kernel software developers)** It is better to keep the I2C @@ -117,7 +114,7 @@ Walk through Logical I2C Bus For the following content, we will use a more complex I2C topology as an example. Here is a brief graph for the I2C topology. If you do not understand -this graph at the first glance, do not be afraid to continue reading this doc +this graph at first glance, do not be afraid to continue reading this doc and review it when you finish reading. :: @@ -290,8 +287,7 @@ MUX channel 0, and all the way to ``i2c-19`` for the MUX channel 3. The kernel software developer is able to pin the fanout MUX channels to a static logical I2C bus number in the DTS. This doc will not go through the details on how to implement this in DTS, but we can see an example in: -`arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts -<../../arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts>`_ +``arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts`` In the above example, there is an 8-channel I2C MUX at address 0x70 on physical I2C bus 2. The channel 2 of the MUX is defined as ``imux18`` in DTS, @@ -383,13 +379,9 @@ Sysfs for the I2C sensor device:: For more info on the Hwmon Sysfs, refer to the doc: -`Naming and data format standards for sysfs files -<../hwmon/sysfs-interface.rst>`_ +../hwmon/sysfs-interface.rst Instantiate I2C Devices in I2C Sysfs ------------------------------------ -Refer to the doc: - -`How to instantiate I2C devices, Method 4: Instantiate from user-space -<instantiating-devices.rst#method-4-instantiate-from-user-space>`_ +Refer to section "Method 4: Instantiate from user-space" of instantiating-devices.rst diff --git a/Documentation/i2c/instantiating-devices.rst b/Documentation/i2c/instantiating-devices.rst index 890c9360ce19..3ea056a95812 100644 --- a/Documentation/i2c/instantiating-devices.rst +++ b/Documentation/i2c/instantiating-devices.rst @@ -31,7 +31,9 @@ Declare the I2C devices via devicetree On platforms using devicetree, the declaration of I2C devices is done in subnodes of the master controller. -Example:: +Example: + +.. code-block:: dts i2c1: i2c@400a0000 { /* ... master properties skipped ... */ @@ -71,7 +73,9 @@ code. Instantiating I2C devices via board files is done with an array of struct i2c_board_info which is registered by calling i2c_register_board_info(). -Example (from omap2 h4):: +Example (from omap2 h4): + +.. code-block:: c static struct i2c_board_info h4_i2c_board_info[] __initdata = { { @@ -111,7 +115,9 @@ bus in advance, so the method 1 described above can't be used. Instead, you can instantiate your I2C devices explicitly. This is done by filling a struct i2c_board_info and calling i2c_new_client_device(). -Example (from the sfe4001 network driver):: +Example (from the sfe4001 network driver): + +.. code-block:: c static struct i2c_board_info sfe4001_hwmon_info = { I2C_BOARD_INFO("max6647", 0x4e), @@ -136,7 +142,9 @@ it may have different addresses from one board to the next (manufacturer changing its design without notice). In this case, you can call i2c_new_scanned_device() instead of i2c_new_client_device(). -Example (from the nxp OHCI driver):: +Example (from the nxp OHCI driver): + +.. code-block:: c static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END }; diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 00d8e17d0aca..4942c4cad4ad 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -41,12 +41,12 @@ Sr Repeated start condition, used to switch from write to P Stop condition Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0. A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit -Addr (7 bits) I2C 7 bit address. Note that this can be expanded as usual to +Addr (7 bits) I2C 7 bit address. Note that this can be expanded to get a 10 bit I2C address. Comm (8 bits) Command byte, a data byte which often selects a register on the device. -Data (8 bits) A plain data byte. Sometimes, I write DataLow, DataHigh - for 16 bit data. +Data (8 bits) A plain data byte. DataLow and DataHigh represent the low and + high byte of a 16 bit word. Count (8 bits) A data byte containing the length of a block operation. [..] Data sent by I2C device, as opposed to data sent by the host diff --git a/Documentation/index.rst b/Documentation/index.rst index 67036a05b771..4737c18c97ff 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -128,7 +128,7 @@ needed). sound/index crypto/index filesystems/index - vm/index + mm/index bpf/index usb/index PCI/index diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index a7173843a294..858ed5d80def 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -525,8 +525,8 @@ followed by a test macro:: If you need to expose a compiler capability to makefiles and/or C source files, `CC_HAS_` is the recommended prefix for the config option:: - config CC_HAS_ASM_GOTO - def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC)) + config CC_HAS_FOO + def_bool $(success,$(srctree)/scripts/cc-check-foo.sh $(CC)) Build as module only ~~~~~~~~~~~~~~~~~~~~ @@ -672,7 +672,7 @@ Future kconfig work Work on kconfig is welcomed on both areas of clarifying semantics and on evaluating the use of a full SAT solver for it. A full SAT solver can be desirable to enable more complex dependency mappings and / or queries, -for instance on possible use case for a SAT solver could be that of handling +for instance one possible use case for a SAT solver could be that of handling the current known recursive dependency issues. It is not known if this would address such issues but such evaluation is desirable. If support for a full SAT solver proves too complex or that it cannot address recursive dependency issues diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst index ebd9d90882ea..9a1f020c8449 100644 --- a/Documentation/kernel-hacking/hacking.rst +++ b/Documentation/kernel-hacking/hacking.rst @@ -755,8 +755,7 @@ make a neat patch, there's administrative work to be done: it implies a more-than-passing commitment to some part of the code. - Finally, don't forget to read - ``Documentation/process/submitting-patches.rst`` and possibly - ``Documentation/process/submitting-drivers.rst``. + ``Documentation/process/submitting-patches.rst`` Kernel Cantrips =============== diff --git a/Documentation/livepatch/module-elf-format.rst b/Documentation/livepatch/module-elf-format.rst index dbe9b400e39f..7347638895a0 100644 --- a/Documentation/livepatch/module-elf-format.rst +++ b/Documentation/livepatch/module-elf-format.rst @@ -210,11 +210,11 @@ module->symtab. ===================================== Normally, a stripped down copy of a module's symbol table (containing only "core" symbols) is made available through module->symtab (See layout_symtab() -in kernel/module.c). For livepatch modules, the symbol table copied into memory -on module load must be exactly the same as the symbol table produced when the -patch module was compiled. This is because the relocations in each livepatch -relocation section refer to their respective symbols with their symbol indices, -and the original symbol indices (and thus the symtab ordering) must be +in kernel/module/kallsyms.c). For livepatch modules, the symbol table copied +into memory on module load must be exactly the same as the symbol table produced +when the patch module was compiled. This is because the relocations in each +livepatch relocation section refer to their respective symbols with their symbol +indices, and the original symbol indices (and thus the symtab ordering) must be preserved in order for apply_relocate_add() to find the right symbol. For example, take this particular rela from a livepatch module::: diff --git a/Documentation/loongarch/introduction.rst b/Documentation/loongarch/introduction.rst index 216b3f390e80..6c9160c4e9be 100644 --- a/Documentation/loongarch/introduction.rst +++ b/Documentation/loongarch/introduction.rst @@ -221,7 +221,7 @@ I26 Opcode + I26L + I26H =========== ========================== Rd is the destination register operand, while Rj, Rk and Ra ("a" stands for -"additional") are the source register operands. I8/I12/I16/I21/I26 are +"additional") are the source register operands. I8/I12/I14/I16/I21/I26 are immediate operands of respective width. The longer I21 and I26 are stored in separate higher and lower parts in the instruction word, denoted by the "L" and "H" suffixes. diff --git a/Documentation/m68k/kernel-options.rst b/Documentation/m68k/kernel-options.rst index cabd9419740d..2008a20b4329 100644 --- a/Documentation/m68k/kernel-options.rst +++ b/Documentation/m68k/kernel-options.rst @@ -367,8 +367,8 @@ activated by a "external:" sub-option. 4.1.2) inverse -------------- -Invert the display. This affects both, text (consoles) and graphics -(X) display. Usually, the background is chosen to be black. With this +Invert the display. This affects only text consoles. +Usually, the background is chosen to be black. With this option, you can make the background white. 4.1.3) font diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b12df9137e1c..832b5d36e279 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1894,6 +1894,7 @@ There are some more advanced barrier functions: (*) dma_wmb(); (*) dma_rmb(); + (*) dma_mb(); These are for use with consistent memory to guarantee the ordering of writes or reads of shared memory accessible to both the CPU and a @@ -1925,11 +1926,11 @@ There are some more advanced barrier functions: The dma_rmb() allows us guarantee the device has released ownership before we read the data from the descriptor, and the dma_wmb() allows us to guarantee the data is written to the descriptor before the device - can see it now has ownership. Note that, when using writel(), a prior - wmb() is not needed to guarantee that the cache coherent memory writes - have completed before writing to the MMIO region. The cheaper - writel_relaxed() does not provide this guarantee and must not be used - here. + can see it now has ownership. The dma_mb() implies both a dma_rmb() and + a dma_wmb(). Note that, when using writel(), a prior wmb() is not needed + to guarantee that the cache coherent memory writes have completed before + writing to the MMIO region. The cheaper writel_relaxed() does not provide + this guarantee and must not be used here. See the subsection "Kernel I/O barrier effects" for more information on relaxed I/O accessors and the Documentation/core-api/dma-api.rst file for diff --git a/Documentation/vm/active_mm.rst b/Documentation/mm/active_mm.rst index 6f8269c284ed..6f8269c284ed 100644 --- a/Documentation/vm/active_mm.rst +++ b/Documentation/mm/active_mm.rst diff --git a/Documentation/vm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst index cbaee9e59241..cbaee9e59241 100644 --- a/Documentation/vm/arch_pgtable_helpers.rst +++ b/Documentation/mm/arch_pgtable_helpers.rst diff --git a/Documentation/vm/balance.rst b/Documentation/mm/balance.rst index 6a1fadf3e173..6a1fadf3e173 100644 --- a/Documentation/vm/balance.rst +++ b/Documentation/mm/balance.rst diff --git a/Documentation/vm/bootmem.rst b/Documentation/mm/bootmem.rst index eb2b31eedfa1..eb2b31eedfa1 100644 --- a/Documentation/vm/bootmem.rst +++ b/Documentation/mm/bootmem.rst diff --git a/Documentation/vm/damon/api.rst b/Documentation/mm/damon/api.rst index 08f34df45523..08f34df45523 100644 --- a/Documentation/vm/damon/api.rst +++ b/Documentation/mm/damon/api.rst diff --git a/Documentation/vm/damon/design.rst b/Documentation/mm/damon/design.rst index 0cff6fac6b7e..0cff6fac6b7e 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/mm/damon/design.rst diff --git a/Documentation/vm/damon/faq.rst b/Documentation/mm/damon/faq.rst index dde7e2414ee6..dde7e2414ee6 100644 --- a/Documentation/vm/damon/faq.rst +++ b/Documentation/mm/damon/faq.rst diff --git a/Documentation/vm/damon/index.rst b/Documentation/mm/damon/index.rst index 48c0bbff98b2..48c0bbff98b2 100644 --- a/Documentation/vm/damon/index.rst +++ b/Documentation/mm/damon/index.rst diff --git a/Documentation/vm/free_page_reporting.rst b/Documentation/mm/free_page_reporting.rst index 8c05e62d8b2b..8c05e62d8b2b 100644 --- a/Documentation/vm/free_page_reporting.rst +++ b/Documentation/mm/free_page_reporting.rst diff --git a/Documentation/vm/frontswap.rst b/Documentation/mm/frontswap.rst index feecc5e24477..feecc5e24477 100644 --- a/Documentation/vm/frontswap.rst +++ b/Documentation/mm/frontswap.rst diff --git a/Documentation/vm/highmem.rst b/Documentation/mm/highmem.rst index c9887f241c6c..0f731d9196b0 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/mm/highmem.rst @@ -60,17 +60,40 @@ list shows them in order of preference of use. This function should be preferred, where feasible, over all the others. 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. + can only be accessed from within this thread and the thread is bound to the + CPU while the mapping is active. Although preemption is never disabled by + this 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. + As said, pagefaults and preemption are never disabled. There is no need to + disable preemption because, when context switches to a different task, the + maps of the outgoing task are saved and those of the incoming one are + restored. + kmap_local_page() always returns a valid virtual address and it is assumed that kunmap_local() will never fail. + On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the + virtual address of the direct mapping. Only real highmem pages are + temporarily mapped. Therefore, users may call a plain page_address() + for pages which are known to not come from ZONE_HIGHMEM. However, it is + always safe to use kmap_local_page() / kunmap_local(). + + While it is significantly faster than kmap(), for the higmem case it + comes with restrictions about the pointers validity. Contrary to kmap() + mappings, the local mappings are only valid in the context of the caller + and cannot be handed to other contexts. This implies that users must + be absolutely sure to keep the use of the return address local to the + thread which mapped it. + + Most code can be designed to use thread local mappings. User should + therefore try to design their code to avoid the use of kmap() by mapping + pages in the same thread the address will be used and prefer + kmap_local_page(). + 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 diff --git a/Documentation/vm/hmm.rst b/Documentation/mm/hmm.rst index f2a59ed82ed3..f2a59ed82ed3 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/mm/hmm.rst diff --git a/Documentation/vm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst index f143954e0d05..f143954e0d05 100644 --- a/Documentation/vm/hugetlbfs_reserv.rst +++ b/Documentation/mm/hugetlbfs_reserv.rst diff --git a/Documentation/vm/hwpoison.rst b/Documentation/mm/hwpoison.rst index b9d5253c1305..b9d5253c1305 100644 --- a/Documentation/vm/hwpoison.rst +++ b/Documentation/mm/hwpoison.rst diff --git a/Documentation/vm/index.rst b/Documentation/mm/index.rst index 575ccd40e30c..575ccd40e30c 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/mm/index.rst diff --git a/Documentation/vm/ksm.rst b/Documentation/mm/ksm.rst index 9e37add068e6..9e37add068e6 100644 --- a/Documentation/vm/ksm.rst +++ b/Documentation/mm/ksm.rst diff --git a/Documentation/vm/memory-model.rst b/Documentation/mm/memory-model.rst index 30e8fbed6914..3779e562dc76 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/mm/memory-model.rst @@ -170,7 +170,7 @@ The users of `ZONE_DEVICE` are: * hmm: Extend `ZONE_DEVICE` with `->page_fault()` and `->page_free()` event callbacks to allow a device-driver to coordinate memory management events related to device-memory, typically GPU memory. See - Documentation/vm/hmm.rst. + Documentation/mm/hmm.rst. * p2pdma: Create `struct page` objects to allow peer devices in a PCI/-E topology to coordinate direct-DMA operations between themselves, diff --git a/Documentation/vm/mmu_notifier.rst b/Documentation/mm/mmu_notifier.rst index df5d7777fc6b..df5d7777fc6b 100644 --- a/Documentation/vm/mmu_notifier.rst +++ b/Documentation/mm/mmu_notifier.rst diff --git a/Documentation/vm/numa.rst b/Documentation/mm/numa.rst index 99fdeca917ca..99fdeca917ca 100644 --- a/Documentation/vm/numa.rst +++ b/Documentation/mm/numa.rst diff --git a/Documentation/vm/oom.rst b/Documentation/mm/oom.rst index 18e9e40c1ec1..18e9e40c1ec1 100644 --- a/Documentation/vm/oom.rst +++ b/Documentation/mm/oom.rst diff --git a/Documentation/vm/overcommit-accounting.rst b/Documentation/mm/overcommit-accounting.rst index 1addb0c374a4..a4895d6fc1c2 100644 --- a/Documentation/vm/overcommit-accounting.rst +++ b/Documentation/mm/overcommit-accounting.rst @@ -1,5 +1,3 @@ -.. _overcommit_accounting: - ===================== Overcommit Accounting ===================== diff --git a/Documentation/vm/page_allocation.rst b/Documentation/mm/page_allocation.rst index d9b4495561f1..d9b4495561f1 100644 --- a/Documentation/vm/page_allocation.rst +++ b/Documentation/mm/page_allocation.rst diff --git a/Documentation/vm/page_cache.rst b/Documentation/mm/page_cache.rst index 75eba7c431b2..75eba7c431b2 100644 --- a/Documentation/vm/page_cache.rst +++ b/Documentation/mm/page_cache.rst diff --git a/Documentation/vm/page_frags.rst b/Documentation/mm/page_frags.rst index 7d6f9385d129..7d6f9385d129 100644 --- a/Documentation/vm/page_frags.rst +++ b/Documentation/mm/page_frags.rst diff --git a/Documentation/vm/page_migration.rst b/Documentation/mm/page_migration.rst index 8c5cb8147e55..11493bad7112 100644 --- a/Documentation/vm/page_migration.rst +++ b/Documentation/mm/page_migration.rst @@ -152,110 +152,15 @@ Steps: Non-LRU page migration ====================== -Although migration originally aimed for reducing the latency of memory accesses -for NUMA, compaction also uses migration to create high-order pages. +Although migration originally aimed for reducing the latency of memory +accesses for NUMA, compaction also uses migration to create high-order +pages. For compaction purposes, it is also useful to be able to move +non-LRU pages, such as zsmalloc and virtio-balloon pages. -Current problem of the implementation is that it is designed to migrate only -*LRU* pages. However, there are potential non-LRU pages which can be migrated -in drivers, for example, zsmalloc, virtio-balloon pages. - -For virtio-balloon pages, some parts of migration code path have been hooked -up and added virtio-balloon specific functions to intercept migration logics. -It's too specific to a driver so other drivers who want to make their pages -movable would have to add their own specific hooks in the migration path. - -To overcome the problem, VM supports non-LRU page migration which provides -generic functions for non-LRU movable pages without driver specific hooks -in the migration path. - -If a driver wants to make its pages movable, it should define three functions -which are function pointers of struct address_space_operations. - -1. ``bool (*isolate_page) (struct page *page, isolate_mode_t mode);`` - - What VM expects from isolate_page() function of driver is to return *true* - if driver isolates the page successfully. On returning true, VM marks the page - as PG_isolated so concurrent isolation in several CPUs skip the page - for isolation. If a driver cannot isolate the page, it should return *false*. - - Once page is successfully isolated, VM uses page.lru fields so driver - shouldn't expect to preserve values in those fields. - -2. ``int (*migratepage) (struct address_space *mapping,`` -| ``struct page *newpage, struct page *oldpage, enum migrate_mode);`` - - After isolation, VM calls migratepage() of driver with the isolated page. - The function of migratepage() is to move the contents of the old page to the - new page - and set up fields of struct page newpage. Keep in mind that you should - indicate to the VM the oldpage is no longer movable via __ClearPageMovable() - under page_lock if you migrated the oldpage successfully and returned - MIGRATEPAGE_SUCCESS. If driver cannot migrate the page at the moment, driver - can return -EAGAIN. On -EAGAIN, VM will retry page migration in a short time - because VM interprets -EAGAIN as "temporary migration failure". On returning - any error except -EAGAIN, VM will give up the page migration without - retrying. - - Driver shouldn't touch the page.lru field while in the migratepage() function. - -3. ``void (*putback_page)(struct page *);`` - - If migration fails on the isolated page, VM should return the isolated page - to the driver so VM calls the driver's putback_page() with the isolated page. - In this function, the driver should put the isolated page back into its own data - structure. - -Non-LRU movable page flags - - There are two page flags for supporting non-LRU movable page. - - * PG_movable - - Driver should use the function below to make page movable under page_lock:: - - void __SetPageMovable(struct page *page, struct address_space *mapping) - - It needs argument of address_space for registering migration - family functions which will be called by VM. Exactly speaking, - PG_movable is not a real flag of struct page. Rather, VM - reuses the page->mapping's lower bits to represent it:: - - #define PAGE_MAPPING_MOVABLE 0x2 - page->mapping = page->mapping | PAGE_MAPPING_MOVABLE; - - so driver shouldn't access page->mapping directly. Instead, driver should - use page_mapping() which masks off the low two bits of page->mapping under - page lock so it can get the right struct address_space. - - For testing of non-LRU movable pages, VM supports __PageMovable() function. - However, it doesn't guarantee to identify non-LRU movable pages because - the page->mapping field is unified with other variables in struct page. - If the driver releases the page after isolation by VM, page->mapping - doesn't have a stable value although it has PAGE_MAPPING_MOVABLE set - (look at __ClearPageMovable). But __PageMovable() is cheap to call whether - page is LRU or non-LRU movable once the page has been isolated because LRU - pages can never have PAGE_MAPPING_MOVABLE set in page->mapping. It is also - good for just peeking to test non-LRU movable pages before more expensive - checking with lock_page() in pfn scanning to select a victim. - - For guaranteeing non-LRU movable page, VM provides PageMovable() function. - Unlike __PageMovable(), PageMovable() validates page->mapping and - mapping->a_ops->isolate_page under lock_page(). The lock_page() prevents - sudden destroying of page->mapping. - - Drivers using __SetPageMovable() should clear the flag via - __ClearMovablePage() under page_lock() before the releasing the page. - - * PG_isolated - - To prevent concurrent isolation among several CPUs, VM marks isolated page - as PG_isolated under lock_page(). So if a CPU encounters PG_isolated - non-LRU movable page, it can skip it. Driver doesn't need to manipulate the - flag because VM will set/clear it automatically. Keep in mind that if the - driver sees a PG_isolated page, it means the page has been isolated by the - VM so it shouldn't touch the page.lru field. - The PG_isolated flag is aliased with the PG_reclaim flag so drivers - shouldn't use PG_isolated for its own purposes. +If a driver wants to make its pages movable, it should define a struct +movable_operations. It then needs to call __SetPageMovable() on each +page that it may be able to move. This uses the ``page->mapping`` field, +so this field is not available for the driver to use for other purposes. Monitoring Migration ===================== @@ -286,3 +191,5 @@ THP_MIGRATION_FAIL and PGMIGRATE_FAIL to increase. Christoph Lameter, May 8, 2006. Minchan Kim, Mar 28, 2016. + +.. kernel-doc:: include/linux/migrate.h diff --git a/Documentation/vm/page_owner.rst b/Documentation/mm/page_owner.rst index f5c954afe97c..f5c954afe97c 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/mm/page_owner.rst diff --git a/Documentation/vm/page_reclaim.rst b/Documentation/mm/page_reclaim.rst index 50a30b7f8ac3..50a30b7f8ac3 100644 --- a/Documentation/vm/page_reclaim.rst +++ b/Documentation/mm/page_reclaim.rst diff --git a/Documentation/vm/page_table_check.rst b/Documentation/mm/page_table_check.rst index 1a09472f10a3..1a09472f10a3 100644 --- a/Documentation/vm/page_table_check.rst +++ b/Documentation/mm/page_table_check.rst diff --git a/Documentation/vm/page_tables.rst b/Documentation/mm/page_tables.rst index 96939571d7bc..96939571d7bc 100644 --- a/Documentation/vm/page_tables.rst +++ b/Documentation/mm/page_tables.rst diff --git a/Documentation/vm/physical_memory.rst b/Documentation/mm/physical_memory.rst index 2ab7b8c1c863..2ab7b8c1c863 100644 --- a/Documentation/vm/physical_memory.rst +++ b/Documentation/mm/physical_memory.rst diff --git a/Documentation/vm/process_addrs.rst b/Documentation/mm/process_addrs.rst index e8618fbc62c9..e8618fbc62c9 100644 --- a/Documentation/vm/process_addrs.rst +++ b/Documentation/mm/process_addrs.rst diff --git a/Documentation/vm/remap_file_pages.rst b/Documentation/mm/remap_file_pages.rst index 7bef6718e3a9..7bef6718e3a9 100644 --- a/Documentation/vm/remap_file_pages.rst +++ b/Documentation/mm/remap_file_pages.rst diff --git a/Documentation/vm/shmfs.rst b/Documentation/mm/shmfs.rst index 8b01ebb4c30e..8b01ebb4c30e 100644 --- a/Documentation/vm/shmfs.rst +++ b/Documentation/mm/shmfs.rst diff --git a/Documentation/vm/slab.rst b/Documentation/mm/slab.rst index 87d5a5bb172f..87d5a5bb172f 100644 --- a/Documentation/vm/slab.rst +++ b/Documentation/mm/slab.rst diff --git a/Documentation/vm/slub.rst b/Documentation/mm/slub.rst index 43063ade737a..43063ade737a 100644 --- a/Documentation/vm/slub.rst +++ b/Documentation/mm/slub.rst diff --git a/Documentation/vm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst index c08919662704..c08919662704 100644 --- a/Documentation/vm/split_page_table_lock.rst +++ b/Documentation/mm/split_page_table_lock.rst diff --git a/Documentation/vm/swap.rst b/Documentation/mm/swap.rst index 78819bd4d745..78819bd4d745 100644 --- a/Documentation/vm/swap.rst +++ b/Documentation/mm/swap.rst diff --git a/Documentation/vm/transhuge.rst b/Documentation/mm/transhuge.rst index 216db1d67d04..216db1d67d04 100644 --- a/Documentation/vm/transhuge.rst +++ b/Documentation/mm/transhuge.rst diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst index b280367d6a44..b280367d6a44 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/mm/unevictable-lru.rst diff --git a/Documentation/vm/vmalloc.rst b/Documentation/mm/vmalloc.rst index 363fe20d6b9f..363fe20d6b9f 100644 --- a/Documentation/vm/vmalloc.rst +++ b/Documentation/mm/vmalloc.rst diff --git a/Documentation/vm/vmalloced-kernel-stacks.rst b/Documentation/mm/vmalloced-kernel-stacks.rst index fc8c67833af6..fc8c67833af6 100644 --- a/Documentation/vm/vmalloced-kernel-stacks.rst +++ b/Documentation/mm/vmalloced-kernel-stacks.rst diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst index c9c495f62d12..a4b12ff906c4 100644 --- a/Documentation/vm/vmemmap_dedup.rst +++ b/Documentation/mm/vmemmap_dedup.rst @@ -7,23 +7,25 @@ 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. +This section is to explain how HugeTLB Vmemmap Optimization (HVO) works. + +The ``struct page`` structures 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 +``struct page``. 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. +For each base page, there is a corresponding ``struct page``. -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 +Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to +contain unique information about a HugeTLB page. ``__NR_USED_SUBPAGE`` provides +this upper limit. The only 'useful' information in the remaining ``struct page`` 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 +By removing redundant ``struct page`` for HugeTLB pages, memory can be returned to the buddy allocator for other uses. Different architectures support different HugeTLB pages. For example, the @@ -44,7 +46,7 @@ page. | | 64KB | 2MB | 512MB | 16GB | | +--------------+-----------+-----------+-----------+-----------+-----------+ -When the system boot up, every HugeTLB page has more than one struct page +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 @@ -74,10 +76,10 @@ 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. +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 ``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:: @@ -86,7 +88,7 @@ For the HugeTLB page of the pud level mapping, then:: = PAGE_SIZE / 8 * 8 (pages) = PAGE_SIZE (pages) -Where the struct_size(pmd) is the size of the struct page structs of a +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 @@ -94,7 +96,7 @@ 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. +``struct page`` structs associated with a HugeTLB page which is pmd mapped. Here is how things look before optimization:: @@ -122,10 +124,10 @@ Here is how things look before optimization:: +-----------+ 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 +page of ``struct page`` (page 0) associated with the HugeTLB page contains the 4 +``struct page`` necessary to describe the HugeTLB. The only use of the remaining +pages of ``struct page`` (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 ``struct page`` will be used for each HugeTLB page. This will allow us to free the remaining 7 pages to the buddy allocator. @@ -167,13 +169,37 @@ 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. +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()). +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. There is only **one** head ``struct page``, the tail +``struct page`` with ``PG_head`` are fake head ``struct page``. We need an +approach to distinguish between those two different types of ``struct page`` so +that ``compound_head()`` can return the real head ``struct page`` when the +parameter is the tail ``struct page`` but with ``PG_head``. The following code +snippet describes how to distinguish between real and fake head ``struct page``. + +.. code-block:: c + + if (test_bit(PG_head, &page->flags)) { + unsigned long head = READ_ONCE(page[1].compound_head); + + if (head & 1) { + if (head == (unsigned long)page + 1) + /* head struct page */ + else + /* tail struct page */ + } else { + /* head struct page */ + } + } + +We can safely access the field of the **page[1]** with ``PG_head`` because the +page is a compound page composed with at least two contiguous pages. +The implementation refers to ``page_fixed_fake_head()``. Device DAX ========== @@ -187,7 +213,7 @@ 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 +It only use 3 ``struct page`` 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 diff --git a/Documentation/vm/z3fold.rst b/Documentation/mm/z3fold.rst index 224e3c61d686..224e3c61d686 100644 --- a/Documentation/vm/z3fold.rst +++ b/Documentation/mm/z3fold.rst diff --git a/Documentation/vm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst index 6e79893d6132..6e79893d6132 100644 --- a/Documentation/vm/zsmalloc.rst +++ b/Documentation/mm/zsmalloc.rst diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 43be3782e5df..7823a069a903 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -780,6 +780,17 @@ peer_notif_delay value is 0 which means to match the value of the link monitor interval. +prio + Slave priority. A higher number means higher priority. + The primary slave has the highest priority. This option also + follows the primary_reselect rules. + + This option could only be configured via netlink, and is only valid + for active-backup(1), balance-tlb (5) and balance-alb (6) mode. + The valid value range is a signed 32 bit integer. + + The default value is 0. + primary A string (eth0, eth2, etc) specifying which slave is the @@ -1971,15 +1982,6 @@ uses the response as an indication that the link is operating. This gives some assurance that traffic is actually flowing to and from one or more peers on the local network. -The ARP monitor relies on the device driver itself to verify -that traffic is flowing. In particular, the driver must keep up to -date the last receive time, dev->last_rx. Drivers that use NETIF_F_LLTX -flag must also update netdev_queue->trans_start. If they do not, then the -ARP monitor will immediately fail any slaves using that driver, and -those slaves will stay down. If networking monitoring (tcpdump, etc) -shows the ARP requests and replies on the network, then it may be that -your device driver is not updating last_rx and trans_start. - 7.2 Configuring Multiple ARP Targets ------------------------------------ diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst index f34cb0e4460e..ebc822e605f5 100644 --- a/Documentation/networking/can.rst +++ b/Documentation/networking/can.rst @@ -168,7 +168,7 @@ reflect the correct [#f1]_ traffic on the node the loopback of the sent data has to be performed right after a successful transmission. If the CAN network interface is not capable of performing the loopback for some reason the SocketCAN core can do this task as a fallback solution. -See :ref:`socketcan-local-loopback1` for details (recommended). +See :ref:`socketcan-local-loopback2` for details (recommended). The loopback functionality is enabled by default to reflect standard networking behaviour for CAN applications. Due to some requests from diff --git a/Documentation/networking/device_drivers/can/can327.rst b/Documentation/networking/device_drivers/can/can327.rst new file mode 100644 index 000000000000..b87bfbe5d51c --- /dev/null +++ b/Documentation/networking/device_drivers/can/can327.rst @@ -0,0 +1,331 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) + +can327: ELM327 driver for Linux SocketCAN +========================================== + +Authors +-------- + +Max Staudt <max@enpas.org> + + + +Motivation +----------- + +This driver aims to lower the initial cost for hackers interested in +working with CAN buses. + +CAN adapters are expensive, few, and far between. +ELM327 interfaces are cheap and plentiful. +Let's use ELM327s as CAN adapters. + + + +Introduction +------------- + +This driver is an effort to turn abundant ELM327 based OBD interfaces +into full fledged (as far as possible) CAN interfaces. + +Since the ELM327 was never meant to be a stand alone CAN controller, +the driver has to switch between its modes as quickly as possible in +order to fake full-duplex operation. + +As such, can327 is a best effort driver. However, this is more than +enough to implement simple request-response protocols (such as OBD II), +and to monitor broadcast messages on a bus (such as in a vehicle). + +Most ELM327s come as nondescript serial devices, attached via USB or +Bluetooth. The driver cannot recognize them by itself, and as such it +is up to the user to attach it in form of a TTY line discipline +(similar to PPP, SLIP, slcan, ...). + +This driver is meant for ELM327 versions 1.4b and up, see below for +known limitations in older controllers and clones. + + + +Data sheet +----------- + +The official data sheets can be found at ELM electronics' home page: + + https://www.elmelectronics.com/ + + + +How to attach the line discipline +---------------------------------- + +Every ELM327 chip is factory programmed to operate at a serial setting +of 38400 baud/s, 8 data bits, no parity, 1 stopbit. + +If you have kept this default configuration, the line discipline can +be attached on a command prompt as follows:: + + sudo ldattach \ + --debug \ + --speed 38400 \ + --eightbits \ + --noparity \ + --onestopbit \ + --iflag -ICRNL,INLCR,-IXOFF \ + 30 \ + /dev/ttyUSB0 + +To change the ELM327's serial settings, please refer to its data +sheet. This needs to be done before attaching the line discipline. + +Once the ldisc is attached, the CAN interface starts out unconfigured. +Set the speed before starting it:: + + # The interface needs to be down to change parameters + sudo ip link set can0 down + sudo ip link set can0 type can bitrate 500000 + sudo ip link set can0 up + +500000 bit/s is a common rate for OBD-II diagnostics. +If you're connecting straight to a car's OBD port, this is the speed +that most cars (but not all!) expect. + +After this, you can set out as usual with candump, cansniffer, etc. + + + +How to check the controller version +------------------------------------ + +Use a terminal program to attach to the controller. + +After issuing the "``AT WS``" command, the controller will respond with +its version:: + + >AT WS + + + ELM327 v1.4b + + > + +Note that clones may claim to be any version they like. +It is not indicative of their actual feature set. + + + + +Communication example +---------------------- + +This is a short and incomplete introduction on how to talk to an ELM327. +It is here to guide understanding of the controller's and the driver's +limitation (listed below) as well as manual testing. + + +The ELM327 has two modes: + +- Command mode +- Reception mode + +In command mode, it expects one command per line, terminated by CR. +By default, the prompt is a "``>``", after which a command can be +entered:: + + >ATE1 + OK + > + +The init script in the driver switches off several configuration options +that are only meaningful in the original OBD scenario the chip is meant +for, and are actually a hindrance for can327. + + +When a command is not recognized, such as by an older version of the +ELM327, a question mark is printed as a response instead of OK:: + + >ATUNKNOWN + ? + > + +At present, can327 does not evaluate this response. See the section +below on known limitations for details. + + +When a CAN frame is to be sent, the target address is configured, after +which the frame is sent as a command that consists of the data's hex +dump:: + + >ATSH123 + OK + >DEADBEEF12345678 + OK + > + +The above interaction sends the SFF frame "``DE AD BE EF 12 34 56 78``" +with (11 bit) CAN ID ``0x123``. +For this to function, the controller must be configured for SFF sending +mode (using "``AT PB``", see code or datasheet). + + +Once a frame has been sent and wait-for-reply mode is on (``ATR1``, +configured on ``listen-only=off``), or when the reply timeout expires +and the driver sets the controller into monitoring mode (``ATMA``), +the ELM327 will send one line for each received CAN frame, consisting +of CAN ID, DLC, and data:: + + 123 8 DEADBEEF12345678 + +For EFF (29 bit) CAN frames, the address format is slightly different, +which can327 uses to tell the two apart:: + + 12 34 56 78 8 DEADBEEF12345678 + +The ELM327 will receive both SFF and EFF frames - the current CAN +config (``ATPB``) does not matter. + + +If the ELM327's internal UART sending buffer runs full, it will abort +the monitoring mode, print "BUFFER FULL" and drop back into command +mode. Note that in this case, unlike with other error messages, the +error message may appear on the same line as the last (usually +incomplete) data frame:: + + 12 34 56 78 8 DEADBEEF123 BUFFER FULL + + + +Known limitations of the controller +------------------------------------ + +- Clone devices ("v1.5" and others) + + Sending RTR frames is not supported and will be dropped silently. + + Receiving RTR with DLC 8 will appear to be a regular frame with + the last received frame's DLC and payload. + + "``AT CSM``" (CAN Silent Monitoring, i.e. don't send CAN ACKs) is + not supported, and is hard coded to ON. Thus, frames are not ACKed + while listening: "``AT MA``" (Monitor All) will always be "silent". + However, immediately after sending a frame, the ELM327 will be in + "receive reply" mode, in which it *does* ACK any received frames. + Once the bus goes silent, or an error occurs (such as BUFFER FULL), + or the receive reply timeout runs out, the ELM327 will end reply + reception mode on its own and can327 will fall back to "``AT MA``" + in order to keep monitoring the bus. + + Other limitations may apply, depending on the clone and the quality + of its firmware. + + +- All versions + + No full duplex operation is supported. The driver will switch + between input/output mode as quickly as possible. + + The length of outgoing RTR frames cannot be set. In fact, some + clones (tested with one identifying as "``v1.5``") are unable to + send RTR frames at all. + + We don't have a way to get real-time notifications on CAN errors. + While there is a command (``AT CS``) to retrieve some basic stats, + we don't poll it as it would force us to interrupt reception mode. + + +- Versions prior to 1.4b + + These versions do not send CAN ACKs when in monitoring mode (AT MA). + However, they do send ACKs while waiting for a reply immediately + after sending a frame. The driver maximizes this time to make the + controller as useful as possible. + + Starting with version 1.4b, the ELM327 supports the "``AT CSM``" + command, and the "listen-only" CAN option will take effect. + + +- Versions prior to 1.4 + + These chips do not support the "``AT PB``" command, and thus cannot + change bitrate or SFF/EFF mode on-the-fly. This will have to be + programmed by the user before attaching the line discipline. See the + data sheet for details. + + +- Versions prior to 1.3 + + These chips cannot be used at all with can327. They do not support + the "``AT D1``" command, which is necessary to avoid parsing conflicts + on incoming data, as well as distinction of RTR frame lengths. + + Specifically, this allows for easy distinction of SFF and EFF + frames, and to check whether frames are complete. While it is possible + to deduce the type and length from the length of the line the ELM327 + sends us, this method fails when the ELM327's UART output buffer + overruns. It may abort sending in the middle of the line, which will + then be mistaken for something else. + + + +Known limitations of the driver +-------------------------------- + +- No 8/7 timing. + + ELM327 can only set CAN bitrates that are of the form 500000/n, where + n is an integer divisor. + However there is an exception: With a separate flag, it may set the + speed to be 8/7 of the speed indicated by the divisor. + This mode is not currently implemented. + +- No evaluation of command responses. + + The ELM327 will reply with OK when a command is understood, and with ? + when it is not. The driver does not currently check this, and simply + assumes that the chip understands every command. + The driver is built such that functionality degrades gracefully + nevertheless. See the section on known limitations of the controller. + +- No use of hardware CAN ID filtering + + An ELM327's UART sending buffer will easily overflow on heavy CAN bus + load, resulting in the "``BUFFER FULL``" message. Using the hardware + filters available through "``AT CF xxx``" and "``AT CM xxx``" would be + helpful here, however SocketCAN does not currently provide a facility + to make use of such hardware features. + + + +Rationale behind the chosen configuration +------------------------------------------ + +``AT E1`` + Echo on + + We need this to be able to get a prompt reliably. + +``AT S1`` + Spaces on + + We need this to distinguish 11/29 bit CAN addresses received. + + Note: + We can usually do this using the line length (odd/even), + but this fails if the line is not transmitted fully to + the host (BUFFER FULL). + +``AT D1`` + DLC on + + We need this to tell the "length" of RTR frames. + + + +A note on CAN bus termination +------------------------------ + +Your adapter may have resistors soldered in which are meant to terminate +the bus. This is correct when it is plugged into a OBD-II socket, but +not helpful when trying to tap into the middle of an existing CAN bus. + +If communications don't work with the adapter connected, check for the +termination resistors on its PCB and try removing them. diff --git a/Documentation/networking/device_drivers/can/index.rst b/Documentation/networking/device_drivers/can/index.rst index 0c3cc6633559..6a8a4f74fa26 100644 --- a/Documentation/networking/device_drivers/can/index.rst +++ b/Documentation/networking/device_drivers/can/index.rst @@ -10,6 +10,7 @@ Contents: .. toctree:: :maxdepth: 2 + can327 ctu/ctucanfd-driver freescale/flexcan diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst index 4e06684d079b..7f1777173abb 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -42,7 +42,6 @@ Contents: mellanox/mlx5 microsoft/netvsc neterion/s2io - neterion/vxge netronome/nfp pensando/ionic smsc/smc9 @@ -52,6 +51,7 @@ Contents: ti/am65_nuss_cpsw_switchdev ti/tlan toshiba/spider_net + wangxun/txgbe .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index 67b7a701ce9e..dc2e60ced927 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -901,6 +901,15 @@ To enable/disable UDP Segmentation Offload, issue the following command:: # ethtool -K <ethX> tx-udp-segmentation [off|on] +GNSS module +----------- +Allows user to read messages from the GNSS module and write supported commands. +If the module is physically present, driver creates 2 TTYs for each supported +device in /dev, ttyGNSS_<device>:<function>_0 and _1. First one (_0) is RW and +the second one is RO. +The protocol of write commands is dependent on the GNSS module as the driver +writes raw bytes from the TTY to the GNSS i2c. Please refer to the module +documentation for details. Performance Optimization ======================== diff --git a/Documentation/networking/device_drivers/ethernet/neterion/vxge.rst b/Documentation/networking/device_drivers/ethernet/neterion/vxge.rst deleted file mode 100644 index 589c6b15c63d..000000000000 --- a/Documentation/networking/device_drivers/ethernet/neterion/vxge.rst +++ /dev/null @@ -1,115 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -============================================================================== -Neterion's (Formerly S2io) X3100 Series 10GbE PCIe Server Adapter Linux driver -============================================================================== - -.. Contents - - 1) Introduction - 2) Features supported - 3) Configurable driver parameters - 4) Troubleshooting - -1. Introduction -=============== - -This Linux driver supports all Neterion's X3100 series 10 GbE PCIe I/O -Virtualized Server adapters. - -The X3100 series supports four modes of operation, configurable via -firmware: - - - Single function mode - - Multi function mode - - SRIOV mode - - MRIOV mode - -The functions share a 10GbE link and the pci-e bus, but hardly anything else -inside the ASIC. Features like independent hw reset, statistics, bandwidth/ -priority allocation and guarantees, GRO, TSO, interrupt moderation etc are -supported independently on each function. - -(See below for a complete list of features supported for both IPv4 and IPv6) - -2. Features supported -===================== - -i) Single function mode (up to 17 queues) - -ii) Multi function mode (up to 17 functions) - -iii) PCI-SIG's I/O Virtualization - - - Single Root mode: v1.0 (up to 17 functions) - - Multi-Root mode: v1.0 (up to 17 functions) - -iv) Jumbo frames - - X3100 Series supports MTU up to 9600 bytes, modifiable using - ip command. - -v) Offloads supported: (Enabled by default) - - - Checksum offload (TCP/UDP/IP) on transmit and receive paths - - TCP Segmentation Offload (TSO) on transmit path - - Generic Receive Offload (GRO) on receive path - -vi) MSI-X: (Enabled by default) - - Resulting in noticeable performance improvement (up to 7% on certain - platforms). - -vii) NAPI: (Enabled by default) - - For better Rx interrupt moderation. - -viii)RTH (Receive Traffic Hash): (Enabled by default) - - Receive side steering for better scaling. - -ix) Statistics - - Comprehensive MAC-level and software statistics displayed using - "ethtool -S" option. - -x) Multiple hardware queues: (Enabled by default) - - Up to 17 hardware based transmit and receive data channels, with - multiple steering options (transmit multiqueue enabled by default). - -3) Configurable driver parameters: ----------------------------------- - -i) max_config_dev - Specifies maximum device functions to be enabled. - - Valid range: 1-8 - -ii) max_config_port - Specifies number of ports to be enabled. - - Valid range: 1,2 - - Default: 1 - -iii) max_config_vpath - Specifies maximum VPATH(s) configured for each device function. - - Valid range: 1-17 - -iv) vlan_tag_strip - Enables/disables vlan tag stripping from all received tagged frames that - are not replicated at the internal L2 switch. - - Valid range: 0,1 (disabled, enabled respectively) - - Default: 1 - -v) addr_learn_en - Enable learning the mac address of the guest OS interface in - virtualization environment. - - Valid range: 0,1 (disabled, enabled respectively) - - Default: 0 diff --git a/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst b/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst new file mode 100644 index 000000000000..eaa87dbe8848 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================================ +Linux Base Driver for WangXun(R) 10 Gigabit PCI Express Adapters +================================================================ + +WangXun 10 Gigabit Linux driver. +Copyright (c) 2015 - 2022 Beijing WangXun Technology Co., Ltd. + + +Contents +======== + +- Support + + +Support +======= +If you got any problem, contact Wangxun support team via support@trustnetic.com +and Cc: netdev. diff --git a/Documentation/networking/devlink/devlink-selftests.rst b/Documentation/networking/devlink/devlink-selftests.rst new file mode 100644 index 000000000000..c0aa1f3aef0d --- /dev/null +++ b/Documentation/networking/devlink/devlink-selftests.rst @@ -0,0 +1,38 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +================= +Devlink Selftests +================= + +The ``devlink-selftests`` API allows executing selftests on the device. + +Tests Mask +========== +The ``devlink-selftests`` command should be run with a mask indicating +the tests to be executed. + +Tests Description +================= +The following is a list of tests that drivers may execute. + +.. list-table:: List of tests + :widths: 5 90 + + * - Name + - Description + * - ``DEVLINK_SELFTEST_FLASH`` + - Devices may have the firmware on non-volatile memory on the board, e.g. + flash. This particular test helps to run a flash selftest on the device. + Implementation of the test is left to the driver/firmware. + +example usage +------------- + +.. code:: shell + + # Query selftests supported on the devlink device + $ devlink dev selftests show DEV + # Query selftests supported on all devlink devices + $ devlink dev selftests show + # Executes selftests on the device + $ devlink dev selftests run DEV id flash diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 850715512293..e3a5f985673e 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -38,6 +38,7 @@ general. devlink-region devlink-resource devlink-reload + devlink-selftests devlink-trap devlink-linecard diff --git a/Documentation/networking/devlink/mlxsw.rst b/Documentation/networking/devlink/mlxsw.rst index cf857cb4ba8f..433962225bd4 100644 --- a/Documentation/networking/devlink/mlxsw.rst +++ b/Documentation/networking/devlink/mlxsw.rst @@ -58,6 +58,30 @@ The ``mlxsw`` driver reports the following versions - running - Three digit firmware version +Line card auxiliary device info versions +======================================== + +The ``mlxsw`` driver reports the following versions for line card auxiliary device + +.. list-table:: devlink info versions implemented + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``hw.revision`` + - fixed + - The hardware revision for this line card + * - ``ini.version`` + - running + - Version of line card INI loaded + * - ``fw.psid`` + - fixed + - Line card device PSID + * - ``fw.version`` + - running + - Three digit firmware version of line card device + Driver-specific Traps ===================== diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst index 8a292fb5aaea..ec5e6d79b2e2 100644 --- a/Documentation/networking/devlink/netdevsim.rst +++ b/Documentation/networking/devlink/netdevsim.rst @@ -67,7 +67,7 @@ The ``netdevsim`` driver supports rate objects management, which includes: - setting tx_share and tx_max rate values for any rate object type; - setting parent node for any rate object type. -Rate nodes and it's parameters are exposed in ``netdevsim`` debugfs in RO mode. +Rate nodes and their parameters are exposed in ``netdevsim`` debugfs in RO mode. For example created rate node with name ``some_group``: .. code:: shell diff --git a/Documentation/networking/driver.rst b/Documentation/networking/driver.rst index c8f59dbda46f..64f7236ff10b 100644 --- a/Documentation/networking/driver.rst +++ b/Documentation/networking/driver.rst @@ -8,7 +8,7 @@ Transmit path guidelines: 1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under any normal circumstances. It is considered a hard error unless - there is no way your device can tell ahead of time when it's + there is no way your device can tell ahead of time when its transmit function will become busy. Instead it must maintain the queue properly. For example, diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index ed7fa76e7a40..d742ba6bd211 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -503,26 +503,108 @@ per-port PHY specific details: interface connection, MDIO bus location, etc. Driver development ================== -DSA switch drivers need to implement a dsa_switch_ops structure which will +DSA switch drivers need to implement a ``dsa_switch_ops`` structure which will contain the various members described below. -``register_switch_driver()`` registers this dsa_switch_ops in its internal list -of drivers to probe for. ``unregister_switch_driver()`` does the exact opposite. +Probing, registration and device lifetime +----------------------------------------- -Unless requested differently by setting the priv_size member accordingly, DSA -does not allocate any driver private context space. +DSA switches are regular ``device`` structures on buses (be they platform, SPI, +I2C, MDIO or otherwise). The DSA framework is not involved in their probing +with the device core. + +Switch registration from the perspective of a driver means passing a valid +``struct dsa_switch`` pointer to ``dsa_register_switch()``, usually from the +switch driver's probing function. The following members must be valid in the +provided structure: + +- ``ds->dev``: will be used to parse the switch's OF node or platform data. + +- ``ds->num_ports``: will be used to create the port list for this switch, and + to validate the port indices provided in the OF node. + +- ``ds->ops``: a pointer to the ``dsa_switch_ops`` structure holding the DSA + method implementations. + +- ``ds->priv``: backpointer to a driver-private data structure which can be + retrieved in all further DSA method callbacks. + +In addition, the following flags in the ``dsa_switch`` structure may optionally +be configured to obtain driver-specific behavior from the DSA core. Their +behavior when set is documented through comments in ``include/net/dsa.h``. + +- ``ds->vlan_filtering_is_global`` + +- ``ds->needs_standalone_vlan_filtering`` + +- ``ds->configure_vlan_while_not_filtering`` + +- ``ds->untag_bridge_pvid`` + +- ``ds->assisted_learning_on_cpu_port`` + +- ``ds->mtu_enforcement_ingress`` + +- ``ds->fdb_isolation`` + +Internally, DSA keeps an array of switch trees (group of switches) global to +the kernel, and attaches a ``dsa_switch`` structure to a tree on registration. +The tree ID to which the switch is attached is determined by the first u32 +number of the ``dsa,member`` property of the switch's OF node (0 if missing). +The switch ID within the tree is determined by the second u32 number of the +same OF property (0 if missing). Registering multiple switches with the same +switch ID and tree ID is illegal and will cause an error. Using platform data, +a single switch and a single switch tree is permitted. + +In case of a tree with multiple switches, probing takes place asymmetrically. +The first N-1 callers of ``dsa_register_switch()`` only add their ports to the +port list of the tree (``dst->ports``), each port having a backpointer to its +associated switch (``dp->ds``). Then, these switches exit their +``dsa_register_switch()`` call early, because ``dsa_tree_setup_routing_table()`` +has determined that the tree is not yet complete (not all ports referenced by +DSA links are present in the tree's port list). The tree becomes complete when +the last switch calls ``dsa_register_switch()``, and this triggers the effective +continuation of initialization (including the call to ``ds->ops->setup()``) for +all switches within that tree, all as part of the calling context of the last +switch's probe function. + +The opposite of registration takes place when calling ``dsa_unregister_switch()``, +which removes a switch's ports from the port list of the tree. The entire tree +is torn down when the first switch unregisters. + +It is mandatory for DSA switch drivers to implement the ``shutdown()`` callback +of their respective bus, and call ``dsa_switch_shutdown()`` from it (a minimal +version of the full teardown performed by ``dsa_unregister_switch()``). +The reason is that DSA keeps a reference on the master net device, and if the +driver for the master device decides to unbind on shutdown, DSA's reference +will block that operation from finalizing. + +Either ``dsa_switch_shutdown()`` or ``dsa_unregister_switch()`` must be called, +but not both, and the device driver model permits the bus' ``remove()`` method +to be called even if ``shutdown()`` was already called. Therefore, drivers are +expected to implement a mutual exclusion method between ``remove()`` and +``shutdown()`` by setting their drvdata to NULL after any of these has run, and +checking whether the drvdata is NULL before proceeding to take any action. + +After ``dsa_switch_shutdown()`` or ``dsa_unregister_switch()`` was called, no +further callbacks via the provided ``dsa_switch_ops`` may take place, and the +driver may free the data structures associated with the ``dsa_switch``. Switch configuration -------------------- -- ``tag_protocol``: this is to indicate what kind of tagging protocol is supported, - should be a valid value from the ``dsa_tag_protocol`` enum +- ``get_tag_protocol``: this is to indicate what kind of tagging protocol is + supported, should be a valid value from the ``dsa_tag_protocol`` enum. + The returned information does not have to be static; the driver is passed the + CPU port number, as well as the tagging protocol of a possibly stacked + upstream switch, in case there are hardware limitations in terms of supported + tag formats. -- ``probe``: probe routine which will be invoked by the DSA platform device upon - registration to test for the presence/absence of a switch device. For MDIO - devices, it is recommended to issue a read towards internal registers using - the switch pseudo-PHY and return whether this is a supported device. For other - buses, return a non-NULL string +- ``change_tag_protocol``: when the default tagging protocol has compatibility + problems with the master or other issues, the driver may support changing it + at runtime, either through a device tree property or through sysfs. In that + case, further calls to ``get_tag_protocol`` should report the protocol in + current use. - ``setup``: setup function for the switch, this function is responsible for setting up the ``dsa_switch_ops`` private structure with all it needs: register maps, @@ -535,7 +617,17 @@ Switch configuration fully configured and ready to serve any kind of request. It is recommended to issue a software reset of the switch during this setup function in order to avoid relying on what a previous software agent such as a bootloader/firmware - may have previously configured. + may have previously configured. The method responsible for undoing any + applicable allocations or operations done here is ``teardown``. + +- ``port_setup`` and ``port_teardown``: methods for initialization and + destruction of per-port data structures. It is mandatory for some operations + such as registering and unregistering devlink port regions to be done from + these methods, otherwise they are optional. A port will be torn down only if + it has been previously set up. It is possible for a port to be set up during + probing only to be torn down immediately afterwards, for example in case its + PHY cannot be found. In this case, probing of the DSA switch continues + without that particular port. PHY devices and link management ------------------------------- @@ -635,26 +727,198 @@ Power management ``BR_STATE_DISABLED`` and propagating changes to the hardware if this port is disabled while being a bridge member +Address databases +----------------- + +Switching hardware is expected to have a table for FDB entries, however not all +of them are active at the same time. An address database is the subset (partition) +of FDB entries that is active (can be matched by address learning on RX, or FDB +lookup on TX) depending on the state of the port. An address database may +occasionally be called "FID" (Filtering ID) in this document, although the +underlying implementation may choose whatever is available to the hardware. + +For example, all ports that belong to a VLAN-unaware bridge (which is +*currently* VLAN-unaware) are expected to learn source addresses in the +database associated by the driver with that bridge (and not with other +VLAN-unaware bridges). During forwarding and FDB lookup, a packet received on a +VLAN-unaware bridge port should be able to find a VLAN-unaware FDB entry having +the same MAC DA as the packet, which is present on another port member of the +same bridge. At the same time, the FDB lookup process must be able to not find +an FDB entry having the same MAC DA as the packet, if that entry points towards +a port which is a member of a different VLAN-unaware bridge (and is therefore +associated with a different address database). + +Similarly, each VLAN of each offloaded VLAN-aware bridge should have an +associated address database, which is shared by all ports which are members of +that VLAN, but not shared by ports belonging to different bridges that are +members of the same VID. + +In this context, a VLAN-unaware database means that all packets are expected to +match on it irrespective of VLAN ID (only MAC address lookup), whereas a +VLAN-aware database means that packets are supposed to match based on the VLAN +ID from the classified 802.1Q header (or the pvid if untagged). + +At the bridge layer, VLAN-unaware FDB entries have the special VID value of 0, +whereas VLAN-aware FDB entries have non-zero VID values. Note that a +VLAN-unaware bridge may have VLAN-aware (non-zero VID) FDB entries, and a +VLAN-aware bridge may have VLAN-unaware FDB entries. As in hardware, the +software bridge keeps separate address databases, and offloads to hardware the +FDB entries belonging to these databases, through switchdev, asynchronously +relative to the moment when the databases become active or inactive. + +When a user port operates in standalone mode, its driver should configure it to +use a separate database called a port private database. This is different from +the databases described above, and should impede operation as standalone port +(packet in, packet out to the CPU port) as little as possible. For example, +on ingress, it should not attempt to learn the MAC SA of ingress traffic, since +learning is a bridging layer service and this is a standalone port, therefore +it would consume useless space. With no address learning, the port private +database should be empty in a naive implementation, and in this case, all +received packets should be trivially flooded to the CPU port. + +DSA (cascade) and CPU ports are also called "shared" ports because they service +multiple address databases, and the database that a packet should be associated +to is usually embedded in the DSA tag. This means that the CPU port may +simultaneously transport packets coming from a standalone port (which were +classified by hardware in one address database), and from a bridge port (which +were classified to a different address database). + +Switch drivers which satisfy certain criteria are able to optimize the naive +configuration by removing the CPU port from the flooding domain of the switch, +and just program the hardware with FDB entries pointing towards the CPU port +for which it is known that software is interested in those MAC addresses. +Packets which do not match a known FDB entry will not be delivered to the CPU, +which will save CPU cycles required for creating an skb just to drop it. + +DSA is able to perform host address filtering for the following kinds of +addresses: + +- Primary unicast MAC addresses of ports (``dev->dev_addr``). These are + associated with the port private database of the respective user port, + and the driver is notified to install them through ``port_fdb_add`` towards + the CPU port. + +- Secondary unicast and multicast MAC addresses of ports (addresses added + through ``dev_uc_add()`` and ``dev_mc_add()``). These are also associated + with the port private database of the respective user port. + +- Local/permanent bridge FDB entries (``BR_FDB_LOCAL``). These are the MAC + addresses of the bridge ports, for which packets must be terminated locally + and not forwarded. They are associated with the address database for that + bridge. + +- Static bridge FDB entries installed towards foreign (non-DSA) interfaces + present in the same bridge as some DSA switch ports. These are also + associated with the address database for that bridge. + +- Dynamically learned FDB entries on foreign interfaces present in the same + bridge as some DSA switch ports, only if ``ds->assisted_learning_on_cpu_port`` + is set to true by the driver. These are associated with the address database + for that bridge. + +For various operations detailed below, DSA provides a ``dsa_db`` structure +which can be of the following types: + +- ``DSA_DB_PORT``: the FDB (or MDB) entry to be installed or deleted belongs to + the port private database of user port ``db->dp``. +- ``DSA_DB_BRIDGE``: the entry belongs to one of the address databases of bridge + ``db->bridge``. Separation between the VLAN-unaware database and the per-VID + databases of this bridge is expected to be done by the driver. +- ``DSA_DB_LAG``: the entry belongs to the address database of LAG ``db->lag``. + Note: ``DSA_DB_LAG`` is currently unused and may be removed in the future. + +The drivers which act upon the ``dsa_db`` argument in ``port_fdb_add``, +``port_mdb_add`` etc should declare ``ds->fdb_isolation`` as true. + +DSA associates each offloaded bridge and each offloaded LAG with a one-based ID +(``struct dsa_bridge :: num``, ``struct dsa_lag :: id``) for the purposes of +refcounting addresses on shared ports. Drivers may piggyback on DSA's numbering +scheme (the ID is readable through ``db->bridge.num`` and ``db->lag.id`` or may +implement their own. + +Only the drivers which declare support for FDB isolation are notified of FDB +entries on the CPU port belonging to ``DSA_DB_PORT`` databases. +For compatibility/legacy reasons, ``DSA_DB_BRIDGE`` addresses are notified to +drivers even if they do not support FDB isolation. However, ``db->bridge.num`` +and ``db->lag.id`` are always set to 0 in that case (to denote the lack of +isolation, for refcounting purposes). + +Note that it is not mandatory for a switch driver to implement physically +separate address databases for each standalone user port. Since FDB entries in +the port private databases will always point to the CPU port, there is no risk +for incorrect forwarding decisions. In this case, all standalone ports may +share the same database, but the reference counting of host-filtered addresses +(not deleting the FDB entry for a port's MAC address if it's still in use by +another port) becomes the responsibility of the driver, because DSA is unaware +that the port databases are in fact shared. This can be achieved by calling +``dsa_fdb_present_in_other_db()`` and ``dsa_mdb_present_in_other_db()``. +The down side is that the RX filtering lists of each user port are in fact +shared, which means that user port A may accept a packet with a MAC DA it +shouldn't have, only because that MAC address was in the RX filtering list of +user port B. These packets will still be dropped in software, however. + Bridge layer ------------ +Offloading the bridge forwarding plane is optional and handled by the methods +below. They may be absent, return -EOPNOTSUPP, or ``ds->max_num_bridges`` may +be non-zero and exceeded, and in this case, joining a bridge port is still +possible, but the packet forwarding will take place in software, and the ports +under a software bridge must remain configured in the same way as for +standalone operation, i.e. have all bridging service functions (address +learning etc) disabled, and send all received packets to the CPU port only. + +Concretely, a port starts offloading the forwarding plane of a bridge once it +returns success to the ``port_bridge_join`` method, and stops doing so after +``port_bridge_leave`` has been called. Offloading the bridge means autonomously +learning FDB entries in accordance with the software bridge port's state, and +autonomously forwarding (or flooding) received packets without CPU intervention. +This is optional even when offloading a bridge port. Tagging protocol drivers +are expected to call ``dsa_default_offload_fwd_mark(skb)`` for packets which +have already been autonomously forwarded in the forwarding domain of the +ingress switch port. DSA, through ``dsa_port_devlink_setup()``, considers all +switch ports part of the same tree ID to be part of the same bridge forwarding +domain (capable of autonomous forwarding to each other). + +Offloading the TX forwarding process of a bridge is a distinct concept from +simply offloading its forwarding plane, and refers to the ability of certain +driver and tag protocol combinations to transmit a single skb coming from the +bridge device's transmit function to potentially multiple egress ports (and +thereby avoid its cloning in software). + +Packets for which the bridge requests this behavior are called data plane +packets and have ``skb->offload_fwd_mark`` set to true in the tag protocol +driver's ``xmit`` function. Data plane packets are subject to FDB lookup, +hardware learning on the CPU port, and do not override the port STP state. +Additionally, replication of data plane packets (multicast, flooding) is +handled in hardware and the bridge driver will transmit a single skb for each +packet that may or may not need replication. + +When the TX forwarding offload is enabled, the tag protocol driver is +responsible to inject packets into the data plane of the hardware towards the +correct bridging domain (FID) that the port is a part of. The port may be +VLAN-unaware, and in this case the FID must be equal to the FID used by the +driver for its VLAN-unaware address database associated with that bridge. +Alternatively, the bridge may be VLAN-aware, and in that case, it is guaranteed +that the packet is also VLAN-tagged with the VLAN ID that the bridge processed +this packet in. It is the responsibility of the hardware to untag the VID on +the egress-untagged ports, or keep the tag on the egress-tagged ones. + - ``port_bridge_join``: bridge layer function invoked when a given switch port is added to a bridge, this function should do what's necessary at the switch level to permit the joining port to be added to the relevant logical domain for it to ingress/egress traffic with other members of the bridge. + By setting the ``tx_fwd_offload`` argument to true, the TX forwarding process + of this bridge is also offloaded. - ``port_bridge_leave``: bridge layer function invoked when a given switch port is removed from a bridge, this function should do what's necessary at the switch level to deny the leaving port from ingress/egress traffic from the - remaining bridge members. When the port leaves the bridge, it should be aged - out at the switch hardware for the switch to (re) learn MAC addresses behind - this port. + remaining bridge members. - ``port_stp_state_set``: bridge layer function invoked when a given switch port STP state is computed by the bridge layer and should be propagated to switch - hardware to forward/block/learn traffic. The switch driver is responsible for - computing a STP state change based on current and asked parameters and perform - the relevant ageing based on the intersection results + hardware to forward/block/learn traffic. - ``port_bridge_flags``: bridge layer function invoked when a port must configure its settings for e.g. flooding of unknown traffic or source address @@ -667,21 +931,11 @@ Bridge layer CPU port, and flooding towards the CPU port should also be enabled, due to a lack of an explicit address filtering mechanism in the DSA core. -- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after - ``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to - a non-zero value. Returning success in this function activates the TX - forwarding offload bridge feature for this port, which enables the tagging - protocol driver to inject data plane packets towards the bridging domain that - the port is a part of. Data plane packets are subject to FDB lookup, hardware - learning on the CPU port, and do not override the port STP state. - Additionally, replication of data plane packets (multicast, flooding) is - handled in hardware and the bridge driver will transmit a single skb for each - packet that needs replication. The method is provided as a configuration - point for drivers that need to configure the hardware for enabling this - feature. - -- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoked when a driver - leaves a bridge port which had the TX forwarding offload feature enabled. +- ``port_fast_age``: bridge layer function invoked when flushing the + dynamically learned FDB entries on the port is necessary. This is called when + transitioning from an STP state where learning should take place to an STP + state where it shouldn't, or when leaving a bridge, or when address learning + is turned off via ``port_bridge_flags``. Bridge VLAN filtering --------------------- @@ -697,55 +951,44 @@ Bridge VLAN filtering allowed. - ``port_vlan_add``: bridge layer function invoked when a VLAN is configured - (tagged or untagged) for the given switch port. If the operation is not - supported by the hardware, this function should return ``-EOPNOTSUPP`` to - inform the bridge code to fallback to a software implementation. + (tagged or untagged) for the given switch port. The CPU port becomes a member + of a VLAN only if a foreign bridge port is also a member of it (and + forwarding needs to take place in software), or the VLAN is installed to the + VLAN group of the bridge device itself, for termination purposes + (``bridge vlan add dev br0 vid 100 self``). VLANs on shared ports are + reference counted and removed when there is no user left. Drivers do not need + to manually install a VLAN on the CPU port. - ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the given switch port -- ``port_vlan_dump``: bridge layer function invoked with a switchdev callback - function that the driver has to call for each VLAN the given port is a member - of. A switchdev object is used to carry the VID and bridge flags. - - ``port_fdb_add``: bridge layer function invoked when the bridge wants to install a Forwarding Database entry, the switch hardware should be programmed with the specified address in the specified VLAN Id in the forwarding database - associated with this VLAN ID. If the operation is not supported, this - function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to - a software implementation. - -.. note:: VLAN ID 0 corresponds to the port private database, which, in the context - of DSA, would be its port-based VLAN, used by the associated bridge device. + associated with this VLAN ID. - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a Forwarding Database entry, the switch hardware should be programmed to delete the specified MAC address from the specified VLAN ID if it was mapped into this port forwarding database -- ``port_fdb_dump``: bridge layer function invoked with a switchdev callback - function that the driver has to call for each MAC address known to be behind - the given port. A switchdev object is used to carry the VID and FDB info. +- ``port_fdb_dump``: bridge bypass function invoked by ``ndo_fdb_dump`` on the + physical DSA port interfaces. Since DSA does not attempt to keep in sync its + hardware FDB entries with the software bridge, this method is implemented as + a means to view the entries visible on user ports in the hardware database. + The entries reported by this function have the ``self`` flag in the output of + the ``bridge fdb show`` command. - ``port_mdb_add``: bridge layer function invoked when the bridge wants to install - a multicast database entry. If the operation is not supported, this function - should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to a - software implementation. The switch hardware should be programmed with the + a multicast database entry. The switch hardware should be programmed with the specified address in the specified VLAN ID in the forwarding database associated with this VLAN ID. -.. note:: VLAN ID 0 corresponds to the port private database, which, in the context - of DSA, would be its port-based VLAN, used by the associated bridge device. - - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a multicast database entry, the switch hardware should be programmed to delete the specified MAC address from the specified VLAN ID if it was mapped into this port forwarding database. -- ``port_mdb_dump``: bridge layer function invoked with a switchdev callback - function that the driver has to call for each MAC address known to be behind - the given port. A switchdev object is used to carry the VID and MDB info. - Link aggregation ---------------- diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 9f41961d11d5..a759872a2883 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -202,6 +202,12 @@ neigh/default/unres_qlen - INTEGER Default: 101 +neigh/default/interval_probe_time_ms - INTEGER + The probe interval for neighbor entries with NTF_MANAGED flag, + the min value is 1. + + Default: 5000 + mtu_expires - INTEGER Time, in seconds, that cached PMTU information is kept. @@ -630,6 +636,16 @@ tcp_recovery - INTEGER Default: 0x1 +tcp_reflect_tos - BOOLEAN + For listening sockets, reuse the DSCP value of the initial SYN message + for outgoing packets. This allows to have both directions of a TCP + stream to use the same DSCP value, assuming DSCP remains unchanged for + the lifetime of the connection. + + This options affects both IPv4 and IPv6. + + Default: 0 (disabled) + tcp_reordering - INTEGER Initial reordering level of packets in a TCP stream. TCP stack can then dynamically adjust flow reordering level @@ -1019,7 +1035,10 @@ tcp_limit_output_bytes - INTEGER tcp_challenge_ack_limit - INTEGER Limits number of Challenge ACK sent per second, as recommended in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks) - Default: 1000 + Note that this per netns rate limit can allow some side channel + attacks and probably should not be enabled. + TCP stack implements per TCP socket limits anyway. + Default: INT_MAX (unlimited) UDP variables ============= @@ -1052,11 +1071,7 @@ udp_rmem_min - INTEGER Default: 4K udp_wmem_min - INTEGER - Minimal size of send buffer used by UDP sockets in moderation. - Each UDP socket is able to use the size for sending data, even if - total pages of UDP sockets exceed udp_mem pressure. The unit is byte. - - Default: 4K + UDP does not have tx memory accounting and this tunable has no effect. RAW variables ============= @@ -1085,7 +1100,7 @@ cipso_cache_enable - BOOLEAN cipso_cache_bucket_size - INTEGER The CIPSO label cache consists of a fixed size hash table with each hash bucket containing a number of cache entries. This variable limits - the number of entries in each hash bucket; the larger the value the + the number of entries in each hash bucket; the larger the value is, the more CIPSO label mappings that can be cached. When the number of entries in a given hash bucket reaches this limit adding new entries causes the oldest entry in the bucket to be removed to make room. @@ -1179,7 +1194,7 @@ ip_autobind_reuse - BOOLEAN option should only be set by experts. Default: 0 -ip_dynaddr - BOOLEAN +ip_dynaddr - INTEGER If set non-zero, enables support for dynamic addresses. If set to a non-zero value larger than 1, a kernel log message will be printed when dynamic address rewriting @@ -1627,12 +1642,15 @@ arp_notify - BOOLEAN or hardware address changes. == ========================================================== -arp_accept - BOOLEAN - Define behavior for gratuitous ARP frames who's IP is not - already present in the ARP table: +arp_accept - INTEGER + Define behavior for accepting gratuitous ARP (garp) frames from devices + that are not already present in the ARP table: - 0 - don't create new entries in the ARP table - 1 - create new entries in the ARP table + - 2 - create new entries only if the source IP address is in the same + subnet as an address configured on the interface that received the + garp message. Both replies and requests type gratuitous arp will trigger the ARP table to be updated, if this setting is on. @@ -2474,27 +2492,36 @@ drop_unsolicited_na - BOOLEAN By default this is turned off. -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. +accept_untracked_na - INTEGER + Define behavior for accepting neighbor advertisements from devices that + are absent in the neighbor cache: - This is as per router-side behaviour documented in RFC9131. + - 0 - (default) Do not accept unsolicited and untracked neighbor + advertisements. - This has lower precedence than drop_unsolicited_na. + - 1 - Add a new neighbor cache entry in STALE state for routers on + receiving a neighbor advertisement (either solicited or unsolicited) + with target link-layer address option specified if no neighbor entry + is already present for the advertised IPv6 address. Without this knob, + NAs received for untracked addresses (absent in neighbor cache) are + silently ignored. - This will optimize the return path for the initial off-link communication - that is initiated by a directly connected host, by ensuring that - the first-hop router which turns on this setting doesn't have to - buffer the initial return packets to do neighbour-solicitation. - The prerequisite is that the host is configured to send - unsolicited neighbour advertisements on interface bringup. - This setting should be used in conjunction with the ndisc_notify setting - on the host to satisfy this prerequisite. + This is as per router-side behavior documented in RFC9131. - By default this is turned off. + 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 the first-hop router which turns on this setting doesn't + have to buffer the initial return packets to do neighbor-solicitation. + The prerequisite is that the host is configured to send unsolicited + neighbor advertisements on interface bringup. This setting should be + used in conjunction with the ndisc_notify setting on the host to + satisfy this prerequisite. + + - 2 - Extend option (1) to add a new neighbor cache entry only if the + source IP address is in the same subnet as an address configured on + the interface that received the neighbor advertisement. enhanced_dad - BOOLEAN Include a nonce option in the IPv6 neighbor solicitation messages used for @@ -2870,7 +2897,14 @@ sctp_rmem - vector of 3 INTEGERs: min, default, max Default: 4K sctp_wmem - vector of 3 INTEGERs: min, default, max - Currently this tunable has no effect. + Only the first value ("min") is used, "default" and "max" are + ignored. + + min: Minimum size of send buffer that can be used by SCTP sockets. + It is guaranteed to each SCTP socket (but not association) even + under moderate memory pressure. + + Default: 4K addr_scope_policy - INTEGER Control IPv4 address scoping - draft-stewart-tsvwg-sctp-ipv4-00 diff --git a/Documentation/networking/ipvlan.rst b/Documentation/networking/ipvlan.rst index 694adcba36b0..0000c1d383bc 100644 --- a/Documentation/networking/ipvlan.rst +++ b/Documentation/networking/ipvlan.rst @@ -11,7 +11,7 @@ Initial Release: ================ This is conceptually very similar to the macvlan driver with one major exception of using L3 for mux-ing /demux-ing among slaves. This property makes -the master device share the L2 with it's slave devices. I have developed this +the master device share the L2 with its slave devices. I have developed this driver in conjunction with network namespaces and not sure if there is use case outside of it. diff --git a/Documentation/networking/l2tp.rst b/Documentation/networking/l2tp.rst index 498b382d25a0..7f383e99dbad 100644 --- a/Documentation/networking/l2tp.rst +++ b/Documentation/networking/l2tp.rst @@ -530,7 +530,7 @@ its tunnel close actions. For L2TPIP sockets, the socket's close handler initiates the same tunnel close actions. All sessions are first closed. Each session drops its tunnel ref. When the tunnel ref reaches zero, the tunnel puts its socket ref. When the socket is -eventually destroyed, it's sk_destruct finally frees the L2TP tunnel +eventually destroyed, its sk_destruct finally frees the L2TP tunnel context. Sessions diff --git a/Documentation/networking/sfp-phylink.rst b/Documentation/networking/sfp-phylink.rst index 328f8d39eeb3..55b65f607a64 100644 --- a/Documentation/networking/sfp-phylink.rst +++ b/Documentation/networking/sfp-phylink.rst @@ -203,7 +203,7 @@ this documentation. The :c:func:`validate` method should mask the supplied supported mask, and ``state->advertising`` with the supported ethtool link modes. These are the new ethtool link modes, so bitmask operations must be - used. For an example, see drivers/net/ethernet/marvell/mvneta.c. + used. For an example, see ``drivers/net/ethernet/marvell/mvneta.c``. The :c:func:`mac_link_state` method is used to read the link state from the MAC, and report back the settings that the MAC is currently @@ -224,7 +224,7 @@ this documentation. function should modify the state and only take the link down when absolutely necessary to change the MAC configuration. An example of how to do this can be found in :c:func:`mvneta_mac_config` in - drivers/net/ethernet/marvell/mvneta.c. + ``drivers/net/ethernet/marvell/mvneta.c``. For further information on these methods, please see the inline documentation in :c:type:`struct phylink_mac_ops <phylink_mac_ops>`. @@ -281,4 +281,4 @@ as necessary. For information describing the SFP cage in DT, please see the binding documentation in the kernel source tree -``Documentation/devicetree/bindings/net/sff,sfp.txt`` +``Documentation/devicetree/bindings/net/sff,sfp.yaml``. diff --git a/Documentation/networking/smc-sysctl.rst b/Documentation/networking/smc-sysctl.rst index 0987fd1bc220..742e90e6d822 100644 --- a/Documentation/networking/smc-sysctl.rst +++ b/Documentation/networking/smc-sysctl.rst @@ -21,3 +21,16 @@ autocorking_size - INTEGER know how/when to uncork their sockets. Default: 64K + +smcr_buf_type - INTEGER + Controls which type of sndbufs and RMBs to use in later newly created + SMC-R link group. Only for SMC-R. + + Default: 0 (physically contiguous sndbufs and RMBs) + + Possible values: + + - 0 - Use physically contiguous buffers + - 1 - Use virtually contiguous buffers + - 2 - Mixed use of the two types. Try physically contiguous buffers first. + If not available, use virtually contiguous buffers then. diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst index f1f4e6a85a29..bbf272e9d607 100644 --- a/Documentation/networking/switchdev.rst +++ b/Documentation/networking/switchdev.rst @@ -159,7 +159,7 @@ tools such as iproute2. The switchdev driver can know a particular port's position in the topology by monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a -bond will see it's upper master change. If that bond is moved into a bridge, +bond will see its upper master change. If that bond is moved into a bridge, the bond's upper master will change. And so on. The driver will track such movements to know what position a port is in in the overall topology by registering for netdevice events and acting on NETDEV_CHANGEUPPER. diff --git a/Documentation/networking/tls.rst b/Documentation/networking/tls.rst index 8cb2cd4e2a80..658ed3a71e1b 100644 --- a/Documentation/networking/tls.rst +++ b/Documentation/networking/tls.rst @@ -214,6 +214,44 @@ of calling send directly after a handshake using gnutls. Since it doesn't implement a full record layer, control messages are not supported. +Optional optimizations +---------------------- + +There are certain condition-specific optimizations the TLS ULP can make, +if requested. Those optimizations are either not universally beneficial +or may impact correctness, hence they require an opt-in. +All options are set per-socket using setsockopt(), and their +state can be checked using getsockopt() and via socket diag (``ss``). + +TLS_TX_ZEROCOPY_RO +~~~~~~~~~~~~~~~~~~ + +For device offload only. Allow sendfile() data to be transmitted directly +to the NIC without making an in-kernel copy. This allows true zero-copy +behavior when device offload is enabled. + +The application must make sure that the data is not modified between being +submitted and transmission completing. In other words this is mostly +applicable if the data sent on a socket via sendfile() is read-only. + +Modifying the data may result in different versions of the data being used +for the original TCP transmission and TCP retransmissions. To the receiver +this will look like TLS records had been tampered with and will result +in record authentication failures. + +TLS_RX_EXPECT_NO_PAD +~~~~~~~~~~~~~~~~~~~~ + +TLS 1.3 only. Expect the sender to not pad records. This allows the data +to be decrypted directly into user space buffers with TLS 1.3. + +This optimization is safe to enable only if the remote end is trusted, +otherwise it is an attack vector to doubling the TLS processing cost. + +If the record decrypted turns out to had been padded or is not a data +record it will be decrypted again into a kernel buffer without zero copy. +Such events are counted in the ``TlsDecryptRetry`` statistic. + Statistics ========== @@ -239,3 +277,12 @@ TLS implementation exposes the following per-namespace statistics - ``TlsDeviceRxResync`` - number of RX resyncs sent to NICs handling cryptography + +- ``TlsDecryptRetry`` - + number of RX records which had to be re-decrypted due to + ``TLS_RX_EXPECT_NO_PAD`` mis-prediction. Note that this counter will + also increment for non-data records. + +- ``TlsRxNoPadViolation`` - + number of data RX records which had to be re-decrypted due to + ``TLS_RX_EXPECT_NO_PAD`` mis-prediction. diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index feb257b7f350..ef341be2882b 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -20,20 +20,20 @@ possible source of information on its own, the EM framework intervenes as an abstraction layer which standardizes the format of power cost tables in the kernel, hence enabling to avoid redundant work. -The power values might be expressed in milli-Watts or in an 'abstract scale'. +The power values might be expressed in micro-Watts or in an 'abstract scale'. Multiple subsystems might use the EM and it is up to the system integrator to check that the requirements for the power value scale types are met. An example can be found in the Energy-Aware Scheduler documentation Documentation/scheduler/sched-energy.rst. For some subsystems like thermal or powercap power values expressed in an 'abstract scale' might cause issues. These subsystems are more interested in estimation of power used in the past, -thus the real milli-Watts might be needed. An example of these requirements can +thus the real micro-Watts might be needed. An example of these requirements can be found in the Intelligent Power Allocation in Documentation/driver-api/thermal/power_allocator.rst. Kernel subsystems might implement automatic detection to check whether EM registered devices have inconsistent scale (based on EM internal flag). Important thing to keep in mind is that when the power values are expressed in -an 'abstract scale' deriving real energy in milli-Joules would not be possible. +an 'abstract scale' deriving real energy in micro-Joules would not be possible. The figure below depicts an example of drivers (Arm-specific here, but the approach is applicable to any architecture) providing power costs to the EM @@ -98,7 +98,7 @@ Drivers are expected to register performance domains into the EM framework by calling the following API:: int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, - struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts); + struct em_data_callback *cb, cpumask_t *cpus, bool microwatts); Drivers must provide a callback function returning <frequency, power> tuples for each performance state. The callback function provided by the driver is free @@ -106,10 +106,10 @@ to fetch data from any relevant location (DT, firmware, ...), and by any mean deemed necessary. Only for CPU devices, drivers must specify the CPUs of the performance domains using cpumask. For other devices than CPUs the last argument must be set to NULL. -The last argument 'milliwatts' is important to set with correct value. Kernel +The last argument 'microwatts' is important to set with correct value. Kernel subsystems which use EM might rely on this flag to check if all EM devices use the same scale. If there are different scales, these subsystems might decide -to: return warning/error, stop working or panic. +to return warning/error, stop working or panic. See Section 3. for an example of driver implementing this callback, or Section 2.4 for further documentation on this API @@ -137,7 +137,7 @@ The .get_cost() allows to provide the 'cost' values which reflect the efficiency of the CPUs. This would allow to provide EAS information which has different relation than what would be forced by the EM internal formulas calculating 'cost' values. To register an EM for such platform, the -driver must set the flag 'milliwatts' to 0, provide .get_power() callback +driver must set the flag 'microwatts' to 0, provide .get_power() callback and provide .get_cost() callback. The EM framework would handle such platform properly during registration. A flag EM_PERF_DOMAIN_ARTIFICIAL is set for such platform. Special care should be taken by other frameworks which are using EM diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst index b04fb18cc4e2..a125544b4cb6 100644 --- a/Documentation/power/pci.rst +++ b/Documentation/power/pci.rst @@ -315,7 +315,7 @@ that these callbacks operate on:: configuration space */ unsigned int pme_support:5; /* Bitmask of states from which PME# can be generated */ - unsigned int pme_interrupt:1;/* Is native PCIe PME signaling used? */ + unsigned int pme_poll:1; /* Poll device's PME status bit */ unsigned int d1_support:1; /* Low power state D1 is supported */ unsigned int d2_support:1; /* Low power state D2 is supported */ unsigned int no_d1d2:1; /* D1 and D2 are forbidden */ diff --git a/Documentation/powerpc/elf_hwcaps.rst b/Documentation/powerpc/elf_hwcaps.rst new file mode 100644 index 000000000000..3366e5b18e67 --- /dev/null +++ b/Documentation/powerpc/elf_hwcaps.rst @@ -0,0 +1,231 @@ +.. _elf_hwcaps_powerpc: + +================== +POWERPC ELF HWCAPs +================== + +This document describes the usage and semantics of the powerpc ELF HWCAPs. + + +1. Introduction +--------------- + +Some hardware or software features are only available on some CPU +implementations, and/or with certain kernel configurations, but have no other +discovery mechanism available to userspace code. The kernel exposes the +presence of these features to userspace through a set of flags called HWCAPs, +exposed in the auxiliary vector. + +Userspace software can test for features by acquiring the AT_HWCAP or +AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant +flags are set, e.g.:: + + bool floating_point_is_present(void) + { + unsigned long HWCAPs = getauxval(AT_HWCAP); + if (HWCAPs & PPC_FEATURE_HAS_FPU) + return true; + + return false; + } + +Where software relies on a feature described by a HWCAP, it should check the +relevant HWCAP flag to verify that the feature is present before attempting to +make use of the feature. + +HWCAP is the preferred method to test for the presence of a feature rather +than probing through other means, which may not be reliable or may cause +unpredictable behaviour. + +Software that targets a particular platform does not necessarily have to +test for required or implied features. For example if the program requires +FPU, VMX, VSX, it is not necessary to test those HWCAPs, and it may be +impossible to do so if the compiler generates code requiring those features. + +2. Facilities +------------- + +The Power ISA uses the term "facility" to describe a class of instructions, +registers, interrupts, etc. The presence or absence of a facility indicates +whether this class is available to be used, but the specifics depend on the +ISA version. For example, if the VSX facility is available, the VSX +instructions that can be used differ between the v3.0B and v3.1B ISA +versions. + +3. Categories +------------- + +The Power ISA before v3.0 uses the term "category" to describe certain +classes of instructions and operating modes which may be optional or +mutually exclusive, the exact meaning of the HWCAP flag may depend on +context, e.g., the presence of the BOOKE feature implies that the server +category is not implemented. + +4. HWCAP allocation +------------------- + +HWCAPs are allocated as described in Power Architecture 64-Bit ELF V2 ABI +Specification (which will be reflected in the kernel's uapi headers). + +5. The HWCAPs exposed in AT_HWCAP +--------------------------------- + +PPC_FEATURE_32 + 32-bit CPU + +PPC_FEATURE_64 + 64-bit CPU (userspace may be running in 32-bit mode). + +PPC_FEATURE_601_INSTR + The processor is PowerPC 601. + Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601") + +PPC_FEATURE_HAS_ALTIVEC + Vector (aka Altivec, VMX) facility is available. + +PPC_FEATURE_HAS_FPU + Floating point facility is available. + +PPC_FEATURE_HAS_MMU + Memory management unit is present and enabled. + +PPC_FEATURE_HAS_4xxMAC + The processor is 40x or 44x family. + +PPC_FEATURE_UNIFIED_CACHE + The processor has a unified L1 cache for instructions and data, as + found in NXP e200. + Unused in the kernel since 39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)") + +PPC_FEATURE_HAS_SPE + Signal Processing Engine facility is available. + +PPC_FEATURE_HAS_EFP_SINGLE + Embedded Floating Point single precision operations are available. + +PPC_FEATURE_HAS_EFP_DOUBLE + Embedded Floating Point double precision operations are available. + +PPC_FEATURE_NO_TB + The timebase facility (mftb instruction) is not available. + This is a 601 specific HWCAP, so if it is known that the processor + running is not a 601, via other HWCAPs or other means, it is not + required to test this bit before using the timebase. + Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601") + +PPC_FEATURE_POWER4 + The processor is POWER4 or PPC970/FX/MP. + POWER4 support dropped from the kernel since 471d7ff8b51b ("powerpc/64s: Remove POWER4 support") + +PPC_FEATURE_POWER5 + The processor is POWER5. + +PPC_FEATURE_POWER5_PLUS + The processor is POWER5+. + +PPC_FEATURE_CELL + The processor is Cell. + +PPC_FEATURE_BOOKE + The processor implements the embedded category ("BookE") architecture. + +PPC_FEATURE_SMT + The processor implements SMT. + +PPC_FEATURE_ICACHE_SNOOP + The processor icache is coherent with the dcache, and instruction storage + can be made consistent with data storage for the purpose of executing + instructions with the sequence (as described in, e.g., POWER9 Processor + User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)):: + + sync + icbi (to any address) + isync + +PPC_FEATURE_ARCH_2_05 + The processor supports the v2.05 userlevel architecture. Processors + supporting later architectures DO NOT set this feature. + +PPC_FEATURE_PA6T + The processor is PA6T. + +PPC_FEATURE_HAS_DFP + DFP facility is available. + +PPC_FEATURE_POWER6_EXT + The processor is POWER6. + +PPC_FEATURE_ARCH_2_06 + The processor supports the v2.06 userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE_HAS_VSX + VSX facility is available. + +PPC_FEATURE_PSERIES_PERFMON_COMPAT + The processor supports architected PMU events in the range 0xE0-0xFF. + +PPC_FEATURE_TRUE_LE + The processor supports true little-endian mode. + +PPC_FEATURE_PPC_LE + The processor supports "PowerPC Little-Endian", that uses address + munging to make storage access appear to be little-endian, but the + data is stored in a different format that is unsuitable to be + accessed by other agents not running in this mode. + +6. The HWCAPs exposed in AT_HWCAP2 +---------------------------------- + +PPC_FEATURE2_ARCH_2_07 + The processor supports the v2.07 userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE2_HTM + Transactional Memory feature is available. + +PPC_FEATURE2_DSCR + DSCR facility is available. + +PPC_FEATURE2_EBB + EBB facility is available. + +PPC_FEATURE2_ISEL + isel instruction is available. This is superseded by ARCH_2_07 and + later. + +PPC_FEATURE2_TAR + TAR facility is available. + +PPC_FEATURE2_VEC_CRYPTO + v2.07 crypto instructions are available. + +PPC_FEATURE2_HTM_NOSC + System calls fail if called in a transactional state, see + Documentation/powerpc/syscall64-abi.rst + +PPC_FEATURE2_ARCH_3_00 + The processor supports the v3.0B / v3.0C userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE2_HAS_IEEE128 + IEEE 128-bit binary floating point is supported with VSX + quad-precision instructions and data types. + +PPC_FEATURE2_DARN + darn instruction is available. + +PPC_FEATURE2_SCV + The scv 0 instruction may be used for system calls, see + Documentation/powerpc/syscall64-abi.rst. + +PPC_FEATURE2_HTM_NO_SUSPEND + A limited Transactional Memory facility that does not support suspend is + available, see Documentation/powerpc/transactional_memory.rst. + +PPC_FEATURE2_ARCH_3_1 + The processor supports the v3.1 userlevel architecture. Processors + supporting later architectures also set this feature. + +PPC_FEATURE2_MMA + MMA facility is available. diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst index 0f7d3c495693..85e80e30160b 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -17,6 +17,7 @@ powerpc dawr-power9 dscr eeh-pci-error-recovery + elf_hwcaps elfnote firmware-assisted-dump hvcs diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index bd36ecb29409..906235c11c24 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -10,8 +10,7 @@ of conventions and procedures which are used in the posting of patches; following them will make life much easier for everybody involved. This document will attempt to cover these expectations in reasonable detail; more information can also be found in the files -:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`, -:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` +:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`. diff --git a/Documentation/process/8.Conclusion.rst b/Documentation/process/8.Conclusion.rst index b32a40215858..8c847dffe76b 100644 --- a/Documentation/process/8.Conclusion.rst +++ b/Documentation/process/8.Conclusion.rst @@ -5,15 +5,13 @@ For more information There are numerous sources of information on Linux kernel development and related topics. First among those will always be the Documentation -directory found in the kernel source distribution. The top-level :ref:`process/howto.rst <process_howto>` -file is an important starting point; :ref:`process/submitting-patches.rst <submittingpatches>` -and :ref:`process/submitting-drivers.rst <submittingdrivers>` -are also something which all kernel developers should -read. Many internal kernel APIs are documented using the kerneldoc -mechanism; "make htmldocs" or "make pdfdocs" can be used to generate those -documents in HTML or PDF format (though the version of TeX shipped by some -distributions runs into internal limits and fails to process the documents -properly). +directory found in the kernel source distribution. Start with the +top-level :ref:`process/howto.rst <process_howto>`; also read +:ref:`process/submitting-patches.rst <submittingpatches>`. Many internal +kernel APIs are documented using the kerneldoc mechanism; "make htmldocs" +or "make pdfdocs" can be used to generate those documents in HTML or PDF +format (though the version of TeX shipped by some distributions runs into +internal limits and fails to process the documents properly). Various web sites discuss kernel development at all levels of detail. Your author would like to humbly suggest https://lwn.net/ as a source; diff --git a/Documentation/process/email-clients.rst b/Documentation/process/email-clients.rst index 16586f6cc888..fc2c46f3f82d 100644 --- a/Documentation/process/email-clients.rst +++ b/Documentation/process/email-clients.rst @@ -277,36 +277,61 @@ Thunderbird (GUI) Thunderbird is an Outlook clone that likes to mangle text, but there are ways to coerce it into behaving. +After doing the modifications, this includes installing the extensions, +you need to restart Thunderbird. + - Allow use of an external editor: - The easiest thing to do with Thunderbird and patches is to use an - "external editor" extension and then just use your favorite ``$EDITOR`` - for reading/merging patches into the body text. To do this, download - and install the extension, then add a button for it using - :menuselection:`View-->Toolbars-->Customize...` and finally just click on it - when in the :menuselection:`Compose` dialog. - - Please note that "external editor" requires that your editor must not - fork, or in other words, the editor must not return before closing. - You may have to pass additional flags or change the settings of your - editor. Most notably if you are using gvim then you must pass the -f - option to gvim by putting ``/usr/bin/gvim -f`` (if the binary is in - ``/usr/bin``) to the text editor field in :menuselection:`external editor` - settings. If you are using some other editor then please read its manual - to find out how to do this. + + The easiest thing to do with Thunderbird and patches is to use extensions + which open your favorite external editor. + + Here are some example extensions which are capable of doing this. + + - "External Editor Revived" + + https://github.com/Frederick888/external-editor-revived + + https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/ + + It requires installing a "native messaging host". + Please read the wiki which can be found here: + https://github.com/Frederick888/external-editor-revived/wiki + + - "External Editor" + + https://github.com/exteditor/exteditor + + To do this, download and install the extension, then open the + :menuselection:`compose` window, add a button for it using + :menuselection:`View-->Toolbars-->Customize...` + then just click on the new button when you wish to use the external editor. + + Please note that "External Editor" requires that your editor must not + fork, or in other words, the editor must not return before closing. + You may have to pass additional flags or change the settings of your + editor. Most notably if you are using gvim then you must pass the -f + option to gvim by putting ``/usr/bin/gvim --nofork"`` (if the binary is in + ``/usr/bin``) to the text editor field in :menuselection:`external editor` + settings. If you are using some other editor then please read its manual + to find out how to do this. To beat some sense out of the internal editor, do this: -- Edit your Thunderbird config settings so that it won't use ``format=flowed``. - Go to :menuselection:`edit-->preferences-->advanced-->config editor` to bring up - the thunderbird's registry editor. +- Edit your Thunderbird config settings so that it won't use ``format=flowed``! + Go to your main window and find the button for your main dropdown menu. + :menuselection:`Main Menu-->Preferences-->General-->Config Editor...` + to bring up the thunderbird's registry editor. -- Set ``mailnews.send_plaintext_flowed`` to ``false`` + - Set ``mailnews.send_plaintext_flowed`` to ``false`` -- Set ``mailnews.wraplength`` from ``72`` to ``0`` + - Set ``mailnews.wraplength`` from ``72`` to ``0`` -- :menuselection:`View-->Message Body As-->Plain Text` +- Don't write HTML messages! Go to the main window + :menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`! + There you can disable the option "Compose messages in HTML format". -- :menuselection:`View-->Character Encoding-->Unicode (UTF-8)` +- Open messages only as plain text! Go to the main window + :menuselection:`Main Menu-->View-->Message Body As-->Plain Text`! TkRat (GUI) *********** diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index 95999302d279..b6b4481e2474 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -244,7 +244,7 @@ disclosure of a particular issue, unless requested by a response team or by an involved disclosed party. The current ambassadors list: ============= ======================================================== - AMD Tom Lendacky <tom.lendacky@amd.com> + AMD Tom Lendacky <thomas.lendacky@amd.com> Ampere Darren Hart <darren@os.amperecomputing.com> ARM Catalin Marinas <catalin.marinas@arm.com> IBM Power Anton Blanchard <anton@linux.ibm.com> @@ -264,6 +264,9 @@ an involved disclosed party. The current ambassadors list: Amazon Google Kees Cook <keescook@chromium.org> + + GCC + LLVM Nick Desaulniers <ndesaulniers@google.com> ============= ======================================================== If you want your organization to be added to the ambassadors list, please diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index e4beeca57e5f..cd6997a9d203 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -105,8 +105,8 @@ required reading: patches if these rules are followed, and many people will only review code if it is in the proper style. - :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` - These files describe in explicit detail how to successfully create + :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` + This file describes in explicit detail how to successfully create and send a patch, including (but not limited to): - Email contents diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 3587dae4d0ef..2ba2a1582bbe 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -40,7 +40,6 @@ Other guides to the community that are of interest to most developers are: :maxdepth: 1 changes - submitting-drivers stable-api-nonsense management-style stable-kernel-rules diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index da9527502ef0..306ad373a002 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -1,9 +1,10 @@ .. _kernel_docs: -Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel -============================================================================================= +Index of Further Kernel Documentation +===================================== - Juan-Mariano de Goyeneche <jmseyas@dit.upm.es> +Initial Author: Juan-Mariano de Goyeneche (<jmseyas@dit.upm.es>; +email address is defunct now.) The need for a document like this one became apparent in the linux-kernel mailing list as the same questions, asking for pointers @@ -16,21 +17,16 @@ philosophy and design decisions behind this code. Unfortunately, not many documents are available for beginners to start. And, even if they exist, there was no "well-known" place which -kept track of them. These lines try to cover this lack. All documents -available on line known by the author are listed, while some reference -books are also mentioned. +kept track of them. These lines try to cover this lack. PLEASE, if you know any paper not listed here or write a new document, -send me an e-mail, and I'll include a reference to it here. Any -corrections, ideas or comments are also welcomed. +include a reference to it here, following the kernel's patch submission +process. Any corrections, ideas or comments are also welcome. -The papers that follow are listed in no particular order. All are -cataloged with the following fields: the document's "Title", the -"Author"/s, the "URL" where they can be found, some "Keywords" helpful -when searching for specific topics, and a brief "Description" of the -Document. - -Enjoy! +All documents are cataloged with the following fields: the document's +"Title", the "Author"/s, the "URL" where they can be found, some +"Keywords" helpful when searching for specific topics, and a brief +"Description" of the Document. .. note:: @@ -83,6 +79,18 @@ On-line docs Finally this trace-log is used as base for more a exact conceptual exploration and description of the Linux TCP/IP implementation.* + * Title: **The Linux Kernel Module Programming Guide** + + :Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram, + Jim Huang. + :URL: https://sysprog21.github.io/lkmpg/ + :Date: 2021 + :Keywords: modules, GPL book, /proc, ioctls, system calls, + interrupt handlers . + :Description: A very nice GPL book on the topic of modules + programming. Lots of examples. Currently the new version is being + actively maintained at https://github.com/sysprog21/lkmpg. + * Title: **On submitting kernel Patches** :Author: Andi Kleen @@ -108,7 +116,7 @@ On-line docs * Title: **Writing an ALSA Driver** :Author: Takashi Iwai <tiwai@suse.de> - :URL: http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html + :URL: https://www.kernel.org/doc/html/latest/sound/kernel-api/writing-an-alsa-driver.html :Date: 2005 :Keywords: ALSA, sound, soundcard, driver, lowlevel, hardware. :Description: Advanced Linux Sound Architecture for developers, @@ -126,17 +134,19 @@ On-line docs describes how to write user-mode utilities for communicating with Card Services. - * Title: **The Linux Kernel Module Programming Guide** - - :Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram, - Jim Huang. - :URL: https://sysprog21.github.io/lkmpg/ - :Date: 2021 - :Keywords: modules, GPL book, /proc, ioctls, system calls, - interrupt handlers . - :Description: A very nice GPL book on the topic of modules - programming. Lots of examples. Currently the new version is being - actively maintained at https://github.com/sysprog21/lkmpg. + * Title: **How NOT to write kernel drivers** + + :Author: Arjan van de Ven. + :URL: https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf + :Date: 2002 + :Keywords: driver. + :Description: Programming bugs and Do-nots in kernel driver development + :Abstract: *Quit a few tutorials, articles and books give an introduction + on how to write Linux kernel drivers. Unfortunately the things one + should NOT do in Linux kernel code is either only a minor appendix + or, more commonly, completely absent. This paper tries to briefly touch + the areas in which the most common and serious bugs and do-nots are + encountered.* * Title: **Global spinlock list and usage** diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index c456b5225d66..d14007081595 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -6,6 +6,15 @@ netdev FAQ ========== +tl;dr +----- + + - designate your patch to a tree - ``[PATCH net]`` or ``[PATCH net-next]`` + - for fixes the ``Fixes:`` tag is required, regardless of the tree + - don't post large series (> 15 patches), break them up + - don't repost your patches within one 24h period + - reverse xmas tree + What is netdev? --------------- It is a mailing list for all network-related Linux stuff. This @@ -136,6 +145,20 @@ it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. +How do I divide my work into patches? +------------------------------------- + +Put yourself in the shoes of the reviewer. Each patch is read separately +and therefore should constitute a comprehensible step towards your stated +goal. + +Avoid sending series longer than 15 patches. Larger series takes longer +to review as reviewers will defer looking at it until they find a large +chunk of time. A small series can be reviewed in a short time, so Maintainers +just do it. As a result, a sequence of smaller series gets merged quicker and +with better review coverage. Re-posting large series also increases the mailing +list traffic. + I made changes to only a few patches in a patch series should I resend only those changed? ------------------------------------------------------------------------------------------ No, please resend the entire patch series and make sure you do number your @@ -183,6 +206,19 @@ it is requested that you make it look like this:: * another line of text */ +What is "reverse xmas tree"? +---------------------------- + +Netdev has a convention for ordering local variables in functions. +Order the variable declaration lines longest to shortest, e.g.:: + + struct scatterlist *sg; + struct sk_buff *skb; + int err, i; + +If there are dependencies between the variables preventing the ordering +move the initialization out of line. + I am working in existing code which uses non-standard formatting. Which formatting should I use? ------------------------------------------------------------------------------------------------ Make your code follow the most recent guidelines, so that eventually all code diff --git a/Documentation/process/submitting-drivers.rst b/Documentation/process/submitting-drivers.rst deleted file mode 100644 index 8413b693d10d..000000000000 --- a/Documentation/process/submitting-drivers.rst +++ /dev/null @@ -1,194 +0,0 @@ -.. _submittingdrivers: - -Submitting Drivers For The Linux Kernel -======================================= - -This document is intended to explain how to submit device drivers to the -various kernel trees. Note that if you are interested in video card drivers -you should probably talk to XFree86 (https://www.xfree86.org/) and/or X.Org -(https://x.org/) instead. - -.. note:: - - This document is old and has seen little maintenance in recent years; it - should probably be updated or, perhaps better, just deleted. Most of - what is here can be found in the other development documents anyway. - - Oh, and we don't really recommend submitting changes to XFree86 :) - -Also read the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` -document. - - -Allocating Device Numbers -------------------------- - -Major and minor numbers for block and character devices are allocated -by the Linux assigned name and number authority (currently this is -Torben Mathiasen). The site is https://www.lanana.org/. This -also deals with allocating numbers for devices that are not going to -be submitted to the mainstream kernel. -See :ref:`Documentation/admin-guide/devices.rst <admin_devices>` -for more information on this. - -If you don't use assigned numbers then when your device is submitted it will -be given an assigned number even if that is different from values you may -have shipped to customers before. - -Who To Submit Drivers To ------------------------- - -Linux 2.0: - No new drivers are accepted for this kernel tree. - -Linux 2.2: - No new drivers are accepted for this kernel tree. - -Linux 2.4: - If the code area has a general maintainer then please submit it to - the maintainer listed in MAINTAINERS in the kernel file. If the - maintainer does not respond or you cannot find the appropriate - maintainer then please contact Willy Tarreau <w@1wt.eu>. - -Linux 2.6 and upper: - The same rules apply as 2.4 except that you should follow linux-kernel - to track changes in API's. The final contact point for Linux 2.6+ - submissions is Andrew Morton. - -What Criteria Determine Acceptance ----------------------------------- - -Licensing: - The code must be released to us under the - GNU General Public License. If you wish the driver to be - useful to other communities such as BSD you may release - under multiple licenses. If you choose to release under - licenses other than the GPL, you should include your - rationale for your license choices in your cover letter. - See accepted licenses at include/linux/module.h - -Copyright: - The copyright owner must agree to use of GPL. - It's best if the submitter and copyright owner - are the same person/entity. If not, the name of - the person/entity authorizing use of GPL should be - listed in case it's necessary to verify the will of - the copyright owner. - -Interfaces: - If your driver uses existing interfaces and behaves like - other drivers in the same class it will be much more likely - to be accepted than if it invents gratuitous new ones. - If you need to implement a common API over Linux and NT - drivers do it in userspace. - -Code: - Please use the Linux style of code formatting as documented - in :ref:`Documentation/process/coding-style.rst <codingStyle>`. - If you have sections of code - that need to be in other formats, for example because they - are shared with a windows driver kit and you want to - maintain them just once separate them out nicely and note - this fact. - -Portability: - Pointers are not always 32bits, not all computers are little - endian, people do not all have floating point and you - shouldn't use inline x86 assembler in your driver without - careful thought. Pure x86 drivers generally are not popular. - If you only have x86 hardware it is hard to test portability - but it is easy to make sure the code can easily be made - portable. - -Clarity: - It helps if anyone can see how to fix the driver. It helps - you because you get patches not bug reports. If you submit a - driver that intentionally obfuscates how the hardware works - it will go in the bitbucket. - -PM support: - Since Linux is used on many portable and desktop systems, your - driver is likely to be used on such a system and therefore it - should support basic power management by implementing, if - necessary, the .suspend and .resume methods used during the - system-wide suspend and resume transitions. You should verify - that your driver correctly handles the suspend and resume, but - if you are unable to ensure that, please at least define the - .suspend method returning the -ENOSYS ("Function not - implemented") error. You should also try to make sure that your - driver uses as little power as possible when it's not doing - anything. For the driver testing instructions see - Documentation/power/drivers-testing.rst and for a relatively - complete overview of the power management issues related to - drivers see :ref:`Documentation/driver-api/pm/devices.rst <driverapi_pm_devices>`. - -Control: - In general if there is active maintenance of a driver by - the author then patches will be redirected to them unless - they are totally obvious and without need of checking. - If you want to be the contact and update point for the - driver it is a good idea to state this in the comments, - and include an entry in MAINTAINERS for your driver. - -What Criteria Do Not Determine Acceptance ------------------------------------------ - -Vendor: - Being the hardware vendor and maintaining the driver is - often a good thing. If there is a stable working driver from - other people already in the tree don't expect 'we are the - vendor' to get your driver chosen. Ideally work with the - existing driver author to build a single perfect driver. - -Author: - It doesn't matter if a large Linux company wrote the driver, - or you did. Nobody has any special access to the kernel - tree. Anyone who tells you otherwise isn't telling the - whole story. - - -Resources ---------- - -Linux kernel master tree: - ftp.\ *country_code*\ .kernel.org:/pub/linux/kernel/... - - where *country_code* == your country code, such as - **us**, **uk**, **fr**, etc. - - https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git - -Linux kernel mailing list: - linux-kernel@vger.kernel.org - [mail majordomo@vger.kernel.org to subscribe] - -Linux Device Drivers, Third Edition (covers 2.6.10): - https://lwn.net/Kernel/LDD3/ (free version) - -LWN.net: - Weekly summary of kernel development activity - https://lwn.net/ - - 2.6 API changes: - - https://lwn.net/Articles/2.6-kernel-api/ - - Porting drivers from prior kernels to 2.6: - - https://lwn.net/Articles/driver-porting/ - -KernelNewbies: - Documentation and assistance for new kernel programmers - - https://kernelnewbies.org/ - -Linux USB project: - http://www.linux-usb.org/ - -How to NOT write kernel driver by Arjan van de Ven: - https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf - -Kernel Janitor: - https://kernelnewbies.org/KernelJanitors - -GIT, Fast Version Control System: - https://git-scm.com/ diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index a1cb6280fbcf..be49d8f2601b 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -12,9 +12,8 @@ This document contains a large number of suggestions in a relatively terse format. For detailed information on how the kernel development process works, see Documentation/process/development-process.rst. Also, read Documentation/process/submit-checklist.rst -for a list of items to check before submitting code. If you are submitting -a driver, also read Documentation/process/submitting-drivers.rst; for device -tree binding patches, read +for a list of items to check before submitting code. +For device tree binding patches, read Documentation/devicetree/bindings/submitting-patches.rst. This documentation assumes that you're using ``git`` to prepare your patches. diff --git a/Documentation/s390/index.rst b/Documentation/s390/index.rst index b10ca9192557..73c79bf586fd 100644 --- a/Documentation/s390/index.rst +++ b/Documentation/s390/index.rst @@ -12,6 +12,7 @@ s390 Architecture qeth s390dbf vfio-ap + vfio-ap-locking vfio-ccw zfcpdump common_io diff --git a/Documentation/s390/vfio-ap-locking.rst b/Documentation/s390/vfio-ap-locking.rst new file mode 100644 index 000000000000..0dfcdb562e21 --- /dev/null +++ b/Documentation/s390/vfio-ap-locking.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +VFIO AP Locks Overview +====================== +This document describes the locks that are pertinent to the secure operation +of the vfio_ap device driver. Throughout this document, the following variables +will be used to denote instances of the structures herein described: + +.. code-block:: c + + struct ap_matrix_dev *matrix_dev; + struct ap_matrix_mdev *matrix_mdev; + struct kvm *kvm; + +The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h) +--------------------------------------------------------------- + +.. code-block:: c + + struct ap_matrix_dev { + ... + struct list_head mdev_list; + struct mutex mdevs_lock; + ... + } + +The Matrix Devices Lock (matrix_dev->mdevs_lock) is implemented as a global +mutex contained within the single object of struct ap_matrix_dev. This lock +controls access to all fields contained within each matrix_mdev +(matrix_dev->mdev_list). This lock must be held while reading from, writing to +or using the data from a field contained within a matrix_mdev instance +representing one of the vfio_ap device driver's mediated devices. + +The KVM Lock (include/linux/kvm_host.h) +--------------------------------------- + +.. code-block:: c + + struct kvm { + ... + struct mutex lock; + ... + } + +The KVM Lock (kvm->lock) controls access to the state data for a KVM guest. This +lock must be held by the vfio_ap device driver while one or more AP adapters, +domains or control domains are being plugged into or unplugged from the guest. + +The KVM pointer is stored in the in the matrix_mdev instance +(matrix_mdev->kvm = kvm) containing the state of the mediated device that has +been attached to the KVM guest. + +The Guests Lock (drivers/s390/crypto/vfio_ap_private.h) +----------------------------------------------------------- + +.. code-block:: c + + struct ap_matrix_dev { + ... + struct list_head mdev_list; + struct mutex guests_lock; + ... + } + +The Guests Lock (matrix_dev->guests_lock) controls access to the +matrix_mdev instances (matrix_dev->mdev_list) that represent mediated devices +that hold the state for the mediated devices that have been attached to a +KVM guest. This lock must be held: + +1. To control access to the KVM pointer (matrix_mdev->kvm) while the vfio_ap + device driver is using it to plug/unplug AP devices passed through to the KVM + guest. + +2. To add matrix_mdev instances to or remove them from matrix_dev->mdev_list. + This is necessary to ensure the proper locking order when the list is perused + to find an ap_matrix_mdev instance for the purpose of plugging/unplugging + AP devices passed through to a KVM guest. + + For example, when a queue device is removed from the vfio_ap device driver, + if the adapter is passed through to a KVM guest, it will have to be + unplugged. In order to figure out whether the adapter is passed through, + the matrix_mdev object to which the queue is assigned will have to be + found. The KVM pointer (matrix_mdev->kvm) can then be used to determine if + the mediated device is passed through (matrix_mdev->kvm != NULL) and if so, + to unplug the adapter. + +It is not necessary to take the Guests Lock to access the KVM pointer if the +pointer is not used to plug/unplug devices passed through to the KVM guest; +however, in this case, the Matrix Devices Lock (matrix_dev->mdevs_lock) must be +held in order to access the KVM pointer since it is set and cleared under the +protection of the Matrix Devices Lock. A case in point is the function that +handles interception of the PQAP(AQIC) instruction sub-function. This handler +needs to access the KVM pointer only for the purposes of setting or clearing IRQ +resources, so only the matrix_dev->mdevs_lock needs to be held. + +The PQAP Hook Lock (arch/s390/include/asm/kvm_host.h) +----------------------------------------------------- + +.. code-block:: c + + typedef int (*crypto_hook)(struct kvm_vcpu *vcpu); + + struct kvm_s390_crypto { + ... + struct rw_semaphore pqap_hook_rwsem; + crypto_hook *pqap_hook; + ... + }; + +The PQAP Hook Lock is a r/w semaphore that controls access to the function +pointer of the handler ``(*kvm->arch.crypto.pqap_hook)`` to invoke when the +PQAP(AQIC) instruction sub-function is intercepted by the host. The lock must be +held in write mode when pqap_hook value is set, and in read mode when the +pqap_hook function is called. diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index f57ae621f33e..61a0a3c6c7b4 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -123,27 +123,24 @@ Let's now take a look at how AP instructions executed on a guest are interpreted by the hardware. A satellite control block called the Crypto Control Block (CRYCB) is attached to -our main hardware virtualization control block. The CRYCB contains three fields -to identify the adapters, usage domains and control domains assigned to the KVM -guest: +our main hardware virtualization control block. The CRYCB contains an AP Control +Block (APCB) that has three fields to identify the adapters, usage domains and +control domains assigned to the KVM guest: * The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned - to the KVM guest. Each bit in the mask, from left to right (i.e. from most - significant to least significant bit in big endian order), corresponds to + to the KVM guest. Each bit in the mask, from left to right, corresponds to an APID from 0-255. If a bit is set, the corresponding adapter is valid for use by the KVM guest. * The AP Queue Mask (AQM) field is a bit mask identifying the AP usage domains - assigned to the KVM guest. Each bit in the mask, from left to right (i.e. from - most significant to least significant bit in big endian order), corresponds to - an AP queue index (APQI) from 0-255. If a bit is set, the corresponding queue - is valid for use by the KVM guest. + assigned to the KVM guest. Each bit in the mask, from left to right, + corresponds to an AP queue index (APQI) from 0-255. If a bit is set, the + corresponding queue is valid for use by the KVM guest. * The AP Domain Mask field is a bit mask that identifies the AP control domains assigned to the KVM guest. The ADM bit mask controls which domains can be changed by an AP command-request message sent to a usage domain from the - guest. Each bit in the mask, from left to right (i.e. from most significant to - least significant bit in big endian order), corresponds to a domain from + guest. Each bit in the mask, from left to right, corresponds to a domain from 0-255. If a bit is set, the corresponding domain can be modified by an AP command-request message sent to a usage domain. @@ -151,10 +148,10 @@ If you recall from the description of an AP Queue, AP instructions include an APQN to identify the AP queue to which an AP command-request message is to be sent (NQAP and PQAP instructions), or from which a command-reply message is to be received (DQAP instruction). The validity of an APQN is defined by the matrix -calculated from the APM and AQM; it is the cross product of all assigned adapter -numbers (APM) with all assigned queue indexes (AQM). For example, if adapters 1 -and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs (1,5), (1,6), -(2,5) and (2,6) will be valid for the guest. +calculated from the APM and AQM; it is the Cartesian product of all assigned +adapter numbers (APM) with all assigned queue indexes (AQM). For example, if +adapters 1 and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs +(1,5), (1,6), (2,5) and (2,6) will be valid for the guest. The APQNs can provide secure key functionality - i.e., a private key is stored on the adapter card for each of its domains - so each APQN must be assigned to @@ -192,7 +189,7 @@ The design introduces three new objects: 1. AP matrix device 2. VFIO AP device driver (vfio_ap.ko) -3. VFIO AP mediated matrix pass-through device +3. VFIO AP mediated pass-through device The VFIO AP device driver ------------------------- @@ -200,12 +197,13 @@ The VFIO AP (vfio_ap) device driver serves the following purposes: 1. Provides the interfaces to secure APQNs for exclusive use of KVM guests. -2. Sets up the VFIO mediated device interfaces to manage a mediated matrix +2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated device and creates the sysfs interfaces for assigning adapters, usage domains, and control domains comprising the matrix for a KVM guest. -3. Configures the APM, AQM and ADM in the CRYCB referenced by a KVM guest's - SIE state description to grant the guest access to a matrix of AP devices +3. Configures the APM, AQM and ADM in the APCB contained in the CRYCB referenced + by a KVM guest's SIE state description to grant the guest access to a matrix + of AP devices Reserve APQNs for exclusive use of KVM guests --------------------------------------------- @@ -235,10 +233,10 @@ reserved:: | | 8 probe | | +--------^---------+ +--^--^------------+ 6 edit | | | - apmask | +-----------------------------+ | 9 mdev create + apmask | +-----------------------------+ | 11 mdev create aqmask | | 1 modprobe | +--------+-----+---+ +----------------+-+ +----------------+ - | | | |8 create | mediated | + | | | |10 create| mediated | | admin | | VFIO device core |---------> matrix | | + | | | device | +------+-+---------+ +--------^---------+ +--------^-------+ @@ -246,14 +244,14 @@ reserved:: | | 9 create vfio_ap-passthrough | | | +------------------------------+ | +-------------------------------------------------------------+ - 10 assign adapter/domain/control domain + 12 assign adapter/domain/control domain The process for reserving an AP queue for use by a KVM guest is: 1. The administrator loads the vfio_ap device driver 2. The vfio-ap driver during its initialization will register a single 'matrix' device with the device core. This will serve as the parent device for - all mediated matrix devices used to configure an AP matrix for a guest. + all vfio_ap mediated devices used to configure an AP matrix for a guest. 3. The /sys/devices/vfio_ap/matrix device is created by the device core 4. The vfio_ap device driver will register with the AP bus for AP queue devices of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap @@ -269,24 +267,24 @@ The process for reserving an AP queue for use by a KVM guest is: default zcrypt cex4queue driver. 8. The AP bus probes the vfio_ap device driver to bind the queues reserved for it. -9. The administrator creates a passthrough type mediated matrix device to be +9. The administrator creates a passthrough type vfio_ap mediated device to be used by a guest 10. The administrator assigns the adapters, usage domains and control domains to be exclusively used by a guest. Set up the VFIO mediated device interfaces ------------------------------------------ -The VFIO AP device driver utilizes the common interface of the VFIO mediated +The VFIO AP device driver utilizes the common interfaces of the VFIO mediated device core driver to: -* Register an AP mediated bus driver to add a mediated matrix device to and +* Register an AP mediated bus driver to add a vfio_ap mediated device to and remove it from a VFIO group. -* Create and destroy a mediated matrix device -* Add a mediated matrix device to and remove it from the AP mediated bus driver -* Add a mediated matrix device to and remove it from an IOMMU group +* Create and destroy a vfio_ap mediated device +* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver +* Add a vfio_ap mediated device to and remove it from an IOMMU group The following high-level block diagram shows the main components and interfaces -of the VFIO AP mediated matrix device driver:: +of the VFIO AP mediated device driver:: +-------------+ | | @@ -343,7 +341,7 @@ matrix device. * device_api: the mediated device type's API * available_instances: - the number of mediated matrix passthrough devices + the number of vfio_ap mediated passthrough devices that can be created * device_api: specifies the VFIO API @@ -351,29 +349,37 @@ matrix device. This attribute group identifies the user-defined sysfs attributes of the mediated device. When a device is registered with the VFIO mediated device framework, the sysfs attribute files identified in the 'mdev_attr_groups' - structure will be created in the mediated matrix device's directory. The - sysfs attributes for a mediated matrix device are: + structure will be created in the vfio_ap mediated device's directory. The + sysfs attributes for a vfio_ap mediated device are: assign_adapter / unassign_adapter: Write-only attributes for assigning/unassigning an AP adapter to/from the - mediated matrix device. To assign/unassign an adapter, the APID of the - adapter is echoed to the respective attribute file. + vfio_ap mediated device. To assign/unassign an adapter, the APID of the + adapter is echoed into the respective attribute file. assign_domain / unassign_domain: Write-only attributes for assigning/unassigning an AP usage domain to/from - the mediated matrix device. To assign/unassign a domain, the domain - number of the usage domain is echoed to the respective attribute + the vfio_ap mediated device. To assign/unassign a domain, the domain + number of the usage domain is echoed into the respective attribute file. matrix: - A read-only file for displaying the APQNs derived from the cross product - of the adapter and domain numbers assigned to the mediated matrix device. + A read-only file for displaying the APQNs derived from the Cartesian + product of the adapter and domain numbers assigned to the vfio_ap mediated + device. + guest_matrix: + A read-only file for displaying the APQNs derived from the Cartesian + product of the adapter and domain numbers assigned to the APM and AQM + fields respectively of the KVM guest's CRYCB. This may differ from the + the APQNs assigned to the vfio_ap mediated device if any APQN does not + reference a queue device bound to the vfio_ap device driver (i.e., the + queue is not in the host's AP configuration). assign_control_domain / unassign_control_domain: Write-only attributes for assigning/unassigning an AP control domain - to/from the mediated matrix device. To assign/unassign a control domain, - the ID of the domain to be assigned/unassigned is echoed to the respective - attribute file. + to/from the vfio_ap mediated device. To assign/unassign a control domain, + the ID of the domain to be assigned/unassigned is echoed into the + respective attribute file. control_domains: A read-only file for displaying the control domain numbers assigned to the - mediated matrix device. + vfio_ap mediated device. * functions: @@ -383,45 +389,75 @@ matrix device. * Store the reference to the KVM structure for the guest using the mdev * Store the AP matrix configuration for the adapters, domains, and control domains assigned via the corresponding sysfs attributes files + * Store the AP matrix configuration for the adapters, domains and control + domains available to a guest. A guest may not be provided access to APQNs + referencing queue devices that do not exist, or are not bound to the + vfio_ap device driver. remove: - deallocates the mediated matrix device's ap_matrix_mdev structure. This will - be allowed only if a running guest is not using the mdev. + deallocates the vfio_ap mediated device's ap_matrix_mdev structure. + This will be allowed only if a running guest is not using the mdev. * callback interfaces - open: + open_device: The vfio_ap driver uses this callback to register a - VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the mdev matrix - device. The open is invoked when QEMU connects the VFIO iommu group - for the mdev matrix device to the MDEV bus. Access to the KVM structure used - to configure the KVM guest is provided via this callback. The KVM structure, - is used to configure the guest's access to the AP matrix defined via the - mediated matrix device's sysfs attribute files. - release: + VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the matrix mdev + devices. The open_device callback is invoked by userspace to connect the + VFIO iommu group for the matrix mdev device to the MDEV bus. Access to the + KVM structure used to configure the KVM guest is provided via this callback. + The KVM structure, is used to configure the guest's access to the AP matrix + defined via the vfio_ap mediated device's sysfs attribute files. + + close_device: unregisters the VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the - mdev matrix device and deconfigures the guest's AP matrix. + matrix mdev device and deconfigures the guest's AP matrix. -Configure the APM, AQM and ADM in the CRYCB -------------------------------------------- -Configuring the AP matrix for a KVM guest will be performed when the + ioctl: + this callback handles the VFIO_DEVICE_GET_INFO and VFIO_DEVICE_RESET ioctls + defined by the vfio framework. + +Configure the guest's AP resources +---------------------------------- +Configuring the AP resources for a KVM guest will be performed when the VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier -function is called when QEMU connects to KVM. The guest's AP matrix is -configured via it's CRYCB by: +function is called when userspace connects to KVM. The guest's AP resources are +configured via it's APCB by: * Setting the bits in the APM corresponding to the APIDs assigned to the - mediated matrix device via its 'assign_adapter' interface. + vfio_ap mediated device via its 'assign_adapter' interface. * Setting the bits in the AQM corresponding to the domains assigned to the - mediated matrix device via its 'assign_domain' interface. + vfio_ap mediated device via its 'assign_domain' interface. * Setting the bits in the ADM corresponding to the domain dIDs assigned to the - mediated matrix device via its 'assign_control_domains' interface. + vfio_ap mediated device via its 'assign_control_domains' interface. + +The linux device model precludes passing a device through to a KVM guest that +is not bound to the device driver facilitating its pass-through. Consequently, +an APQN that does not reference a queue device bound to the vfio_ap device +driver will not be assigned to a KVM guest's matrix. The AP architecture, +however, does not provide a means to filter individual APQNs from the guest's +matrix, so the adapters, domains and control domains assigned to vfio_ap +mediated device via its sysfs 'assign_adapter', 'assign_domain' and +'assign_control_domain' interfaces will be filtered before providing the AP +configuration to a guest: + +* The APIDs of the adapters, the APQIs of the domains and the domain numbers of + the control domains assigned to the matrix mdev that are not also assigned to + the host's AP configuration will be filtered. + +* Each APQN derived from the Cartesian product of the APIDs and APQIs assigned + to the vfio_ap mdev is examined and if any one of them does not reference a + queue device bound to the vfio_ap device driver, the adapter will not be + plugged into the guest (i.e., the bit corresponding to its APID will not be + set in the APM of the guest's APCB). The CPU model features for AP ----------------------------- -The AP stack relies on the presence of the AP instructions as well as two -facilities: The AP Facilities Test (APFT) facility; and the AP Query -Configuration Information (QCI) facility. These features/facilities are made -available to a KVM guest via the following CPU model features: +The AP stack relies on the presence of the AP instructions as well as three +facilities: The AP Facilities Test (APFT) facility; the AP Query +Configuration Information (QCI) facility; and the AP Queue Interruption Control +facility. These features/facilities are made available to a KVM guest via the +following CPU model features: 1. ap: Indicates whether the AP instructions are installed on the guest. This feature will be enabled by KVM only if the AP instructions are installed @@ -435,24 +471,28 @@ available to a KVM guest via the following CPU model features: can be made available to the guest only if it is available on the host (i.e., facility bit 12 is set). +4. apqi: Indicates AP Queue Interruption Control faclity is available on the + guest. This facility can be made available to the guest only if it is + available on the host (i.e., facility bit 65 is set). + Note: If the user chooses to specify a CPU model different than the 'host' model to QEMU, the CPU model features and facilities need to be turned on explicitly; for example:: - /usr/bin/qemu-system-s390x ... -cpu z13,ap=on,apqci=on,apft=on + /usr/bin/qemu-system-s390x ... -cpu z13,ap=on,apqci=on,apft=on,apqi=on A guest can be precluded from using AP features/facilities by turning them off explicitly; for example:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off + /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off,apqi=off Note: If the APFT facility is turned off (apft=off) for the guest, the guest -will not see any AP devices. The zcrypt device drivers that register for type 10 -and newer AP devices - i.e., the cex4card and cex4queue device drivers - need -the APFT facility to ascertain the facilities installed on a given AP device. If -the APFT facility is not installed on the guest, then the probe of device -drivers will fail since only type 10 and newer devices can be configured for -guest use. +will not see any AP devices. The zcrypt device drivers on the guest that +register for type 10 and newer AP devices - i.e., the cex4card and cex4queue +device drivers - need the APFT facility to ascertain the facilities installed on +a given AP device. If the APFT facility is not installed on the guest, then no +adapter or domain devices will get created by the AP bus running on the +guest because only type 10 and newer devices can be configured for guest use. Example ======= @@ -471,7 +511,7 @@ CARD.DOMAIN TYPE MODE 05.00ab CEX5C CCA-Coproc 06 CEX5A Accelerator 06.0004 CEX5A Accelerator -06.00ab CEX5C CCA-Coproc +06.00ab CEX5A Accelerator =========== ===== ============ Guest2 @@ -479,9 +519,9 @@ Guest2 =========== ===== ============ CARD.DOMAIN TYPE MODE =========== ===== ============ -05 CEX5A Accelerator -05.0047 CEX5A Accelerator -05.00ff CEX5A Accelerator +05 CEX5C CCA-Coproc +05.0047 CEX5C CCA-Coproc +05.00ff CEX5C CCA-Coproc =========== ===== ============ Guest3 @@ -529,40 +569,56 @@ These are the steps: 2. Secure the AP queues to be used by the three guests so that the host can not access them. To secure them, there are two sysfs files that specify - bitmasks marking a subset of the APQN range as 'usable by the default AP - queue device drivers' or 'not usable by the default device drivers' and thus - available for use by the vfio_ap device driver'. The location of the sysfs - files containing the masks are:: + bitmasks marking a subset of the APQN range as usable only by the default AP + queue device drivers. All remaining APQNs are available for use by + any other device driver. The vfio_ap device driver is currently the only + non-default device driver. The location of the sysfs files containing the + masks are:: /sys/bus/ap/apmask /sys/bus/ap/aqmask The 'apmask' is a 256-bit mask that identifies a set of AP adapter IDs - (APID). Each bit in the mask, from left to right (i.e., from most significant - to least significant bit in big endian order), corresponds to an APID from - 0-255. If a bit is set, the APID is marked as usable only by the default AP - queue device drivers; otherwise, the APID is usable by the vfio_ap - device driver. + (APID). Each bit in the mask, from left to right, corresponds to an APID from + 0-255. If a bit is set, the APID belongs to the subset of APQNs marked as + available only to the default AP queue device drivers. The 'aqmask' is a 256-bit mask that identifies a set of AP queue indexes - (APQI). Each bit in the mask, from left to right (i.e., from most significant - to least significant bit in big endian order), corresponds to an APQI from - 0-255. If a bit is set, the APQI is marked as usable only by the default AP - queue device drivers; otherwise, the APQI is usable by the vfio_ap device - driver. + (APQI). Each bit in the mask, from left to right, corresponds to an APQI from + 0-255. If a bit is set, the APQI belongs to the subset of APQNs marked as + available only to the default AP queue device drivers. + + The Cartesian product of the APIDs corresponding to the bits set in the + apmask and the APQIs corresponding to the bits set in the aqmask comprise + the subset of APQNs that can be used only by the host default device drivers. + All other APQNs are available to the non-default device drivers such as the + vfio_ap driver. + + Take, for example, the following masks:: + + apmask: + 0x7d00000000000000000000000000000000000000000000000000000000000000 - Take, for example, the following mask:: + aqmask: + 0x8000000000000000000000000000000000000000000000000000000000000000 - 0x7dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff + The masks indicate: - It indicates: + * Adapters 1, 2, 3, 4, 5, and 7 are available for use by the host default + device drivers. - 1, 2, 3, 4, 5, and 7-255 belong to the default drivers' pool, and 0 and 6 - belong to the vfio_ap device driver's pool. + * Domain 0 is available for use by the host default device drivers + + * The subset of APQNs available for use only by the default host device + drivers are: + + (1,0), (2,0), (3,0), (4.0), (5,0) and (7,0) + + * All other APQNs are available for use by the non-default device drivers. The APQN of each AP queue device assigned to the linux host is checked by the - AP bus against the set of APQNs derived from the cross product of APIDs - and APQIs marked as usable only by the default AP queue device drivers. If a + AP bus against the set of APQNs derived from the Cartesian product of APIDs + and APQIs marked as available to the default AP queue device drivers. If a match is detected, only the default AP queue device drivers will be probed; otherwise, the vfio_ap device driver will be probed. @@ -579,8 +635,7 @@ These are the steps: 0x4100000000000000000000000000000000000000000000000000000000000000 - Keep in mind that the mask reads from left to right (i.e., most - significant to least significant bit in big endian order), so the mask + Keep in mind that the mask reads from left to right, so the mask above identifies device numbers 1 and 7 (01000001). If the string is longer than the mask, the operation is terminated with @@ -626,11 +681,22 @@ These are the steps: default drivers pool: adapter 0-15, domain 1 alternate drivers pool: adapter 16-255, domains 0, 2-255 + **Note:** + Changing a mask such that one or more APQNs will be taken from a vfio_ap + mediated device (see below) will fail with an error (EBUSY). A message + is logged to the kernel ring buffer which can be viewed with the 'dmesg' + command. The output identifies each APQN flagged as 'in use' and identifies + the vfio_ap mediated device to which it is assigned; for example: + + Userspace may not re-assign queue 05.0054 already assigned to 62177883-f1bb-47f0-914d-32a22e3a8804 + Userspace may not re-assign queue 04.0054 already assigned to cef03c3c-903d-4ecc-9a83-40694cb8aee4 + Securing the APQNs for our example ---------------------------------- To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047, 06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding - APQNs can either be removed from the default masks:: + APQNs can be removed from the default masks using either of the following + commands:: echo -5,-6 > /sys/bus/ap/apmask @@ -683,7 +749,7 @@ Securing the APQNs for our example /sys/devices/vfio_ap/matrix/ --- [mdev_supported_types] - ------ [vfio_ap-passthrough] (passthrough mediated matrix device type) + ------ [vfio_ap-passthrough] (passthrough vfio_ap mediated device type) --------- create --------- [devices] @@ -734,6 +800,9 @@ Securing the APQNs for our example ----------------unassign_control_domain ----------------unassign_domain + Note *****: The vfio_ap mdevs do not persist across reboots unless the + mdevctl tool is used to create and persist them. + 4. The administrator now needs to configure the matrixes for the mediated devices $uuid1 (for Guest1), $uuid2 (for Guest2) and $uuid3 (for Guest3). @@ -755,6 +824,10 @@ Securing the APQNs for our example cat matrix + To display the matrix that is or will be assigned to Guest1:: + + cat guest_matrix + This is how the matrix is configured for Guest2:: echo 5 > assign_adapter @@ -774,17 +847,24 @@ Securing the APQNs for our example higher than the maximum is specified, the operation will terminate with an error (ENODEV). - * All APQNs that can be derived from the adapter ID and the IDs of - the previously assigned domains must be bound to the vfio_ap device - driver. If no domains have yet been assigned, then there must be at least - one APQN with the specified APID bound to the vfio_ap driver. If no such - APQNs are bound to the driver, the operation will terminate with an - error (EADDRNOTAVAIL). + Note: The maximum adapter number can be obtained via the sysfs + /sys/bus/ap/ap_max_adapter_id attribute file. + + * Each APQN derived from the Cartesian product of the APID of the adapter + being assigned and the APQIs of the domains previously assigned: + + - Must only be available to the vfio_ap device driver as specified in the + sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even + one APQN is reserved for use by the host device driver, the operation + will terminate with an error (EADDRNOTAVAIL). + + - Must NOT be assigned to another vfio_ap mediated device. If even one APQN + is assigned to another vfio_ap mediated device, the operation will + terminate with an error (EBUSY). - No APQN that can be derived from the adapter ID and the IDs of the - previously assigned domains can be assigned to another mediated matrix - device. If an APQN is assigned to another mediated matrix device, the - operation will terminate with an error (EADDRINUSE). + - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and + sys/bus/ap/aqmask attribute files are being edited or the operation may + terminate with an error (EBUSY). In order to successfully assign a domain: @@ -793,41 +873,50 @@ Securing the APQNs for our example higher than the maximum is specified, the operation will terminate with an error (ENODEV). - * All APQNs that can be derived from the domain ID and the IDs of - the previously assigned adapters must be bound to the vfio_ap device - driver. If no domains have yet been assigned, then there must be at least - one APQN with the specified APQI bound to the vfio_ap driver. If no such - APQNs are bound to the driver, the operation will terminate with an - error (EADDRNOTAVAIL). + Note: The maximum domain number can be obtained via the sysfs + /sys/bus/ap/ap_max_domain_id attribute file. + + * Each APQN derived from the Cartesian product of the APQI of the domain + being assigned and the APIDs of the adapters previously assigned: + + - Must only be available to the vfio_ap device driver as specified in the + sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even + one APQN is reserved for use by the host device driver, the operation + will terminate with an error (EADDRNOTAVAIL). + + - Must NOT be assigned to another vfio_ap mediated device. If even one APQN + is assigned to another vfio_ap mediated device, the operation will + terminate with an error (EBUSY). - No APQN that can be derived from the domain ID and the IDs of the - previously assigned adapters can be assigned to another mediated matrix - device. If an APQN is assigned to another mediated matrix device, the - operation will terminate with an error (EADDRINUSE). + - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and + sys/bus/ap/aqmask attribute files are being edited or the operation may + terminate with an error (EBUSY). - In order to successfully assign a control domain, the domain number - specified must represent a value from 0 up to the maximum domain number - configured for the system. If a control domain number higher than the maximum - is specified, the operation will terminate with an error (ENODEV). + In order to successfully assign a control domain: + + * The domain number specified must represent a value from 0 up to the maximum + domain number configured for the system. If a control domain number higher + than the maximum is specified, the operation will terminate with an + error (ENODEV). 5. Start Guest1:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \ + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ... 7. Start Guest2:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \ + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ... 7. Start Guest3:: - /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \ + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ... -When the guest is shut down, the mediated matrix devices may be removed. +When the guest is shut down, the vfio_ap mediated devices may be removed. -Using our example again, to remove the mediated matrix device $uuid1:: +Using our example again, to remove the vfio_ap mediated device $uuid1:: /sys/devices/vfio_ap/matrix/ --- [mdev_supported_types] @@ -840,26 +929,143 @@ Using our example again, to remove the mediated matrix device $uuid1:: echo 1 > remove -This will remove all of the mdev matrix device's sysfs structures including -the mdev device itself. To recreate and reconfigure the mdev matrix device, +This will remove all of the matrix mdev device's sysfs structures including +the mdev device itself. To recreate and reconfigure the matrix mdev device, all of the steps starting with step 3 will have to be performed again. Note -that the remove will fail if a guest using the mdev is still running. +that the remove will fail if a guest using the vfio_ap mdev is still running. -It is not necessary to remove an mdev matrix device, but one may want to +It is not necessary to remove a vfio_ap mdev, but one may want to remove it if no guest will use it during the remaining lifetime of the linux -host. If the mdev matrix device is removed, one may want to also reconfigure +host. If the vfio_ap mdev is removed, one may want to also reconfigure the pool of adapters and queues reserved for use by the default drivers. +Hot plug/unplug support: +======================== +An adapter, domain or control domain may be hot plugged into a running KVM +guest by assigning it to the vfio_ap mediated device being used by the guest if +the following conditions are met: + +* The adapter, domain or control domain must also be assigned to the host's + AP configuration. + +* Each APQN derived from the Cartesian product comprised of the APID of the + adapter being assigned and the APQIs of the domains assigned must reference a + queue device bound to the vfio_ap device driver. + +* To hot plug a domain, each APQN derived from the Cartesian product + comprised of the APQI of the domain being assigned and the APIDs of the + adapters assigned must reference a queue device bound to the vfio_ap device + driver. + +An adapter, domain or control domain may be hot unplugged from a running KVM +guest by unassigning it from the vfio_ap mediated device being used by the +guest. + +Over-provisioning of AP queues for a KVM guest: +=============================================== +Over-provisioning is defined herein as the assignment of adapters or domains to +a vfio_ap mediated device that do not reference AP devices in the host's AP +configuration. The idea here is that when the adapter or domain becomes +available, it will be automatically hot-plugged into the KVM guest using +the vfio_ap mediated device to which it is assigned as long as each new APQN +resulting from plugging it in references a queue device bound to the vfio_ap +device driver. + Limitations =========== -* The KVM/kernel interfaces do not provide a way to prevent restoring an APQN - to the default drivers pool of a queue that is still assigned to a mediated - device in use by a guest. It is incumbent upon the administrator to - ensure there is no mediated device in use by a guest to which the APQN is - assigned lest the host be given access to the private data of the AP queue - device such as a private key configured specifically for the guest. +Live guest migration is not supported for guests using AP devices without +intervention by a system administrator. Before a KVM guest can be migrated, +the vfio_ap mediated device must be removed. Unfortunately, it can not be +removed manually (i.e., echo 1 > /sys/devices/vfio_ap/matrix/$UUID/remove) while +the mdev is in use by a KVM guest. If the guest is being emulated by QEMU, +its mdev can be hot unplugged from the guest in one of two ways: + +1. If the KVM guest was started with libvirt, you can hot unplug the mdev via + the following commands: + + virsh detach-device <guestname> <path-to-device-xml> + + For example, to hot unplug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 from + the guest named 'my-guest': + + virsh detach-device my-guest ~/config/my-guest-hostdev.xml + + The contents of my-guest-hostdev.xml: + +.. code-block:: xml + + <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'> + <source> + <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/> + </source> + </hostdev> + + + virsh qemu-monitor-command <guest-name> --hmp "device-del <device-id>" + + For example, to hot unplug the vfio_ap mediated device identified on the + qemu command line with 'id=hostdev0' from the guest named 'my-guest': + +.. code-block:: sh + + virsh qemu-monitor-command my-guest --hmp "device_del hostdev0" + +2. A vfio_ap mediated device can be hot unplugged by attaching the qemu monitor + to the guest and using the following qemu monitor command: + + (QEMU) device-del id=<device-id> + + For example, to hot unplug the vfio_ap mediated device that was specified + on the qemu command line with 'id=hostdev0' when the guest was started: + + (QEMU) device-del id=hostdev0 + +After live migration of the KVM guest completes, an AP configuration can be +restored to the KVM guest by hot plugging a vfio_ap mediated device on the target +system into the guest in one of two ways: + +1. If the KVM guest was started with libvirt, you can hot plug a matrix mediated + device into the guest via the following virsh commands: + + virsh attach-device <guestname> <path-to-device-xml> + + For example, to hot plug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 into + the guest named 'my-guest': + + virsh attach-device my-guest ~/config/my-guest-hostdev.xml + + The contents of my-guest-hostdev.xml: + +.. code-block:: xml + + <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'> + <source> + <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/> + </source> + </hostdev> + + + virsh qemu-monitor-command <guest-name> --hmp \ + "device_add vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>" + + For example, to hot plug the vfio_ap mediated device + 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with + device-id hostdev0: + + virsh qemu-monitor-command my-guest --hmp \ + "device_add vfio-ap,\ + sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\ + id=hostdev0" + +2. A vfio_ap mediated device can be hot plugged by attaching the qemu monitor + to the guest and using the following qemu monitor command: + + (qemu) device_add "vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>" -* Dynamically modifying the AP matrix for a running guest (which would amount to - hot(un)plug of AP devices for the guest) is currently not supported + For example, to plug the vfio_ap mediated device + 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id + hostdev0: -* Live guest migration is not supported for guests using AP devices. + (QEMU) device-add "vfio-ap,\ + sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\ + id=hostdev0" diff --git a/Documentation/scsi/scsi_eh.rst b/Documentation/scsi/scsi_eh.rst index 885395dc1f15..bad624fab823 100644 --- a/Documentation/scsi/scsi_eh.rst +++ b/Documentation/scsi/scsi_eh.rst @@ -87,8 +87,7 @@ with the command. 1.2.2 Completing a scmd w/ timeout ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The timeout handler is scsi_times_out(). When a timeout occurs, this -function +The timeout handler is scsi_timeout(). When a timeout occurs, this function 1. invokes optional hostt->eh_timed_out() callback. Return value can be one of diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 63ddea2b9640..a8c5bd15a440 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -731,7 +731,7 @@ Details:: * Notes: If 'no_async_abort' is defined this callback * will be invoked from scsi_eh thread. No other commands * will then be queued on current host during eh. - * Otherwise it will be called whenever scsi_times_out() + * Otherwise it will be called whenever scsi_timeout() * is called due to a command timeout. * * Optionally defined in: LLD diff --git a/Documentation/scsi/ufs.rst b/Documentation/scsi/ufs.rst index fbac745b783c..885b1a736e3f 100644 --- a/Documentation/scsi/ufs.rst +++ b/Documentation/scsi/ufs.rst @@ -17,6 +17,8 @@ Universal Flash Storage 3.2 UTP Transfer requests 3.3 UFS error handling 3.4 SCSI Error handling + 4. BSG Support + 5. UFS Reference Clock Frequency configuration 1. Overview @@ -193,3 +195,16 @@ UFS specifications can be found at: - UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf - UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf + +5. UFS Reference Clock Frequency configuration +============================================== + +Devicetree can define a clock named "ref_clk" under the UFS controller node +to specify the intended reference clock frequency for the UFS storage +parts. ACPI-based system can specify the frequency using ACPI +Device-Specific Data property named "ref-clk-freq". In both ways the value +is interpreted as frequency in Hz and must match one of the values given in +the UFS specification. UFS subsystem will attempt to read the value when +executing common controller initialization. If the value is available, UFS +subsytem will ensure the bRefClkFreq attribute of the UFS storage device is +set accordingly and will modify it if there is a mismatch. diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst index b3ed5c581034..811b905b56bf 100644 --- a/Documentation/security/keys/core.rst +++ b/Documentation/security/keys/core.rst @@ -1046,7 +1046,7 @@ The keyctl syscall functions are: "filter" is either NULL to remove a watch or a filter specification to indicate what events are required from the key. - See Documentation/watch_queue.rst for more information. + See Documentation/core-api/watch_queue.rst for more information. Note that only one watch may be emplaced for any particular { key, queue_fd } combination. diff --git a/Documentation/security/secrets/coco.rst b/Documentation/security/secrets/coco.rst index 262e7abb1b24..087e2d1ae38b 100644 --- a/Documentation/security/secrets/coco.rst +++ b/Documentation/security/secrets/coco.rst @@ -98,6 +98,6 @@ References See [sev-api-spec]_ for more info regarding SEV ``LAUNCH_SECRET`` operation. -.. [sev] Documentation/virt/kvm/amd-memory-encryption.rst +.. [sev] Documentation/virt/kvm/x86/amd-memory-encryption.rst .. [secrets-coco-abi] Documentation/ABI/testing/securityfs-secrets-coco .. [sev-api-spec] https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf diff --git a/Documentation/security/siphash.rst b/Documentation/security/siphash.rst index a10380cb78e5..023bd95c74a5 100644 --- a/Documentation/security/siphash.rst +++ b/Documentation/security/siphash.rst @@ -85,7 +85,7 @@ Often times the XuY functions will not be large enough, and instead you'll want to pass a pre-filled struct to siphash. When doing this, it's important to always ensure the struct has no padding holes. The easiest way to do this is to simply arrange the members of the struct in descending order of size, -and to use offsetendof() instead of sizeof() for getting the size. For +and to use offsetofend() instead of sizeof() for getting the size. For performance reasons, if possible, it's probably a good thing to align the struct to the right boundary. Here's an example:: diff --git a/Documentation/sound/soc/codec.rst b/Documentation/sound/soc/codec.rst index 57df149acafc..af973c4cac93 100644 --- a/Documentation/sound/soc/codec.rst +++ b/Documentation/sound/soc/codec.rst @@ -132,7 +132,7 @@ The codec driver also supports the following ALSA PCM operations:- }; Please refer to the ALSA driver PCM documentation for details. -http://www.alsa-project.org/~iwai/writing-an-alsa-driver/ +https://www.kernel.org/doc/html/latest/sound/kernel-api/writing-an-alsa-driver.html DAPM description diff --git a/Documentation/sound/soc/dai.rst b/Documentation/sound/soc/dai.rst index 009b07e5a0f3..bf8431386d26 100644 --- a/Documentation/sound/soc/dai.rst +++ b/Documentation/sound/soc/dai.rst @@ -10,7 +10,7 @@ AC97 ==== AC97 is a five wire interface commonly found on many PC sound cards. It is -now also popular in many portable devices. This DAI has a reset line and time +now also popular in many portable devices. This DAI has a RESET line and time multiplexes its data on its SDATA_OUT (playback) and SDATA_IN (capture) lines. The bit clock (BCLK) is always driven by the CODEC (usually 12.288MHz) and the frame (FRAME) (usually 48kHz) is always driven by the controller. Each AC97 diff --git a/Documentation/sound/soc/platform.rst b/Documentation/sound/soc/platform.rst index c1badea53d3d..7036630eaf01 100644 --- a/Documentation/sound/soc/platform.rst +++ b/Documentation/sound/soc/platform.rst @@ -46,7 +46,7 @@ snd_soc_component_driver:- }; Please refer to the ALSA driver documentation for details of audio DMA. -http://www.alsa-project.org/~iwai/writing-an-alsa-driver/ +https://www.kernel.org/doc/html/latest/sound/kernel-api/writing-an-alsa-driver.html An example DMA driver is soc/pxa/pxa2xx-pcm.c diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py index cc348b219fca..06b34740bf90 100644 --- a/Documentation/sphinx/automarkup.py +++ b/Documentation/sphinx/automarkup.py @@ -121,13 +121,20 @@ def markup_refs(docname, app, node): return repl # +# Keep track of cross-reference lookups that failed so we don't have to +# do them again. +# +failed_lookups = { } +def failure_seen(target): + return (target) in failed_lookups +def note_failure(target): + failed_lookups[target] = True + +# # In sphinx3 we can cross-reference to C macro and function, each one with its # own C role, but both match the same regex, so we try both. # def markup_func_ref_sphinx3(docname, app, match): - class_str = ['c-func', 'c-macro'] - reftype_str = ['function', 'macro'] - cdom = app.env.domains['c'] # # Go through the dance of getting an xref out of the C domain @@ -143,27 +150,28 @@ def markup_func_ref_sphinx3(docname, app, match): if base_target not in Skipnames: for target in possible_targets: - if target not in Skipfuncs: - for class_s, reftype_s in zip(class_str, reftype_str): - lit_text = nodes.literal(classes=['xref', 'c', class_s]) - lit_text += target_text - pxref = addnodes.pending_xref('', refdomain = 'c', - reftype = reftype_s, - reftarget = target, modname = None, - classname = None) - # - # XXX The Latex builder will throw NoUri exceptions here, - # work around that by ignoring them. - # - try: - xref = cdom.resolve_xref(app.env, docname, app.builder, - reftype_s, target, pxref, - lit_text) - except NoUri: - xref = None - - if xref: - return xref + if (target not in Skipfuncs) and not failure_seen(target): + lit_text = nodes.literal(classes=['xref', 'c', 'c-func']) + lit_text += target_text + pxref = addnodes.pending_xref('', refdomain = 'c', + reftype = 'function', + reftarget = target, + modname = None, + classname = None) + # + # XXX The Latex builder will throw NoUri exceptions here, + # work around that by ignoring them. + # + try: + xref = cdom.resolve_xref(app.env, docname, app.builder, + 'function', target, pxref, + lit_text) + except NoUri: + xref = None + + if xref: + return xref + note_failure(target) return target_text diff --git a/Documentation/sphinx/kerneldoc-preamble.sty b/Documentation/sphinx/kerneldoc-preamble.sty index 2a29cbe51396..9707e033c8c4 100644 --- a/Documentation/sphinx/kerneldoc-preamble.sty +++ b/Documentation/sphinx/kerneldoc-preamble.sty @@ -70,8 +70,16 @@ % Translations have Asian (CJK) characters which are only displayed if % xeCJK is used +\usepackage{ifthen} +\newboolean{enablecjk} +\setboolean{enablecjk}{false} \IfFontExistsTF{Noto Sans CJK SC}{ - % Load xeCJK when CJK font is available + \IfFileExists{xeCJK.sty}{ + \setboolean{enablecjk}{true} + }{} +}{} +\ifthenelse{\boolean{enablecjk}}{ + % Load xeCJK when both the Noto Sans CJK font and xeCJK.sty are available. \usepackage{xeCJK} % Noto CJK fonts don't provide slant shape. [AutoFakeSlant] permits % its emulation. @@ -196,7 +204,7 @@ % Inactivate CJK after tableofcontents \apptocmd{\sphinxtableofcontents}{\kerneldocCJKoff}{}{} \xeCJKsetup{CJKspace = true}% For inter-phrase space of Korean TOC -}{ % No CJK font found +}{ % Don't enable CJK % Custom macros to on/off CJK and switch CJK fonts (Dummy) \newcommand{\kerneldocCJKon}{} \newcommand{\kerneldocCJKoff}{} @@ -204,14 +212,16 @@ %% and ignore the argument (#1) in their definitions, whole contents of %% CJK chapters can be ignored. \newcommand{\kerneldocBeginSC}[1]{% - %% Put a note on missing CJK fonts in place of zh_CN translation. - \begin{sphinxadmonition}{note}{Note on missing fonts:} + %% Put a note on missing CJK fonts or the xecjk package in place of + %% zh_CN translation. + \begin{sphinxadmonition}{note}{Note on missing fonts and a package:} Translations of Simplified Chinese (zh\_CN), Traditional Chinese (zh\_TW), Korean (ko\_KR), and Japanese (ja\_JP) were skipped - due to the lack of suitable font families. + due to the lack of suitable font families and/or the texlive-xecjk + package. If you want them, please install ``Noto Sans CJK'' font families - by following instructions from + along with the texlive-xecjk package by following instructions from \sphinxcode{./scripts/sphinx-pre-install}. Having optional ``Noto Serif CJK'' font families will improve the looks of those translations. diff --git a/Documentation/staging/static-keys.rst b/Documentation/staging/static-keys.rst index 38290b9f25eb..b0a519f456cf 100644 --- a/Documentation/staging/static-keys.rst +++ b/Documentation/staging/static-keys.rst @@ -201,9 +201,6 @@ static_key->entry field makes use of the two least significant bits. * ``void arch_jump_label_transform(struct jump_entry *entry, enum jump_label_type type)``, see: arch/x86/kernel/jump_label.c -* ``__init_or_module void arch_jump_label_transform_static(struct jump_entry *entry, enum jump_label_type type)``, - see: arch/x86/kernel/jump_label.c - * ``struct jump_entry``, see: arch/x86/include/asm/jump_label.h diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst index e12eae1f3301..6bf7f0ca4556 100644 --- a/Documentation/tools/rtla/rtla-timerlat-hist.rst +++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst @@ -33,7 +33,7 @@ EXAMPLE ======= In the example below, **rtla timerlat hist** is set to run for *10* minutes, in the cpus *0-4*, *skipping zero* only lines. Moreover, **rtla timerlat -hist** will change the priority of the *timelat* threads to run under +hist** will change the priority of the *timerlat* threads to run under *SCHED_DEADLINE* priority, with a *10us* runtime every *1ms* period. The *1ms* period is also passed to the *timerlat* tracer:: diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst index d25dfe86af9b..fb7578fd9372 100644 --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst @@ -650,13 +650,26 @@ Bit assignments shown below:- parameter is set this value is applied to the currently indexed address range. +.. _coresight-branch-broadcast: **bit (4):** ETM_MODE_BB **description:** - Set to enable branch broadcast if supported in hardware [IDR0]. + Set to enable branch broadcast if supported in hardware [IDR0]. The primary use for this feature + is when code is patched dynamically at run time and the full program flow may not be able to be + reconstructed using only conditional branches. + There is currently no support in Perf for supplying modified binaries to the decoder, so this + feature is only inteded to be used for debugging purposes or with a 3rd party tool. + + Choosing this option will result in a significant increase in the amount of trace generated - + possible danger of overflows, or fewer instructions covered. Note, that this option also + overrides any setting of :ref:`ETM_MODE_RETURNSTACK <coresight-return-stack>`, so where a branch + broadcast range overlaps a return stack range, return stacks will not be available for that + range. + +.. _coresight-cycle-accurate: **bit (5):** ETMv4_MODE_CYCACC @@ -678,6 +691,7 @@ Bit assignments shown below:- **description:** Set to enable virtual machine ID tracing if supported [IDR2]. +.. _coresight-timestamp: **bit (11):** ETMv4_MODE_TIMESTAMP @@ -685,6 +699,7 @@ Bit assignments shown below:- **description:** Set to enable timestamp generation if supported [IDR0]. +.. _coresight-return-stack: **bit (12):** ETM_MODE_RETURNSTACK diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index a15571d96cc8..4a71ea6cb390 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -130,7 +130,7 @@ Misc: Device Tree Bindings -------------------- -See Documentation/devicetree/bindings/arm/coresight.txt for details. +See Documentation/devicetree/bindings/arm/arm,coresight-\*.yaml for details. As of this writing drivers for ITM, STMs and CTIs are not provided but are expected to be added as the solution matures. @@ -339,7 +339,8 @@ Preference is given to the former as using the sysFS interface requires a deep understanding of the Coresight HW. The following sections provide details on using both methods. -1) Using the sysFS interface: +Using the sysFS interface +~~~~~~~~~~~~~~~~~~~~~~~~~ Before trace collection can start, a coresight sink needs to be identified. There is no limit on the amount of sinks (nor sources) that can be enabled at @@ -446,7 +447,8 @@ wealth of possibilities that coresight provides. Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc} Timestamp Timestamp: 17107041535 -2) Using perf framework: +Using perf framework +~~~~~~~~~~~~~~~~~~~~ Coresight tracers are represented using the Perf framework's Performance Monitoring Unit (PMU) abstraction. As such the perf framework takes charge of @@ -495,7 +497,11 @@ More information on the above and other example on how to use Coresight with the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub repository [#third]_. -2.1) AutoFDO analysis using the perf tools: +Advanced perf framework usage +----------------------------- + +AutoFDO analysis using the perf tools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ perf can be used to record and analyze trace of programs. @@ -513,7 +519,8 @@ The --itrace option controls the type and frequency of synthesized events Note that only 64-bit programs are currently supported - further work is required to support instruction decode of 32-bit Arm programs. -2.2) Tracing PID +Tracing PID +~~~~~~~~~~~ The kernel can be built to write the PID value into the PE ContextID registers. For a kernel running at EL1, the PID is stored in CONTEXTIDR_EL1. A PE may @@ -547,7 +554,7 @@ wants to trace PIDs for both host and guest, the two configs "contextid1" and Generating coverage files for Feedback Directed Optimization: AutoFDO ---------------------------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 'perf inject' accepts the --itrace option in which case tracing data is removed and replaced with the synthesized events. e.g. @@ -578,6 +585,45 @@ sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tuto Bubble sorting array of 30000 elements 5806 ms +Config option formats +~~~~~~~~~~~~~~~~~~~~~ + +The following strings can be provided between // on the perf command line to enable various options. +They are also listed in the folder /sys/bus/event_source/devices/cs_etm/format/ + +.. list-table:: + :header-rows: 1 + + * - Option + - Description + * - branch_broadcast + - Session local version of the system wide setting: + :ref:`ETM_MODE_BB <coresight-branch-broadcast>` + * - contextid + - See `Tracing PID`_ + * - contextid1 + - See `Tracing PID`_ + * - contextid2 + - See `Tracing PID`_ + * - configid + - Selection for a custom configuration. This is an implementation detail and not used directly, + see :ref:`trace/coresight/coresight-config:Using Configurations in perf` + * - preset + - Override for parameters in a custom configuration, see + :ref:`trace/coresight/coresight-config:Using Configurations in perf` + * - sinkid + - Hashed version of the string to select a sink, automatically set when using the @ notation. + This is an internal implementation detail and is not used directly, see `Using perf + framework`_. + * - cycacc + - Session local version of the system wide setting: :ref:`ETMv4_MODE_CYCACC + <coresight-cycle-accurate>` + * - retstack + - Session local version of the system wide setting: :ref:`ETM_MODE_RETURNSTACK + <coresight-return-stack>` + * - timestamp + - Session local version of the system wide setting: :ref:`ETMv4_MODE_TIMESTAMP + <coresight-timestamp>` How to use the STM module ------------------------- diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index f9b7bcb5a630..2d73e8697523 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -32,3 +32,4 @@ Linux Tracing Technologies sys-t coresight/index user_events + rv/index diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst index b175d88f31eb..4274cc6a2f94 100644 --- a/Documentation/trace/kprobetrace.rst +++ b/Documentation/trace/kprobetrace.rst @@ -28,10 +28,10 @@ Synopsis of kprobe_events ------------------------- :: - p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe - r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe - p:[GRP/]EVENT] [MOD:]SYM[+0]%return [FETCHARGS] : Set a return probe - -:[GRP/]EVENT : Clear a probe + p[:[GRP/][EVENT]] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe + r[MAXACTIVE][:[GRP/][EVENT]] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe + p[:[GRP/][EVENT]] [MOD:]SYM[+0]%return [FETCHARGS] : Set a return probe + -:[GRP/][EVENT] : Clear a probe GRP : Group name. If omitted, use "kprobes" for it. EVENT : Event name. If omitted, the event name is generated diff --git a/Documentation/trace/rv/da_monitor_instrumentation.rst b/Documentation/trace/rv/da_monitor_instrumentation.rst new file mode 100644 index 000000000000..6c67c7b57811 --- /dev/null +++ b/Documentation/trace/rv/da_monitor_instrumentation.rst @@ -0,0 +1,171 @@ +Deterministic Automata Instrumentation +====================================== + +The RV monitor file created by dot2k, with the name "$MODEL_NAME.c" +includes a section dedicated to instrumentation. + +In the example of the wip.dot monitor created on [1], it will look like:: + + /* + * This is the instrumentation part of the monitor. + * + * This is the section where manual work is required. Here the kernel events + * are translated into model's event. + * + */ + static void handle_preempt_disable(void *data, /* XXX: fill header */) + { + da_handle_event_wip(preempt_disable_wip); + } + + static void handle_preempt_enable(void *data, /* XXX: fill header */) + { + da_handle_event_wip(preempt_enable_wip); + } + + static void handle_sched_waking(void *data, /* XXX: fill header */) + { + da_handle_event_wip(sched_waking_wip); + } + + static int enable_wip(void) + { + int retval; + + retval = da_monitor_init_wip(); + if (retval) + return retval; + + rv_attach_trace_probe("wip", /* XXX: tracepoint */, handle_preempt_disable); + rv_attach_trace_probe("wip", /* XXX: tracepoint */, handle_preempt_enable); + rv_attach_trace_probe("wip", /* XXX: tracepoint */, handle_sched_waking); + + return 0; + } + +The comment at the top of the section explains the general idea: the +instrumentation section translates *kernel events* into the *model's +event*. + +Tracing callback functions +-------------------------- + +The first three functions are the starting point of the callback *handler +functions* for each of the three events from the wip model. The developer +does not necessarily need to use them: they are just starting points. + +Using the example of:: + + void handle_preempt_disable(void *data, /* XXX: fill header */) + { + da_handle_event_wip(preempt_disable_wip); + } + +The preempt_disable event from the model connects directly to the +preemptirq:preempt_disable. The preemptirq:preempt_disable event +has the following signature, from include/trace/events/preemptirq.h:: + + TP_PROTO(unsigned long ip, unsigned long parent_ip) + +Hence, the handle_preempt_disable() function will look like:: + + void handle_preempt_disable(void *data, unsigned long ip, unsigned long parent_ip) + +In this case, the kernel event translates one to one with the automata +event, and indeed, no other change is required for this function. + +The next handler function, handle_preempt_enable() has the same argument +list from the handle_preempt_disable(). The difference is that the +preempt_enable event will be used to synchronize the system to the model. + +Initially, the *model* is placed in the initial state. However, the *system* +might or might not be in the initial state. The monitor cannot start +processing events until it knows that the system has reached the initial state. +Otherwise, the monitor and the system could be out-of-sync. + +Looking at the automata definition, it is possible to see that the system +and the model are expected to return to the initial state after the +preempt_enable execution. Hence, it can be used to synchronize the +system and the model at the initialization of the monitoring section. + +The start is informed via a special handle function, the +"da_handle_start_event_$(MONITOR_NAME)(event)", in this case:: + + da_handle_start_event_wip(preempt_enable_wip); + +So, the callback function will look like:: + + void handle_preempt_enable(void *data, unsigned long ip, unsigned long parent_ip) + { + da_handle_start_event_wip(preempt_enable_wip); + } + +Finally, the "handle_sched_waking()" will look like:: + + void handle_sched_waking(void *data, struct task_struct *task) + { + da_handle_event_wip(sched_waking_wip); + } + +And the explanation is left for the reader as an exercise. + +enable and disable functions +---------------------------- + +dot2k automatically creates two special functions:: + + enable_$(MONITOR_NAME)() + disable_$(MONITOR_NAME)() + +These functions are called when the monitor is enabled and disabled, +respectively. + +They should be used to *attach* and *detach* the instrumentation to the running +system. The developer must add to the relative function all that is needed to +*attach* and *detach* its monitor to the system. + +For the wip case, these functions were named:: + + enable_wip() + disable_wip() + +But no change was required because: by default, these functions *attach* and +*detach* the tracepoints_to_attach, which was enough for this case. + +Instrumentation helpers +----------------------- + +To complete the instrumentation, the *handler functions* need to be attached to a +kernel event, at the monitoring enable phase. + +The RV interface also facilitates this step. For example, the macro "rv_attach_trace_probe()" +is used to connect the wip model events to the relative kernel event. dot2k automatically +adds "rv_attach_trace_probe()" function call for each model event in the enable phase, as +a suggestion. + +For example, from the wip sample model:: + + static int enable_wip(void) + { + int retval; + + retval = da_monitor_init_wip(); + if (retval) + return retval; + + rv_attach_trace_probe("wip", /* XXX: tracepoint */, handle_preempt_enable); + rv_attach_trace_probe("wip", /* XXX: tracepoint */, handle_sched_waking); + rv_attach_trace_probe("wip", /* XXX: tracepoint */, handle_preempt_disable); + + return 0; + } + +The probes then need to be detached at the disable phase. + +[1] The wip model is presented in:: + + Documentation/trace/rv/deterministic_automata.rst + +The wip monitor is presented in:: + + Documentation/trace/rv/da_monitor_synthesis.rst diff --git a/Documentation/trace/rv/da_monitor_synthesis.rst b/Documentation/trace/rv/da_monitor_synthesis.rst new file mode 100644 index 000000000000..0dbdcd1e62b9 --- /dev/null +++ b/Documentation/trace/rv/da_monitor_synthesis.rst @@ -0,0 +1,147 @@ +Deterministic Automata Monitor Synthesis +======================================== + +The starting point for the application of runtime verification (RV) technics +is the *specification* or *modeling* of the desired (or undesired) behavior +of the system under scrutiny. + +The formal representation needs to be then *synthesized* into a *monitor* +that can then be used in the analysis of the trace of the system. The +*monitor* connects to the system via an *instrumentation* that converts +the events from the *system* to the events of the *specification*. + + +In Linux terms, the runtime verification monitors are encapsulated inside +the *RV monitor* abstraction. The RV monitor includes a set of instances +of the monitor (per-cpu monitor, per-task monitor, and so on), the helper +functions that glue the monitor to the system reference model, and the +trace output as a reaction to event parsing and exceptions, as depicted +below:: + + Linux +----- RV Monitor ----------------------------------+ Formal + Realm | | Realm + +-------------------+ +----------------+ +-----------------+ + | Linux kernel | | Monitor | | Reference | + | Tracing | -> | Instance(s) | <- | Model | + | (instrumentation) | | (verification) | | (specification) | + +-------------------+ +----------------+ +-----------------+ + | | | + | V | + | +----------+ | + | | Reaction | | + | +--+--+--+-+ | + | | | | | + | | | +-> trace output ? | + +------------------------|--|----------------------+ + | +----> panic ? + +-------> <user-specified> + +DA monitor synthesis +-------------------- + +The synthesis of automata-based models into the Linux *RV monitor* abstraction +is automated by the dot2k tool and the rv/da_monitor.h header file that +contains a set of macros that automatically generate the monitor's code. + +dot2k +----- + +The dot2k utility leverages dot2c by converting an automaton model in +the DOT format into the C representation [1] and creating the skeleton of +a kernel monitor in C. + +For example, it is possible to transform the wip.dot model present in +[1] into a per-cpu monitor with the following command:: + + $ dot2k -d wip.dot -t per_cpu + +This will create a directory named wip/ with the following files: + +- wip.h: the wip model in C +- wip.c: the RV monitor + +The wip.c file contains the monitor declaration and the starting point for +the system instrumentation. + +Monitor macros +-------------- + +The rv/da_monitor.h enables automatic code generation for the *Monitor +Instance(s)* using C macros. + +The benefits of the usage of macro for monitor synthesis are 3-fold as it: + +- Reduces the code duplication; +- Facilitates the bug fix/improvement; +- Avoids the case of developers changing the core of the monitor code + to manipulate the model in a (let's say) non-standard way. + +This initial implementation presents three different types of monitor instances: + +- ``#define DECLARE_DA_MON_GLOBAL(name, type)`` +- ``#define DECLARE_DA_MON_PER_CPU(name, type)`` +- ``#define DECLARE_DA_MON_PER_TASK(name, type)`` + +The first declares the functions for a global deterministic automata monitor, +the second for monitors with per-cpu instances, and the third with per-task +instances. + +In all cases, the 'name' argument is a string that identifies the monitor, and +the 'type' argument is the data type used by dot2k on the representation of +the model in C. + +For example, the wip model with two states and three events can be +stored in an 'unsigned char' type. Considering that the preemption control +is a per-cpu behavior, the monitor declaration in the 'wip.c' file is:: + + DECLARE_DA_MON_PER_CPU(wip, unsigned char); + +The monitor is executed by sending events to be processed via the functions +presented below:: + + da_handle_event_$(MONITOR_NAME)($(event from event enum)); + da_handle_start_event_$(MONITOR_NAME)($(event from event enum)); + da_handle_start_run_event_$(MONITOR_NAME)($(event from event enum)); + +The function ``da_handle_event_$(MONITOR_NAME)()`` is the regular case where +the event will be processed if the monitor is processing events. + +When a monitor is enabled, it is placed in the initial state of the automata. +However, the monitor does not know if the system is in the *initial state*. + +The ``da_handle_start_event_$(MONITOR_NAME)()`` function is used to notify the +monitor that the system is returning to the initial state, so the monitor can +start monitoring the next event. + +The ``da_handle_start_run_event_$(MONITOR_NAME)()`` function is used to notify +the monitor that the system is known to be in the initial state, so the +monitor can start monitoring and monitor the current event. + +Using the wip model as example, the events "preempt_disable" and +"sched_waking" should be sent to monitor, respectively, via [2]:: + + da_handle_event_wip(preempt_disable_wip); + da_handle_event_wip(sched_waking_wip); + +While the event "preempt_enabled" will use:: + + da_handle_start_event_wip(preempt_enable_wip); + +To notify the monitor that the system will be returning to the initial state, +so the system and the monitor should be in sync. + +Final remarks +------------- + +With the monitor synthesis in place using the rv/da_monitor.h and +dot2k, the developer's work should be limited to the instrumentation +of the system, increasing the confidence in the overall approach. + +[1] For details about deterministic automata format and the translation +from one representation to another, see:: + + Documentation/trace/rv/deterministic_automata.rst + +[2] dot2k appends the monitor's name suffix to the events enums to +avoid conflicting variables when exporting the global vmlinux.h +use by BPF programs. diff --git a/Documentation/trace/rv/deterministic_automata.rst b/Documentation/trace/rv/deterministic_automata.rst new file mode 100644 index 000000000000..d0638f95a455 --- /dev/null +++ b/Documentation/trace/rv/deterministic_automata.rst @@ -0,0 +1,184 @@ +Deterministic Automata +====================== + +Formally, a deterministic automaton, denoted by G, is defined as a quintuple: + + *G* = { *X*, *E*, *f*, x\ :subscript:`0`, X\ :subscript:`m` } + +where: + +- *X* is the set of states; +- *E* is the finite set of events; +- x\ :subscript:`0` is the initial state; +- X\ :subscript:`m` (subset of *X*) is the set of marked (or final) states. +- *f* : *X* x *E* -> *X* $ is the transition function. It defines the state + transition in the occurrence of an event from *E* in the state *X*. In the + special case of deterministic automata, the occurrence of the event in *E* + in a state in *X* has a deterministic next state from *X*. + +For example, a given automaton named 'wip' (wakeup in preemptive) can +be defined as: + +- *X* = { ``preemptive``, ``non_preemptive``} +- *E* = { ``preempt_enable``, ``preempt_disable``, ``sched_waking``} +- x\ :subscript:`0` = ``preemptive`` +- X\ :subscript:`m` = {``preemptive``} +- *f* = + - *f*\ (``preemptive``, ``preempt_disable``) = ``non_preemptive`` + - *f*\ (``non_preemptive``, ``sched_waking``) = ``non_preemptive`` + - *f*\ (``non_preemptive``, ``preempt_enable``) = ``preemptive`` + +One of the benefits of this formal definition is that it can be presented +in multiple formats. For example, using a *graphical representation*, using +vertices (nodes) and edges, which is very intuitive for *operating system* +practitioners, without any loss. + +The previous 'wip' automaton can also be represented as:: + + preempt_enable + +---------------------------------+ + v | + #============# preempt_disable +------------------+ + --> H preemptive H -----------------> | non_preemptive | + #============# +------------------+ + ^ | + | sched_waking | + +--------------+ + +Deterministic Automaton in C +---------------------------- + +In the paper "Efficient formal verification for the Linux kernel", +the authors present a simple way to represent an automaton in C that can +be used as regular code in the Linux kernel. + +For example, the 'wip' automata can be presented as (augmented with comments):: + + /* enum representation of X (set of states) to be used as index */ + enum states { + preemptive = 0, + non_preemptive, + state_max + }; + + #define INVALID_STATE state_max + + /* enum representation of E (set of events) to be used as index */ + enum events { + preempt_disable = 0, + preempt_enable, + sched_waking, + event_max + }; + + struct automaton { + char *state_names[state_max]; // X: the set of states + char *event_names[event_max]; // E: the finite set of events + unsigned char function[state_max][event_max]; // f: transition function + unsigned char initial_state; // x_0: the initial state + bool final_states[state_max]; // X_m: the set of marked states + }; + + struct automaton aut = { + .state_names = { + "preemptive", + "non_preemptive" + }, + .event_names = { + "preempt_disable", + "preempt_enable", + "sched_waking" + }, + .function = { + { non_preemptive, INVALID_STATE, INVALID_STATE }, + { INVALID_STATE, preemptive, non_preemptive }, + }, + .initial_state = preemptive, + .final_states = { 1, 0 }, + }; + +The *transition function* is represented as a matrix of states (lines) and +events (columns), and so the function *f* : *X* x *E* -> *X* can be solved +in O(1). For example:: + + next_state = automaton_wip.function[curr_state][event]; + +Graphviz .dot format +-------------------- + +The Graphviz open-source tool can produce the graphical representation +of an automaton using the (textual) DOT language as the source code. +The DOT format is widely used and can be converted to many other formats. + +For example, this is the 'wip' model in DOT:: + + digraph state_automaton { + {node [shape = circle] "non_preemptive"}; + {node [shape = plaintext, style=invis, label=""] "__init_preemptive"}; + {node [shape = doublecircle] "preemptive"}; + {node [shape = circle] "preemptive"}; + "__init_preemptive" -> "preemptive"; + "non_preemptive" [label = "non_preemptive"]; + "non_preemptive" -> "non_preemptive" [ label = "sched_waking" ]; + "non_preemptive" -> "preemptive" [ label = "preempt_enable" ]; + "preemptive" [label = "preemptive"]; + "preemptive" -> "non_preemptive" [ label = "preempt_disable" ]; + { rank = min ; + "__init_preemptive"; + "preemptive"; + } + } + +This DOT format can be transformed into a bitmap or vectorial image +using the dot utility, or into an ASCII art using graph-easy. For +instance:: + + $ dot -Tsvg -o wip.svg wip.dot + $ graph-easy wip.dot > wip.txt + +dot2c +----- + +dot2c is a utility that can parse a .dot file containing an automaton as +in the example above and automatically convert it to the C representation +presented in [3]. + +For example, having the previous 'wip' model into a file named 'wip.dot', +the following command will transform the .dot file into the C +representation (previously shown) in the 'wip.h' file:: + + $ dot2c wip.dot > wip.h + +The 'wip.h' content is the code sample in section 'Deterministic Automaton +in C'. + +Remarks +------- + +The automata formalism allows modeling discrete event systems (DES) in +multiple formats, suitable for different applications/users. + +For example, the formal description using set theory is better suitable +for automata operations, while the graphical format for human interpretation; +and computer languages for machine execution. + +References +---------- + +Many textbooks cover automata formalism. For a brief introduction see:: + + O'Regan, Gerard. Concise guide to software engineering. Springer, + Cham, 2017. + +For a detailed description, including operations, and application on Discrete +Event Systems (DES), see:: + + Cassandras, Christos G., and Stephane Lafortune, eds. Introduction to discrete + event systems. Boston, MA: Springer US, 2008. + +For the C representation in kernel, see:: + + De Oliveira, Daniel Bristot; Cucinotta, Tommaso; De Oliveira, Romulo + Silva. Efficient formal verification for the Linux kernel. In: + International Conference on Software Engineering and Formal Methods. + Springer, Cham, 2019. p. 315-332. diff --git a/Documentation/trace/rv/index.rst b/Documentation/trace/rv/index.rst new file mode 100644 index 000000000000..15fa966102c0 --- /dev/null +++ b/Documentation/trace/rv/index.rst @@ -0,0 +1,14 @@ +==================== +Runtime Verification +==================== + +.. toctree:: + :maxdepth: 2 + :glob: + + runtime-verification.rst + deterministic_automata.rst + da_monitor_synthesis.rst + da_monitor_instrumentation.rst + monitor_wip.rst + monitor_wwnr.rst diff --git a/Documentation/trace/rv/monitor_wip.rst b/Documentation/trace/rv/monitor_wip.rst new file mode 100644 index 000000000000..a95763438c48 --- /dev/null +++ b/Documentation/trace/rv/monitor_wip.rst @@ -0,0 +1,55 @@ +Monitor wip +=========== + +- Name: wip - wakeup in preemptive +- Type: per-cpu deterministic automaton +- Author: Daniel Bristot de Oliveira <bristot@kernel.org> + +Description +----------- + +The wakeup in preemptive (wip) monitor is a sample per-cpu monitor +that verifies if the wakeup events always take place with +preemption disabled:: + + | + | + v + #==================# + H preemptive H <+ + #==================# | + | | + | preempt_disable | preempt_enable + v | + sched_waking +------------------+ | + +--------------- | | | + | | non_preemptive | | + +--------------> | | -+ + +------------------+ + +The wakeup event always takes place with preemption disabled because +of the scheduler synchronization. However, because the preempt_count +and its trace event are not atomic with regard to interrupts, some +inconsistencies might happen. For example:: + + preempt_disable() { + __preempt_count_add(1) + -------> smp_apic_timer_interrupt() { + preempt_disable() + do not trace (preempt count >= 1) + + wake up a thread + + preempt_enable() + do not trace (preempt count >= 1) + } + <------ + trace_preempt_disable(); + } + +This problem was reported and discussed here: + https://lore.kernel.org/r/cover.1559051152.git.bristot@redhat.com/ + +Specification +------------- +Grapviz Dot file in tools/verification/models/wip.dot diff --git a/Documentation/trace/rv/monitor_wwnr.rst b/Documentation/trace/rv/monitor_wwnr.rst new file mode 100644 index 000000000000..80f1777b85aa --- /dev/null +++ b/Documentation/trace/rv/monitor_wwnr.rst @@ -0,0 +1,45 @@ +Monitor wwnr +============ + +- Name: wwrn - wakeup while not running +- Type: per-task deterministic automaton +- Author: Daniel Bristot de Oliveira <bristot@kernel.org> + +Description +----------- + +This is a per-task sample monitor, with the following +definition:: + + | + | + v + wakeup +-------------+ + +--------- | | + | | not_running | + +--------> | | <+ + +-------------+ | + | | + | switch_in | switch_out + v | + +-------------+ | + | running | -+ + +-------------+ + +This model is borken, the reason is that a task can be running +in the processor without being set as RUNNABLE. Think about a +task about to sleep:: + + 1: set_current_state(TASK_UNINTERRUPTIBLE); + 2: schedule(); + +And then imagine an IRQ happening in between the lines one and two, +waking the task up. BOOM, the wakeup will happen while the task is +running. + +- Why do we need this model, so? +- To test the reactors. + +Specification +------------- +Grapviz Dot file in tools/verification/models/wwnr.dot diff --git a/Documentation/trace/rv/runtime-verification.rst b/Documentation/trace/rv/runtime-verification.rst new file mode 100644 index 000000000000..c46b6149470e --- /dev/null +++ b/Documentation/trace/rv/runtime-verification.rst @@ -0,0 +1,231 @@ +==================== +Runtime Verification +==================== + +Runtime Verification (RV) is a lightweight (yet rigorous) method that +complements classical exhaustive verification techniques (such as *model +checking* and *theorem proving*) with a more practical approach for complex +systems. + +Instead of relying on a fine-grained model of a system (e.g., a +re-implementation a instruction level), RV works by analyzing the trace of the +system's actual execution, comparing it against a formal specification of +the system behavior. + +The main advantage is that RV can give precise information on the runtime +behavior of the monitored system, without the pitfalls of developing models +that require a re-implementation of the entire system in a modeling language. +Moreover, given an efficient monitoring method, it is possible execute an +*online* verification of a system, enabling the *reaction* for unexpected +events, avoiding, for example, the propagation of a failure on safety-critical +systems. + +Runtime Monitors and Reactors +============================= + +A monitor is the central part of the runtime verification of a system. The +monitor stands in between the formal specification of the desired (or +undesired) behavior, and the trace of the actual system. + +In Linux terms, the runtime verification monitors are encapsulated inside the +*RV monitor* abstraction. A *RV monitor* includes a reference model of the +system, a set of instances of the monitor (per-cpu monitor, per-task monitor, +and so on), and the helper functions that glue the monitor to the system via +trace, as depicted bellow:: + + Linux +---- RV Monitor ----------------------------------+ Formal + Realm | | Realm + +-------------------+ +----------------+ +-----------------+ + | Linux kernel | | Monitor | | Reference | + | Tracing | -> | Instance(s) | <- | Model | + | (instrumentation) | | (verification) | | (specification) | + +-------------------+ +----------------+ +-----------------+ + | | | + | V | + | +----------+ | + | | Reaction | | + | +--+--+--+-+ | + | | | | | + | | | +-> trace output ? | + +------------------------|--|----------------------+ + | +----> panic ? + +-------> <user-specified> + +In addition to the verification and monitoring of the system, a monitor can +react to an unexpected event. The forms of reaction can vary from logging the +event occurrence to the enforcement of the correct behavior to the extreme +action of taking a system down to avoid the propagation of a failure. + +In Linux terms, a *reactor* is an reaction method available for *RV monitors*. +By default, all monitors should provide a trace output of their actions, +which is already a reaction. In addition, other reactions will be available +so the user can enable them as needed. + +For further information about the principles of runtime verification and +RV applied to Linux: + + Bartocci, Ezio, et al. *Introduction to runtime verification.* In: Lectures on + Runtime Verification. Springer, Cham, 2018. p. 1-33. + + Falcone, Ylies, et al. *A taxonomy for classifying runtime verification tools.* + In: International Conference on Runtime Verification. Springer, Cham, 2018. p. + 241-262. + + De Oliveira, Daniel Bristot. *Automata-based formal analysis and + verification of the real-time Linux kernel.* Ph.D. Thesis, 2020. + +Online RV monitors +================== + +Monitors can be classified as *offline* and *online* monitors. *Offline* +monitor process the traces generated by a system after the events, generally by +reading the trace execution from a permanent storage system. *Online* monitors +process the trace during the execution of the system. Online monitors are said +to be *synchronous* if the processing of an event is attached to the system +execution, blocking the system during the event monitoring. On the other hand, +an *asynchronous* monitor has its execution detached from the system. Each type +of monitor has a set of advantages. For example, *offline* monitors can be +executed on different machines but require operations to save the log to a +file. In contrast, *synchronous online* method can react at the exact moment +a violation occurs. + +Another important aspect regarding monitors is the overhead associated with the +event analysis. If the system generates events at a frequency higher than the +monitor's ability to process them in the same system, only the *offline* +methods are viable. On the other hand, if the tracing of the events incurs +on higher overhead than the simple handling of an event by a monitor, then a +*synchronous online* monitors will incur on lower overhead. + +Indeed, the research presented in: + + De Oliveira, Daniel Bristot; Cucinotta, Tommaso; De Oliveira, Romulo Silva. + *Efficient formal verification for the Linux kernel.* In: International + Conference on Software Engineering and Formal Methods. Springer, Cham, 2019. + p. 315-332. + +Shows that for Deterministic Automata models, the synchronous processing of +events in-kernel causes lower overhead than saving the same events to the trace +buffer, not even considering collecting the trace for user-space analysis. +This motivated the development of an in-kernel interface for online monitors. + +For further information about modeling of Linux kernel behavior using automata, +see: + + De Oliveira, Daniel B.; De Oliveira, Romulo S.; Cucinotta, Tommaso. *A thread + synchronization model for the PREEMPT_RT Linux kernel.* Journal of Systems + Architecture, 2020, 107: 101729. + +The user interface +================== + +The user interface resembles the tracing interface (on purpose). It is +currently at "/sys/kernel/tracing/rv/". + +The following files/folders are currently available: + +**available_monitors** + +- Reading list the available monitors, one per line + +For example:: + + # cat available_monitors + wip + wwnr + +**available_reactors** + +- Reading shows the available reactors, one per line. + +For example:: + + # cat available_reactors + nop + panic + printk + +**enabled_monitors**: + +- Reading lists the enabled monitors, one per line +- Writing to it enables a given monitor +- Writing a monitor name with a '!' prefix disables it +- Truncating the file disables all enabled monitors + +For example:: + + # cat enabled_monitors + # echo wip > enabled_monitors + # echo wwnr >> enabled_monitors + # cat enabled_monitors + wip + wwnr + # echo '!wip' >> enabled_monitors + # cat enabled_monitors + wwnr + # echo > enabled_monitors + # cat enabled_monitors + # + +Note that it is possible to enable more than one monitor concurrently. + +**monitoring_on** + +This is an on/off general switcher for monitoring. It resembles the +"tracing_on" switcher in the trace interface. + +- Writing "0" stops the monitoring +- Writing "1" continues the monitoring +- Reading returns the current status of the monitoring + +Note that it does not disable enabled monitors but stop the per-entity +monitors monitoring the events received from the system. + +**reacting_on** + +- Writing "0" prevents reactions for happening +- Writing "1" enable reactions +- Reading returns the current status of the reaction + +**monitors/** + +Each monitor will have its own directory inside "monitors/". There the +monitor-specific files will be presented. The "monitors/" directory resembles +the "events" directory on tracefs. + +For example:: + + # cd monitors/wip/ + # ls + desc enable + # cat desc + wakeup in preemptive per-cpu testing monitor. + # cat enable + 0 + +**monitors/MONITOR/desc** + +- Reading shows a description of the monitor *MONITOR* + +**monitors/MONITOR/enable** + +- Writing "0" disables the *MONITOR* +- Writing "1" enables the *MONITOR* +- Reading return the current status of the *MONITOR* + +**monitors/MONITOR/reactors** + +- List available reactors, with the select reaction for the given *MONITOR* + inside "[]". The default one is the nop (no operation) reactor. +- Writing the name of a reactor enables it to the given MONITOR. + +For example:: + + # cat monitors/wip/reactors + [nop] + panic + printk + # echo panic > monitors/wip/reactors + # cat monitors/wip/reactors + nop + [panic] + printk diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst index a8e5938f609e..3a1797d707f4 100644 --- a/Documentation/trace/uprobetracer.rst +++ b/Documentation/trace/uprobetracer.rst @@ -26,10 +26,10 @@ Synopsis of uprobe_tracer ------------------------- :: - p[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a uprobe - r[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe) - p[:[GRP/]EVENT] PATH:OFFSET%return [FETCHARGS] : Set a return uprobe (uretprobe) - -:[GRP/]EVENT : Clear uprobe or uretprobe event + p[:[GRP/][EVENT]] PATH:OFFSET [FETCHARGS] : Set a uprobe + r[:[GRP/][EVENT]] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe) + p[:[GRP/][EVENT]] PATH:OFFSET%return [FETCHARGS] : Set a return uprobe (uretprobe) + -:[GRP/][EVENT] : Clear uprobe or uretprobe event GRP : Group name. If omitted, "uprobes" is the default value. EVENT : Event name. If omitted, the event name is generated based diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst index 42f5d04e38ec..0f6898860d6d 100644 --- a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -50,9 +50,9 @@ Di conseguenza, nella tabella dei simboli del kernel ci sarà una voce rappresentata dalla struttura ``kernel_symbol`` che avrà il campo ``namespace`` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio dei nomi avrà questo campo impostato a ``NULL``. Non esiste uno spazio dei nomi -di base. Il programma ``modpost`` e il codice in kernel/module.c usano lo spazio -dei nomi, rispettivamente, durante la compilazione e durante il caricamento -di un modulo. +di base. Il programma ``modpost`` e il codice in kernel/module/main.c usano lo +spazio dei nomi, rispettivamente, durante la compilazione e durante il +caricamento di un modulo. 2.2 Usare il simbolo di preprocessore DEFAULT_SYMBOL_NAMESPACE ============================================================== diff --git a/Documentation/translations/it_IT/devicetree/bindings/submitting-patches.rst b/Documentation/translations/it_IT/devicetree/bindings/submitting-patches.rst new file mode 100644 index 000000000000..b473cd2190be --- /dev/null +++ b/Documentation/translations/it_IT/devicetree/bindings/submitting-patches.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../../disclaimer-ita.rst + +:Original: Documentation/devicetree/bindings/submitting-patches.rst + +================================================ +Sottomettere patch per devicetree (DT) *binding* +================================================ + +.. note:: to be translated diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst index 009cdac014b6..78082281acf9 100644 --- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst +++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst @@ -5,6 +5,7 @@ .. _it_kernel_doc: +================================= Scrivere i commenti in kernel-doc ================================= @@ -469,6 +470,7 @@ Il titolo che segue ``DOC:`` funziona da intestazione all'interno del file sorgente, ma anche come identificatore per l'estrazione di questi commenti di documentazione. Quindi, il titolo dev'essere unico all'interno del file. +======================================= Includere i commenti di tipo kernel-doc ======================================= diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst b/Documentation/translations/it_IT/doc-guide/sphinx.rst index 9762452c584c..64528790dc34 100644 --- a/Documentation/translations/it_IT/doc-guide/sphinx.rst +++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst @@ -5,8 +5,9 @@ .. _it_sphinxdoc: -Introduzione -============ +============================================= +Usare Sphinx per la documentazione del kernel +============================================= Il kernel Linux usa `Sphinx`_ per la generazione della documentazione a partire dai file `reStructuredText`_ che si trovano nella cartella ``Documentation``. @@ -158,6 +159,9 @@ Per poter passare ulteriori opzioni a Sphinx potete utilizzare la variabile make ``SPHINXOPTS``. Per esempio, se volete che Sphinx sia più verboso durante la generazione potete usare il seguente comando ``make SPHINXOPTS=-v htmldocs``. +Potete anche personalizzare l'ouptut html passando un livello aggiuntivo +DOCS_CSS usando la rispettiva variabile d'ambiente ``DOCS_CSS``. + Potete eliminare la documentazione generata tramite il comando ``make cleandocs``. @@ -276,11 +280,11 @@ incrociato quando questa ha una voce nell'indice. Se trovate degli usi di Tabelle a liste --------------- -Raccomandiamo l'uso delle tabelle in formato lista (*list table*). Le tabelle -in formato lista sono liste di liste. In confronto all'ASCII-art potrebbero -non apparire di facile lettura nei file in formato testo. Il loro vantaggio è -che sono facili da creare o modificare e che la differenza di una modifica è -molto più significativa perché limitata alle modifiche del contenuto. +Il formato ``list-table`` può essere utile per tutte quelle tabelle che non +possono essere facilmente scritte usando il formato ASCII-art di Sphinx. Però, +questo genere di tabelle sono illeggibili per chi legge direttamente i file di +testo. Dunque, questo formato dovrebbe essere evitato senza forti argomenti che +ne giustifichino l'uso. La ``flat-table`` è anch'essa una lista di liste simile alle ``list-table`` ma con delle funzionalità aggiuntive: diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index d5c521327f6a..560f1d0482d2 100644 --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst @@ -129,8 +129,7 @@ eseguiti simultaneamente. .. warning:: Il nome 'tasklet' è ingannevole: non hanno niente a che fare - con i 'processi' ('tasks'), e probabilmente hanno più a che vedere - con qualche pessima vodka che Alexey Kuznetsov si fece a quel tempo. + con i 'processi' ('tasks'). Potete determinate se siete in un softirq (o tasklet) utilizzando la macro :c:func:`in_softirq()` (``include/linux/preempt.h``). @@ -308,7 +307,7 @@ esse copiano una quantità arbitraria di dati da e verso lo spazio utente. Al contrario di:c:func:`put_user()` e :c:func:`get_user()`, queste funzioni ritornano la quantità di dati copiati (0 è comunque un successo). -[Sì, questa stupida interfaccia mi imbarazza. La battaglia torna in auge anno +[Sì, questa interfaccia mi imbarazza. La battaglia torna in auge anno dopo anno. --RR] Le funzioni potrebbero dormire implicitamente. Queste non dovrebbero mai essere @@ -679,9 +678,8 @@ tutti sulle spine: questo riflette cambiamenti fondamentati (eg. la funzione non può più essere chiamata con le funzioni attive, o fa controlli aggiuntivi, o non fa più controlli che venivano fatti in precedenza). Solitamente a questo s'accompagna un'adeguata e completa nota sulla lista di discussone -linux-kernel; cercate negli archivi. -Solitamente eseguire una semplice sostituzione su tutto un file rendere -le cose **peggiori**. +più adatta; cercate negli archivi. Solitamente eseguire una semplice +sostituzione su tutto un file rendere le cose **peggiori**. Inizializzazione dei campi d'una struttura ------------------------------------------ @@ -759,14 +757,14 @@ Mettere le vostre cose nel kernel Al fine d'avere le vostre cose in ordine per l'inclusione ufficiale, o anche per avere patch pulite, c'è del lavoro amministrativo da fare: -- Trovare di chi è lo stagno in cui state pisciando. Guardare in cima +- Trovare chi è responsabile del codice che state modificando. Guardare in cima ai file sorgenti, all'interno del file ``MAINTAINERS``, ed alla fine di tutti nel file ``CREDITS``. Dovreste coordinarvi con queste persone per evitare di duplicare gli sforzi, o provare qualcosa che è già stato rigettato. Assicuratevi di mettere il vostro nome ed indirizzo email in cima a - tutti i file che create o che mangeggiate significativamente. Questo è + tutti i file che create o che maneggiate significativamente. Questo è il primo posto dove le persone guarderanno quando troveranno un baco, o quando **loro** vorranno fare una modifica. @@ -787,16 +785,15 @@ anche per avere patch pulite, c'è del lavoro amministrativo da fare: "obj-$(CONFIG_xxx) += xxx.o". La sintassi è documentata nel file ``Documentation/kbuild/makefiles.rst``. -- Aggiungete voi stessi in ``CREDITS`` se avete fatto qualcosa di notevole, - solitamente qualcosa che supera il singolo file (comunque il vostro nome - dovrebbe essere all'inizio dei file sorgenti). ``MAINTAINERS`` significa +- Aggiungete voi stessi in ``CREDITS`` se credete di aver fatto qualcosa di + notevole, solitamente qualcosa che supera il singolo file (comunque il vostro + nome dovrebbe essere all'inizio dei file sorgenti). ``MAINTAINERS`` significa che volete essere consultati quando vengono fatte delle modifiche ad un - sottosistema, e quando ci sono dei bachi; questo implica molto di più - di un semplice impegno su una parte del codice. + sottosistema, e quando ci sono dei bachi; questo implica molto di più di un + semplice impegno su una parte del codice. - Infine, non dimenticatevi di leggere - ``Documentation/process/submitting-patches.rst`` e possibilmente anche - ``Documentation/process/submitting-drivers.rst``. + ``Documentation/process/submitting-patches.rst``. Trucchetti del kernel ===================== diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 163f1bd4e857..51af37f2d621 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -102,16 +102,11 @@ che non esistano. Sincronizzazione nel kernel Linux ================================= -Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di -voi. Ma se dovessi darvi un suggerimento sulla sincronizzazione: -**mantenetela semplice**. +Se dovessi darvi un suggerimento sulla sincronizzazione: **mantenetela +semplice**. Siate riluttanti nell'introduzione di nuovi *lock*. -Abbastanza strano, quest'ultimo è l'esatto opposto del mio suggerimento -su quando **avete** dormito con qualcuno più pazzo di voi. E dovreste -pensare a prendervi un cane bello grande. - I due principali tipi di *lock* nel kernel: spinlock e mutex ------------------------------------------------------------ @@ -316,7 +311,7 @@ Pete Zaitcev ci offre il seguente riassunto: - Se siete in un contesto utente (una qualsiasi chiamata di sistema) e volete sincronizzarvi con altri processi, usate i mutex. Potete trattenere - il mutex e dormire (``copy_from_user*(`` o ``kmalloc(x,GFP_KERNEL)``). + il mutex e dormire (``copy_from_user(`` o ``kmalloc(x,GFP_KERNEL)``). - Altrimenti (== i dati possono essere manipolati da un'interruzione) usate spin_lock_irqsave() e spin_unlock_irqrestore(). @@ -979,9 +974,6 @@ fallisce nel trovare quello che vuole, quindi rilascia il *lock* di lettura, trattiene un *lock* di scrittura ed inserisce un oggetto; questo genere di codice presenta una corsa critica. -Se non riuscite a capire il perché, per favore state alla larga dal mio -codice. - corsa fra temporizzatori: un passatempo del kernel -------------------------------------------------- diff --git a/Documentation/translations/it_IT/maintainer/configure-git.rst b/Documentation/translations/it_IT/maintainer/configure-git.rst new file mode 100644 index 000000000000..8316fa53946f --- /dev/null +++ b/Documentation/translations/it_IT/maintainer/configure-git.rst @@ -0,0 +1,10 @@ +.. include:: ../disclaimer-ita.rst + +:Original: Documentation/process/botching-up-ioctls.rst + +.. _it_configuregit: + +Configurare Git +=============== + +.. note:: To be translated diff --git a/Documentation/translations/it_IT/networking/netdev-FAQ.rst b/Documentation/translations/it_IT/networking/netdev-FAQ.rst index 7e2456bb7d92..8a1e049585c0 100644 --- a/Documentation/translations/it_IT/networking/netdev-FAQ.rst +++ b/Documentation/translations/it_IT/networking/netdev-FAQ.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>` +:Original: :ref:`Documentation/process/maintainer-netdev.rst <netdev-FAQ>` .. _it_netdev-FAQ: diff --git a/Documentation/translations/it_IT/process/3.Early-stage.rst b/Documentation/translations/it_IT/process/3.Early-stage.rst index 443ac1e5558f..0809de39108a 100644 --- a/Documentation/translations/it_IT/process/3.Early-stage.rst +++ b/Documentation/translations/it_IT/process/3.Early-stage.rst @@ -168,14 +168,15 @@ in questa ricerca: .../scripts/get_maintainer.pl -Se questo script viene eseguito con l'opzione "-f" ritornerà il -manutentore(i) attuale per un dato file o cartella. Se viene passata una -patch sulla linea di comando, lo script elencherà i manutentori che -dovrebbero riceverne una copia. Ci sono svariate opzioni che regolano -quanto a fondo get_maintainer.pl debba cercare i manutentori; -siate quindi prudenti nell'utilizzare le opzioni più aggressive poiché -potreste finire per includere sviluppatori che non hanno un vero interesse -per il codice che state modificando. +Se questo script viene eseguito con l'opzione "-f" ritornerà il manutentore(i) +attuale per un dato file o cartella. Se viene passata una patch sulla linea di +comando, lo script elencherà i manutentori che dovrebbero riceverne una copia. +Questo è la maniera raccomandata (non quella con "-f") per ottenere la lista di +persone da aggiungere a Cc per le vostre patch. Ci sono svariate opzioni che +regolano quanto a fondo get_maintainer.pl debba cercare i manutentori; siate +quindi prudenti nell'utilizzare le opzioni più aggressive poiché potreste finire +per includere sviluppatori che non hanno un vero interesse per il codice che +state modificando. Se tutto ciò dovesse fallire, parlare con Andrew Morton potrebbe essere un modo efficace per capire chi è il manutentore di un dato pezzo di codice. diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst index 1476d51eb5e5..cf92a16ed7e5 100644 --- a/Documentation/translations/it_IT/process/5.Posting.rst +++ b/Documentation/translations/it_IT/process/5.Posting.rst @@ -16,9 +16,8 @@ e di procedure per la pubblicazione delle patch; seguirle renderà la vita più facile a tutti quanti. Questo documento cercherà di coprire questi argomenti con un ragionevole livello di dettaglio; più informazioni possono essere trovare nella cartella 'Documentation', nei file -:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`, -:ref:`translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`, e -:ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`. +:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` +e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`. Quando pubblicarle @@ -214,13 +213,28 @@ irrilevanti (quelli generati dal processo di generazione, per esempio, o i file di backup del vostro editor). Il file "dontdiff" nella cartella Documentation potrà esservi d'aiuto su questo punto; passatelo a diff con l'opzione "-X". -Le etichette sopra menzionante sono usate per descrivere come i vari -sviluppatori sono stati associati allo sviluppo di una patch. Sono descritte -in dettaglio nel documento :ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`; -quello che segue è un breve riassunto. Ognuna di queste righe ha il seguente -formato: +Le etichette sopracitate danno un'idea di come una patch prende vita e sono +descritte nel dettaglio nel documento +:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`. +Qui di seguito un breve riassunto. -:: +Un'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch:: + + Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID") + +Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti +maggiori informazioni, per esempio un rapporto circa il baco risolto dalla +patch, oppure un documento con le specifiche implementate dalla patch:: + + Link: https://example.com/somewhere.html optional-other-stuff + +Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento +alla più recente discussione pubblica. A volte questo è fatto automaticamente da +alcuni strumenti come b4 or un *hook* git come quello descritto qui +'Documentation/translations/it_IT/maintainer/configure-git.rst' + +Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo +sviluppo della patch. Tutte queste etichette seguono il formato:: tag: Full Name <email address> optional-other-stuff diff --git a/Documentation/translations/it_IT/process/8.Conclusion.rst b/Documentation/translations/it_IT/process/8.Conclusion.rst index 039bfc5a4108..32659ff467c0 100644 --- a/Documentation/translations/it_IT/process/8.Conclusion.rst +++ b/Documentation/translations/it_IT/process/8.Conclusion.rst @@ -13,9 +13,8 @@ e argomenti correlati. Primo tra questi sarà sempre la cartella Documentation che si trova nei sorgenti kernel. Il file :ref:`process/howto.rst <it_process_howto>` è un punto di partenza -importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` e -:ref:`process/submitting-drivers.rst <it_submittingdrivers>` sono -anch'essi qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere. +importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` è +anch'esso qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere. Molte API interne al kernel sono documentate utilizzando il meccanismo kerneldoc; "make htmldocs" o "make pdfdocs" possono essere usati per generare quei documenti in HTML o PDF (sebbene le versioni di TeX di alcune diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index dc7193377b7f..10e0ef9c34b7 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -11,8 +11,8 @@ Requisiti minimi per compilare il kernel Introduzione ============ -Questo documento fornisce una lista dei software necessari per eseguire i -kernel 4.x. +Questo documento fornisce una lista dei software necessari per eseguire questa +versione del kernel. Questo documento è basato sul file "Changes" del kernel 2.0.x e quindi le persone che lo scrissero meritano credito (Jared Mauch, Axel Boldt, @@ -32,12 +32,13 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils. ====================== ================= ======================================== Programma Versione minima Comando per verificare la versione ====================== ================= ======================================== -GNU C 4.9 gcc --version -Clang/LLVM (optional) 10.0.1 clang --version +GNU C 5.1 gcc --version +Clang/LLVM (optional) 11.0.0 clang --version GNU make 3.81 make --version binutils 2.23 ld -v flex 2.5.35 flex --version bison 2.0 bison --version +pahole 1.16 pahole --version util-linux 2.10o fdformat --version kmod 13 depmod -V e2fsprogs 1.41.4 e2fsck -V @@ -58,6 +59,7 @@ iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version Sphinx\ [#f1]_ 1.7 sphinx-build --version +cpio any cpio --version ====================== ================= ======================================== .. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel @@ -111,6 +113,16 @@ Bison Dalla versione 4.16, il sistema di compilazione, durante l'esecuzione, genera un parsificatore. Questo richiede bison 2.0 o successivo. +pahole +------ + +Dalla versione 5.2, quando viene impostato CONFIG_DEBUG_INFO_BTF, il sistema di +compilazione genera BTF (BPF Type Format) a partire da DWARF per vmlinux. Più +tardi anche per i moduli. Questo richiede pahole v1.16 o successivo. + +A seconda della distribuzione, lo si può trovare nei pacchetti 'dwarves' o +'pahole'. Oppure lo si può trovare qui: https://fedorapeople.org/~acme/dwarves/. + Perl ---- @@ -455,6 +467,11 @@ mcelog - <http://www.mcelog.org/> +cpio +---- + +- <https://www.gnu.org/software/cpio/> + Rete **** diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index ecc74ba50d3e..a393ee4182af 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -466,14 +466,52 @@ la riga della parentesi graffa di chiusura. Ad esempio: } EXPORT_SYMBOL(system_is_up); +6.1) Prototipi di funzione +************************** + Nei prototipi di funzione, includete i nomi dei parametri e i loro tipi. Nonostante questo non sia richiesto dal linguaggio C, in Linux viene preferito perché è un modo semplice per aggiungere informazioni importanti per il lettore. -Non usate la parola chiave ``extern`` coi prototipi di funzione perché +Non usate la parola chiave ``extern`` con le dichiarazioni di funzione perché rende le righe più lunghe e non è strettamente necessario. +Quando scrivete i prototipi di funzione mantenete `l'ordine degli elementi <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_. + +Prendiamo questa dichiarazione di funzione come esempio:: + + __init void * __must_check action(enum magic value, size_t size, u8 count, + char *fmt, ...) __printf(4, 5) __malloc; + +L'ordine suggerito per gli elementi di un prototipo di funzione è il seguente: + +- classe d'archiviazione (in questo caso ``static __always_inline``. Da notare + che ``__always_inline`` è tecnicamente un attributo ma che viene trattato come + ``inline``) +- attributi della classe di archiviazione (in questo caso ``__init``, in altre + parole la sezione, ma anche cose tipo ``__cold``) +- il tipo di ritorno (in questo caso, ``void *``) +- attributi per il valore di ritorno (in questo caso, ``__must_check``) +- il nome della funzione (in questo caso, ``action``) +- i parametri della funzione(in questo caso, + ``(enum magic value, size_t size, u8 count, char *fmt, ...)``, + da notare che va messo anche il nome del parametro) +- attributi dei parametri (in questo caso, ``__printf(4, 5)``) +- attributi per il comportamento della funzione (in questo caso, ``__malloc_``) + +Notate che per la **definizione** di una funzione (il altre parole il corpo +della funzione), il compilatore non permette di usare gli attributi per i +parametri dopo i parametri. In questi casi, devono essere messi dopo gli +attributi della classe d'archiviazione (notate che la posizione di +``__printf(4,5)`` cambia rispetto alla **dichiarazione**):: + + static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value, + size_t size, u8 count, char *fmt, ...) __malloc + { + ... + }*)**``)**``)``)``*)``)``)``)``*``)``)``)*) + 7) Centralizzare il ritorno delle funzioni ------------------------------------------ @@ -855,7 +893,7 @@ I messaggi del kernel non devono terminare con un punto fermo. Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo dovrebbero essere evitati. -Ci sono alcune macro per la diagnostica in <linux/device.h> che dovreste +Ci sono alcune macro per la diagnostica in <linux/dev_printk.h> che dovreste usare per assicurarvi che i messaggi vengano associati correttamente ai dispositivi e ai driver, e che siano etichettati correttamente: dev_err(), dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index 987f45ee1804..febf83897783 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -69,8 +69,8 @@ dovrebbero essere fatto negli argomenti di funzioni di allocazione di memoria piccoli di quelli che il chiamante si aspettava. L'uso di questo modo di allocare può portare ad un overflow della memoria di heap e altri malfunzionamenti. (Si fa eccezione per valori numerici per i quali il -compilatore può generare avvisi circa un potenziale overflow. Tuttavia usare -i valori numerici come suggerito di seguito è innocuo). +compilatore può generare avvisi circa un potenziale overflow. Tuttavia, anche in +questi casi è preferibile riscrivere il codice come suggerito di seguito). Per esempio, non usate ``count * size`` come argomento:: @@ -80,6 +80,9 @@ Al suo posto, si dovrebbe usare l'allocatore a due argomenti:: foo = kmalloc_array(count, size, GFP_KERNEL); +Nello specifico, kmalloc() può essere sostituta da kmalloc_array(), e kzalloc() +da kcalloc(). + Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate le funzioni del tipo *saturate-on-overflow*:: @@ -100,9 +103,20 @@ Invece, usate la seguente funzione:: invitati a riorganizzare il vostro codice usando il `flexible array member <#zero-length-and-one-element-arrays>`_. -Per maggiori dettagli fate riferimento a array_size(), -array3_size(), e struct_size(), così come la famiglia di -funzioni check_add_overflow() e check_mul_overflow(). +Per altri calcoli, usate le funzioni size_mul(), size_add(), e size_sub(). Per +esempio, al posto di:: + + foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +dovreste scrivere: + + foo = krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +Per maggiori dettagli fate riferimento a array3_size() e flex_array_size(), ma +anche le funzioni della famiglia check_mul_overflow(), check_add_overflow(), +check_sub_overflow(), e check_shl_overflow(). simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() ---------------------------------------------------------------------- diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst index 9554368a2ae2..16ad5622d549 100644 --- a/Documentation/translations/it_IT/process/howto.rst +++ b/Documentation/translations/it_IT/process/howto.rst @@ -109,8 +109,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che accetteranno patch solo se queste osserveranno tali regole, e molte persone revisioneranno il codice solo se scritto nello stile appropriato. - :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` e - :ref:`Documentation/translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>` + :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` Questo file descrive dettagliatamente come creare ed inviare una patch con successo, includendo (ma non solo questo): diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst index c4c867132c88..8d4e36a07ff4 100644 --- a/Documentation/translations/it_IT/process/index.rst +++ b/Documentation/translations/it_IT/process/index.rst @@ -41,12 +41,12 @@ degli sviluppatori: :maxdepth: 1 changes - submitting-drivers stable-api-nonsense management-style stable-kernel-rules submit-checklist kernel-docs + maintainers Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo perché non si è trovato un posto migliore. diff --git a/Documentation/translations/it_IT/process/maintainer-handbooks.rst b/Documentation/translations/it_IT/process/maintainer-handbooks.rst new file mode 100644 index 000000000000..d840145bcceb --- /dev/null +++ b/Documentation/translations/it_IT/process/maintainer-handbooks.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +:Original: Documentation/process/maintainer-handbooks.rst +:Translator: Federico Vaga <federico.vaga@vaga.pv.it> + +.. _it_maintainer_handbooks_main: + +Note sul processo di sviluppo dei sottosistemi e dei sorgenti dei manutentori +============================================================================= + +Lo scopo di questo documento è quello di fornire informazioni sul processo di +sviluppo dedicate ai sottosistemi che vanno ad integrare quelle più generali +descritte in :ref:`Documentation/translations/it_IT/process +<it_development_process_main>`. + +Indice: + +.. toctree:: + :numbered: + :maxdepth: 2 + + maintainer-tip diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst index f3c8e8d377ee..a1e98ec9532e 100644 --- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst +++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst @@ -931,12 +931,11 @@ che avete nel vostro portachiavi:: uid [ unknown] Linus Torvalds <torvalds@kernel.org> sub rsa2048 2011-09-20 [E] -Poi, aprite il `PGP pathfinder`_. Nel campo "From", incollate l'impronta -digitale della chiave di Linus Torvalds che si vede nell'output qui sopra. -Nel campo "to", incollate il key-id della chiave sconosciuta che avete -trovato con ``gpg --search``, e poi verificare il risultato: - -- `Finding paths to Linus`_ +Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete +trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare +diversi strumenti come https://github.com/mricon/wotmate, +https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e +https://the.earth.li/~noodles/pathfind.html. Se trovate un paio di percorsi affidabili è un buon segno circa la validità della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver:: @@ -948,6 +947,3 @@ fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`). Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso miglioramento rispetto alla cieca fiducia nei keyserver. - -.. _`PGP pathfinder`: https://pgp.cs.uu.nl/ -.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html diff --git a/Documentation/translations/it_IT/process/maintainer-tip.rst b/Documentation/translations/it_IT/process/maintainer-tip.rst new file mode 100644 index 000000000000..126f17ee541e --- /dev/null +++ b/Documentation/translations/it_IT/process/maintainer-tip.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-ita.rst + +:Original: Documentation/process/maintainer-tip.rst + +Il tascabile dei sorgenti tip +============================= + +.. note:: To be translated diff --git a/Documentation/translations/it_IT/process/maintainers.rst b/Documentation/translations/it_IT/process/maintainers.rst new file mode 100644 index 000000000000..3225f7c89fda --- /dev/null +++ b/Documentation/translations/it_IT/process/maintainers.rst @@ -0,0 +1,13 @@ +:Original: Documentation/process/maintainers.rst + +Lista dei manutentori e come inviare modifiche al kernel +======================================================== + +Questa pagina non verrà tradotta. Fate riferimento alla versione originale in +inglese. + +.. note:: La pagina originale usa una direttiva speciale per integrare il file + `MAINTAINERS` in sphinx. La parte di quel documento che si potrebbe + tradurre contiene comunque informazioni già presenti in + :ref:`Documentation/translations/it_IT/process/submitting-patches.rst + <it_submittingpatches>`. diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 83f48afe48b9..0be675b03199 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -41,10 +41,10 @@ Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti Procedura per sottomettere patch per i sorgenti -stable ------------------------------------------------------- - - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo - di revisione -stable, ma dovrebbe seguire le procedure descritte in - :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. - +.. note:: + Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo + di revisione -stable, ma dovrebbe seguire le procedure descritte in + :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`. Per tutte le altre sottomissioni, scegliere una delle seguenti procedure ------------------------------------------------------------------------ @@ -90,9 +90,9 @@ L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento dell'inclusione dei sorgenti principali, si ritiene che non debbano essere incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è -particolarmente utile se la patch ha bisogno di qualche modifica per essere -applicata ad un kernel più vecchio (per esempio, perché nel frattempo l'API è -cambiata). +particolarmente utile se una patch dev'essere riportata su una versione +precedente (per esempio la patch richiede modifiche a causa di cambiamenti di +API). Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei sorgenti principali (per esempio perché è stato necessario un lavoro di @@ -167,9 +167,18 @@ Ciclo di una revisione della lista linux-kernel obietta la bontà della patch, sollevando problemi che i manutentori ed i membri non avevano compreso, allora la patch verrà rimossa dalla coda. - - Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK - verranno aggiunte per il prossimo rilascio -stable, e successivamente - questo nuovo rilascio verrà fatto. + - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di + un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e + dai testatori. + - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi + importanti, alcune patch potrebbero essere modificate o essere scartate, + oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate + nuove -rc e così via finché non si ritiene che non vi siano più problemi. + - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email + con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al + commit rilascio. + - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le + patch che erano in coda e sono state verificate. - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente dalla squadra per la sicurezza del kernel, e non passerà per il normale ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli @@ -186,8 +195,19 @@ Sorgenti - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere trovato in rami distinti per versione al seguente indirizzo: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git + + - I rilasci candidati di tutti i kernel stabili possono essere trovati al + seguente indirizzo: + + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ + + .. warning:: + I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e + subirà frequenti modifiche, dunque verrà anche trapiantato spesso. + Dovrebbe essere usato solo allo scopo di verifica (per esempio in un + sistema di CI) Comitato per la revisione ------------------------- diff --git a/Documentation/translations/it_IT/process/submitting-drivers.rst b/Documentation/translations/it_IT/process/submitting-drivers.rst deleted file mode 100644 index dadd77e47613..000000000000 --- a/Documentation/translations/it_IT/process/submitting-drivers.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. include:: ../disclaimer-ita.rst - -:Original: :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` -:Translator: Federico Vaga <federico.vaga@vaga.pv.it> - -.. _it_submittingdrivers: - -Sottomettere driver per il kernel Linux -======================================= - -.. note:: - - Questo documento è vecchio e negli ultimi anni non è stato più aggiornato; - dovrebbe essere aggiornato, o forse meglio, rimosso. La maggior parte di - quello che viene detto qui può essere trovato anche negli altri documenti - dedicati allo sviluppo. Per questo motivo il documento non verrà tradotto. diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index 4fb5b3aa306d..a3bb0008837a 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -18,16 +18,18 @@ Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori dettagli su come funziona il processo di sviluppo del kernel leggete Documentation/translations/it_IT/process/development-process.rst. Leggete anche Documentation/translations/it_IT/process/submit-checklist.rst per una lista di -punti da verificare prima di inviare del codice. Se state inviando un driver, -allora leggete anche -Documentation/translations/it_IT/process/submitting-drivers.rst; per delle patch -relative alle associazioni per Device Tree leggete +punti da verificare prima di inviare del codice. +Per delle patch relative alle associazioni per Device Tree leggete Documentation/translations/it_IT/process/submitting-patches.rst. Questa documentazione assume che sappiate usare ``git`` per preparare le patch. Se non siete pratici di ``git``, allora è bene che lo impariate; renderà la vostra vita di sviluppatore del kernel molto più semplice. +I sorgenti di alcuni sottosistemi e manutentori contengono più informazioni +riguardo al loro modo di lavorare ed aspettative. Consultate +:ref:`Documentation/translations/it_IT/process/maintainer-handbooks.rst <it_maintainer_handbooks_main>` + Ottenere i sorgenti attuali --------------------------- @@ -84,11 +86,11 @@ comporti come descritto. I manutentori vi saranno grati se scrivete la descrizione della patch in un formato che sia compatibile con il gestore dei sorgenti usato dal kernel, -``git``, come un "commit log". Leggete :ref:`it_explicit_in_reply_to`. +``git``, come un "commit log". Leggete :ref:`it_the_canonical_patch_format`. Risolvete solo un problema per patch. Se la vostra descrizione inizia ad essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere -divisa. Leggete :ref:`split_changes`. +divisa. Leggete :ref:`it_split_changes`. Quando inviate o rinviate una patch o una serie, includete la descrizione completa delle modifiche e la loro giustificazione. Non limitatevi a dire che @@ -104,17 +106,28 @@ do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo comportamento. -Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo -il suo numero o il suo URL. Se la patch è la conseguenza di una discussione -su una lista di discussione, allora fornite l'URL all'archivio di quella -discussione; usate i collegamenti a https://lore.kernel.org/ con il -``Message-Id``, in questo modo vi assicurerete che il collegamento non diventi -invalido nel tempo. +Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno +riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi +riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere +quest'etichetta per fare riferimento ad un rapporto su una lista di discussione +o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far +riferimento ad una discussione precedentemente avvenuta su una lista di +discussione, o qualcosa di documentato sul web, da cui poi è nata la patch in +questione. + +Quando volete fare riferimento ad una lista di discussione, preferite il +servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è +sufficiente usare il campo ``Message-Id``, presente nell'intestazione del +messaggio, senza parentesi angolari. Per esempio:: + + Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + +Prima d'inviare il messaggio ricordatevi di verificare che il collegamento così +creato funzioni e che indirizzi verso il messaggio desiderato. -Tuttavia, cercate di rendere la vostra spiegazione comprensibile anche senza -far riferimento a fonti esterne. In aggiunta ai collegamenti a bachi e liste -di discussione, riassumente i punti più importanti della discussione che hanno -portato alla creazione della patch. +Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza +accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno +condotto all'invio della patch. Se volete far riferimento a uno specifico commit, non usate solo l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga @@ -226,10 +239,11 @@ nella vostra patch. Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia -delle revisioni per scoprire chi si occupa del codice. Lo script -scripts/get_maintainer.pl può esservi d'aiuto. Se non riuscite a trovare un -manutentore per il sottosistema su cui state lavorando, allora Andrew Morton -(akpm@linux-foundation.org) sarà la vostra ultima possibilità . +delle revisioni per scoprire chi si occupa del codice. Lo script +scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle +vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su +cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la +vostra ultima possibilità . Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org @@ -324,14 +338,19 @@ cosa stia accadendo. Assicuratevi di dire ai revisori quali cambiamenti state facendo e di ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che -richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche -in questo caso, rispondete con educazione e concentratevi sul problema che -hanno evidenziato. +richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche in +questo caso, rispondete con educazione e concentratevi sul problema che hanno +evidenziato. Quando inviate una version successiva ricordatevi di aggiungere un +``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando +le differenze rispetto a sottomissioni precedenti (vedere +:ref:`it_the_canonical_patch_format`). Leggete Documentation/translations/it_IT/process/email-clients.rst per le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare sulle liste di discussione. +.. _it_resend_reminders: + Non scoraggiatevi - o impazientitevi ------------------------------------ @@ -504,7 +523,8 @@ Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes: L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro. Rammentate che se il baco è stato riportato in privato, dovrete chiedere il -permesso prima di poter utilizzare l'etichetta Reported-by. +permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va +usata per i bachi, dunque non usatela per richieste di nuove funzionalità . L'etichetta Tested-by: indica che la patch è stata verificata con successo (su un qualche sistema) dalla persona citata. Questa etichetta informa i @@ -574,6 +594,8 @@ previste per i kernel stabili, e nemmeno dalla necessità di aggiungere in copia conoscenza stable@vger.kernel.org su tutte le patch per suddetti kernel. +.. _it_the_canonical_patch_format: + Il formato canonico delle patch ------------------------------- @@ -719,6 +741,8 @@ messe correttamente oltre la riga.:: Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito. +.. _it_backtraces: + Aggiungere i *backtrace* nei messaggi di commit ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/translations/ja_JP/SubmittingPatches b/Documentation/translations/ja_JP/SubmittingPatches index 66ce0d8b0526..04deb77b20c6 100644 --- a/Documentation/translations/ja_JP/SubmittingPatches +++ b/Documentation/translations/ja_JP/SubmittingPatches @@ -35,8 +35,7 @@ Linux カーãƒãƒ«ã«å¤‰æ›´ã‚’åŠ ãˆãŸã„ã¨æ€ã£ã¦ã„る個人åˆã¯ä¼šç¤¾ã ã¦ã‚‚らãˆã‚„ã™ãã™ã‚‹æ案を集ã‚ãŸã‚‚ã®ã§ã™ã€‚ コードを投稿ã™ã‚‹å‰ã«ã€Documentation/process/submit-checklist.rst ã®é …目リストã«ç›® -を通ã—ã¦ãƒã‚§ãƒƒã‚¯ã—ã¦ãã ã•ã„。もã—ã‚ãªãŸãŒãƒ‰ãƒ©ã‚¤ãƒãƒ¼ã‚’投稿ã—よã†ã¨ã— -ã¦ã„ã‚‹ãªã‚‰ã€Documentation/process/submitting-drivers.rst ã«ã‚‚目を通ã—ã¦ãã ã•ã„。 +を通ã—ã¦ãƒã‚§ãƒƒã‚¯ã—ã¦ãã ã•ã„。 -------------------------------------------- セクション1 パッãƒã®ä½œã‚Šæ–¹ã¨é€ã‚Šæ–¹ diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst index 38fed6fe62fe..649e2ff2a407 100644 --- a/Documentation/translations/ja_JP/howto.rst +++ b/Documentation/translations/ja_JP/howto.rst @@ -129,8 +129,8 @@ linux-api@vger.kernel.org ã«é€ã‚‹ã“ã¨ã‚’勧ã‚ã¾ã™ã€‚ ルã«å¾“ã£ã¦ã„ã‚‹ã‚‚ã®ã ã‘ã‚’å—ã‘付ã‘ã€å¤šãã®äººã¯æ£ã—ã„スタイルã®ã‚³ãƒ¼ãƒ‰ ã ã‘をレビューã—ã¾ã™ã€‚ - :ref:`Documentation/process/submitting-patches.rst <codingstyle>` 㨠:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` - ã“れらã®ãƒ•ã‚¡ã‚¤ãƒ«ã«ã¯ã€ã©ã†ã‚„ã£ã¦ã†ã¾ãパッãƒã‚’作ã£ã¦æŠ•ç¨¿ã™ã‚‹ã‹ã«ã¤ + :ref:`Documentation/process/submitting-patches.rst <codingstyle>` + ã“ã®ãƒ•ã‚¡ã‚¤ãƒ«ã«ã¯ã€ã©ã†ã‚„ã£ã¦ã†ã¾ãパッãƒã‚’作ã£ã¦æŠ•ç¨¿ã™ã‚‹ã‹ã«ã¤ ã„ã¦éžå¸¸ã«è©³ã—ã書ã‹ã‚Œã¦ãŠã‚Šã€ä»¥ä¸‹ã‚’å«ã¿ã¾ã™ (ã“ã‚Œã ã‘ã«é™ã‚‰ãªã„ ã‘ã‚Œã©ã‚‚) diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst index e3cdf0c84892..e43970584ca4 100644 --- a/Documentation/translations/ko_KR/howto.rst +++ b/Documentation/translations/ko_KR/howto.rst @@ -124,7 +124,7 @@ mtk.manpages@gmail.comì˜ ë©”ì¸í…Œì´ë„ˆì—게 보낼 ê²ƒì„ ê¶Œìž¥í•œë‹¤. ë©”ì¸í…Œì´ë„ˆë“¤ì€ ì´ ê·œì¹™ì„ ë”°ë¥´ëŠ” íŒ¨ì¹˜ë“¤ë§Œì„ ë°›ì•„ë“¤ì¼ ê²ƒì´ê³ ë§Žì€ ì‚¬ëžŒë“¤ì´ ê·¸ 패치가 올바른 스타ì¼ì¼ 경우만 코드를 ê²€í† í• ê²ƒì´ë‹¤. - :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 와 :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` + :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` ì´ íŒŒì¼ë“¤ì€ 성공ì 으로 패치를 ë§Œë“¤ê³ ë³´ë‚´ëŠ” ë²•ì„ ë‹¤ìŒì˜ 내용들로 굉장히 ìƒì„¸ížˆ ì„¤ëª…í•˜ê³ ìžˆë‹¤(그러나 다ìŒìœ¼ë¡œ í•œì •ë˜ì§„ 않는다). diff --git a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst index fbc83dfdcead..fb023ea1374d 100644 --- a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst +++ b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst @@ -123,14 +123,14 @@ nr_virtfn'是è¦å¯ç”¨çš„VFçš„ç¼–å·ã€‚ ... } - static int dev_suspend(struct pci_dev *dev, pm_message_t state) + static int dev_suspend(struct device *dev) { ... return 0; } - static int dev_resume(struct pci_dev *dev) + static int dev_resume(struct device *dev) { ... @@ -163,8 +163,7 @@ nr_virtfn'是è¦å¯ç”¨çš„VFçš„ç¼–å·ã€‚ .id_table = dev_id_table, .probe = dev_probe, .remove = dev_remove, - .suspend = dev_suspend, - .resume = dev_resume, + .driver.pm = &dev_pm_ops .shutdown = dev_shutdown, .sriov_configure = dev_sriov_configure, }; diff --git a/Documentation/translations/zh_CN/PCI/pci.rst b/Documentation/translations/zh_CN/PCI/pci.rst index 520707787256..83c2a41d38d3 100644 --- a/Documentation/translations/zh_CN/PCI/pci.rst +++ b/Documentation/translations/zh_CN/PCI/pci.rst @@ -255,13 +255,13 @@ pci_set_master()将通过设置PCI_COMMAND寄å˜å™¨ä¸çš„总线主控ä½æ¥å¯ç” 虽然所有的驱动程åºéƒ½åº”该明确指出PCI总线主控的DMA功能（如32ä½æˆ–64ä½ï¼‰ï¼Œä½†å¯¹äºŽæµå¼ æ•°æ®æ¥è¯´ï¼Œå…·æœ‰è¶…过32ä½æ€»çº¿ä¸»ç«™åŠŸèƒ½çš„设备需è¦é©±åŠ¨ç¨‹åºé€šè¿‡è°ƒç”¨å¸¦æœ‰é€‚当å‚æ•°çš„ -``pci_set_dma_mask()`` æ¥â€œæ³¨å†Œâ€è¿™ç§åŠŸèƒ½ã€‚一般æ¥è¯´ï¼Œåœ¨ç³»ç»ŸRAM高于4G物ç†åœ°å€çš„情 +``dma_set_mask()`` æ¥â€œæ³¨å†Œâ€è¿™ç§åŠŸèƒ½ã€‚一般æ¥è¯´ï¼Œåœ¨ç³»ç»ŸRAM高于4G物ç†åœ°å€çš„情 况下，这å…许更有效的DMA。 -所有PCI-Xå’ŒPCIe兼容设备的驱动程åºå¿…须调用 ``pci_set_dma_mask()`` ï¼Œå› ä¸ºå®ƒä»¬ +所有PCI-Xå’ŒPCIe兼容设备的驱动程åºå¿…须调用 ``dma_set_mask()`` ï¼Œå› ä¸ºå®ƒä»¬ 是64ä½DMA设备。 -åŒæ ·ï¼Œå¦‚果设备å¯ä»¥é€šè¿‡è°ƒç”¨ ``pci_set_consistent_dma_mask()`` 直接寻å€åˆ° +åŒæ ·ï¼Œå¦‚果设备å¯ä»¥é€šè¿‡è°ƒç”¨ ``dma_set_coherent_mask()`` 直接寻å€åˆ° 4G物ç†åœ°å€ä»¥ä¸Šçš„系统RAMä¸çš„“一致性内å˜â€ï¼Œé‚£ä¹ˆé©±åŠ¨ç¨‹åºä¹Ÿå¿…须“注册â€è¿™ç§åŠŸèƒ½ã€‚åŒ æ ·ï¼Œè¿™åŒ…æ‹¬æ‰€æœ‰PCI-Xå’ŒPCIe兼容设备的驱动程åºã€‚许多64ä½â€œPCIâ€è®¾å¤‡ï¼ˆåœ¨PCI-X之å‰ï¼‰ 和一些PCI-X设备对有效载è·ï¼ˆâ€œæµå¼â€ï¼‰æ•°æ®å…·æœ‰64ä½DMA功能，但对控制（“一致性â€ï¼‰æ•° diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index be535ffaf4b0..2f6970d0a032 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -36,6 +36,7 @@ Todolist: :maxdepth: 1 reporting-issues + reporting-regressions security-bugs bug-hunting bug-bisect @@ -44,7 +45,6 @@ Todolist: Todolist: -* reporting-bugs * ramoops * dynamic-debug-howto * kdump/index diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst index 0c8276109fc0..30c69e1f44fe 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -13,7 +13,7 @@ 监测数æ®è®¿é—® ============ -:doc:`DAMON </vm/damon/index>` å…许轻é‡çº§çš„æ•°æ®è®¿é—®ç›‘测。使用DAMON， +:doc:`DAMON </mm/damon/index>` å…许轻é‡çº§çš„æ•°æ®è®¿é—®ç›‘测。使用DAMON， 用户å¯ä»¥åˆ†æžä»–们系统的内å˜è®¿é—®æ¨¡å¼ï¼Œå¹¶ä¼˜åŒ–它们。 .. toctree:: diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst index 1500bdbf338a..c976f3e33ffd 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst @@ -229,4 +229,4 @@ DAMON_RECLAIMå†æ¬¡ä»€ä¹ˆéƒ½ä¸åšï¼Œè¿™æ ·æˆ‘们就å¯ä»¥é€€å›žåˆ°åŸºäºŽLRU列è .. [1] https://research.google/pubs/pub48551/ .. [2] https://lwn.net/Articles/787611/ -.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html +.. [3] https://www.kernel.org/doc/html/latest/mm/free_page_reporting.html diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst index eee0e8c5c368..aeae2ab65dd8 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -33,9 +33,9 @@ DAMON 为ä¸åŒçš„用户æ供了下é¢è¿™äº›æŽ¥å£ã€‚ å£ç›¸åŒã€‚这将在下一个LTSå†…æ ¸å‘布åŽè¢«ç§»é™¤ï¼Œæ‰€ä»¥ç”¨æˆ·åº”该转移到 :ref:`sysfs interface <sysfs_interface>`。 - *å†…æ ¸ç©ºé—´ç¼–ç¨‹æŽ¥å£ã€‚* - :doc:`è¿™ </vm/damon/api>` è¿™æ˜¯ä¸ºå†…æ ¸ç©ºé—´ç¨‹åºå‘˜å‡†å¤‡çš„。使用它，用户å¯ä»¥é€šè¿‡ä¸ºä½ 编写内 + :doc:`è¿™ </mm/damon/api>` è¿™æ˜¯ä¸ºå†…æ ¸ç©ºé—´ç¨‹åºå‘˜å‡†å¤‡çš„。使用它，用户å¯ä»¥é€šè¿‡ä¸ºä½ 编写内 æ ¸ç©ºé—´çš„DAMON应用程åºï¼Œæœ€çµæ´»æœ‰æ•ˆåœ°åˆ©ç”¨DAMONçš„æ¯ä¸€ä¸ªåŠŸèƒ½ã€‚ä½ ç”šè‡³å¯ä»¥ä¸ºå„ç§åœ°å€ç©ºé—´æ‰©å±•DAMON。 - 详细情况请å‚è€ƒæŽ¥å£ :doc:`文件 </vm/damon/api>`。 + 详细情况请å‚è€ƒæŽ¥å£ :doc:`文件 </mm/damon/api>`。 sysfsæŽ¥å£ ========= @@ -148,7 +148,7 @@ contexts/<N>/monitoring_attrs/ 在 ``nr_regions`` 目录下，有两个文件分别用于DAMON监测区域的下é™å’Œä¸Šé™ï¼ˆ``min`` å’Œ ``max`` ）， 这两个文件控制ç€ç›‘æµ‹çš„å¼€é”€ã€‚ä½ å¯ä»¥é€šè¿‡å‘这些文件的写入和读出æ¥è®¾ç½®å’ŒèŽ·å–这些值。 -关于间隔和监测区域范围的更多细节，请å‚考设计文件 (:doc:`/vm/damon/design`)。 +关于间隔和监测区域范围的更多细节，请å‚考设计文件 (:doc:`/mm/damon/design`)。 contexts/<N>/targets/ --------------------- @@ -210,6 +210,8 @@ schemes/<N>/ - ``pageout``: 为具有 ``MADV_PAGEOUT`` 的区域调用 ``madvise()`` 。 - ``hugepage``: 为带有 ``MADV_HUGEPAGE`` 的区域调用 ``madvise()`` 。 - ``nohugepage``: 为带有 ``MADV_NOHUGEPAGE`` 的区域调用 ``madvise()``。 + - ``lru_prio``: 在其LRU列表上对区域进行优先排åºã€‚ + - ``lru_deprio``: 对区域的LRU列表进行é™ä½Žä¼˜å…ˆå¤„ç†ã€‚ - ``stat``: 什么都ä¸åšï¼Œåªè®¡ç®—ç»Ÿè®¡æ•°æ® schemes/<N>/access_pattern/ @@ -318,7 +320,7 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, ---- 用户å¯ä»¥é€šè¿‡è¯»å–和写入 ``attrs`` 文件获得和设置 ``é‡‡æ ·é—´éš”`` 〠``èšé›†é—´éš”`` 〠``æ›´æ–°é—´éš”`` -以åŠç›‘æµ‹ç›®æ ‡åŒºåŸŸçš„æœ€å°/最大数é‡ã€‚è¦è¯¦ç»†äº†è§£ç›‘测属性，请å‚考 `:doc:/vm/damon/design` 。例如， +以åŠç›‘æµ‹ç›®æ ‡åŒºåŸŸçš„æœ€å°/最大数é‡ã€‚è¦è¯¦ç»†äº†è§£ç›‘测属性，请å‚考 `:doc:/mm/damon/design` 。例如， 下é¢çš„命令将这些值设置为5msã€100msã€1000msã€10å’Œ1000，然åŽå†æ¬¡æ£€æŸ¥:: # cd <debugfs>/damon diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst index 6b4988da2c5a..59e51e3539b4 100644 --- a/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst +++ b/Documentation/translations/zh_CN/admin-guide/reporting-issues.rst @@ -1,13 +1,6 @@ .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) -.. - If you want to distribute this text under CC-BY-4.0 only, please use 'The - Linux kernel developers' for author attribution and link this as source: - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst -.. - Note: Only the content of this RST file as found in the Linux kernel sources - is available under CC-BY-4.0, as versions of this text that were processed - (for example by the kernel's build system) might contain content taken from - files which use a more restrictive license. +.. See the bottom of this file for additional redistribution information. + .. include:: ../disclaimer-zh_CN.rst @@ -29,7 +22,9 @@ 请æœç´¢ `LKMLå†…æ ¸é‚®ä»¶åˆ—è¡¨ <https://lore.kernel.org/lkml/>`_ å’Œ `Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ å˜æ¡£ä¸åŒ¹é…的报告并 åŠ å…¥è®¨è®ºã€‚å¦‚æžœæ‰¾ä¸åˆ°åŒ¹é…的报告，请安装该系列的最新版本。如果它ä»ç„¶å‡ºçŽ°é—®é¢˜ï¼Œ -报告给稳定版邮件列表（stable@vger.kernel.org）。 +请报告给稳定版邮件列表（stable@vger.kernel.org）并抄é€å›žå½’邮件列表 +（regressions@lists.linux.dev）；ç†æƒ³æƒ…况下，还å¯ä»¥æŠ„é€ç»´æŠ¤è€…和相关å系统的 +邮件列表。 在所有其他情况下，请尽å¯èƒ½çŒœæµ‹æ˜¯å“ªä¸ªå†…æ ¸éƒ¨åˆ†å¯¼è‡´äº†é—®é¢˜ã€‚æŸ¥çœ‹MAINTAINERS文件， 了解开å‘人员希望如何得知问题，大多数情况下，报告问题都是通过电åé‚®ä»¶å’ŒæŠ„é€ @@ -46,9 +41,10 @@ æœ‰ä½¿ç”¨é™„åŠ æ¨¡å—）。还è¦ç¡®ä¿å®ƒæ˜¯åœ¨ä¸€ä¸ªæ£å¸¸çš„环境ä¸æž„建和è¿è¡Œï¼Œå¹¶ä¸”在问题å‘生 之å‰æ²¡æœ‰è¢«æ±¡æŸ“（tainted）。 -在编写报告时，è¦æ¶µç›–与问题相关的所有信æ¯ï¼Œå¦‚ä½¿ç”¨çš„å†…æ ¸å’Œå‘行版。在碰è§å›žå½’时， -å°è¯•ç»™å‡ºå¼•å…¥å®ƒçš„更改的æ交ID，二分å¯ä»¥æ‰¾åˆ°å®ƒã€‚如果您åŒæ—¶é¢ä¸´Linuxå†…æ ¸çš„å¤šä¸ª -问题，请分别报告æ¯ä¸ªé—®é¢˜ã€‚ +å½“ä½ åŒæ—¶é¢ä¸´Linuxå†…æ ¸çš„å¤šä¸ªé—®é¢˜æ—¶ï¼Œè¯·åˆ†åˆ«æŠ¥å‘Šã€‚åœ¨ç¼–å†™æŠ¥å‘Šæ—¶ï¼Œè¦æ¶µç›–与问题 +相关的所有信æ¯ï¼Œå¦‚ä½¿ç”¨çš„å†…æ ¸å’Œå‘行版。如果碰è§å›žå½’，请把报告抄é€å›žå½’邮件列表 +（regressions@lists.linux.dev）。也请试试用二分法找出æºå¤´ï¼›å¦‚æžœæˆåŠŸæ‰¾åˆ°ï¼Œè¯· +在报告ä¸å†™ä¸Šå®ƒçš„æ交ID并抄é€sign-off-by链ä¸çš„所有人。 一旦报告å‘出，请回ç”任何出现的问题，并尽å¯èƒ½åœ°æ供帮助。这包括通过ä¸æ—¶é‡æ–° 测试新版本并å‘é€çŠ¶æ€æ›´æ–°æ¥æŽ¨åŠ¨è¿›å±•ã€‚ @@ -156,9 +152,10 @@ å˜åœ¨é—®é¢˜ï¼Œå› 为问题å¯èƒ½å·²ç»åœ¨é‚£é‡Œè¢«ä¿®å¤äº†ã€‚如果您第一次å‘çŽ°ä¾›åº”å•†å†…æ ¸çš„é—®é¢˜ï¼Œ 请检查已知最新版本的普通构建是å¦å¯ä»¥æ£å¸¸è¿è¡Œã€‚ - * å‘Linux稳定版邮件列表å‘é€ä¸€ä¸ªç®€çŸçš„问题报告(stable@vger.kernel.org)。大致 - æ述问题，并解释如何å¤çŽ°ã€‚讲清楚首个出现问题的版本和最åŽä¸€ä¸ªå·¥ä½œæ£å¸¸çš„版本。 - 然åŽç‰å¾…进一æ¥çš„指示。 + * å‘Linux稳定版邮件列表å‘é€ä¸€ä¸ªç®€çŸçš„问题报告（stable@vger.kernel.orgï¼‰å¹¶æŠ„é€ + Linux回归邮件列表（regressions@lists.linux.devï¼‰ï¼›å¦‚æžœä½ æ€€ç–‘æ˜¯ç”±æŸå系统 + 引起的，请抄é€å…¶ç»´æŠ¤äººå‘˜å’Œå系统邮件列表。大致æ述问题，并解释如何å¤çŽ°ã€‚ + 讲清楚首个出现问题的版本和最åŽä¸€ä¸ªå·¥ä½œæ£å¸¸çš„版本。然åŽç‰å¾…进一æ¥çš„指示。 下é¢çš„å‚è€ƒç« èŠ‚éƒ¨åˆ†è¯¦ç»†è§£é‡Šäº†è¿™äº›æ¥éª¤ä¸çš„æ¯ä¸€æ¥ã€‚ @@ -296,17 +293,14 @@ Linus Torvalds和主è¦çš„Linuxå†…æ ¸å¼€å‘人员希望看到一些问题尽快å 报告过程ä¸æœ‰ä¸€äº›â€œé«˜ä¼˜å…ˆçº§é—®é¢˜â€çš„处ç†ç•¥æœ‰ä¸åŒã€‚有三ç§æƒ…况符åˆæ¡ä»¶:回归ã€å®‰å…¨ 问题和éžå¸¸ä¸¥é‡çš„问题。 -如果在旧版本的Linuxå†…æ ¸ä¸å·¥ä½œçš„东西ä¸èƒ½åœ¨æ–°ç‰ˆæœ¬çš„Linuxå†…æ ¸ä¸å·¥ä½œï¼Œæˆ–者æŸç§ -程度上在新版本的Linuxå†…æ ¸ä¸å·¥ä½œå¾—æ›´å·®ï¼Œé‚£ä¹ˆä½ å°±éœ€è¦å¤„ç†â€œå›žå½’â€ã€‚å› æ¤ï¼Œå½“一个 -在Linux 5.7ä¸è¡¨çŽ°è‰¯å¥½çš„WiFi驱动程åºåœ¨5.8ä¸è¡¨çŽ°ä¸ä½³æˆ–æ ¹æœ¬ä¸èƒ½å·¥ä½œæ—¶ï¼Œè¿™æ˜¯ä¸€ -ç§å›žå½’。如果应用程åºåœ¨æ–°çš„å†…æ ¸ä¸å‡ºçŽ°ä¸ç¨³å®šçš„现象，这也是一ç§å›žå½’，这å¯èƒ½æ˜¯ -ç”±äºŽå†…æ ¸å’Œç”¨æˆ·ç©ºé—´ä¹‹é—´çš„æŽ¥å£ï¼ˆå¦‚procfså’Œsysfs）å‘生ä¸å…¼å®¹çš„æ›´æ”¹é€ æˆçš„。显著 -的性能é™ä½Žæˆ–åŠŸè€—å¢žåŠ ä¹Ÿå¯ä»¥ç§°ä¸ºå›žå½’。但是请记ä½:æ–°å†…æ ¸éœ€è¦ä½¿ç”¨ä¸Žæ—§å†…æ ¸ç›¸ä¼¼çš„ -é…ç½®æ¥æž„建（å‚è§ä¸‹é¢å¦‚ä½•å®žçŽ°è¿™ä¸€ç‚¹ï¼‰ã€‚è¿™æ˜¯å› ä¸ºå†…æ ¸å¼€å‘人员在实现新特性时有 -æ—¶æ— æ³•é¿å…ä¸å…¼å®¹æ€§ï¼›ä½†æ˜¯ä¸ºäº†é¿å…回归，这些特性必须在构建é…置期间显å¼åœ°å¯ç”¨ã€‚ +如果æŸä¸ªåº”用程åºæˆ–实际用例在原先的Linuxå†…æ ¸ä¸Šè¿è¡Œè‰¯å¥½ï¼Œä½†åœ¨ä½¿ç”¨ç±»ä¼¼é…置编译的 +较新版本上效果更差ã€æˆ–è€…æ ¹æœ¬ä¸èƒ½ç”¨ï¼Œé‚£ä¹ˆä½ 就需è¦å¤„ç†å›žå½’问题。 +Documentation/admin-guide/reporting-regressions.rst 对æ¤è¿›è¡Œäº†æ›´è¯¦ç»†çš„解释。 +它还æä¾›äº†å¾ˆå¤šä½ å¯èƒ½æƒ³çŸ¥é“的关于回归的其他信æ¯ï¼›ä¾‹å¦‚，它解释了如何将您的问题 +æ·»åŠ åˆ°å›žå½’è·Ÿè¸ªåˆ—è¡¨ä¸ï¼Œä»¥ç¡®ä¿å®ƒä¸ä¼šè¢«å¿½ç•¥ã€‚ 什么是安全问题留给您自己判æ–。在继ç»ä¹‹å‰ï¼Œè¯·è€ƒè™‘阅读 -“Documentation/translations/zh_CN/admin-guide/security-bugs.rstâ€ï¼Œ +Documentation/translations/zh_CN/admin-guide/security-bugs.rst ， å› ä¸ºå®ƒæ供了如何最æ°å½“地处ç†å®‰å…¨é—®é¢˜çš„é¢å¤–细节。 当å‘ç”Ÿäº†å®Œå…¨æ— æ³•æŽ¥å—的糟糕事情时，æ¤é—®é¢˜å°±æ˜¯ä¸€ä¸ªâ€œéžå¸¸ä¸¥é‡çš„问题â€ã€‚例如， @@ -390,7 +384,7 @@ Linuxå†…æ ¸ç ´å了它处ç†çš„æ•°æ®æˆ–æŸå了它è¿è¡Œçš„ç¡¬ä»¶ã€‚å½“å†…æ ¸ æ ¸æœªè¢«æ±¡æŸ“ï¼Œé‚£ä¹ˆå®ƒåº”è¯¥ä»¥â€œNot infectedâ€ç»“æŸï¼›å¦‚æžœä½ çœ‹åˆ°â€œTainted:â€ä¸”åŽè·Ÿä¸€äº› ç©ºæ ¼å’Œå—æ¯ï¼Œé‚£å°±è¢«æ±¡æŸ“了。 -å¦‚æžœä½ çš„å†…æ ¸è¢«æ±¡æŸ“äº†ï¼Œè¯·é˜…è¯»â€œDocumentation/translations/zh_CN/admin-guide/tainted-kernels.rst†+å¦‚æžœä½ çš„å†…æ ¸è¢«æ±¡æŸ“äº†ï¼Œè¯·é˜…è¯» Documentation/translations/zh_CN/admin-guide/tainted-kernels.rst ä»¥æ‰¾å‡ºåŽŸå› ã€‚è®¾æ³•æ¶ˆé™¤æ±¡æŸ“å› ç´ ã€‚é€šå¸¸æ˜¯ç”±ä»¥ä¸‹ä¸‰ç§å› ç´ ä¹‹ä¸€å¼•èµ·çš„ï¼š 1. å‘生了一个å¯æ¢å¤çš„错误（“kernel Oopsâ€ï¼‰ï¼Œå†…æ ¸æ±¡æŸ“äº†è‡ªå·±ï¼Œå› ä¸ºå†…æ ¸çŸ¥é“在 @@ -591,7 +585,8 @@ ath10k@lists.infradead.orgâ€ï¼Œå°†å¼•å¯¼æ‚¨åˆ°ath10k邮件列表的信æ¯é¡µï¼Œ æœç´¢å¼•æ“Žï¼Œå¹¶æ·»åŠ 类似“site:lists.infadead.org/pipermail/ath10k/â€è¿™ æ ·çš„æœç´¢æ¡ä»¶ï¼Œè¿™ä¼šæŠŠç»“æžœé™åˆ¶åœ¨è¯¥é“¾æŽ¥ä¸çš„档案。 -也请进一æ¥æœç´¢ç½‘络ã€LKMLå’Œbugzilla.kernel.org网站。 +也请进一æ¥æœç´¢ç½‘络ã€LKMLå’Œbugzilla.kernel.orgç½‘ç«™ã€‚å¦‚æžœä½ çš„æŠ¥å‘Šéœ€è¦å‘é€åˆ°ç¼ºé™· +跟踪器ä¸ï¼Œé‚£ä¹ˆæ‚¨å¯èƒ½è¿˜éœ€è¦æ£€æŸ¥å系统的邮件列表å˜æ¡£ï¼Œå› 为å¯èƒ½æœ‰äººåªåœ¨é‚£é‡ŒæŠ¥å‘Šäº†å®ƒã€‚ 有关如何æœç´¢ä»¥åŠåœ¨æ‰¾åˆ°åŒ¹é…报告时如何æ“作的详细信æ¯ï¼Œè¯·å‚阅上é¢çš„“æœç´¢çŽ°æœ‰æŠ¥å‘Š （第一部分）â€ã€‚ @@ -802,10 +797,10 @@ Linux 首å¸å¼€å‘者 Linus Torvalds 认为 Linux å†…æ ¸æ°¸è¿œä¸åº”æ¶åŒ–，这 é‡çŽ°å®ƒã€‚ 有一个å«åšâ€œäºŒåˆ†â€çš„过程å¯ä»¥æ¥å¯»æ‰¾å˜åŒ–，这在 -“Documentation/translations/zh_CN/admin-guide/bug-bisect.rstâ€æ–‡æ¡£ä¸è¿›è¡Œäº†è¯¦ç»† +Documentation/translations/zh_CN/admin-guide/bug-bisect.rst 文档ä¸è¿›è¡Œäº†è¯¦ç»† çš„æ述，这个过程通常需è¦ä½ 构建å到二åä¸ªå†…æ ¸é•œåƒï¼Œæ¯æ¬¡éƒ½å°è¯•åœ¨æž„å»ºä¸‹ä¸€ä¸ªé•œåƒ ä¹‹å‰é‡çŽ°é—®é¢˜ã€‚是的，这需è¦èŠ±è´¹ä¸€äº›æ—¶é—´ï¼Œä½†ä¸ç”¨æ‹…心，它比大多数人想象的è¦å¿«å¾—多。 -多äºäº†â€œbinary search二进制æœç´¢â€ï¼Œè¿™å°†å¼•å¯¼ä½ 在æºä»£ç 管ç†ç³»ç»Ÿä¸æ‰¾åˆ°å¯¼è‡´å›žå½’çš„æ交。 +多äºäº†â€œbinary search二分æœç´¢â€ï¼Œè¿™å°†å¼•å¯¼ä½ 在æºä»£ç 管ç†ç³»ç»Ÿä¸æ‰¾åˆ°å¯¼è‡´å›žå½’çš„æ交。 ä¸€æ—¦ä½ æ‰¾åˆ°å®ƒï¼Œå°±åœ¨ç½‘ä¸Šæœç´¢å…¶ä¸»é¢˜ã€æ交ID和缩çŸçš„æ交ID（æ交IDçš„å‰12个å—符）。 如果有的è¯ï¼Œè¿™å°†å¼•å¯¼æ‚¨æ‰¾åˆ°å…³äºŽå®ƒçš„现有报告。 @@ -823,10 +818,10 @@ Linux 首å¸å¼€å‘者 Linus Torvalds 认为 Linux å†…æ ¸æ°¸è¿œä¸åº”æ¶åŒ–，这 当处ç†å›žå½’问题时，请确ä¿ä½ 所é¢ä¸´çš„é—®é¢˜çœŸçš„æ˜¯ç”±å†…æ ¸å¼•èµ·çš„ï¼Œè€Œä¸æ˜¯ç”±å…¶ä»–东西 引起的，如上文所述。 -在整个过程ä¸ï¼Œè¯·è®°ä½ï¼šåªæœ‰å½“æ—§å†…æ ¸å’Œæ–°å†…æ ¸çš„é…置相似时，问题æ‰ç®—回归。最好 -的方法是：把é…置文件（``.config``ï¼‰ä»Žæ—§çš„å·¥ä½œå†…æ ¸ç›´æŽ¥å¤åˆ¶åˆ°ä½ å°è¯•çš„æ¯ä¸ªæ–°å†… -æ ¸ç‰ˆæœ¬ã€‚ä¹‹åŽè¿è¡Œ ``make oldnoconfig`` æ¥è°ƒæ•´å®ƒä»¥é€‚应新版本的需è¦ï¼Œè€Œä¸å¯ç”¨ -ä»»ä½•æ–°çš„åŠŸèƒ½ï¼Œå› ä¸ºé‚£äº›åŠŸèƒ½ä¹Ÿå¯èƒ½å¯¼è‡´å›žå½’。 +在整个过程ä¸ï¼Œè¯·è®°ä½ï¼šåªæœ‰å½“æ—§å†…æ ¸å’Œæ–°å†…æ ¸çš„é…置相似时，问题æ‰ç®—回归。这å¯ä»¥ +通过 ``make olddefconfig`` æ¥å®žçŽ°ï¼Œè¯¦ç»†è§£é‡Šå‚è§ +Documentation/admin-guide/reporting-regressions.rst ；它还æ供了大é‡å…¶ä»–您 +å¯èƒ½å¸Œæœ›äº†è§£çš„有关回归的信æ¯ã€‚ 撰写并å‘é€æŠ¥å‘Š @@ -959,11 +954,19 @@ Linux 首å¸å¼€å‘者 Linus Torvalds 认为 Linux å†…æ ¸æ°¸è¿œä¸åº”æ¶åŒ–，这 **éžå¸¸ä¸¥é‡çš„缺陷** ：确ä¿åœ¨ä¸»é¢˜æˆ–å·¥å•æ ‡é¢˜ä»¥åŠç¬¬ä¸€æ®µä¸æ˜Žæ˜¾æ ‡å‡º severeness （éžå¸¸ä¸¥é‡çš„）。 -**回归** ï¼šå¦‚æžœé—®é¢˜æ˜¯ä¸€ä¸ªå›žå½’ï¼Œè¯·åœ¨é‚®ä»¶çš„ä¸»é¢˜æˆ–ç¼ºé™·è·Ÿè¸ªå™¨çš„æ ‡é¢˜ä¸æ·»åŠ -[REGRESSION]。如果您没有进行二分，请至少注明您测试的最新主线版本（比如 5.7） -和出现问题的最新版本（比如 5.8）。如果您æˆåŠŸåœ°è¿›è¡Œäº†äºŒåˆ†ï¼Œè¯·æ³¨æ˜Žå¯¼è‡´å›žå½’ -çš„æ交IDå’Œä¸»é¢˜ã€‚ä¹Ÿè¯·æ·»åŠ è¯¥å˜æ›´çš„ä½œè€…åˆ°ä½ çš„æŠ¥å‘Šä¸ï¼›å¦‚果您需è¦å°†æ‚¨çš„缺陷æ交 -到缺陷跟踪器ä¸ï¼Œè¯·å°†æŠ¥å‘Šä»¥ç§äººé‚®ä»¶çš„å½¢å¼è½¬å‘给他，并注明报告æ交地点。 +**回归** ：报告的主题应以“[REGRESSION]â€å¼€å¤´ã€‚ + +如果您æˆåŠŸç”¨äºŒåˆ†æ³•å®šä½äº†é—®é¢˜ï¼Œè¯·ä½¿ç”¨å¼•å…¥å›žå½’ä¹‹æ›´æ”¹çš„æ ‡é¢˜ä½œä¸ºä¸»é¢˜çš„ç¬¬äºŒéƒ¨åˆ†ã€‚ +请在报告ä¸å†™æ˜Žâ€œç½ªé祸首â€çš„æ交ID。如果未能æˆåŠŸäºŒåˆ†ï¼Œè¯·åœ¨æŠ¥å‘Šä¸è®²æ˜Žæœ€åŽä¸€ä¸ª +æ£å¸¸å·¥ä½œçš„版本（例如5.7）和最先å‘生问题的版本（例如5.8-rc1）。 + +通过邮件å‘é€æŠ¥å‘Šæ—¶ï¼Œè¯·æŠ„é€Linux回归邮件列表（regressions@lists.linux.dev）。 +如果报告需è¦æ交到æŸä¸ªweb追踪器，请继ç»æ交；并在æ交åŽï¼Œé€šè¿‡é‚®ä»¶å°†æŠ¥å‘Šè½¬å‘ +至回归列表；抄é€ç›¸å…³å系统的维护人员和邮件列表。请确ä¿æŠ¥å‘Šæ˜¯å†…è”转å‘的，ä¸è¦ +把它作为附件。å¦å¤–è¯·åœ¨é¡¶éƒ¨æ·»åŠ ä¸€ä¸ªç®€çŸçš„说明，在那里写上工å•çš„网å€ã€‚ + +在邮寄或转å‘报告时，如果æˆåŠŸäºŒåˆ†ï¼Œéœ€è¦å°†â€œç½ªé祸首â€çš„ä½œè€…æ·»åŠ åˆ°æ”¶ä»¶äººä¸ï¼›åŒæ—¶ +抄é€signed-off-by链ä¸çš„æ¯ä¸ªäººï¼Œæ‚¨å¯ä»¥åœ¨æ交消æ¯çš„末尾找到。 **安全问题** ：对于这ç§é—®é¢˜ï¼Œä½ 将必须评估：如果细节被公开披露，是å¦ä¼šå¯¹å…¶ä»– 用户产生çŸæœŸé£Žé™©ã€‚如果ä¸ä¼šï¼Œåªéœ€æŒ‰ç…§æ‰€è¿°ç»§ç»æŠ¥å‘Šé—®é¢˜ã€‚如果有æ¤é£Žé™©ï¼Œä½ éœ€è¦ @@ -980,7 +983,7 @@ Linux 首å¸å¼€å‘者 Linus Torvalds 认为 Linux å†…æ ¸æ°¸è¿œä¸åº”æ¶åŒ–，这 报告，请将报告的文本转å‘到这些地å€ï¼›ä½†è¯·åœ¨æŠ¥å‘Šçš„é¡¶éƒ¨åŠ ä¸Šæ³¨é‡Šï¼Œè¡¨æ˜Žæ‚¨æ交了 报告，并附上工å•é“¾æŽ¥ã€‚ -更多信æ¯è¯·å‚è§â€œDocumentation/translations/zh_CN/admin-guide/security-bugs.rstâ€ã€‚ +更多信æ¯è¯·å‚è§ Documentation/translations/zh_CN/admin-guide/security-bugs.rst 。 å‘布报告åŽçš„责任 @@ -1173,14 +1176,18 @@ FLOSS 问题报告的人看，询问他们的æ„è§ã€‚åŒæ—¶å¾æ±‚ä»–ä»¬å…³äºŽå¦ æŠ¥å‘Šå›žå½’ ~~~~~~~~~~ - *å‘Linux稳定版邮件列表å‘é€ä¸€ä¸ªç®€çŸçš„问题报告(stable@vger.kernel.org)。 - 大致æ述问题，并解释如何å¤çŽ°ã€‚讲清楚首个出现问题的版本和最åŽä¸€ä¸ªå·¥ä½œæ£å¸¸ - 的版本。然åŽç‰å¾…进一æ¥çš„指示。* + *å‘Linux稳定版邮件列表å‘é€ä¸€ä¸ªç®€çŸçš„问题报告(stable@vger.kernel.org)并 + 抄é€Linux回归邮件列表（regressions@lists.linux.devï¼‰ï¼›å¦‚æžœä½ æ€€ç–‘æ˜¯ç”±æŸ + å系统引起的，请抄é€å…¶ç»´æŠ¤äººå‘˜å’Œå系统邮件列表。大致æ述问题，并解释如 + 何å¤çŽ°ã€‚讲清楚首个出现问题的版本和最åŽä¸€ä¸ªå·¥ä½œæ£å¸¸çš„版本。然åŽç‰å¾…进一 + æ¥çš„指示。* 当报告在稳定版或长期支æŒå†…æ ¸çº¿å†…å‘生的回归（例如在从5.10.4更新到5.10.5时）， -一份简çŸçš„æŠ¥å‘Šè¶³ä»¥å¿«é€ŸæŠ¥å‘Šé—®é¢˜ã€‚å› æ¤åªéœ€è¦ç²—略的æ述。 +一份简çŸçš„æŠ¥å‘Šè¶³ä»¥å¿«é€ŸæŠ¥å‘Šé—®é¢˜ã€‚å› æ¤åªéœ€å‘稳定版和回归邮件列表å‘é€ç²—略的æè¿°ï¼› +ä¸è¿‡å¦‚æžœä½ æ€€ç–‘æŸå系统导致æ¤é—®é¢˜çš„è¯ï¼Œè¯·ä¸€å¹¶æŠ„é€å…¶ç»´æŠ¤äººå‘˜å’Œå系统邮件列表， +è¿™ä¼šåŠ å¿«è¿›ç¨‹ã€‚ -但是请注æ„，如果您能够指明引入问题的确切版本，这将对开å‘äººå‘˜æœ‰å¾ˆå¤§å¸®åŠ©ã€‚å› æ¤ +请注æ„，如果您能够指明引入问题的确切版本，这将对开å‘äººå‘˜æœ‰å¾ˆå¤§å¸®åŠ©ã€‚å› æ¤ å¦‚æžœæœ‰æ—¶é—´çš„è¯ï¼Œè¯·å°è¯•ä½¿ç”¨æ™®é€šå†…æ ¸æ‰¾åˆ°è¯¥ç‰ˆæœ¬ã€‚è®©æˆ‘ä»¬å‡è®¾å‘行版å‘布Linuxå†…æ ¸ 5.10.5到5.10.8çš„æ›´æ–°æ—¶å‘生了故障。那么按照上é¢çš„指示，去检查该版本线ä¸çš„最新 å†…æ ¸ï¼Œæ¯”å¦‚5.10.9。如果问题出现，请å°è¯•æ™®é€š5.10.5，以确ä¿ä¾›åº”商应用的补ä¸ä¸ä¼š @@ -1190,7 +1197,9 @@ FLOSS 问题报告的人看，询问他们的æ„è§ã€‚åŒæ—¶å¾æ±‚ä»–ä»¬å…³äºŽå¦ å‰ä¸€æ®µåŸºæœ¬ç²—略地概述了“二分â€æ–¹æ³•ã€‚一旦报告出æ¥ï¼Œæ‚¨å¯èƒ½ä¼šè¢«è¦æ±‚åšä¸€ä¸ªæ£ç¡®çš„ æŠ¥å‘Šï¼Œå› ä¸ºå®ƒå…许精确地定ä½å¯¼è‡´é—®é¢˜çš„确切更改（然åŽå¾ˆå®¹æ˜“被æ¢å¤ä»¥å¿«é€Ÿä¿®å¤é—®é¢˜ï¼‰ã€‚ å› æ¤å¦‚果时间å…许，考虑立å³è¿›è¡Œé€‚当的二分。有关如何详细信æ¯ï¼Œè¯·å‚阅“对回归的 -特别关照â€éƒ¨åˆ†å’Œæ–‡æ¡£â€œDocumentation/translations/zh_CN/admin-guide/bug-bisect.rstâ€ã€‚ +特别关照â€éƒ¨åˆ†å’Œæ–‡æ¡£ Documentation/translations/zh_CN/admin-guide/bug-bisect.rst 。 +如果æˆåŠŸäºŒåˆ†çš„è¯ï¼Œè¯·å°†â€œç½ªé祸首â€çš„ä½œè€…æ·»åŠ åˆ°æ”¶ä»¶äººä¸ï¼›åŒæ—¶æŠ„é€æ‰€æœ‰åœ¨ +signed-off-by链ä¸çš„人，您å¯ä»¥åœ¨æ交消æ¯çš„末尾找到。 â€œæŠ¥å‘Šä»…åœ¨æ—§å†…æ ¸ç‰ˆæœ¬çº¿ä¸å‘生的问题â€çš„å‚考 @@ -1207,7 +1216,7 @@ FLOSS 问题报告的人看，询问他们的æ„è§ã€‚åŒæ—¶å¾æ±‚ä»–ä»¬å…³äºŽå¦ å³ä½¿æ˜¯å¾®å°çš„ã€çœ‹ä¼¼æ˜Žæ˜¾çš„代ç å˜åŒ–，有时也会带æ¥æ–°çš„ã€å®Œå…¨æ„想ä¸åˆ°çš„问题。稳 定版和长期支æŒå†…æ ¸çš„ç»´æŠ¤è€…éžå¸¸æ¸…æ¥šè¿™ä¸€ç‚¹ï¼Œå› æ¤ä»–们åªå¯¹è¿™äº›å†…æ ¸è¿›è¡Œç¬¦åˆ -“Documentation/translations/zh_CN/process/stable-kernel-rules.rstâ€ä¸æ‰€åˆ—出的 +Documentation/translations/zh_CN/process/stable-kernel-rules.rst ä¸æ‰€åˆ—出的 规则的修改。 å¤æ‚或有风险的修改ä¸ç¬¦åˆæ¡ä»¶ï¼Œå› æ¤åªèƒ½åº”用于主线。其他的修å¤å¾ˆå®¹æ˜“被回溯到 @@ -1333,3 +1342,27 @@ FLOSS 问题报告的人看，询问他们的æ„è§ã€‚åŒæ—¶å¾æ±‚ä»–ä»¬å…³äºŽå¦ å‘ Linux å†…æ ¸å¼€å‘者报告问题是很难的：这个文档的长度和å¤æ‚性以åŠå—里行间的内 涵都说明了这一点。但目å‰å°±æ˜¯è¿™æ ·äº†ã€‚这篇文å—的主è¦ä½œè€…希望通过记录现状æ¥ä¸º 以åŽæ”¹å–„è¿™ç§çŠ¶å†µæ‰“下一些基础。 + + +.. + end-of-content +.. + This English version of this document is maintained by Thorsten Leemhuis + <linux@leemhuis.info>. If you spot a typo or small mistake, feel free to + let him know directly and he'll fix it. For translation problems, please + contact with translators. You are free to do the same in a mostly informal + way if you want to contribute changes to the text, but for copyright + reasons please CC linux-doc@vger.kernel.org and "sign-off" your + contribution as Documentation/process/submitting-patches.rst outlines in + the section "Sign your work - the Developer's Certificate of Origin". +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. diff --git a/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst b/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst new file mode 100644 index 000000000000..c0461ee855bc --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst @@ -0,0 +1,370 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. ã€é‡åˆ†å‘ä¿¡æ¯å‚è§æœ¬æ–‡ä»¶ç»“尾】 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/reporting-regressions.rst + +:译者: + + å´æƒ³æˆ Wu XiangCheng <bobwxc@email.cn> + + +============ +报告回归问题 +============ + +“*我们拒ç»å‡ºçŽ°å›žå½’*â€æ˜¯Linuxå†…æ ¸å¼€å‘的首è¦è§„则；Linuxçš„å‘起者和领军开å‘者Linus +Torvalds立下了æ¤è§„则并确ä¿å®ƒè¢«è½å®žã€‚ + +本文档æ述了这æ¡è§„则对用户的æ„义，以åŠLinuxå†…æ ¸å¼€å‘模型如何确ä¿è§£å†³æ‰€æœ‰è¢«æŠ¥å‘Š +çš„å›žå½’ï¼›å…³äºŽå†…æ ¸å¼€å‘者如何处ç†çš„æ–¹é¢å‚è§ Documentation/process/handling-regressions.rst 。 + + +本文é‡ç‚¹ï¼ˆäº¦å³â€œå¤ªé•¿ä¸çœ‹â€ï¼‰ +========================== + +#. 如果æŸç¨‹åºåœ¨åŽŸå…ˆçš„Linuxå†…æ ¸ä¸Šè¿è¡Œè‰¯å¥½ï¼Œä½†åœ¨è¾ƒæ–°ç‰ˆæœ¬ä¸Šæ•ˆæžœæ›´å·®ã€æˆ–è€…æ ¹æœ¬ä¸ + èƒ½ç”¨ï¼Œé‚£ä¹ˆä½ å°±ç¢°è§å›žå½’问题了。注æ„ï¼Œæ–°å†…æ ¸éœ€è¦ä½¿ç”¨ç±»ä¼¼é…置编译；更多相关细 + 节å‚è§ä¸‹æ–¹ã€‚ + +#. 按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst ä¸ + æ‰€è¯´çš„æŠ¥å‘Šä½ çš„é—®é¢˜ï¼Œè¯¥æ–‡æ¡£å·²ç»åŒ…å«äº†æ‰€æœ‰å…³äºŽå›žå½’çš„é‡è¦æ–¹é¢ï¼Œä¸ºäº†æ–¹ä¾¿èµ·è§ä¹Ÿ + å¤åˆ¶åˆ°äº†ä¸‹é¢ã€‚两个é‡ç‚¹ï¼šåœ¨æŠ¥å‘Šä¸»é¢˜ä¸ä½¿ç”¨â€œ[REGRESSION]â€å¼€å¤´å¹¶æŠ„é€æˆ–转å‘到 + `回归邮件列表 <https://lore.kernel.org/regressions/>`_ + （regressions@lists.linux.dev）。 + +#. å¯é€‰ä½†æ˜¯å»ºè®®ï¼šåœ¨å‘é€æˆ–转å‘报告时，指明该回归å‘生的起点，以便Linuxå†…æ ¸å›žå½’ + 追踪机器人“regzbotâ€å¯ä»¥è¿½è¸ªæ¤é—®é¢˜:: + + #regzbot introduced v5.13..v5.14-rc1 + + +与用户相关的所有Linuxå†…æ ¸å›žå½’ç»†èŠ‚ +================================= + + +基本é‡ç‚¹ +-------- + + +什么是“回归â€ä»¥åŠä»€ä¹ˆæ˜¯â€œæ— 回归规则â€ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +如果æŸç¨‹åº/实例在原先的Linuxå†…æ ¸ä¸Šè¿è¡Œè‰¯å¥½ï¼Œä½†åœ¨è¾ƒæ–°ç‰ˆæœ¬ä¸Šæ•ˆæžœæ›´å·®ã€æˆ–è€…æ ¹æœ¬ +ä¸èƒ½ç”¨ï¼Œé‚£ä¹ˆä½ 就碰è§å›žå½’é—®é¢˜äº†ã€‚â€œæ— å›žå½’è§„åˆ™â€ä¸å…许出现这ç§æƒ…况。如果å¶ç„¶å‘ +生了，导致问题的开å‘者应当迅速修å¤é—®é¢˜ã€‚ + +也就是说，若Linux 5.13ä¸çš„WiFi驱动程åºè¿è¡Œè‰¯å¥½ï¼Œä½†æ˜¯åœ¨5.14版本上å´ä¸èƒ½ç”¨ã€é€Ÿ +度明显å˜æ…¢æˆ–出现错误，那就出现了回归。如果æŸæ£å¸¸å·¥ä½œçš„应用程åºçªç„¶åœ¨æ–°å†…æ ¸ä¸Š +出现ä¸ç¨³å®šï¼Œè¿™ä¹Ÿæ˜¯å›žå½’；这些问题å¯èƒ½æ˜¯ç”±äºŽprocfsã€sysfs或Linuxæ供给用户空间 +软件的许多其他接å£ä¹‹ä¸€çš„å˜åŒ–。但请记ä½ï¼Œå‰è¿°ä¾‹åä¸çš„5.14需è¦ä½¿ç”¨ç±»ä¼¼äºŽ5.13çš„ +é…置构建。这å¯ä»¥ç”¨ ``make olddefconfig`` 实现，详细解释è§ä¸‹ã€‚ + +注æ„本节第一å¥è¯ä¸çš„“实例â€ï¼šå³ä½¿å¼€å‘者需è¦éµå¾ªâ€œæ— 回归â€è§„则，但ä»å¯è‡ªç”±åœ°æ”¹ +å˜å†…æ ¸çš„ä»»ä½•æ–¹é¢ï¼Œç”šè‡³æ˜¯å¯¼å‡ºåˆ°ç”¨æˆ·ç©ºé—´çš„API或ABI，åªè¦åˆ«ç ´å现有的应用程åºæˆ– +用例。 + +还需注æ„ï¼Œâ€œæ— å›žå½’â€è§„则åªé™åˆ¶å†…æ ¸æ供给用户空间的接å£ã€‚它ä¸é€‚ç”¨äºŽå†…æ ¸å†…éƒ¨æŽ¥ +å£ï¼Œæ¯”如一些外部开å‘的驱动程åºç”¨æ¥æ’入钩ååˆ°å†…æ ¸çš„æ¨¡å—API。 + +如何报告回归？ +~~~~~~~~~~~~~~ + +åªéœ€æŒ‰ç…§ Documentation/translations/zh_CN/admin-guide/reporting-issues.rst ä¸ +æ‰€è¯´çš„æŠ¥å‘Šä½ çš„é—®é¢˜ï¼Œè¯¥æ–‡æ¡£å·²ç»åŒ…å«äº†è¦ç‚¹ã€‚下é¢å‡ 点概述了一下åªåœ¨å›žå½’ä¸é‡è¦çš„ +æ–¹é¢ï¼š + + * 在检查å¯åŠ 入讨论的现有报告时，别忘了æœç´¢ `Linux回归邮件列表 + <https://lore.kernel.org/regressions/>`_ å’Œ `regzbotç½‘é¡µç•Œé¢ + <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。 + + * åœ¨æŠ¥å‘Šä¸»é¢˜çš„å¼€å¤´åŠ ä¸Šâ€œ[REGRESSION]â€ã€‚ + + * åœ¨ä½ çš„æŠ¥å‘Šä¸æ˜Žç¡®æœ€åŽä¸€ä¸ªæ£å¸¸å·¥ä½œçš„å†…æ ¸ç‰ˆæœ¬å’Œé¦–ä¸ªå‡ºé—®é¢˜çš„ç‰ˆæœ¬ã€‚å¦‚è‹¥å¯èƒ½ï¼Œ + 用二分法å°è¯•æ‰¾å‡ºå¯¼è‡´å›žå½’çš„å˜æ›´ï¼Œæ›´å¤šç»†èŠ‚è§ä¸‹ã€‚ + + * 记得把报告å‘到Linux回归邮件列表（regressions@lists.linux.dev）。 + + * 如果通过邮件报告回归，请抄é€å›žå½’列表。 + + * å¦‚æžœä½ ä½¿ç”¨æŸäº›ç¼ºé™·è¿½è¸ªå™¨æŠ¥å‘Šå›žå½’，请通过邮件转å‘å·²æ交的报告到回归列表， + 并抄é€ç»´æŠ¤è€…以åŠå‡ºé—®é¢˜çš„相关å系统的邮件列表。 + + 如果是稳定版或长期支æŒç‰ˆç³»åˆ—（如v5.15.3…v5.15.5ï¼‰çš„å›žå½’ï¼Œè¯·è®°å¾—æŠ„é€ + `Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ （stable@vger.kernel.org）。 + + å¦‚æžœä½ æˆåŠŸåœ°æ‰§è¡Œäº†äºŒåˆ†ï¼Œè¯·æŠ„é€è‚‡äº‹æ交的信æ¯ä¸æ‰€æœ‰ç¾äº†â€œSigned-off-by:â€çš„人。 + +在抄é€ä½ 的报告到列表时，也请记得通知å‰è¿°çš„Linuxå†…æ ¸å›žå½’è¿½è¸ªæœºå™¨äººã€‚åªéœ€åœ¨é‚®ä»¶ +ä¸åŒ…å«å¦‚下片段:: + + #regzbot introduced: v5.13..v5.14-rc1 + +Regzbotä¼šå°±å°†ä½ çš„é‚®ä»¶è§†ä¸ºåœ¨æŸä¸ªç‰¹å®šç‰ˆæœ¬åŒºé—´çš„回归报告。上例ä¸å³linux v5.13ä» +然æ£å¸¸ï¼Œè€ŒLinux 5.14-rc1是首个您é‡åˆ°é—®é¢˜çš„ç‰ˆæœ¬ã€‚å¦‚æžœä½ æ‰§è¡Œäº†äºŒåˆ†ä»¥æŸ¥æ‰¾å¯¼è‡´å›ž +å½’çš„æ交，请使用指定肇事æ交的id代替:: + + #regzbot introduced: 1f2e3d4c5d + +æ·»åŠ è¿™æ ·çš„â€œregzbot命令â€å¯¹ä½ 是有好处的，它会确ä¿æŠ¥å‘Šä¸ä¼šè¢«å¿½ç•¥ã€‚å¦‚æžœä½ çœç•¥äº† +它，Linuxå†…æ ¸çš„å›žå½’è·Ÿè¸ªè€…ä¼šæŠŠä½ çš„å›žå½’å‘Šè¯‰regzbot，åªè¦ä½ å‘é€äº†ä¸€ä¸ªå‰¯æœ¬åˆ°å›žå½’ +邮件列表。但是回归跟踪者åªæœ‰ä¸€ä¸ªäººï¼Œæœ‰æ—¶ä¸å¾—ä¸ä¼‘æ¯æˆ–甚至å¶å°”享å—å¯ä»¥è¿œç¦»ç”µè„‘ +的时光（å¬èµ·æ¥å¾ˆç–¯ç‹‚ï¼‰ã€‚å› æ¤ï¼Œä¾èµ–æ¤äººæ‰‹åŠ¨å°†å›žå½’æ·»åŠ åˆ° `已追踪且尚未解决的 +Linuxå†…æ ¸å›žå½’åˆ—è¡¨ <https://linux-regtracking.leemhuis.info/regzbot/>`_ å’Œ +regzbotå‘é€çš„æ¯å‘¨å›žå½’报告，å¯èƒ½ä¼šå‡ºçŽ°å»¶è¿Ÿã€‚ è¿™æ ·çš„å»¶è¯¯ä¼šå¯¼è‡´Linus Torvalds +在决定“继ç»å¼€å‘还是å‘布新版本？â€æ—¶å¿½ç•¥ä¸¥é‡çš„回归。 + +真的修å¤äº†æ‰€æœ‰çš„回归å—？ +~~~~~~~~~~~~~~~~~~~~~~~~ + +å‡ ä¹Žæ‰€æœ‰éƒ½æ˜¯ï¼Œåªè¦å¼•èµ·é—®é¢˜çš„å˜æ›´ï¼ˆè‚‡äº‹æ交）被å¯é 定ä½ã€‚也有些回归å¯ä»¥ä¸ç”¨è¿™ +æ ·ï¼Œä½†é€šå¸¸æ˜¯å¿…é¡»çš„ã€‚ + +è°éœ€è¦æ‰¾å‡ºå›žå½’çš„æ ¹æœ¬åŽŸå› ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +å—å½±å“代ç 区域的开å‘者应该自行å°è¯•å®šä½é—®é¢˜æ‰€åœ¨ã€‚但仅é 他们的努力往往是ä¸å¯ +能åšåˆ°çš„，很多问题åªå‘生在开å‘è€…çš„æ— æ³•æŽ¥è§¦çš„å…¶ä»–ç‰¹å®šå¤–éƒ¨çŽ¯å¢ƒä¸â€”—例如特定的 +硬件平å°ã€å›ºä»¶ã€Linuxå‘行版ã€ç³»ç»Ÿçš„é…置或应用程åºã€‚这就是为什么最终往往是报 +告者定ä½è‚‡äº‹æ交；有时用户甚至需è¦å†è¿è¡Œé¢å¤–æµ‹è¯•ä»¥æŸ¥æ˜Žç¡®åˆ‡çš„æ ¹æœ¬åŽŸå› ã€‚å¼€å‘ +者应该æ供建议和å¯èƒ½çš„帮助，以使普通用户更容易完æˆè¯¥æµç¨‹ã€‚ + +如何找到罪é祸首？ +~~~~~~~~~~~~~~~~~~ + +如 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst （简è¦ï¼‰ +å’Œ Documentation/translations/zh_CN/admin-guide/bug-bisect.rst （详细）ä¸æ‰€ +述，执行二分。å¬èµ·æ¥å·¥ä½œé‡å¾ˆå¤§ï¼Œä½†å¤§éƒ¨åˆ†æƒ…况下很快就能找到罪é祸首。如果这很 +困难或å¯é 地é‡çŽ°é—®é¢˜å¾ˆè€—时，请考虑与其他å—å½±å“的用户åˆä½œï¼Œä¸€èµ·ç¼©å°æœç´¢èŒƒå›´ã€‚ + +当出现回归时我å¯ä»¥å‘è°å¯»æ±‚建议？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +å‘é€é‚®ä»¶åˆ°å›žå½’邮件列表（regressions@lists.linux.dev）åŒæ—¶æŠ„é€Linuxå†…æ ¸çš„å›žå½’ +跟踪者（regressions@leemhuis.info）;如果问题需è¦ä¿å¯†å¤„ç†ï¼Œå¯ä»¥çœç•¥åˆ—表。 + + +关于回归的更多细节 +------------------ + + +â€œæ— å›žå½’è§„åˆ™â€çš„ç›®æ ‡æ˜¯ä»€ä¹ˆï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +用户应该放心å‡çº§å†…æ ¸ç‰ˆæœ¬ï¼Œè€Œä¸å¿…担心有程åºå¯èƒ½å´©æºƒã€‚这符åˆå†…æ ¸å¼€å‘者的利益， +å¯ä»¥ä½¿æ›´æ–°æœ‰å¸å¼•åŠ›ï¼šä»–们ä¸å¸Œæœ›ç”¨æˆ·åœç•™åœ¨åœæ¢ç»´æŠ¤æˆ–超过一年åŠçš„稳定/长期Linux +版本系列上。这也符åˆæ‰€æœ‰äººçš„åˆ©ç›Šï¼Œå› ä¸º `那些系列å¯èƒ½å«æœ‰å·²çŸ¥çš„缺陷ã€å®‰å…¨é—®é¢˜ +或其他åŽç»ç‰ˆæœ¬å·²ç»ä¿®å¤çš„问题 +<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_ 。 +æ¤å¤–ï¼Œå†…æ ¸å¼€å‘者希望使用户测试最新的预å‘行版或常规å‘行版å˜å¾—简å•è€Œæœ‰å¸å¼•åŠ›ã€‚ +è¿™åŒæ ·ç¬¦åˆæ‰€æœ‰äººçš„利益，如果新版本出æ¥åŽå¾ˆå¿«å°±æœ‰ç›¸å…³æŠ¥å‘Šï¼Œä¼šä½¿è¿½è¸ªå’Œä¿®å¤é—®é¢˜ +更容易。 + +实际ä¸â€œæ— 回归â€è§„则真的å¯è¡Œå—？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +è¿™ä¸æ˜¯å¥çŽ©ç¬‘è¯ï¼Œè¯·è§Linux创建者和主è¦å¼€å‘人员Linus Torvalds在邮件列表ä¸çš„许 +多å‘言，其ä¸ä¸€äº›åœ¨ Documentation/process/handling-regressions.rst ä¸è¢«å¼•ç”¨ã€‚ + +æ¤è§„则的例外情况æžä¸ºç½•è§ï¼›ä¹‹å‰å½“å¼€å‘者认为æŸä¸ªç‰¹å®šçš„情况有必è¦æ´å¼•ä¾‹å¤–时， +基本都被è¯æ˜Žé”™äº†ã€‚ + +è°æ¥ç¡®ä¿â€œæ— 回归â€è¢«è½å®žï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~ + +ç…§çœ‹å’Œæ”¯æ’‘æ ‘çš„å系统维护者应该关心这一点——例如，Linus Torvalds之于主线， +Greg Kroah-Hartmanç‰äººä¹‹äºŽå„ç§ç¨³å®š/长期系列。 + +他们都得到了别人的帮助，以确ä¿å›žå½’报告ä¸ä¼šè¢«é—æ¼ã€‚å…¶ä¸ä¹‹ä¸€æ˜¯Thorsten +Leemhuis，他目å‰æ‹…ä»»Linuxå†…æ ¸çš„â€œå›žå½’è·Ÿè¸ªè€…â€ï¼›ä¸ºäº†åšå¥½è¿™é¡¹å·¥ä½œï¼Œä»–使用了 +regzbot——Linuxå†…æ ¸å›žå½’è·Ÿè¸ªæœºå™¨äººã€‚æ‰€ä»¥è¿™å°±æ˜¯ä¸ºä»€ä¹ˆè¦æŠ„é€æˆ–转å‘ä½ çš„æŠ¥å‘Šåˆ° +回归邮件列表æ¥é€šçŸ¥è¿™äº›äººï¼Œå·²ç»æœ€å¥½åœ¨ä½ 的邮件ä¸åŒ…å«â€œregzbot命令â€æ¥ç«‹å³è¿½è¸ªå®ƒã€‚ + +回归通常多久能修å¤ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~ + +å¼€å‘者应该尽快修å¤ä»»ä½•è¢«æŠ¥å‘Šçš„回归，以æä¾›åŠæ—¶ä¸ºå—å½±å“的用户æ供解决方案，并 +防æ¢æ›´å¤šç”¨æˆ·é‡åˆ°é—®é¢˜ï¼›ç„¶è€Œï¼Œå¼€å‘人员需è¦èŠ±è¶³å¤Ÿçš„时间和注æ„力确ä¿å›žå½’ä¿®å¤ä¸ä¼š +é€ æˆé¢å¤–çš„æŸå®³ã€‚ + +å› æ¤ï¼Œç”案å–决于å„ç§å› ç´ ï¼Œå¦‚å›žå½’çš„å½±å“ã€å˜åœ¨æ—¶é•¿æˆ–出现于哪个Linux版本系列。 +但最终，大多数的回归应该在两周内修å¤ã€‚ + +当问题å¯ä»¥é€šè¿‡å‡çº§æŸäº›è½¯ä»¶è§£å†³æ—¶ï¼Œæ˜¯å›žå½’å—？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +基本都是。如果开å‘人员告诉您其他情况，请咨询上述回归跟踪者。 + +å½“æ–°å†…æ ¸å˜æ…¢æˆ–èƒ½è€—å¢žåŠ ï¼Œæ˜¯å›žå½’å—？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +是的，但有一些差别。在微型基准测试ä¸å˜æ…¢5%ä¸å¤ªå¯èƒ½è¢«è§†ä¸ºå›žå½’，除éžå®ƒä¹Ÿä¼šå¯¹ +广泛基准测试的结果产生超过1%çš„å½±å“。如果有疑问，请寻求建议。 + +当更新Linuxæ—¶å¤–éƒ¨å†…æ ¸æ¨¡å—崩溃了，是回归å—？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ä¸ï¼Œå› ä¸ºâ€œæ— å›žå½’â€è§„则仅é™äºŽLinuxå†…æ ¸æ供给用户空间的接å£å’ŒæœåŠ¡ã€‚å› æ¤ï¼Œå®ƒä¸åŒ…括 +构建或è¿è¡Œå¤–部开å‘çš„å†…æ ¸æ¨¡å—ï¼Œå› ä¸ºå®ƒä»¬åœ¨å†…æ ¸ç©ºé—´ä¸è¿è¡Œä¸ŽæŒ‚è¿›å†…æ ¸ä½¿ç”¨çš„å†…éƒ¨æŽ¥ +å£å¶å°”会å˜åŒ–。 + +如何处ç†å®‰å…¨ä¿®å¤å¼•èµ·çš„回归？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +在æžä¸ºç½•è§çš„æƒ…å†µä¸‹ï¼Œå®‰å…¨é—®é¢˜æ— æ³•åœ¨ä¸å¼•èµ·å›žå½’的情况下修å¤ï¼›è¿™äº›ä¿®å¤éƒ½è¢«æ”¾å¼ƒäº†ï¼Œ +å› ä¸ºå®ƒä»¬ç»ˆç©¶ä¼šå¼•èµ·é—®é¢˜ã€‚å¹¸è¿çš„是这ç§ä¸¤éš¾å¢ƒåœ°åŸºæœ¬éƒ½å¯ä»¥é¿å…，å—å½±å“åŒºåŸŸçš„ä¸»è¦ +å¼€å‘者以åŠLinus Torvalds本人通常都会努力在ä¸å¼•å…¥å›žå½’的情况下解决安全问题。 + +å¦‚æžœä½ ä»ç„¶é¢ä¸´æ¤ç§æƒ…况，请查看邮件列表档案是å¦æœ‰äººå°½åŠ›é¿å…过回归。如果没有， +请报告它；如有疑问，请如上所述寻求建议。 + +当修å¤å›žå½’æ—¶ä¸å¯é¿å…会引入å¦ä¸€ä¸ªï¼Œå¦‚何处ç†ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +很é—憾这ç§äº‹ç¡®å®žä¼šå‡ºçŽ°ï¼Œä½†å¹¸è¿çš„是并ä¸ç»å¸¸å‡ºçŽ°ï¼›å¦‚æžœå‘生了，å—å½±å“代ç 区的资 +深开å‘者应当调查该问题以找到é¿å…回归的解决方法，至少é¿å…它们的影å“ã€‚å¦‚æžœä½ é‡ +åˆ°è¿™æ ·çš„æƒ…å†µï¼Œå¦‚ä¸Šæ‰€è¿°ï¼šæ£€æŸ¥ä¹‹å‰çš„讨论是å¦æœ‰äººå·²ç»å°½äº†æœ€å¤§åŠªåŠ›ï¼Œå¦‚有疑问请寻 +求建议。 + +å°æ示：如果人们在æ¯ä¸ªå¼€å‘周期ä¸å®šæœŸç»™å‡ºä¸»çº¿é¢„å‘布（å³v5.15-rc1或-rc3）以供 +测试，则å¯ä»¥é¿å…è¿™ç§æƒ…况。为了更好地解释，å¯ä»¥è®¾æƒ³ä¸€ä¸ªåœ¨Linux v5.14å’Œv5.15-rc1 +之间集æˆçš„更改，该更改导致了回归，但åŒæ—¶æ˜¯åº”用于5.15-rc1的其他改进的强ä¾èµ–。 +如果有人在5.15å‘布之å‰å°±å‘现并报告了这个问题，那么所有更改都å¯ä»¥ç›´æŽ¥æ’¤é”€ï¼Œä»Ž +è€Œè§£å†³å›žå½’é—®é¢˜ã€‚è€Œå°±åœ¨å‡ å¤©æˆ–å‡ å‘¨åŽï¼Œæ¤è§£å†³æ–¹æ¡ˆå˜æˆäº†ä¸å¯èƒ½ï¼Œå› 为一些软件å¯èƒ½ +å·²ç»å¼€å§‹ä¾èµ–于åŽç»æ›´æ”¹ä¹‹ä¸€ï¼šæ’¤é”€æ‰€æœ‰æ›´æ”¹å°†å¯¼è‡´ä¸Šè¿°ç”¨æˆ·è½¯ä»¶å‡ºçŽ°å›žå½’，这是ä¸å¯ +接å—的。 + +若我所ä¾èµ–的功能在数月å‰è¢«ç§»é™¤äº†ï¼Œæ˜¯å›žå½’å—？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +是的，但如å‰èŠ‚所述，通常很难修å¤æ¤ç±»å›žå½’ã€‚å› æ¤éœ€è¦é€æ¡ˆå¤„ç†ã€‚这也是定期测试主 +线预å‘布对所有人有好处的å¦ä¸€ä¸ªåŽŸå› 。 + +如果我似乎是唯一å—å½±å“的人，是å¦ä»é€‚ç”¨â€œæ— å›žå½’â€è§„则？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +适用，但仅é™äºŽå®žé™…使用：Linuxå¼€å‘人员希望能够自由地å–消那些åªèƒ½åœ¨é˜æ¥¼å’Œåšç‰© +馆ä¸æ‰¾åˆ°çš„硬件的支æŒã€‚ + +请注æ„，有时为了å–得进展，ä¸å¾—ä¸å‡ºçŽ°å›žå½’——åŽè€…也是防æ¢Linuxåœæ»žä¸å‰æ‰€å¿…需 +çš„ã€‚å› æ¤å¦‚果回归所影å“的用户很少，那么为了他们和其他人更大的利益，还是让事情 +过去å§ã€‚尤其是å˜åœ¨æŸç§è§„é¿å›žå½’的简å•æ–¹æ³•ï¼Œä¾‹å¦‚更新一些软件或者使用专门为æ¤ç›® +çš„åˆ›å»ºçš„å†…æ ¸å‚数。 + +回归规则是å¦ä¹Ÿé€‚用于stagingæ ‘ä¸çš„代ç ？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ä¸ï¼Œå‚è§ `适用于所有staging代ç é…置选项的帮助文本 +<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_ ， +其早已声明:: + + 请注æ„：这些驱动æ£åœ¨ç§¯æžå¼€å‘ä¸ï¼Œå¯èƒ½æ— 法æ£å¸¸å·¥ä½œï¼Œå¹¶å¯èƒ½åŒ…å«ä¼šåœ¨ä¸ä¹…çš„ + å°†æ¥å‘生å˜åŒ–的用户接å£ã€‚ + +虽然stagingå¼€å‘人员通常åšæŒâ€œæ— 回归â€çš„原则，但有时为了å–得进展也会è¿èƒŒå®ƒã€‚这就 +是为什么当stagingæ ‘çš„WiFi驱动被基本推倒é‡æ¥æ—¶ï¼Œæœ‰äº›ç”¨æˆ·ä¸å¾—ä¸å¤„ç†å›žå½’ï¼ˆé€šå¸¸å¯ +以忽略）。 + +为什么较新版本必须“使用相似é…置编译â€ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +å› ä¸ºLinuxå†…æ ¸å¼€å‘人员有时会集æˆå·²çŸ¥çš„会导致回归的å˜æ›´ï¼Œä½†ä½¿å®ƒä»¬æˆä¸ºå¯é€‰çš„，并 +åœ¨å†…æ ¸çš„é»˜è®¤é…置下ç¦ç”¨å®ƒä»¬ã€‚这一技巧å…许进æ¥ï¼Œå¦åˆ™â€œæ— 回归â€è§„则将导致åœæ»žã€‚ + +例如，试想一个新的å¯ä»¥é˜»æ¢æ¶æ„软件滥用æŸä¸ªå†…æ ¸çš„æŽ¥å£çš„安全特性，åŒæ—¶åˆéœ€è¦æ»¡è¶³ +å¦ä¸€ä¸ªå¾ˆç½•è§çš„应用程åºã€‚上述的方法å¯ä½¿ä¸¤æ–¹éƒ½æ»¡æ„：使用这些应用程åºçš„人å¯ä»¥å…³é— +新的安全功能，而其他ä¸ä¼šé‡åˆ°éº»çƒ¦çš„人å¯ä»¥å¯ç”¨å®ƒã€‚ + +å¦‚ä½•åˆ›å»ºä¸Žæ—§å†…æ ¸ç›¸ä¼¼çš„é…置？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ç”¨ä¸€ä¸ªå·²çŸ¥è‰¯å¥½çš„å†…æ ¸å¯åŠ¨æœºå™¨ï¼Œå¹¶ç”¨ ``make olddefconfig`` é…置新版的Linux。这 +ä¼šè®©å†…æ ¸çš„æž„å»ºè„šæœ¬ä»Žæ£åœ¨è¿è¡Œçš„å†…æ ¸ä¸æ‘˜å½•é…置文件（“.configâ€æ–‡ä»¶ï¼‰ï¼Œä½œä¸ºå³å°†ç¼– +译的新版本的基础é…置；åŒæ—¶å°†æ‰€æœ‰æ–°çš„é…置选项设为默认值，以ç¦ç”¨å¯èƒ½å¯¼è‡´å›žå½’çš„ +新功能。 + +å¦‚ä½•æŠ¥å‘Šåœ¨é¢„ç¼–è¯‘çš„æ™®é€šå†…æ ¸ä¸å‘现的回归？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +您需è¦ç¡®ä¿æ–°çš„å†…æ ¸æ˜¯ç”¨ä¸Žæ—§ç‰ˆç›¸ä¼¼çš„é…置编译（è§ä¸Šæ–‡ï¼‰ï¼Œå› ä¸ºé‚£äº›æž„å»ºå®ƒä»¬çš„äººå¯ +能å¯ç”¨äº†ä¸€äº›å·²çŸ¥çš„ä¸Žæ–°å†…æ ¸ä¸å…¼å®¹çš„特性。如有疑问，请å‘å†…æ ¸çš„æ供者报告问题并 +寻求建议。 + + +用“regzbotâ€è¿½è¸ªå›žå½’çš„æ›´å¤šä¿¡æ¯ +----------------------------- + +什么是回归追踪？为啥我需è¦å…³å¿ƒå®ƒï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +åƒâ€œæ— 回归â€è¿™æ ·çš„规则需è¦æœ‰äººæ¥ç¡®ä¿å®ƒä»¬è¢«éµå®ˆï¼Œå¦åˆ™ä¼šè¢«æœ‰æ„/æ— æ„æ‰“ç ´ã€‚åŽ†å²è¯ +明了这一点对于Linuxå†…æ ¸å¼€å‘也适用。这就是为什么Linuxå†…æ ¸çš„å›žå½’è·Ÿè¸ªè€…Thorsten +Leemhuis，，和å¦ä¸€äº›äººå°½åŠ›å…³æ³¨æ‰€æœ‰çš„回归直到他们解决。他们从未为æ¤èŽ·å¾—报酬， +å› æ¤è¿™é¡¹å·¥ä½œæ˜¯åœ¨å°½æœ€å¤§åŠªåŠ›çš„基础上完æˆçš„。 + +为什么/如何使用机器人追踪Linuxå†…æ ¸å›žå½’ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +由于Linuxå†…æ ¸å¼€å‘过程的分布å¼å’Œæ¾æ•£ç»“构，完全手动跟踪回归已ç»è¢«è¯æ˜Žæ˜¯ç›¸å½“å›°éš¾ +çš„ã€‚å› æ¤Linuxå†…æ ¸çš„å›žå½’è·Ÿè¸ªè€…å¼€å‘了regzbotæ¥ä¿ƒè¿›è¿™é¡¹å·¥ä½œï¼Œå…¶é•¿æœŸç›®æ ‡æ˜¯å°½å¯èƒ½ä¸º +所有相关人员自动化回归跟踪。 + +Regzbot通过监视跟踪的回归报告的回å¤æ¥å·¥ä½œã€‚æ¤å¤–，它还查找用“Link:â€æ ‡ç¾å¼•ç”¨è¿™ +些报告的补ä¸ï¼›å¯¹è¿™äº›è¡¥ä¸çš„回å¤ä¹Ÿä¼šè¢«è·Ÿè¸ªã€‚结åˆè¿™äº›æ•°æ®ï¼Œå¯ä»¥å¾ˆå¥½åœ°äº†è§£å½“å‰ä¿® +å¤è¿‡ç¨‹çš„状æ€ã€‚ + +如何查看regzbot当å‰è¿½è¸ªçš„回归？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +å‚è§ `regzbot在线 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。 + +何ç§é—®é¢˜å¯ä»¥ç”±regzbot追踪？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +该机器人åªä¸ºäº†è·Ÿè¸ªå›žå½’ï¼Œå› æ¤è¯·ä¸è¦è®©regzbot涉åŠå¸¸è§„问题。但是对于Linuxå†…æ ¸çš„ +回归跟踪者æ¥è¯´ï¼Œè®©regzbot跟踪严é‡é—®é¢˜ä¹Ÿå¯ä»¥ï¼Œå¦‚有关挂起ã€æŸåæ•°æ®æˆ–内部错误 +（Panicã€Oopsã€BUG（）ã€warning…）的报告。 + +如何修改被追踪回归的相关信æ¯ï¼Ÿ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +在直接或间接回å¤æŠ¥å‘Šé‚®ä»¶æ—¶ä½¿ç”¨â€œregzbot命令â€å³å¯ã€‚最简å•çš„方法是：在“已å‘é€â€æ–‡ +件夹或邮件列表å˜æ¡£ä¸æ‰¾åˆ°æŠ¥å‘Šï¼Œç„¶åŽä½¿ç”¨é‚®ä»¶å®¢æˆ·ç«¯çš„“全部回å¤â€åŠŸèƒ½å¯¹å…¶è¿›è¡Œå›žå¤ã€‚ +在该邮件ä¸çš„独立段è½ä¸å¯ä½¿ç”¨ä»¥ä¸‹å‘½ä»¤ä¹‹ä¸€ï¼ˆå³ä½¿ç”¨ç©ºè¡Œå°†è¿™äº›å‘½ä»¤ä¸çš„一个或多个与 +其余邮件文本分隔开）。 + + * 更新回归引入起点，例如在执行二分之åŽ:: + + #regzbot introduced: 1f2e3d4c5d + + * è®¾ç½®æˆ–æ›´æ–°æ ‡é¢˜:: + + #regzbot title: foo + + * 监视讨论或bugzilla.kernel.org上有关讨论或修å¤çš„å·¥å•:: + + #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * æ ‡è®°ä¸€ä¸ªæœ‰æ›´å¤šç›¸å…³ç»†èŠ‚çš„åœ°æ–¹ï¼Œä¾‹å¦‚æœ‰å…³ä½†ä¸»é¢˜ä¸åŒçš„邮件列表帖å或缺陷追踪器ä¸çš„å·¥å•:: + + #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * æ ‡è®°å›žå½’å·²å¤±æ•ˆ:: + + #regzbot invalid: wasn't a regression, problem has always existed + +Regzbot还支æŒå…¶ä»–一些主è¦ç”±å¼€å‘人员或回归追踪人员使用的命令。命令的更多细节请 +å‚考 `å…¥é—¨æŒ‡å— <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ +å’Œ `å‚考手册 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ 。 + +.. + æ£æ–‡ç»“æŸ +.. + 如本文件开头所述，本文以GPL-2.0+或CC-BY-4.0许å¯å‘行。如您想仅在CC-BY-4.0许 + å¯ä¸‹é‡åˆ†å‘本文，请用“Linuxå†…æ ¸å¼€å‘者â€ä½œä¸ºä½œè€…，并用如下链接作为æ¥æºï¼š + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst +.. + 注æ„：本RST文件内容åªæœ‰åœ¨æ¥è‡ªLinuxå†…æ ¸æºä»£ç 时是使用CC-BY-4.0许å¯çš„ï¼Œå› ä¸ºç» + 过处ç†çš„版本（如ç»å†…æ ¸çš„æž„å»ºç³»ç»Ÿï¼‰å¯èƒ½åŒ…å«æ¥è‡ªä½¿ç”¨æ›´ä¸¥æ ¼è®¸å¯è¯çš„文件的内容。 diff --git a/Documentation/translations/zh_CN/core-api/cachetlb.rst b/Documentation/translations/zh_CN/core-api/cachetlb.rst index 6fee45fe5e80..b4a76ec75daa 100644 --- a/Documentation/translations/zh_CN/core-api/cachetlb.rst +++ b/Documentation/translations/zh_CN/core-api/cachetlb.rst @@ -5,6 +5,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> :æ ¡è¯‘: @@ -278,6 +279,11 @@ HyperSparc cpuå°±æ˜¯è¿™æ ·ä¸€ä¸ªå…·æœ‰è¿™ç§å±žæ€§çš„cpu。 CPUä¸Šï¼Œå› ä¸ºå®ƒå°†cpuå˜å‚¨åˆ°é¡µé¢ä¸Šï¼Œä½¿å…¶å˜è„。åŒæ ·ï¼Œè¯·çœ‹ sparc64关于如何处ç†è¿™ä¸ªé—®é¢˜çš„例å。 + ``void flush_dcache_folio(struct folio *folio)`` + + 该函数的调用情形与flush_dcache_page()相åŒã€‚它å…许架构针对刷新整个 + folio页é¢è¿›è¡Œä¼˜åŒ–，而ä¸æ˜¯ä¸€æ¬¡åˆ·æ–°ä¸€é¡µã€‚ + ``void copy_to_user_page(struct vm_area_struct *vma, struct page *page, unsigned long user_vaddr, void *dst, void *src, int len)`` ``void copy_from_user_page(struct vm_area_struct *vma, struct page *page, diff --git a/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst b/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst index 85a264287426..4772a900c37a 100644 --- a/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst +++ b/Documentation/translations/zh_CN/core-api/cpu_hotplug.rst @@ -4,6 +4,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> :æ ¡è¯‘: @@ -15,12 +16,13 @@ å†…æ ¸ä¸çš„CPUçƒæ‹”æ’ ================= -:时间: 2016å¹´12月 +:时间: 2021å¹´9月 :作者: Sebastian Andrzej Siewior <bigeasy@linutronix.de>, - Rusty Russell <rusty@rustcorp.com.au>, - Srivatsa Vaddagiri <vatsa@in.ibm.com>, - Ashok Raj <ashok.raj@intel.com>, - Joel Schopp <jschopp@austin.ibm.com> + Rusty Russell <rusty@rustcorp.com.au>, + Srivatsa Vaddagiri <vatsa@in.ibm.com>, + Ashok Raj <ashok.raj@intel.com>, + Joel Schopp <jschopp@austin.ibm.com>, + Thomas Gleixner <tglx@linutronix.de> 简介 ==== @@ -139,7 +141,7 @@ CPUçš„çƒæ‹”æ’å作 下线情况 -------- -一旦CPU被逻辑关é—，注册的çƒæ’拔状æ€çš„清除回调将被调用，从 ``CPUHP_ONLINE`` 开始，在 +一旦CPU被逻辑关é—，注册的çƒæ’拔状æ€çš„清除回调将被调用，从 ``CPUHP_ONLINE`` 开始，到 ``CPUHP_OFFLINE`` 状æ€ç»“æŸã€‚这包括: * å¦‚æžœä»»åŠ¡å› æš‚åœæ“作而被冻结，那么 *cpuhp_tasks_frozen* 将被设置为true。 @@ -154,82 +156,399 @@ CPUçš„çƒæ‹”æ’å作 * 一旦所有的æœåŠ¡è¢«è¿ç§»ï¼Œå†…æ ¸ä¼šè°ƒç”¨ä¸€ä¸ªç‰¹å®šçš„ä¾‹ç¨‹ ``__cpu_disable()`` æ¥è¿›è¡Œç‰¹å®šçš„清 ç†ã€‚ -使用çƒæ’æ‹”API -------------- +CPUçƒæ’æ‹”API +============ + +CPUçƒæ‹”æ’状æ€æœº +--------------- + +CPUçƒæ’拔使用一个从CPUHP_OFFLINE到CPUHP_ONLINE的线性状æ€ç©ºé—´çš„普通状æ€æœºã€‚æ¯ä¸ªçŠ¶æ€éƒ½ +有一个startupå’Œteardown的回调。 + +当一个CPU上线时，将按顺åºè°ƒç”¨startup回调，直到达到CPUHP_ONLINE状æ€ã€‚当设置状æ€çš„回调 +æˆ–å°†å®žä¾‹æ·»åŠ åˆ°å¤šå®žä¾‹çŠ¶æ€æ—¶ï¼Œä¹Ÿå¯ä»¥è°ƒç”¨å®ƒä»¬ã€‚ + +当一个CPU下线时，将按相å的顺åºä¾æ¬¡è°ƒç”¨teardown回调，直到达到CPUHP_OFFLINE状æ€ã€‚å½“åˆ +除状æ€çš„回调或从多实例状æ€ä¸åˆ 除实例时，也å¯ä»¥è°ƒç”¨å®ƒä»¬ã€‚ + +如果æŸä¸ªä½¿ç”¨åœºæ™¯åªéœ€è¦ä¸€ä¸ªæ–¹å‘çš„çƒæ’æ‹”æ“作回调（CPU上线或CPU下线），则在设置状æ€æ—¶ï¼Œ +å¯ä»¥å°†å¦ä¸€ä¸ªä¸éœ€è¦çš„回调设置为NULL。 + +状æ€ç©ºé—´è¢«åˆ’分æˆä¸‰ä¸ªé˜¶æ®µ: + +* PREPARE阶段 + + PREPARE阶段涵盖了从CPUHP_OFFLINE到CPUHP_BRINGUP_CPU之间的状æ€ç©ºé—´ã€‚ + + 在该阶段ä¸ï¼Œstartup回调在CPU上线æ“作å¯åŠ¨CPU之å‰è¢«è°ƒç”¨ï¼Œteardown回调在CPU下线æ“作使 + CPU功能失效之åŽè¢«è°ƒç”¨ã€‚ + + 这些回调是在控制CPUä¸Šè°ƒç”¨çš„ï¼Œå› ä¸ºå®ƒä»¬æ˜¾ç„¶ä¸èƒ½åœ¨çƒæ’拔的CPU上è¿è¡Œï¼Œæ¤æ—¶çƒæ’拔的CPUè¦ + 么还没有å¯åŠ¨ï¼Œè¦ä¹ˆå·²ç»åŠŸèƒ½å¤±æ•ˆã€‚ + + startup回调用于设置CPUæˆåŠŸä¸Šçº¿æ‰€éœ€è¦çš„资æºã€‚teardown回调用于释放资æºæˆ–在çƒæ’拔的CPU + 功能失效åŽï¼Œå°†å¾…处ç†çš„工作转移到在线的CPU上。 + + å…许startup回调失败。如果回调失败，CPU上线æ“作被ä¸æ¢ï¼ŒCPUå°†å†æ¬¡è¢«é™åˆ°ä¹‹å‰çš„状æ€ï¼ˆé€š + 常是CPUHP_OFFLINE）。 + + 本阶段ä¸çš„teardown回调ä¸å…许失败。 + +* STARTING阶段 + + STARTING阶段涵盖了CPUHP_BRINGUP_CPU + 1到CPUHP_AP_ONLINE之间的状æ€ç©ºé—´ã€‚ + + 该阶段ä¸çš„startup回调是在早期CPU设置代ç ä¸çš„CPU上线æ“作期间，ç¦ç”¨ä¸æ–的情况下在çƒæ‹” + æ’çš„CPU上被调用。teardown回调是在CPU完全关é—å‰ä¸ä¹…çš„CPU下线æ“作期间，ç¦ç”¨ä¸æ–的情况 + 下在çƒæ‹”æ’çš„CPU上被调用。 + + 该阶段ä¸çš„回调ä¸å…许失败。 + + 回调用于低级别的硬件åˆå§‹åŒ–/å…³æœºå’Œæ ¸å¿ƒå系统。 + +* ONLINE阶段 + + ONLINE阶段涵盖了CPUHP_AP_ONLINE + 1到CPUHP_ONLINE之间的状æ€ç©ºé—´ã€‚ + + 该阶段ä¸çš„startup回调是在CPU上线时在çƒæ’拔的CPU上调用的。teardown回调是在CPUä¸‹çº¿æ“ + 作时在çƒæ’æ‹”CPU上调用的。 + + 回调是在æ¯ä¸ªCPUçƒæ’拔线程的上下文ä¸è°ƒç”¨çš„，该线程绑定在çƒæ’拔的CPU上。回调是在å¯ç”¨ + ä¸æ–和抢å 的情况下调用的。 + + å…许回调失败。如果回调失败，CPUçƒæ’æ‹”æ“作被ä¸æ¢ï¼ŒCPUå°†æ¢å¤åˆ°ä¹‹å‰çš„状æ€ã€‚ + +CPU 上线/下线æ“作 +----------------- + +一个æˆåŠŸçš„上线æ“作如下:: + + [CPUHP_OFFLINE] + [CPUHP_OFFLINE + 1]->startup() -> æˆåŠŸ + [CPUHP_OFFLINE + 2]->startup() -> æˆåŠŸ + [CPUHP_OFFLINE + 3] -> ç•¥è¿‡ï¼Œå› ä¸ºstartup == NULL + ... + [CPUHP_BRINGUP_CPU]->startup() -> æˆåŠŸ + === PREPAREé˜¶æ®µç»“æŸ + [CPUHP_BRINGUP_CPU + 1]->startup() -> æˆåŠŸ + ... + [CPUHP_AP_ONLINE]->startup() -> æˆåŠŸ + === STARTUPé˜¶æ®µç»“æŸ + [CPUHP_AP_ONLINE + 1]->startup() -> æˆåŠŸ + ... + [CPUHP_ONLINE - 1]->startup() -> æˆåŠŸ + [CPUHP_ONLINE] + +一个æˆåŠŸçš„下线æ“作如下:: + + [CPUHP_ONLINE] + [CPUHP_ONLINE - 1]->teardown() -> æˆåŠŸ + ... + [CPUHP_AP_ONLINE + 1]->teardown() -> æˆåŠŸ + === STARTUP阶段开始 + [CPUHP_AP_ONLINE]->teardown() -> æˆåŠŸ + ... + [CPUHP_BRINGUP_ONLINE - 1]->teardown() + ... + === PREPARE阶段开始 + [CPUHP_BRINGUP_CPU]->teardown() + [CPUHP_OFFLINE + 3]->teardown() + [CPUHP_OFFLINE + 2] -> ç•¥è¿‡ï¼Œå› ä¸ºteardown == NULL + [CPUHP_OFFLINE + 1]->teardown() + [CPUHP_OFFLINE] + +一个失败的上线æ“作如下:: + + [CPUHP_OFFLINE] + [CPUHP_OFFLINE + 1]->startup() -> æˆåŠŸ + [CPUHP_OFFLINE + 2]->startup() -> æˆåŠŸ + [CPUHP_OFFLINE + 3] -> ç•¥è¿‡ï¼Œå› ä¸ºstartup == NULL + ... + [CPUHP_BRINGUP_CPU]->startup() -> æˆåŠŸ + === PREPAREé˜¶æ®µç»“æŸ + [CPUHP_BRINGUP_CPU + 1]->startup() -> æˆåŠŸ + ... + [CPUHP_AP_ONLINE]->startup() -> æˆåŠŸ + === STARTUPé˜¶æ®µç»“æŸ + [CPUHP_AP_ONLINE + 1]->startup() -> æˆåŠŸ + --- + [CPUHP_AP_ONLINE + N]->startup() -> 失败 + [CPUHP_AP_ONLINE + (N - 1)]->teardown() + ... + [CPUHP_AP_ONLINE + 1]->teardown() + === STARTUP阶段开始 + [CPUHP_AP_ONLINE]->teardown() + ... + [CPUHP_BRINGUP_ONLINE - 1]->teardown() + ... + === PREPARE阶段开始 + [CPUHP_BRINGUP_CPU]->teardown() + [CPUHP_OFFLINE + 3]->teardown() + [CPUHP_OFFLINE + 2] -> ç•¥è¿‡ï¼Œå› ä¸ºteardown == NULL + [CPUHP_OFFLINE + 1]->teardown() + [CPUHP_OFFLINE] + +一个失败的下线æ“作如下:: + + [CPUHP_ONLINE] + [CPUHP_ONLINE - 1]->teardown() -> æˆåŠŸ + ... + [CPUHP_ONLINE - N]->teardown() -> 失败 + [CPUHP_ONLINE - (N - 1)]->startup() + ... + [CPUHP_ONLINE - 1]->startup() + [CPUHP_ONLINE] + +递归失败ä¸èƒ½è¢«åˆç†åœ°å¤„ç†ã€‚ +请看下é¢çš„例å，由于下线æ“作失败而导致的递归失败:: + + [CPUHP_ONLINE] + [CPUHP_ONLINE - 1]->teardown() -> æˆåŠŸ + ... + [CPUHP_ONLINE - N]->teardown() -> 失败 + [CPUHP_ONLINE - (N - 1)]->startup() -> æˆåŠŸ + [CPUHP_ONLINE - (N - 2)]->startup() -> 失败 + +CPUçƒæ’拔状æ€æœºåœ¨æ¤åœæ¢ï¼Œä¸”ä¸å†å°è¯•å›žæ»šï¼Œå› 为这å¯èƒ½ä¼šå¯¼è‡´æ»å¾ªçŽ¯:: + + [CPUHP_ONLINE - (N - 1)]->teardown() -> æˆåŠŸ + [CPUHP_ONLINE - N]->teardown() -> 失败 + [CPUHP_ONLINE - (N - 1)]->startup() -> æˆåŠŸ + [CPUHP_ONLINE - (N - 2)]->startup() -> 失败 + [CPUHP_ONLINE - (N - 1)]->teardown() -> æˆåŠŸ + [CPUHP_ONLINE - N]->teardown() -> 失败 + +周而å¤å§‹ï¼Œä¸æ–é‡å¤ã€‚在这ç§æƒ…况下，CPU留在该状æ€ä¸:: + + [CPUHP_ONLINE - (N - 1)] + +这至少å¯ä»¥è®©ç³»ç»Ÿå–得进展，让用户有机会进行调试，甚至解决这个问题。 + +分é…ä¸€ä¸ªçŠ¶æ€ +------------ + +有两ç§æ–¹å¼åˆ†é…一个CPUçƒæ’拔状æ€: + +* é™æ€åˆ†é… + + 当å系统或驱动程åºæœ‰ç›¸å¯¹äºŽå…¶ä»–CPUçƒæ’拔状æ€çš„排åºè¦æ±‚时，必须使用é™æ€åˆ†é…。例如， + 在CPU上线æ“作期间，PERFæ ¸å¿ƒstartup回调必须在PERF驱动startup回调之å‰è¢«è°ƒç”¨ã€‚在CPU + 下线æ“作ä¸ï¼Œé©±åŠ¨teardownå›žè°ƒå¿…é¡»åœ¨æ ¸å¿ƒteardown回调之å‰è°ƒç”¨ã€‚é™æ€åˆ†é…的状æ€ç”± + cpuhp_state枚举ä¸çš„常é‡æ述，å¯ä»¥åœ¨include/linux/cpuhotplug.hä¸æ‰¾åˆ°ã€‚ + + 在适当的ä½ç½®å°†çŠ¶æ€æ’入枚举ä¸ï¼Œè¿™æ ·å°±æ»¡è¶³äº†æŽ’åºè¦æ±‚。状æ€å¸¸é‡å¿…须被用于状æ€çš„设置 + 和移除。 + + 当状æ€å›žè°ƒä¸æ˜¯åœ¨è¿è¡Œæ—¶è®¾ç½®çš„，并且是kernel/cpu.cä¸CPUçƒæ’拔状æ€æ•°ç»„åˆå§‹åŒ–的一部分 + 时，也需è¦é™æ€åˆ†é…。 + +* 动æ€åˆ†é… + + 当对状æ€å›žè°ƒæ²¡æœ‰æŽ’åºè¦æ±‚时，动æ€åˆ†é…是首选方法。状æ€ç¼–å·ç”±setup函数分é…，并在æˆåŠŸ + åŽè¿”回给调用者。 + + åªæœ‰PREPAREå’ŒONLINE阶段æ供了一个动æ€åˆ†é…范围。STARTINGé˜¶æ®µåˆ™æ²¡æœ‰ï¼Œå› ä¸ºè¯¥éƒ¨åˆ†çš„å¤§å¤š + 数回调都有明确的排åºè¦æ±‚。 + +CPUçƒæ’拔状æ€çš„设置 +------------------- + +æ ¸å¿ƒä»£ç æ供了以下函数用æ¥è®¾ç½®çŠ¶æ€ï¼š + +* cpuhp_setup_state(state, name, startup, teardown) +* cpuhp_setup_state_nocalls(state, name, startup, teardown) +* cpuhp_setup_state_cpuslocked(state, name, startup, teardown) +* cpuhp_setup_state_nocalls_cpuslocked(state, name, startup, teardown) + +对于一个驱动程åºæˆ–å系统有多个实例，并且æ¯ä¸ªå®žä¾‹éƒ½éœ€è¦è°ƒç”¨ç›¸åŒçš„CPU hotplug状æ€å›ž +调的情况，CPU hotplugæ ¸å¿ƒæ供多实例支æŒã€‚与驱动程åºç‰¹å®šçš„实例列表相比，其优势在于 +与实例相关的函数完全针对CPU hotplugæ“作进行åºåˆ—åŒ–ï¼Œå¹¶åœ¨æ·»åŠ å’Œåˆ é™¤æ—¶æ供状æ€å›žè°ƒçš„ +自动调用。è¦è®¾ç½®è¿™æ ·ä¸€ä¸ªå¤šå®žä¾‹çŠ¶æ€ï¼Œå¯ä»¥ä½¿ç”¨ä»¥ä¸‹å‡½æ•°ï¼š + +* cpuhp_setup_state_multi(state, name, startup, teardown) + +@stateå‚æ•°è¦ä¹ˆæ˜¯é™æ€åˆ†é…的状æ€ï¼Œè¦ä¹ˆæ˜¯åŠ¨æ€åˆ†é…状æ€ï¼ˆPUHP_PREPARE_DYN，CPUHP_ONLINE_DYN） +的常é‡ä¹‹ä¸€ï¼Œ 具体å–决于应该分é…动æ€çŠ¶æ€çš„状æ€é˜¶æ®µï¼ˆPREPARE，ONLINE）。 + +@nameå‚数用于sysfs输出和检测。命å惯例是"subsys:mode"或"subsys/driver:mode"， +例如 "perf:mode"或"perf/x86:mode"。常è§çš„modeå称有： + +======== ============================================ +prepare 对应PREPARE阶段ä¸çš„çŠ¶æ€ + +dead 对应PREPARE阶段ä¸ä¸æä¾›startupå›žè°ƒçš„çŠ¶æ€ + +starting 对应STARTING阶段ä¸çš„çŠ¶æ€ + +dying 对应STARTING阶段ä¸ä¸æä¾›startupå›žè°ƒçš„çŠ¶æ€ + +online 对应ONLINE阶段ä¸çš„çŠ¶æ€ + +offline 对应ONLINE阶段ä¸ä¸æä¾›startupå›žè°ƒçš„çŠ¶æ€ +======== ============================================ + +由于@nameå‚æ•°åªç”¨äºŽsysfs和检测，如果其他modeæ述符比常è§çš„æ述符更好地æ述状æ€çš„性质， +也å¯ä»¥ä½¿ç”¨ã€‚ + +@nameå‚数的示例："perf/online", "perf/x86:prepare", "RCU/tree:dying", "sched/waitempty" + +@startupå‚数是一个指å‘回调的函数指针，在CPU上线æ“作时被调用。若应用ä¸éœ€è¦startup +回调，则将该指针设为NULL。 + +@teardownå‚数是一个指å‘回调的函数指针，在CPU下线æ“作时调用。若应用ä¸éœ€è¦teardown +回调，则将该指针设为NULL。 + +这些函数在处ç†å·²æ³¨å†Œå›žè°ƒçš„æ–¹å¼ä¸Šæœ‰æ‰€ä¸åŒ: + + * cpuhp_setup_state_nocalls(), cpuhp_setup_state_nocalls_cpuslocked()å’Œ + cpuhp_setup_state_multi()åªæ³¨å†Œå›žè°ƒã€‚ + + * cpuhp_setup_state()å’Œcpuhp_setup_state_cpuslocked()注册回调，并对当å‰çŠ¶æ€å¤§äºŽæ–° + 安装状æ€çš„所有在线CPU调用@startup回调（如果ä¸æ˜¯NULLï¼‰ã€‚æ ¹æ®çŠ¶æ€é˜¶æ®µï¼Œå›žè°ƒè¦ä¹ˆåœ¨ + 当å‰çš„CPU上调用（PREPARE阶段），è¦ä¹ˆåœ¨CPUçš„çƒæ’拔线程ä¸è°ƒç”¨æ¯ä¸ªåœ¨çº¿CPU（ONLINE阶段）。 + + 如果CPU N的回调失败，那么CPU 0...N-1çš„teardown回调被调用以回滚æ“作。状æ€è®¾ç½®å¤±è´¥ï¼Œ + 状æ€çš„回调没有被注册，在动æ€åˆ†é…的情况下，分é…的状æ€è¢«é‡Šæ”¾ã€‚ + +状æ€è®¾ç½®å’Œå›žè°ƒè°ƒç”¨æ˜¯é’ˆå¯¹CPUçƒæ‹”æ’æ“作进行åºåˆ—化的。如果设置函数必须从CPUçƒæ’拔的读 +é”定区域调用，那么必须使用_cpuslocked()å˜ä½“。这些函数ä¸èƒ½åœ¨CPUçƒæ‹”æ’回调ä¸ä½¿ç”¨ã€‚ + +函数返回值： + ======== ========================================================== + 0 é™æ€åˆ†é…的状æ€è®¾ç½®æˆåŠŸ + + >0 动æ€åˆ†é…的状æ€è®¾ç½®æˆåŠŸ + + 返回的数值是被分é…的状æ€ç¼–å·ã€‚如果状æ€å›žè°ƒåŽæ¥å¿…须被移除， + 例如模å—移除，那么这个数值必须由调用者ä¿å˜ï¼Œå¹¶ä½œä¸ºçŠ¶æ€ç§» + 除函数的@stateå‚数。对于多实例状æ€ï¼ŒåŠ¨æ€åˆ†é…的状æ€ç¼–å·ä¹Ÿ + 需è¦ä½œä¸ºå®žä¾‹æ·»åŠ /åˆ é™¤æ“作的@stateå‚数。 + + <0 æ“作失败 + ======== ========================================================== + +移除CPUçƒæ‹”æ’çŠ¶æ€ +----------------- + +为了移除一个之å‰è®¾ç½®å¥½çš„状æ€ï¼Œæ供了如下函数： + +* cpuhp_remove_state(state) +* cpuhp_remove_state_nocalls(state) +* cpuhp_remove_state_nocalls_cpuslocked(state) +* cpuhp_remove_multi_state(state) + +@stateå‚æ•°è¦ä¹ˆæ˜¯é™æ€åˆ†é…的状æ€ï¼Œè¦ä¹ˆæ˜¯ç”±cpuhp_setup_state*()在动æ€èŒƒå›´å†…åˆ†é… +的状æ€ç¼–å·ã€‚如果状æ€åœ¨åŠ¨æ€èŒƒå›´å†…，则状æ€ç¼–å·è¢«é‡Šæ”¾ï¼Œå¯å†æ¬¡è¿›è¡ŒåŠ¨æ€åˆ†é…。 + +这些函数在处ç†å·²æ³¨å†Œå›žè°ƒçš„æ–¹å¼ä¸Šæœ‰æ‰€ä¸åŒ: + + * cpuhp_remove_state_nocalls(), cpuhp_remove_state_nocalls_cpuslocked() + å’Œ cpuhp_remove_multi_state()åªåˆ 除回调。 + + * cpuhp_remove_state()åˆ é™¤å›žè°ƒï¼Œå¹¶è°ƒç”¨æ‰€æœ‰å½“å‰çŠ¶æ€å¤§äºŽè¢«åˆ 除状æ€çš„在线CPUçš„ + teardown回调（如果ä¸æ˜¯NULLï¼‰ã€‚æ ¹æ®çŠ¶æ€é˜¶æ®µï¼Œå›žè°ƒè¦ä¹ˆåœ¨å½“å‰çš„CPU上调用 + （PREPARE阶段），è¦ä¹ˆåœ¨CPUçš„çƒæ’拔线程ä¸è°ƒç”¨æ¯ä¸ªåœ¨çº¿CPU（ONLINE阶段）。 + + 为了完æˆç§»é™¤å·¥ä½œï¼Œteardown回调ä¸èƒ½å¤±è´¥ã€‚ + +状æ€ç§»é™¤å’Œå›žè°ƒè°ƒç”¨æ˜¯é’ˆå¯¹CPUçƒæ‹”æ’æ“作进行åºåˆ—化的。如果移除函数必须从CPU hotplug +读å–é”定区域调用，那么必须使用_cpuslocked()å˜ä½“。这些函数ä¸èƒ½ä»ŽCPUçƒæ’拔的回调ä¸ä½¿ç”¨ã€‚ + +如果一个多实例的状æ€è¢«ç§»é™¤ï¼Œé‚£ä¹ˆè°ƒç”¨è€…必须先移除所有的实例。 + +多实例状æ€å®žä¾‹ç®¡ç† +------------------ + +一旦多实例状æ€è¢«å»ºç«‹ï¼Œå®žä¾‹å°±å¯ä»¥è¢«æ·»åŠ 到状æ€ä¸ï¼š -一旦一个CPU下线或上线，就有å¯èƒ½æ”¶åˆ°é€šçŸ¥ã€‚这对æŸäº›éœ€è¦æ ¹æ®å¯ç”¨CPUæ•°é‡æ‰§è¡ŒæŸç§è®¾ç½®æˆ–清 -ç†åŠŸèƒ½çš„驱动程åºæ¥è¯´å¯èƒ½å¾ˆé‡è¦:: + * cpuhp_state_add_instance(state, node) + * cpuhp_state_add_instance_nocalls(state, node) - #include <linux/cpuhotplug.h> +@stateå‚数是一个é™æ€åˆ†é…的状æ€æˆ–ç”±cpuhp_setup_state_multi()在动æ€èŒƒå›´å†…分é…的状 +æ€ç¼–å·ã€‚ - ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "X/Y:online", - Y_online, Y_prepare_down); +@nodeå‚数是一个指å‘hlist_node的指针，它被嵌入到实例的数æ®ç»“æž„ä¸ã€‚这个指针被交给 +多实例状æ€çš„回调，å¯ä»¥è¢«å›žè°ƒç”¨æ¥é€šè¿‡container_of()检索到实例。 -*X* 是å系统， *Y* 是特定的驱动程åºã€‚ *Y_online* 回调将在所有在线CPU的注册过程ä¸è¢«è°ƒç”¨ã€‚ -如果在线回调期间å‘生错误， *Y_prepare_down* 回调将在所有之å‰è°ƒç”¨è¿‡åœ¨çº¿å›žè°ƒçš„CPU上调 -用。注册完æˆåŽï¼Œä¸€æ—¦æœ‰CPU上线， *Y_online* 回调将被调用，当CPUå…³é—时， *Y_prepare_down* -将被调用。所有之å‰åœ¨ *Y_online* ä¸åˆ†é…的资æºéƒ½åº”该在 *Y_prepare_down* ä¸é‡Šæ”¾ã€‚如果在 -注册过程ä¸å‘生错误，返回值 *ret* 为负值。å¦åˆ™ä¼šè¿”回一个æ£å€¼ï¼Œå…¶ä¸åŒ…å«åŠ¨æ€åˆ†é…çŠ¶æ€ -（ *CPUHP_AP_ONLINE_DYN* ）的分é…çƒæ‹”æ’。对于预定义的状æ€ï¼Œå®ƒå°†è¿”回0。 +这些函数在处ç†å·²æ³¨å†Œå›žè°ƒçš„æ–¹å¼ä¸Šæœ‰æ‰€ä¸åŒ: -该回调å¯ä»¥é€šè¿‡è°ƒç”¨ ``cpuhp_remove_state()`` æ¥åˆ 除。如果是动æ€åˆ†é…çš„çŠ¶æ€ -（ *CPUHP_AP_ONLINE_DYN* ），则使用返回的状æ€ã€‚在移除çƒæ’拔状æ€çš„过程ä¸ï¼Œå°†è°ƒç”¨æ‹†è§£å›žè°ƒã€‚ + * cpuhp_state_add_instance_nocalls()åªå°†å®žä¾‹æ·»åŠ 到多实例状æ€çš„节点列表ä¸ã€‚ -多个实例 -~~~~~~~~ + * cpuhp_state_add_instance()为所有当å‰çŠ¶æ€å¤§äºŽ@state的在线CPUæ·»åŠ å®žä¾‹å¹¶è°ƒç”¨ä¸Ž + @state相关的startup回调（如果ä¸æ˜¯NULL）。该回调åªå¯¹å°†è¦æ·»åŠ 的实例进行调用。 + æ ¹æ®çŠ¶æ€é˜¶æ®µï¼Œå›žè°ƒè¦ä¹ˆåœ¨å½“å‰çš„CPU上调用（PREPARE阶段），è¦ä¹ˆåœ¨CPUçš„çƒæ’拔线 + 程ä¸è°ƒç”¨æ¯ä¸ªåœ¨çº¿CPU（ONLINE阶段）。 -如果一个驱动程åºæœ‰å¤šä¸ªå®žä¾‹ï¼Œå¹¶ä¸”æ¯ä¸ªå®žä¾‹éƒ½éœ€è¦ç‹¬ç«‹æ‰§è¡Œå›žè°ƒï¼Œé‚£ä¹ˆå¾ˆå¯èƒ½åº”该使用 -``multi-state`` 。首先需è¦æ³¨å†Œä¸€ä¸ªå¤šçŠ¶æ€çš„状æ€:: + 如果CPU N的回调失败，那么CPU 0 ... N-1çš„teardown回调被调用以回滚æ“作，该函数 + 失败，实例ä¸ä¼šè¢«æ·»åŠ 到多实例状æ€çš„节点列表ä¸ã€‚ - ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "X/Y:online, - Y_online, Y_prepare_down); - Y_hp_online = ret; +è¦ä»ŽçŠ¶æ€çš„节点列表ä¸åˆ 除一个实例，å¯ä»¥ä½¿ç”¨è¿™äº›å‡½æ•°: -``cpuhp_setup_state_multi()`` 的行为与 ``cpuhp_setup_state()`` 类似，åªæ˜¯å®ƒ -为多状æ€å‡†å¤‡äº†å›žè°ƒï¼Œä½†ä¸è°ƒç”¨å›žè°ƒã€‚这是一个一次性的设置。 -一旦分é…äº†ä¸€ä¸ªæ–°çš„å®žä¾‹ï¼Œä½ éœ€è¦æ³¨å†Œè¿™ä¸ªæ–°å®žä¾‹:: + * cpuhp_state_remove_instance(state, node) + * cpuhp_state_remove_instance_nocalls(state, node) - ret = cpuhp_state_add_instance(Y_hp_online, &d->node); +å‚数与上述cpuhp_state_add_instance*()å˜ä½“相åŒã€‚ -è¿™ä¸ªå‡½æ•°å°†æŠŠè¿™ä¸ªå®žä¾‹æ·»åŠ åˆ°ä½ å…ˆå‰åˆ†é…çš„ ``Y_hp_online`` 状æ€ï¼Œå¹¶åœ¨æ‰€æœ‰åœ¨çº¿çš„ -CPU上调用先å‰æ³¨å†Œçš„回调（ ``Y_online`` ）。 *node* å…ƒç´ æ˜¯ä½ çš„æ¯ä¸ªå®žä¾‹æ•°æ®ç»“æž„ -ä¸çš„一个 ``struct hlist_node`` æˆå‘˜ã€‚ +这些函数在处ç†å·²æ³¨å†Œå›žè°ƒçš„æ–¹å¼ä¸Šæœ‰æ‰€ä¸åŒ: -在移除该实例时:: + * cpuhp_state_remove_instance_nocalls()åªä»ŽçŠ¶æ€çš„节点列表ä¸åˆ 除实例。 - cpuhp_state_remove_instance(Y_hp_online, &d->node) + * cpuhp_state_remove_instance()åˆ é™¤å®žä¾‹å¹¶è°ƒç”¨ä¸Ž@state相关的回调（如果ä¸æ˜¯NULL）， + 用于所有当å‰çŠ¶æ€å¤§äºŽ@state的在线CPU。 该回调åªå¯¹å°†è¦è¢«ç§»é™¤çš„实例进行调用。 + æ ¹æ®çŠ¶æ€é˜¶æ®µï¼Œå›žè°ƒè¦ä¹ˆåœ¨å½“å‰çš„CPU上调用（PREPARE阶段），è¦ä¹ˆåœ¨CPUçš„çƒæ’æ‹” + 线程ä¸è°ƒç”¨æ¯ä¸ªåœ¨çº¿CPU（ONLINE阶段）。 -应该被调用，这将在所有在线CPU上调用拆分回调。 + 为了完æˆç§»é™¤å·¥ä½œï¼Œteardown回调ä¸èƒ½å¤±è´¥ã€‚ -手动设置 -~~~~~~~~ +èŠ‚ç‚¹åˆ—è¡¨çš„æ·»åŠ /åˆ é™¤æ“作和回调调用是针对CPUçƒæ‹”æ’æ“作进行åºåˆ—化。这些函数ä¸èƒ½åœ¨ +CPU hotplug回调和CPU hotplug读å–é”定区域内使用。 -通常情况下，在注册或移除状æ€æ—¶è°ƒç”¨setupå’Œteamdownå›žè°ƒæ˜¯å¾ˆæ–¹ä¾¿çš„ï¼Œå› ä¸ºé€šå¸¸åœ¨CPU上线 -（下线）和驱动的åˆå§‹è®¾ç½®ï¼ˆå…³é—）时需è¦æ‰§è¡Œè¯¥æ“作。然而，æ¯ä¸ªæ³¨å†Œå’Œåˆ 除功能也有一个 -_nocallsçš„åŽç¼€ï¼Œå¦‚æžœä¸å¸Œæœ›è°ƒç”¨å›žè°ƒï¼Œåˆ™ä¸è°ƒç”¨æ‰€æ供的回调。在手动设置（或关é—）期间， -应该使用 ``get_online_cpus()`` å’Œ ``put_online_cpus()`` 函数æ¥æŠ‘制CPUçƒæ’æ‹”æ“作。 +æ ·ä¾‹ +---- +在STARTING阶段设置和å–消é™æ€åˆ†é…的状æ€ï¼Œä»¥èŽ·å–上线和下线æ“作的通知:: -äº‹ä»¶çš„é¡ºåº ----------- + ret = cpuhp_setup_state(CPUHP_SUBSYS_STARTING, "subsys:starting", subsys_cpu_starting, subsys_cpu_dying); + if (ret < 0) + return ret; + .... + cpuhp_remove_state(CPUHP_SUBSYS_STARTING); -çƒæ’拔状æ€è¢«å®šä¹‰åœ¨ ``include/linux/cpuhotplug.h``: +在ONLINE阶段设置和å–消动æ€åˆ†é…的状æ€ï¼Œä»¥èŽ·å–下线æ“作的通知:: -* ``CPUHP_OFFLINE`` ... ``CPUHP_AP_OFFLINE`` 状æ€æ˜¯åœ¨CPUå¯åŠ¨å‰è°ƒç”¨çš„。 + state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline); + if (state < 0) + return state; + .... + cpuhp_remove_state(state); -* ``CPUHP_AP_OFFLINE`` ... ``CPUHP_AP_ONLINE`` 状æ€æ˜¯åœ¨CPU被å¯åŠ¨åŽè¢«è°ƒç”¨çš„。 - ä¸æ–是关é—的，调度程åºè¿˜æ²¡æœ‰åœ¨è¿™ä¸ªCPU上活动。从 ``CPUHP_AP_OFFLINE`` 开始， - å›žè°ƒè¢«è°ƒç”¨åˆ°ç›®æ ‡CPU上。 +在ONLINE阶段设置和å–消动æ€åˆ†é…的状æ€ï¼Œä»¥èŽ·å–有关上线æ“ä½œçš„é€šçŸ¥ï¼Œè€Œæ— éœ€è°ƒç”¨å›žè°ƒ:: -* ``CPUHP_AP_ONLINE_DYN`` å’Œ ``CPUHP_AP_ONLINE_DYN_END`` 之间的状æ€è¢«ä¿ç•™ - 给动æ€åˆ†é…。 + state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL); + if (state < 0) + return state; + .... + cpuhp_remove_state_nocalls(state); -* 这些状æ€åœ¨CPUå…³é—时以相å的顺åºè°ƒç”¨ï¼Œä»Ž ``CPUHP_ONLINE`` 开始，在 ``CPUHP_OFFLINE`` - åœæ¢ã€‚这里的回调是在将被关é—çš„CPU上调用的，直到 ``CPUHP_AP_OFFLINE`` 。 +在ONLINE阶段设置ã€ä½¿ç”¨å’Œå–消动æ€åˆ†é…的多实例状æ€ï¼Œä»¥èŽ·å¾—上线和下线æ“作的通知:: -通过 ``CPUHP_AP_ONLINE_DYN`` 动æ€åˆ†é…的状æ€é€šå¸¸å·²ç»è¶³å¤Ÿäº†ã€‚然而，如果在å¯åŠ¨æˆ–å…³é— -期间需è¦æ›´æ—©çš„调用，那么应该获得一个显å¼çŠ¶æ€ã€‚如果çƒæ‹”æ’事件需è¦ç›¸å¯¹äºŽå¦ä¸€ä¸ªçƒæ‹”æ’事 -件的特定排åºï¼Œä¹Ÿå¯èƒ½éœ€è¦ä¸€ä¸ªæ˜¾å¼çŠ¶æ€ã€‚ + state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline); + if (state < 0) + return state; + .... + ret = cpuhp_state_add_instance(state, &inst1->node); + if (ret) + return ret; + .... + ret = cpuhp_state_add_instance(state, &inst2->node); + if (ret) + return ret; + .... + cpuhp_remove_instance(state, &inst1->node); + .... + cpuhp_remove_instance(state, &inst2->node); + .... + remove_multi_state(state); 测试çƒæ‹”æ’çŠ¶æ€ ============== diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 26d9913fc8b6..8a94ad87465d 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -28,6 +28,7 @@ printk-basics printk-formats workqueue + watch_queue symbol-namespaces æ•°æ®ç»“æž„å’Œä½Žçº§å®žç”¨ç¨‹åº @@ -52,7 +53,6 @@ Todolist: circular-buffers generic-radix-tree packing - bus-virt-phys-mapping this_cpu_ops timekeeping errseq @@ -101,7 +101,7 @@ Todolist: ======== å¦‚ä½•åœ¨å†…æ ¸ä¸åˆ†é…和使用内å˜ã€‚请注æ„，在 -:doc:`/vm/index` ä¸æœ‰æ›´å¤šçš„内å˜ç®¡ç†æ–‡æ¡£ã€‚ +:doc:`/mm/index` ä¸æœ‰æ›´å¤šçš„内å˜ç®¡ç†æ–‡æ¡£ã€‚ .. toctree:: :maxdepth: 1 diff --git a/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst b/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst index 7d077742f758..9174fce12c1b 100644 --- a/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst +++ b/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst @@ -5,6 +5,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> .. _cn_irq-domain.rst: @@ -52,8 +53,18 @@ irq_domain和一个hwirqå·ä½œä¸ºå‚数。 如果hwirqçš„æ˜ å°„è¿˜ä¸å˜åœ¨ï¼Œé‚ 一个新的Linux irq_desc，将其与hwirqå…³è”èµ·æ¥ï¼Œå¹¶è°ƒç”¨.map()å›žè°ƒï¼Œè¿™æ ·é©±åŠ¨ 程åºå°±å¯ä»¥æ‰§è¡Œä»»ä½•å¿…è¦çš„硬件设置。 -当接收到一个ä¸æ–时，应该使用irq_find_mapping()函数从hwirqå·ä¸æ‰¾åˆ° -Linux IRQå·ã€‚ +ä¸€æ—¦å»ºç«‹äº†æ˜ å°„ï¼Œå¯ä»¥é€šè¿‡å¤šç§æ–¹æ³•æ£€ç´¢æˆ–使用它： + +- irq_resolve_mapping()返回一个指å‘给定域和hwirqå·çš„irq_desc结构指针， + å¦‚æžœæ²¡æœ‰æ˜ å°„åˆ™è¿”å›žNULL。 + +- irq_find_mapping()返回给定域和hwirqçš„Linux IRQå·ï¼Œå¦‚æžœæ²¡æœ‰æ˜ å°„åˆ™è¿”å›ž0。 + +- irq_linear_revmap()现与irq_find_mapping()相åŒï¼Œå·²è¢«åºŸå¼ƒã€‚ + +- generic_handle_domain_irq()处ç†ä¸€ä¸ªç”±åŸŸå’Œhwirqå·æè¿°çš„ä¸æ–。 + +请注æ„，irq域的查找必须å‘生在与RCU读临界区兼容的上下文ä¸ã€‚ 在调用irq_find_mapping()之å‰ï¼Œè‡³å°‘è¦è°ƒç”¨ä¸€æ¬¡irq_create_mapping()函数， 以å…æ述符ä¸èƒ½è¢«åˆ†é…。 @@ -119,7 +130,8 @@ irq_domain_add_tree()å’Œirq_domain_create_tree()在功能上是ç‰ä»·çš„ï¼Œé™¤äº Linux IRQå·ç¼–å…¥ç¡¬ä»¶æœ¬èº«ï¼Œè¿™æ ·å°±ä¸éœ€è¦æ˜ 射了。 调用irq_create_direct_mapping() 会分é…一个Linux IRQå·ï¼Œå¹¶è°ƒç”¨.map()å›žè°ƒï¼Œè¿™æ ·é©±åŠ¨å°±å¯ä»¥å°†Linux IRQå·ç¼–入硬件ä¸ã€‚ -大多数驱动程åºä¸èƒ½ä½¿ç”¨è¿™ä¸ªæ˜ 射。 +大多数驱动程åºæ— 法使用æ¤æ˜ 射，现在它由CONFIG_IRQ_DOMAIN_NOMAP选项控制。 +请ä¸è¦å¼•å…¥æ¤API的新用户。 ä¼ ç»Ÿæ˜ å°„ç±»åž‹ ------------ @@ -128,7 +140,6 @@ Linux IRQå·ç¼–å…¥ç¡¬ä»¶æœ¬èº«ï¼Œè¿™æ ·å°±ä¸éœ€è¦æ˜ 射了。 调用irq_create irq_domain_add_simple() irq_domain_add_legacy() - irq_domain_add_legacy_isa() irq_domain_create_simple() irq_domain_create_legacy() @@ -137,6 +148,9 @@ Linux IRQå·ç¼–å…¥ç¡¬ä»¶æœ¬èº«ï¼Œè¿™æ ·å°±ä¸éœ€è¦æ˜ 射了。 调用irq_create 一组用于IRQå·çš„定义（#defineï¼‰ï¼Œè¿™äº›å®šä¹‰è¢«ä¼ é€’ç»™struct设备注册。 在这ç§æƒ…况下， ä¸èƒ½åŠ¨æ€åˆ†é…Linux IRQå·ï¼Œåº”è¯¥ä½¿ç”¨ä¼ ç»Ÿæ˜ å°„ã€‚ +顾åæ€ä¹‰ï¼Œ\*_legacy()系列函数已被废弃，åªæ˜¯ä¸ºäº†æ–¹ä¾¿å¯¹å¤è€å¹³å°çš„支æŒè€Œå˜åœ¨ã€‚ +ä¸åº”è¯¥å¢žåŠ æ–°çš„ç”¨æˆ·ã€‚å½“\*_simple()系列函数的使用导致é—留行为时，他们也是如æ¤ã€‚ + ä¼ ç»Ÿæ˜ å°„å‡è®¾å·²ç»ä¸ºæŽ§åˆ¶å™¨åˆ†é…了一个连ç»çš„IRQå·èŒƒå›´ï¼Œå¹¶ä¸”å¯ä»¥é€šè¿‡å‘hwirqå·æ·»åŠ 一 个固定的å移æ¥è®¡ç®—IRQå·ï¼Œå之亦然。 缺点是需è¦ä¸æ–控制器管ç†IRQ分é…，并且需è¦ä¸ºæ¯ 个hwirq分é…一个irq_desc，å³ä½¿å®ƒæ²¡æœ‰è¢«ä½¿ç”¨ã€‚ diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst index e45fe80d1cd8..c22662679065 100644 --- a/Documentation/translations/zh_CN/core-api/kernel-api.rst +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst @@ -5,6 +5,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> .. _cn_kernel-api.rst: @@ -224,7 +225,7 @@ kernel/kmod.c 模å—接å£æ”¯æŒ ------------ -更多信æ¯è¯·å‚考文件kernel/module.c。 +更多信æ¯è¯·å‚阅kernel/module/目录下的文件。 ç¡¬ä»¶æŽ¥å£ ======== @@ -282,6 +283,8 @@ kernel/acct.c 该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: +include/linux/bio.h + block/blk-core.c block/blk-core.c diff --git a/Documentation/translations/zh_CN/core-api/mm-api.rst b/Documentation/translations/zh_CN/core-api/mm-api.rst index 0ea43dc67953..a732b0eebf16 100644 --- a/Documentation/translations/zh_CN/core-api/mm-api.rst +++ b/Documentation/translations/zh_CN/core-api/mm-api.rst @@ -5,6 +5,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> :æ ¡è¯‘: @@ -66,12 +67,24 @@ mm/vmalloc.c 该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: -mm/readahead.c +æ–‡ä»¶æ˜ å°„ +-------- mm/filemap.c +预读 +---- + +mm/readahead.c + +回写 +---- + mm/page-writeback.c +æˆªæ– +---- + mm/truncate.c include/linux/pagemap.h @@ -105,6 +118,14 @@ mm/mempolicy.c include/linux/mm_types.h +include/linux/mm_inline.h + +include/linux/page-flags.h + include/linux/mm.h +include/linux/page_ref.h + include/linux/mmzone.h + +mm/util.c diff --git a/Documentation/translations/zh_CN/core-api/printk-basics.rst b/Documentation/translations/zh_CN/core-api/printk-basics.rst index d574de3167c8..59c6efb3fc41 100644 --- a/Documentation/translations/zh_CN/core-api/printk-basics.rst +++ b/Documentation/translations/zh_CN/core-api/printk-basics.rst @@ -6,6 +6,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> .. _cn_printk-basics.rst: @@ -107,6 +108,4 @@ pr_debug()å’Œpr_devel()，除éžå®šä¹‰äº† ``DEBUG`` (或者在pr_debug()çš„æƒ…å† è¯¥APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: -kernel/printk/printk.c - include/linux/printk.h diff --git a/Documentation/translations/zh_CN/core-api/printk-formats.rst b/Documentation/translations/zh_CN/core-api/printk-formats.rst index ce39c788cf5a..bd36d35eba4e 100644 --- a/Documentation/translations/zh_CN/core-api/printk-formats.rst +++ b/Documentation/translations/zh_CN/core-api/printk-formats.rst @@ -5,6 +5,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> .. _cn_printk-formats.rst: @@ -548,7 +549,7 @@ nodemask_pr_args()æ¥æ–¹ä¾¿æ‰“å°cpumaskå’Œnodemask。 :: - %pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff + %pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff) %pGg GFP_USER|GFP_DMA32|GFP_NOWARN %pGv read|exec|mayread|maywrite|mayexec|denywrite diff --git a/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst index 6abf7ed534ca..bb16f0611046 100644 --- a/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst +++ b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst @@ -52,7 +52,7 @@ 相应的 ksymtab æ¡ç›®ç»“构体 ``kernel_symbol`` 将有相应的æˆå‘˜ ``命å空间`` 集。 导出时未指明命å空间的符å·å°†æŒ‡å‘ ``NULL`` 。如果没有定义命å空间，则默认没有。 -``modpost`` å’Œkernel/module.c分别在构建时或模å—åŠ è½½æ—¶ä½¿ç”¨å称空间。 +``modpost`` å’Œkernel/module/main.c分别在构建时或模å—åŠ è½½æ—¶ä½¿ç”¨å称空间。 2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 ==================================== diff --git a/Documentation/translations/zh_CN/core-api/watch_queue.rst b/Documentation/translations/zh_CN/core-api/watch_queue.rst new file mode 100644 index 000000000000..23b17ae2e4e2 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/watch_queue.rst @@ -0,0 +1,313 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/watch_queue.rst + +:翻译: + +周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> + +:æ ¡è¯‘: + +å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> +å´æƒ³æˆ Wu Xiangcheng <bobwxc@email.cn> + + +============ +通用通知机制 +============ + +é€šç”¨é€šçŸ¥æœºåˆ¶æ˜¯å»ºç«‹åœ¨æ ‡å‡†ç®¡é“驱动之上的，它å¯ä»¥æœ‰æ•ˆåœ°å°†æ¥è‡ªå†…æ ¸çš„é€šçŸ¥æ¶ˆæ¯æ‹¼æŽ¥åˆ°ç”¨ +户空间打开的管é“ä¸ã€‚è¿™å¯ä»¥ä¸Žä»¥ä¸‹æ–¹é¢ç»“åˆä½¿ç”¨:: + + * Key/keyring 通知 + +通知缓冲区å¯ä»¥é€šè¿‡ä»¥ä¸‹æ–¹å¼å¯ç”¨ï¼š + + “General setupâ€/“General notification queue†+ (CONFIG_WATCH_QUEUE) + +文档包å«ä»¥ä¸‹ç« 节： + +.. contents:: :local: + + +概述 +==== + +该设施以一ç§ç‰¹æ®Šæ¨¡å¼æ‰“开的管é“å½¢å¼å‡ºçŽ°ï¼Œç®¡é“的内部环形缓冲区用于ä¿å˜å†…æ ¸ç”Ÿæˆçš„消 +æ¯ã€‚然åŽé€šè¿‡read()读出这些消æ¯ã€‚在æ¤ç±»ç®¡é“上ç¦ç”¨æ‹¼æŽ¥ä»¥åŠç±»ä¼¼çš„æ“ä½œï¼Œå› ä¸ºå®ƒä»¬å¸Œæœ› +在æŸäº›æƒ…å†µä¸‹å°†å…¶æ·»åŠ çš„å†…å®¹è¿˜åŽŸåˆ°çŽ¯ä¸-è¿™å¯èƒ½æœ€ç»ˆä¼šä¸Žé€šçŸ¥æ¶ˆæ¯é‡å 。 + +管é“çš„æ‰€æœ‰è€…å¿…é¡»å‘Šè¯‰å†…æ ¸å®ƒæƒ³é€šè¿‡è¯¥ç®¡é“观察哪些æºã€‚åªæœ‰è¿žæŽ¥åˆ°è¯¥ç®¡é“上的æºæ‰ä¼šå°†æ¶ˆ +æ¯æ’入其ä¸ã€‚请注æ„，一个æºå¯èƒ½ç»‘定到多个管é“，并åŒæ—¶å°†æ¶ˆæ¯æ’入到所有管é“ä¸ã€‚ + +还å¯ä»¥å°†è¿‡æ»¤å™¨æ”¾ç½®åœ¨ç®¡é“上，以便在ä¸æ„Ÿå…´è¶£æ—¶å¯ä»¥å¿½ç•¥æŸäº›æºç±»åž‹å’Œå事件。 + +如果环ä¸æ²¡æœ‰å¯ç”¨çš„æ’槽，或者没有预分é…的消æ¯ç¼“冲区å¯ç”¨ï¼Œåˆ™å°†ä¸¢å¼ƒæ¶ˆæ¯ã€‚在这两ç§æƒ… +况下，read()都会在读å–缓冲区ä¸å½“å‰çš„最åŽä¸€æ¡æ¶ˆæ¯åŽï¼Œå°†WATCH_META_LOSS_NOTIFICATION +æ’入到输出缓冲区ä¸ã€‚ + +请注æ„，当生æˆä¸€ä¸ªé€šçŸ¥æ—¶ï¼Œå†…æ ¸ä¸ä¼šç‰å¾…消费者收集它，而是继ç»æ‰§è¡Œã€‚è¿™æ„味ç€å¯ä»¥åœ¨ +æŒæœ‰è‡ªæ—‹é”çš„åŒæ—¶ç”Ÿæˆé€šçŸ¥ï¼Œå¹¶ä¸”还å¯ä»¥ä¿æŠ¤å†…æ ¸ä¸è¢«ç”¨æˆ·ç©ºé—´æ•…éšœæ— é™æœŸåœ°é˜»ç¢ã€‚ + + +消æ¯ç»“æž„ +======== + +通知消æ¯ç”±ä¸€ä¸ªç®€çŸçš„头部开始:: + + struct watch_notification { + __u32 type:24; + __u32 subtype:8; + __u32 info; + }; + +“typeâ€è¡¨ç¤ºé€šçŸ¥è®°å½•çš„æ¥æºï¼Œâ€œsubtypeâ€è¡¨ç¤ºè¯¥æ¥æºçš„记录类型（è§ä¸‹æ–‡è§‚测æºç« 节）。该类 +型也å¯ä»¥æ˜¯â€œWATCH_TYPE_METAâ€ã€‚这是一个由观测队列本身在内部生æˆçš„特殊记录类型。有两 +个å类型： + + * WATCH_META_REMOVAL_NOTIFICATION + * WATCH_META_LOSS_NOTIFICATION + +ç¬¬ä¸€ä¸ªè¡¨ç¤ºå®‰è£…äº†è§‚å¯Ÿçš„å¯¹è±¡å·²è¢«åˆ é™¤æˆ–é”€æ¯ï¼Œç¬¬äºŒä¸ªè¡¨ç¤ºæŸäº›æ¶ˆæ¯å·²ä¸¢å¤±ã€‚ + +“infoâ€è¡¨ç¤ºä¸€ç³»åˆ—东西，包括： + + * 消æ¯çš„长度，以å—节为å•ä½ï¼ŒåŒ…括头（带有WATCH_INFO_LENGTH的掩ç ，并按 + WATCH_INFO_LENGTH__SHIFT移ä½ï¼‰ã€‚这表示记录的大å°ï¼Œå¯èƒ½åœ¨8到127å—节之间。 + + * 观测ID（带有WATCH_INFO_ID掩ç ，并按WATCH_INFO_ID__SHIFT移ä½ï¼‰ã€‚这表示观测的主 + å«ID，å¯èƒ½åœ¨0到255之间。多个观测组å¯ä»¥å…±äº«ä¸€ä¸ªé˜Ÿåˆ—，这æ供了一ç§åŒºåˆ†å®ƒä»¬çš„方法。 + + * 特定类型的å—段（WATCH_INFO_TYPE_INFO）。这是由通知生产者设置的，以指示类型和 + å类型的æŸäº›ç‰¹å®šå«ä¹‰ã€‚ + +除长度外，信æ¯ä¸çš„所有内容都å¯ä»¥ç”¨äºŽè¿‡æ»¤ã€‚ + +头部åŽé¢å¯ä»¥æœ‰è¡¥å……ä¿¡æ¯ã€‚æ¤æ ¼å¼æ˜¯ç”±ç±»åž‹å’Œå类型决定的。 + + +观测列表（通知æºï¼‰API +===================== + +“观测列表“是订阅通知æºçš„观测者的列表。列表å¯ä»¥é™„åŠ åˆ°å¯¹è±¡ï¼ˆæ¯”å¦‚é”®æˆ–è¶…çº§å—ï¼‰ï¼Œä¹Ÿå¯ +以是全局的（比如对于设备事件）。从用户空间的角度æ¥çœ‹ï¼Œä¸€ä¸ªéžå…¨å±€çš„观测列表通常是 +通过引用它所属的对象æ¥å¼•ç”¨çš„（比如使用KEYCTL_NOTIFY并给它一个密钥åºåˆ—å·æ¥è§‚测特定 +的密钥）。 + +为了管ç†è§‚测列表，æ供了以下函数： + + * :: + + void init_watch_list(struct watch_list *wlist, + void (*release_watch)(struct watch *wlist)); + + åˆå§‹åŒ–一个观测列表。 如果 ``release_watch`` ä¸æ˜¯NULL，那么这表示当watch_list对 + 象被销æ¯æ—¶ï¼Œåº”该调用函数æ¥ä¸¢å¼ƒè§‚测列表对被观测对象的任何引用。 + + * ``void remove_watch_list(struct watch_list *wlist);`` + + è¿™å°†åˆ é™¤è®¢é˜…watch_list的所有观测，并释放它们，然åŽé”€æ¯watch_list对象本身。 + + +观测队列（通知输出）API +======================= + +“观测队列â€æ˜¯ç”±åº”用程åºåˆ†é…的用以记录通知的缓冲区，其工作原ç†å®Œå…¨éšè—在管é“设备驱 +动ä¸ï¼Œä½†å¿…须获得对它的引用æ‰èƒ½è®¾ç½®è§‚测。å¯ä»¥é€šè¿‡ä»¥ä¸‹æ–¹å¼è¿›è¡Œç®¡ç†ï¼š + + * ``struct watch_queue *get_watch_queue(int fd);`` + + ç”±äºŽè§‚æµ‹é˜Ÿåˆ—åœ¨å†…æ ¸ä¸é€šè¿‡å®žçŽ°ç¼“冲区的管é“的文件æ述符表示，用户空间必须通过系 + ç»Ÿè°ƒç”¨ä¼ é€’è¯¥æ–‡ä»¶æ述符，这å¯ä»¥ç”¨äºŽä»Žç³»ç»Ÿè°ƒç”¨ä¸æŸ¥æ‰¾æŒ‡å‘观测队列的ä¸é€æ˜ŽæŒ‡é’ˆã€‚ + + * ``void put_watch_queue(struct watch_queue *wqueue);`` + + 该函数用以丢弃从 ``get_watch_queue()`` 获得的引用。 + + +观测订阅API +=========== + +“观测â€æ˜¯è§‚测列表上的订阅，表示观测队列，从而表示应写入通知记录的缓冲区。观测队列 +对象还å¯ä»¥æºå¸¦è¯¥å¯¹è±¡çš„过滤规则，由用户空间设置。watch结构体的æŸäº›éƒ¨åˆ†å¯ä»¥ç”±é©±åŠ¨ç¨‹ +åºè®¾ç½®:: + + struct watch { + union { + u32 info_id; /* 在infoå—段ä¸è¿›è¡ŒORè¿ç®—çš„ID */ + ... + }; + void *private; /* 被观测对象的ç§æœ‰æ•°æ® */ + u64 id; /* å†…éƒ¨æ ‡è¯†ç¬¦ */ + ... + }; + +``info_id`` 值是从用户空间获得并按WATCH_INFO_ID__SHIFT移ä½çš„8ä½æ•°å—。当通知写入关 +è”的观测队列缓冲区时，这将与struct watch_notification::infoçš„WATCH_INFO_IDå—段进 +行或è¿ç®—。 + +``private`` å—段是与watch_list相关è”的驱动程åºæ•°æ®ï¼Œå¹¶ç”± ``watch_list::release_watch()`` +函数清除。 + +``id`` å—段是æºçš„ID。使用ä¸åŒIDå‘布的通知将被忽略。 + +æ供以下函数æ¥ç®¡ç†è§‚测: + + * ``void init_watch(struct watch *watch, struct watch_queue *wqueue);`` + + åˆå§‹åŒ–一个观测对象，把它的指针设置到观察队列ä¸ï¼Œä½¿ç”¨é€‚当的é™åˆ¶æ¥é¿å…æ»é”。 + + * ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);`` + + 将观测订阅到观测列表（通知æºï¼‰ã€‚watch结构体ä¸çš„driver-settableå—段必须在调用 + 它之å‰è®¾ç½®ã€‚ + + * :: + + int remove_watch_from_object(struct watch_list *wlist, + struct watch_queue *wqueue, + u64 id, false); + + 从观测列表ä¸åˆ 除一个观测，该观测必须与指定的观测队列（``wqueue``ï¼‰å’Œå¯¹è±¡æ ‡è¯† + 符（``id``）匹é…。通知（``WATCH_META_REMOVAL_NOTIFICATION``）被å‘é€åˆ°è§‚测队列 + è¡¨ç¤ºè¯¥è§‚æµ‹å·²è¢«åˆ é™¤ã€‚ + + * ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);`` + + 从观测列表ä¸åˆ 除所有观测。预计这将被称为销æ¯å‰çš„å‡†å¤‡å·¥ä½œï¼Œå±Šæ—¶æ–°çš„è§‚æµ‹å°†æ— æ³• + 访问观测列表。通知（``WATCH_META_REMOVAL_NOTIFICATION``）被å‘é€åˆ°æ¯ä¸ªè®¢é˜…观测 + çš„è§‚æµ‹é˜Ÿåˆ—ï¼Œä»¥è¡¨æ˜Žè¯¥è§‚æµ‹å·²è¢«åˆ é™¤ã€‚ + + +通知å‘布API +=========== + +è¦å°†é€šçŸ¥å‘布到观测列表以便订阅的观测å¯ä»¥çœ‹åˆ°ï¼Œåº”使用以下函数:: + + void post_watch_notification(struct watch_list *wlist, + struct watch_notification *n, + const struct cred *cred, + u64 id); + +åº”é¢„å…ˆè®¾ç½®é€šçŸ¥æ ¼å¼ï¼Œå¹¶åº”ä¼ å…¥ä¸€ä¸ªæŒ‡å‘头部（``n``）的指针。通知å¯èƒ½å¤§äºŽæ¤å€¼ï¼Œå¹¶ä¸”缓 +冲槽为å•ä½çš„大å°åœ¨ ``n->info & WATCH_INFO_LENGTH`` ä¸æ³¨æ˜Žã€‚ + +``cred`` 结构体表示æºï¼ˆå¯¹è±¡ï¼‰çš„è¯ä¹¦ï¼Œå¹¶ä¼ 递给LSM，例如SELinux，以å…许或ç¦æ¢æ ¹æ®è¯¥é˜Ÿ +列（对象）的è¯ä¹¦åœ¨æ¯ä¸ªå•ç‹¬é˜Ÿåˆ—ä¸è®°å½•æ³¨é‡Šã€‚ + +``id`` 是æºå¯¹è±¡ID（如密钥上的åºåˆ—å·ï¼‰ã€‚åªæœ‰è®¾ç½®ç›¸åŒID的观测æ‰èƒ½çœ‹åˆ°è¿™ä¸ªé€šçŸ¥ã€‚ + + +è§‚æµ‹æº +====== + +任何特定的缓冲区都å¯ä»¥ä»Žå¤šä¸ªæºèŽ·å–ä¿¡æ¯ã€‚ 这些æºåŒ…括: + + * WATCH_TYPE_KEY_NOTIFY + + è¿™ç§ç±»åž‹çš„通知表示密钥和密钥环的å˜åŒ–，包括密钥环内容或密钥属性的å˜åŒ–。 + + 更多信æ¯è¯·å‚è§Documentation/security/keys/core.rst。 + + +事件过滤 +======== + +当创建观测队列åŽï¼Œæˆ‘们å¯ä»¥åº”用一组过滤器以é™åˆ¶æŽ¥æ”¶çš„事件:: + + struct watch_notification_filter filter = { + ... + }; + ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter) + +过滤器的æ述的类型å˜é‡æ˜¯:: + + struct watch_notification_filter { + __u32 nr_filters; + __u32 __reserved; + struct watch_notification_type_filter filters[]; + }; + +å…¶ä¸â€œnr_filtersâ€è¡¨ç¤ºfilters[]数组ä¸è¿‡æ»¤å™¨çš„æ•°é‡ï¼Œè€Œâ€œ__reservedâ€åº”为0。 +“filterâ€æ•°ç»„æœ‰ä»¥ä¸‹ç±»åž‹çš„å…ƒç´ :: + + struct watch_notification_type_filter { + __u32 type; + __u32 info_filter; + __u32 info_mask; + __u32 subtype_filter[8]; + }; + +å…¶ä¸ï¼š + + * ``type`` 是过滤的事件类型，应类似于“WATCH_TYPE_KEY_NOTIFYâ€ã€‚ + + * ``info_filter`` 与 ``info_mask`` 充当通知记录的信æ¯å—段的过滤器，åªæœ‰åœ¨ä»¥ä¸‹æƒ… + 况，通知æ‰ä¼šå†™å…¥ç¼“冲区:: + + (watch.info & info_mask) == info_filter + + 例如，这å¯ä»¥ç”¨äºŽå¿½ç•¥ä¸åœ¨ä¸€ä¸ªæŒ‚è½½æ ‘ä¸Šçš„è§‚æµ‹ç‚¹çš„äº‹ä»¶ã€‚ + + * ``subtype_filter`` 是一个ä½æŽ©ç ，表示感兴趣的å类型。subtype_filter[0]çš„ + bit[0]对应å类型0，bit[1]对应å类型1，以æ¤ç±»æŽ¨ã€‚ + +è‹¥ioctl()çš„å‚数为NULL，则过滤器将被移除，并且æ¥è‡ªè§‚测æºçš„所有事件都将通过。 + + +用户空间代ç 示例 +================ + +缓冲区的创建如下所示:: + + pipe2(fds, O_TMPFILE); + ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256); + +它å¯ä»¥è¢«è®¾ç½®æˆæŽ¥æ”¶å¯†é’¥çŽ¯å˜åŒ–的通知:: + + keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01); + +然åŽï¼Œè¿™äº›é€šçŸ¥å¯ä»¥è¢«å¦‚下方å¼æ‰€ä½¿ç”¨:: + + static void consumer(int rfd, struct watch_queue_buffer *buf) + { + unsigned char buffer[128]; + ssize_t buf_len; + + while (buf_len = read(rfd, buffer, sizeof(buffer)), + buf_len > 0 + ) { + void *p = buffer; + void *end = buffer + buf_len; + while (p < end) { + union { + struct watch_notification n; + unsigned char buf1[128]; + } n; + size_t largest, len; + + largest = end - p; + if (largest > 128) + largest = 128; + memcpy(&n, p, largest); + + len = (n->info & WATCH_INFO_LENGTH) >> + WATCH_INFO_LENGTH__SHIFT; + if (len == 0 || len > largest) + return; + + switch (n.n.type) { + case WATCH_TYPE_META: + got_meta(&n.n); + case WATCH_TYPE_KEY_NOTIFY: + saw_key_change(&n.n); + break; + } + + p += len; + } + } + } diff --git a/Documentation/translations/zh_CN/core-api/workqueue.rst b/Documentation/translations/zh_CN/core-api/workqueue.rst index e372fa5cf101..f6567cf9d3fb 100644 --- a/Documentation/translations/zh_CN/core-api/workqueue.rst +++ b/Documentation/translations/zh_CN/core-api/workqueue.rst @@ -6,6 +6,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> .. _cn_workqueue.rst: @@ -178,10 +179,6 @@ workqueue将自动创建与属性相匹é…çš„åŽå¤‡å·¥ä½œè€…æ± ã€‚è°ƒèŠ‚å¹¶å‘æ° è¿™ä¸ªæ ‡å¿—å¯¹äºŽæœªç»‘å®šçš„wqæ¥è¯´æ˜¯æ²¡æœ‰æ„义的。 -请注æ„ï¼Œæ ‡å¿— ``WQ_NON_REENTRANT`` ä¸å†å˜åœ¨ï¼Œå› 为现在所有的工作 -队列都是ä¸å¯é€†çš„——任何工作项都ä¿è¯åœ¨ä»»ä½•æ—¶é—´å†…最多被整个系统的一 -个工作者执行。 - ``max_active`` -------------- @@ -328,6 +325,22 @@ And with cmwq with ``@max_active`` >= 3, :: å·¥ä½œé¡¹å‡½æ•°åœ¨å †æ ˆè¿½è¸ªä¸åº”该是微ä¸è¶³é“的。 +ä¸å¯é‡å…¥æ¡ä»¶ +============ + +工作队列ä¿è¯ï¼Œå¦‚果在工作项排队åŽæ»¡è¶³ä»¥ä¸‹æ¡ä»¶ï¼Œåˆ™å·¥ä½œé¡¹ä¸èƒ½é‡å…¥ï¼š + + + 1. 工作函数没有被改å˜ã€‚ + 2. 没有人将该工作项排到å¦ä¸€ä¸ªå·¥ä½œé˜Ÿåˆ—ä¸ã€‚ + 3. 该工作项尚未被é‡æ–°å¯åŠ¨ã€‚ + +æ¢è¨€ä¹‹ï¼Œå¦‚果上述æ¡ä»¶æˆç«‹ï¼Œåˆ™ä¿è¯åœ¨ä»»ä½•ç»™å®šæ—¶é—´æœ€å¤šç”±ä¸€ä¸ªç³»ç»ŸèŒƒå›´å†…的工作程åºæ‰§è¡Œ +该工作项。 + +请注æ„，在self函数ä¸å°†å·¥ä½œé¡¹é‡æ–°æŽ’队（到åŒä¸€é˜Ÿåˆ—）ä¸ä¼šç ´å这些æ¡ä»¶ï¼Œå› æ¤å¯ä»¥å®‰å…¨ +地执行æ¤æ“作。å¦åˆ™åœ¨ç ´å工作函数内部的æ¡ä»¶æ—¶éœ€è¦å°å¿ƒã€‚ + å†…æ ¸å†…è”文档å‚考 ================ diff --git a/Documentation/translations/zh_CN/core-api/xarray.rst b/Documentation/translations/zh_CN/core-api/xarray.rst index ff2d9bcb7c34..fb19324966ce 100644 --- a/Documentation/translations/zh_CN/core-api/xarray.rst +++ b/Documentation/translations/zh_CN/core-api/xarray.rst @@ -6,6 +6,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> :æ ¡è¯‘: @@ -254,7 +255,8 @@ __xa_set_mark() å’Œ __xa_clear_mark() å‡½æ•°ä¹Ÿé€‚ç”¨äºŽä½ æŸ¥æ‰¾ä¸€ä¸ªæ¡ç›®å¹¶ 高级API是基于xa_state的。这是一个ä¸é€æ˜Žçš„æ•°æ®ç»“æž„ï¼Œä½ ä½¿ç”¨XA_STATE()å®åœ¨å †æ ˆä¸å£°æ˜Žã€‚这个å®åˆå§‹åŒ–了 xa_state，准备开始在XArrayä¸Šç§»åŠ¨ã€‚å®ƒè¢«ç”¨ä½œä¸€ä¸ªæ¸¸æ ‡æ¥ä¿æŒåœ¨XArrayä¸çš„ä½ç½®ï¼Œå¹¶è®©ä½ 把å„ç§æ“作组åˆåœ¨ä¸€ -起，而ä¸å¿…æ¯æ¬¡éƒ½ä»Žå¤´å¼€å§‹ã€‚ +起，而ä¸å¿…æ¯æ¬¡éƒ½ä»Žå¤´å¼€å§‹ã€‚xa_state的内容å—rcu_read_lock()或xas_lock()çš„ä¿æŠ¤ã€‚如果需è¦åˆ 除ä¿æŠ¤çŠ¶æ€ +å’Œæ ‘çš„è¿™äº›é”ä¸çš„ä»»ä½•ä¸€ä¸ªï¼Œä½ å¿…é¡»è°ƒç”¨xas_pause()以便将æ¥çš„调用ä¸ä¼šä¾èµ–于状æ€ä¸æœªå—ä¿æŠ¤çš„部分。 xa_state也被用æ¥å˜å‚¨é”™è¯¯(store errors)ã€‚ä½ å¯ä»¥è°ƒç”¨xas_error()æ¥æ£€ç´¢é”™è¯¯ã€‚所有的æ“作在进行之å‰éƒ½ 会检查xa_state是å¦å¤„于错误状æ€ï¼Œæ‰€ä»¥ä½ 没有必è¦åœ¨æ¯æ¬¡è°ƒç”¨ä¹‹åŽæ£€æŸ¥é”™è¯¯ï¼›ä½ å¯ä»¥è¿žç»è¿›è¡Œå¤šæ¬¡è°ƒç”¨ï¼Œåªåœ¨ diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst index 23db9d419047..fe76cbe77ad6 100644 --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst @@ -11,34 +11,65 @@ 概述 ---- -KernelAddressSANitizer(KASAN)是一ç§åŠ¨æ€å†…å˜å®‰å…¨é”™è¯¯æ£€æµ‹å·¥å…·ï¼Œä¸»è¦åŠŸèƒ½æ˜¯ -检查内å˜è¶Šç•Œè®¿é—®å’Œä½¿ç”¨å·²é‡Šæ”¾å†…å˜çš„问题。KASAN有三ç§æ¨¡å¼: +Kernel Address SANitizer(KASAN)是一ç§åŠ¨æ€å†…å˜å®‰å…¨é”™è¯¯æ£€æµ‹å·¥å…·ï¼Œä¸»è¦åŠŸèƒ½æ˜¯ +检查内å˜è¶Šç•Œè®¿é—®å’Œä½¿ç”¨å·²é‡Šæ”¾å†…å˜çš„问题。 -1. 通用KASAN（与用户空间的ASan类似） -2. åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN（与用户空间的HWASan类似） -3. åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN（基于硬件内å˜æ ‡ç¾ï¼‰ +KASAN有三ç§æ¨¡å¼: -由于通用KASAN的内å˜å¼€é”€è¾ƒå¤§ï¼Œé€šç”¨KASAN主è¦ç”¨äºŽè°ƒè¯•ã€‚åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN -å¯ç”¨äºŽdogfoodæµ‹è¯•ï¼Œå› ä¸ºå®ƒå…·æœ‰è¾ƒä½Žçš„å†…å˜å¼€é”€ï¼Œå¹¶å…许将其用于实际工作é‡ã€‚ -åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN具有较低的内å˜å’Œæ€§èƒ½å¼€é”€ï¼Œå› æ¤å¯ç”¨äºŽç”Ÿäº§ã€‚åŒæ—¶å¯ç”¨äºŽ -检测现场内å˜é—®é¢˜æˆ–作为安全缓解措施。 +1. 通用KASAN +2. åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN +3. åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN -软件KASAN模å¼ï¼ˆ#1å’Œ#2）使用编译时工具在æ¯æ¬¡å†…å˜è®¿é—®ä¹‹å‰æ’入有效性检查， -å› æ¤éœ€è¦ä¸€ä¸ªæ”¯æŒå®ƒçš„编译器版本。 +用CONFIG_KASAN_GENERICå¯ç”¨çš„通用KASAN，是用于调试的模å¼ï¼Œç±»ä¼¼äºŽç”¨æˆ·ç©º +é—´çš„ASan。这ç§æ¨¡å¼åœ¨è®¸å¤šCPU架构上都被支æŒï¼Œä½†å®ƒæœ‰æ˜Žæ˜¾çš„性能和内å˜å¼€é”€ã€‚ -通用KASAN在GCCå’ŒClangå—支æŒã€‚GCC需è¦8.3.0或更高版本。任何å—支æŒçš„Clang -版本都是兼容的，但从Clang 11æ‰å¼€å§‹æ”¯æŒæ£€æµ‹å…¨å±€å˜é‡çš„越界访问。 +åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN或SW_TAGS KASAN，通过CONFIG_KASAN_SW_TAGSå¯ç”¨ï¼Œ +å¯ä»¥ç”¨äºŽè°ƒè¯•å’Œè‡ªæˆ‘测试，类似于用户空间HWASan。这ç§æ¨¡å¼åªæ”¯æŒarm64，但其 +适度的内å˜å¼€é”€å…许在内å˜å—é™çš„设备上用真实的工作负载进行测试。 -åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN模å¼ä»…在Clangä¸å—支æŒã€‚ +åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN或HW_TAGS KASAN，用CONFIG_KASAN_HW_TAGSå¯ç”¨ï¼Œè¢« +用作现场内å˜é”™è¯¯æ£€æµ‹å™¨æˆ–作为安全缓解的模å¼ã€‚è¿™ç§æ¨¡å¼åªåœ¨æ”¯æŒMTE（内å˜æ ‡ç¾ +扩展）的arm64 CPU上工作，但它的内å˜å’Œæ€§èƒ½å¼€é”€å¾ˆä½Žï¼Œå› æ¤å¯ä»¥åœ¨ç”Ÿäº§ä¸ä½¿ç”¨ã€‚ -硬件KASAN模å¼ï¼ˆ#3）ä¾èµ–硬件æ¥æ‰§è¡Œæ£€æŸ¥ï¼Œä½†ä»éœ€è¦æ”¯æŒå†…å˜æ ‡ç¾æŒ‡ä»¤çš„编译器 -版本。GCC 10+å’ŒClang 11+支æŒæ¤æ¨¡å¼ã€‚ +关于æ¯ç§KASAN模å¼çš„内å˜å’Œæ€§èƒ½å½±å“的细节，请å‚è§ç›¸åº”çš„Kconfig选项的æ述。 -两ç§è½¯ä»¶KASAN模å¼éƒ½é€‚用于SLUBå’ŒSLAB内å˜åˆ†é…å™¨ï¼Œè€ŒåŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASANç›®å‰ -仅支æŒSLUB。 +通用模å¼å’ŒåŸºäºŽè½¯ä»¶æ ‡ç¾çš„模å¼é€šå¸¸è¢«ç§°ä¸ºè½¯ä»¶æ¨¡å¼ã€‚åŸºäºŽè½¯ä»¶æ ‡ç¾çš„模å¼å’ŒåŸºäºŽ +ç¡¬ä»¶æ ‡ç¾çš„模å¼è¢«ç§°ä¸ºåŸºäºŽæ ‡ç¾çš„模å¼ã€‚ -ç›®å‰x86_64ã€armã€arm64ã€xtensaã€s390ã€riscv架构支æŒé€šç”¨KASAN模å¼ï¼Œä»… -arm64架构支æŒåŸºäºŽæ ‡ç¾çš„KASAN模å¼ã€‚ +æ”¯æŒ +---- + +体系架构 +~~~~~~~~ + +在x86_64ã€armã€arm64ã€powerpcã€riscvã€s390å’Œxtensa上支æŒé€šç”¨KASAN， +è€ŒåŸºäºŽæ ‡ç¾çš„KASAN模å¼åªåœ¨arm64上支æŒã€‚ + +编译器 +~~~~~~ + +软件KASAN模å¼ä½¿ç”¨ç¼–译时工具在æ¯ä¸ªå†…å˜è®¿é—®ä¹‹å‰æ’å…¥æœ‰æ•ˆæ€§æ£€æŸ¥ï¼Œå› æ¤éœ€è¦ä¸€ä¸ª +æ供支æŒçš„ç¼–è¯‘å™¨ç‰ˆæœ¬ã€‚åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„模å¼ä¾é 硬件æ¥æ‰§è¡Œè¿™äº›æ£€æŸ¥ï¼Œä½†ä»ç„¶éœ€è¦ +一个支æŒå†…å˜æ ‡ç¾æŒ‡ä»¤çš„编译器版本。 + +通用KASAN需è¦GCC 8.3.0ç‰ˆæœ¬æˆ–æ›´é«˜ç‰ˆæœ¬ï¼Œæˆ–è€…å†…æ ¸æ”¯æŒçš„任何Clang版本。 + +åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN需è¦GCC 11+æˆ–è€…å†…æ ¸æ”¯æŒçš„任何Clang版本。 + +åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN需è¦GCC 10+或Clang 12+。 + +内å˜ç±»åž‹ +~~~~~~~~ + +通用KASAN支æŒåœ¨æ‰€æœ‰çš„slabã€page_allocã€vmapã€vmallocã€å †æ ˆå’Œå…¨å±€å†…å˜ +ä¸æŸ¥æ‰¾é”™è¯¯ã€‚ + +åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN支æŒslabã€page_allocã€vmallocå’Œå †æ ˆå†…å˜ã€‚ + +åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN支æŒslabã€page_allocå’Œä¸å¯æ‰§è¡Œçš„vmalloc内å˜ã€‚ + +对于slab，两ç§è½¯ä»¶KASAN模å¼éƒ½æ”¯æŒSLUBå’ŒSLAB分é…å™¨ï¼Œè€ŒåŸºäºŽç¡¬ä»¶æ ‡ç¾çš„ +KASANåªæ”¯æŒSLUB。 用法 ---- @@ -53,7 +84,7 @@ arm64架构支æŒåŸºäºŽæ ‡ç¾çš„KASAN模å¼ã€‚ 对于软件模å¼ï¼Œè¿˜å¯ä»¥åœ¨ ``CONFIG_KASAN_OUTLINE`` å’Œ ``CONFIG_KASAN_INLINE`` 之间进行选择。outlineå’Œinline是编译器æ’桩类型。å‰è€…产生较å°çš„二进制文件， -而åŽè€…å¿«1.1-2å€ã€‚ +而åŽè€…å¿«2å€ã€‚ è¦å°†å—å½±å“çš„slab对象的allocå’Œfreeå †æ ˆè·Ÿè¸ªåŒ…å«åˆ°æŠ¥å‘Šä¸ï¼Œè¯·å¯ç”¨ ``CONFIG_STACKTRACE`` 。è¦åŒ…括å—å½±å“物ç†é¡µé¢çš„分é…å’Œé‡Šæ”¾å †æ ˆè·Ÿè¸ªçš„è¯ï¼Œ @@ -172,21 +203,29 @@ KASANå—通用 ``panic_on_warn`` 命令行å‚æ•°çš„å½±å“。å¯ç”¨è¯¥åŠŸèƒ½åŽï¼ 默认情况下，KASANåªä¸ºç¬¬ä¸€æ¬¡æ— 效内å˜è®¿é—®æ‰“å°é”™è¯¯æŠ¥å‘Šã€‚使用 ``kasan_multi_shot`` ， KASAN会针对æ¯ä¸ªæ— 效访问打å°æŠ¥å‘Šã€‚这有效地ç¦ç”¨äº†KASAN报告的 ``panic_on_warn`` 。 +å¦å¤–，独立于 ``panic_on_warn`` , ``kasan.fault=`` 引导å‚æ•°å¯ä»¥ç”¨æ¥æŽ§åˆ¶æ慌和报 +告行为: + +- ``kasan.fault=report`` 或 ``=panic`` 控制是åªæ‰“å°KASAN报告还是åŒæ—¶ä½¿å†…æ ¸ææ…Œ + (默认: ``report`` )。å³ä½¿å¯ç”¨äº† ``kasan_multi_shot`` ，也会å‘ç”Ÿå†…æ ¸æ慌。 + åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN模å¼ï¼ˆè¯·å‚阅下é¢æœ‰å…³å„ç§æ¨¡å¼çš„部分）旨在在生产ä¸ç”¨ä½œå®‰å…¨ç¼“解 -æŽªæ–½ã€‚å› æ¤ï¼Œå®ƒæ”¯æŒå…许ç¦ç”¨KASAN或控制其功能的引导å‚数。 +æŽªæ–½ã€‚å› æ¤ï¼Œå®ƒæ”¯æŒå…许ç¦ç”¨KASANæˆ–æŽ§åˆ¶å…¶åŠŸèƒ½çš„é™„åŠ å¼•å¯¼å‚数。 - ``kasan=off`` 或 ``=on`` 控制KASAN是å¦å¯ç”¨ (默认: ``on`` )。 -- ``kasan.mode=sync`` 或 ``=async`` 控制KASAN是å¦é…置为åŒæ¥æˆ–异æ¥æ‰§è¡Œæ¨¡å¼(默认: - ``sync`` )。åŒæ¥æ¨¡å¼ï¼šå½“æ ‡ç¾æ£€æŸ¥é”™è¯¯å‘生时，立å³æ£€æµ‹åˆ°é”™è¯¯è®¿é—®ã€‚异æ¥æ¨¡å¼ï¼š - å»¶è¿Ÿé”™è¯¯è®¿é—®æ£€æµ‹ã€‚å½“æ ‡ç¾æ£€æŸ¥é”™è¯¯å‘生时，信æ¯å˜å‚¨åœ¨ç¡¬ä»¶ä¸ï¼ˆåœ¨arm64çš„ +- ``kasan.mode=sync`` 〠``=async`` 或 ``=asymm`` 控制KASAN是å¦é…ç½® + 为åŒæ¥æˆ–异æ¥æ‰§è¡Œæ¨¡å¼(默认:``sync`` )。 + åŒæ¥æ¨¡å¼ï¼šå½“æ ‡ç¾æ£€æŸ¥é”™è¯¯å‘生时，立å³æ£€æµ‹åˆ°é”™è¯¯è®¿é—®ã€‚ + 异æ¥æ¨¡å¼ï¼šå»¶è¿Ÿé”™è¯¯è®¿é—®æ£€æµ‹ã€‚å½“æ ‡ç¾æ£€æŸ¥é”™è¯¯å‘生时，信æ¯å˜å‚¨åœ¨ç¡¬ä»¶ä¸ï¼ˆåœ¨arm64çš„ TFSR_EL1寄å˜å™¨ä¸ï¼‰ã€‚å†…æ ¸ä¼šå®šæœŸæ£€æŸ¥ç¡¬ä»¶ï¼Œå¹¶ä¸”ä»…åœ¨è¿™äº›æ£€æŸ¥æœŸé—´æŠ¥å‘Šæ ‡ç¾é”™è¯¯ã€‚ + éžå¯¹ç§°æ¨¡å¼ï¼šè¯»å–æ—¶åŒæ¥æ£€æµ‹ä¸è‰¯è®¿é—®ï¼Œå†™å…¥æ—¶å¼‚æ¥æ£€æµ‹ã€‚ + +- ``kasan.vmalloc=off`` 或 ``=on`` ç¦ç”¨æˆ–å¯ç”¨vmalloc分é…çš„æ ‡è®°ï¼ˆé»˜è®¤ï¼š``on`` ）。 - ``kasan.stacktrace=off`` 或 ``=on`` ç¦ç”¨æˆ–å¯ç”¨allocå’Œfreeå †æ ˆè·Ÿè¸ªæ”¶é›† (默认: ``on`` )。 -- ``kasan.fault=report`` 或 ``=panic`` 控制是åªæ‰“å°KASAN报告还是åŒæ—¶ä½¿å†…æ ¸ææ…Œ - (默认: ``report`` )。å³ä½¿å¯ç”¨äº† ``kasan_multi_shot`` ，也会å‘ç”Ÿå†…æ ¸æ慌。 实施细则 -------- @@ -244,7 +283,6 @@ KASAN会针对æ¯ä¸ªæ— 效访问打å°æŠ¥å‘Šã€‚这有效地ç¦ç”¨äº†KASAN报告ç åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASAN使用0xFF作为匹é…æ‰€æœ‰æŒ‡é’ˆæ ‡ç¾ï¼ˆä¸æ£€æŸ¥é€šè¿‡å¸¦æœ‰0xFFæŒ‡é’ˆæ ‡ç¾ çš„æŒ‡é’ˆè¿›è¡Œçš„è®¿é—®ï¼‰ã€‚å€¼0xFE当å‰ä¿ç•™ç”¨äºŽæ ‡è®°å·²é‡Šæ”¾çš„内å˜åŒºåŸŸã€‚ -åŸºäºŽè½¯ä»¶æ ‡ç¾çš„KASANç›®å‰ä»…支æŒå¯¹Slabå’Œpage_alloc内å˜è¿›è¡Œæ ‡è®°ã€‚ åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASANæ¨¡å¼ ~~~~~~~~~~~~~~~~~~~~~~~ @@ -262,8 +300,6 @@ KASAN会针对æ¯ä¸ªæ— 效访问打å°æŠ¥å‘Šã€‚这有效地ç¦ç”¨äº†KASAN报告ç åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN使用0xFF作为匹é…æ‰€æœ‰æŒ‡é’ˆæ ‡ç¾ï¼ˆä¸æ£€æŸ¥é€šè¿‡å¸¦æœ‰0xFFæŒ‡é’ˆæ ‡ç¾çš„ 指针进行的访问）。值0xFE当å‰ä¿ç•™ç”¨äºŽæ ‡è®°å·²é‡Šæ”¾çš„内å˜åŒºåŸŸã€‚ -åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASANç›®å‰ä»…支æŒå¯¹Slabå’Œpage_alloc内å˜è¿›è¡Œæ ‡è®°ã€‚ - 如果硬件ä¸æ”¯æŒMTE（ARMv8.5之å‰ï¼‰ï¼Œåˆ™ä¸ä¼šå¯ç”¨åŸºäºŽç¡¬ä»¶æ ‡ç¾çš„KASAN。在这ç§æƒ…况下， 所有KASAN引导å‚数都将被忽略。 @@ -275,6 +311,8 @@ KASAN会针对æ¯ä¸ªæ— 效访问打å°æŠ¥å‘Šã€‚这有效地ç¦ç”¨äº†KASAN报告ç å½±åå†…å˜ -------- +本节的内容åªé€‚用于软件KASAN模å¼ã€‚ + å†…æ ¸å°†å†…å˜æ˜ 射到地å€ç©ºé—´çš„å‡ ä¸ªä¸åŒéƒ¨åˆ†ã€‚å†…æ ¸è™šæ‹Ÿåœ°å€çš„范围很大：没有足够的真实 内å˜æ¥æ”¯æŒå†…æ ¸å¯ä»¥è®¿é—®çš„æ¯ä¸ªåœ°å€çš„真实影ååŒºåŸŸã€‚å› æ¤ï¼ŒKASANåªä¸ºåœ°å€ç©ºé—´çš„æŸäº› éƒ¨åˆ†æ˜ å°„çœŸå®žçš„å½±å。 @@ -297,7 +335,7 @@ CONFIG_KASAN_VMALLOC ~~~~~~~~~~~~~~~~~~~~ 使用 ``CONFIG_KASAN_VMALLOC`` ，KASANå¯ä»¥ä»¥æ›´å¤§çš„内å˜ä½¿ç”¨ä¸ºä»£ä»·è¦†ç›–vmalloc -空间。目å‰ï¼Œè¿™åœ¨x86ã€riscvã€s390å’Œpowerpc上å—支æŒã€‚ +空间。目å‰ï¼Œè¿™åœ¨arm64ã€x86ã€riscvã€s390å’Œpowerpc上å—支æŒã€‚ 这通过连接到vmallocå’Œvmap并动æ€åˆ†é…真实的影å内å˜æ¥æ”¯æŒæ˜ 射。 @@ -349,10 +387,10 @@ KASAN连接到vmap基础架构以懒清ç†æœªä½¿ç”¨çš„å½±å内å˜ã€‚ ``kasan_disable_current()``/``kasan_enable_current()`` 部分注释这部分代ç 。 这也会ç¦ç”¨é€šè¿‡å‡½æ•°è°ƒç”¨å‘生的间接访问的报告。 -å¯¹äºŽåŸºäºŽæ ‡ç¾çš„KASAN模å¼ï¼ˆåŒ…括硬件模å¼ï¼‰ï¼Œè¦ç¦ç”¨è®¿é—®æ£€æŸ¥ï¼Œè¯·ä½¿ç”¨ -``kasan_reset_tag()`` 或 ``page_kasan_tag_reset()`` 。请注æ„，通过 -``page_kasan_tag_reset()`` 临时ç¦ç”¨è®¿é—®æ£€æŸ¥éœ€è¦é€šè¿‡ ``page_kasan_tag`` -/ ``page_kasan_tag_set`` ä¿å˜å’Œæ¢å¤æ¯é¡µKASANæ ‡ç¾ã€‚ +å¯¹äºŽåŸºäºŽæ ‡ç¾çš„KASAN模å¼ï¼Œè¦ç¦ç”¨è®¿é—®æ£€æŸ¥ï¼Œè¯·ä½¿ç”¨ ``kasan_reset_tag()`` 或 +``page_kasan_tag_reset()`` 。请注æ„，通过 ``page_kasan_tag_reset()`` +临时ç¦ç”¨è®¿é—®æ£€æŸ¥éœ€è¦é€šè¿‡ ``page_kasan_tag`` / ``page_kasan_tag_set`` ä¿ +å˜å’Œæ¢å¤æ¯é¡µKASANæ ‡ç¾ã€‚ 测试 ~~~~ @@ -381,11 +419,10 @@ KASAN连接到vmap基础架构以懒清ç†æœªä½¿ç”¨çš„å½±å内å˜ã€‚ 当由于缺少KASAN报告而导致测试失败时:: - # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 - Expected kasan_data->report_expected == kasan_data->report_found, but - kasan_data->report_expected == 1 - kasan_data->report_found == 0 - not ok 28 - kmalloc_double_kzfree + # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974 + KASAN failure expected in "kfree_sensitive(ptr)", but none occurred + not ok 44 - kmalloc_double_kzfree + 最åŽæ‰“å°æ‰€æœ‰KASAN测试的累积状æ€ã€‚æˆåŠŸ:: diff --git a/Documentation/translations/zh_CN/dev-tools/sparse.rst b/Documentation/translations/zh_CN/dev-tools/sparse.rst index 556282437aad..0664c634bc4f 100644 --- a/Documentation/translations/zh_CN/dev-tools/sparse.rst +++ b/Documentation/translations/zh_CN/dev-tools/sparse.rst @@ -106,3 +106,5 @@ __releases - 指定的é”在函数进入时被æŒæœ‰ï¼Œä½†åœ¨é€€å‡ºæ—¶ä¸è¢«æŒ make çš„å¯é€‰å˜é‡ CHECKFLAGS å¯ä»¥ç”¨æ¥å‘ sparse å·¥å…·ä¼ é€’å‚数。编译系统会自 åŠ¨å‘ sparse å·¥å…·ä¼ é€’ -Wbitwise å‚数。 + +注æ„sparse定义了__CHECKER__预处ç†å™¨ç¬¦å·ã€‚
\ No newline at end of file diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst index b7a1d13da6c6..d6f2c65ed511 100644 --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst @@ -107,3 +107,28 @@ Documentation/dev-tools/kcov.rst æ˜¯èƒ½å¤Ÿæž„å»ºåœ¨å†…æ ¸ä¹‹ä¸ï¼Œç”¨äºŽåœ¨æ¯ä¸ 之åŽä½ 就能确ä¿è¿™äº›é”™è¯¯åœ¨æµ‹è¯•è¿‡ç¨‹ä¸éƒ½ä¸ä¼šå‘生了。 一些工具与KUnitå’Œkselftest集æˆï¼Œå¹¶ä¸”在检测到问题时会自动打æ–测试。 + +é™æ€åˆ†æžå·¥å…· +============ + +除了测试è¿è¡Œä¸çš„å†…æ ¸ï¼Œæˆ‘ä»¬è¿˜å¯ä»¥ä½¿ç”¨**é™æ€åˆ†æž**工具直接分æžå†…æ ¸çš„æºä»£ +ç （**在编译时**ï¼‰ã€‚å†…æ ¸ä¸å¸¸ç”¨çš„工具å…许人们检查整个æºä»£ç æ ‘æˆ–å…¶ä¸çš„特 +定文件。它们使得在开å‘过程ä¸æ›´å®¹æ˜“å‘现和修å¤é—®é¢˜ã€‚ + + Sparseå¯ä»¥é€šè¿‡æ‰§è¡Œç±»åž‹æ£€æŸ¥ã€é”检查ã€å€¼èŒƒå›´æ£€æŸ¥æ¥å¸®åŠ©æµ‹è¯•å†…æ ¸ï¼Œæ¤å¤–还 + å¯ä»¥åœ¨æ£€æŸ¥ä»£ç 时报告å„ç§é”™è¯¯å’Œè¦å‘Šã€‚关于如何使用它的细节，请å‚阅 + Documentation/translations/zh_CN/dev-tools/sparse.rst。 + + Smatch扩展了Sparse，并æ供了对编程逻辑错误的é¢å¤–检查，如开关è¯å¥ä¸ + 缺少æ–点，错误检查ä¸æœªä½¿ç”¨çš„返回值，忘记在错误路径的返回ä¸è®¾ç½®é”™è¯¯ä»£ + ç ç‰ã€‚Smatch也有针对更严é‡é—®é¢˜çš„测试，如整数溢出ã€ç©ºæŒ‡é’ˆè§£é™¤å¼•ç”¨å’Œå†… + å˜æ³„æ¼ã€‚è§é¡¹ç›®é¡µé¢http://smatch.sourceforge.net/。 + + Coccinelle是我们å¯ä»¥ä½¿ç”¨çš„å¦ä¸€ä¸ªé™æ€åˆ†æžå™¨ã€‚Coccinelleç»å¸¸è¢«ç”¨æ¥ + 帮助æºä»£ç çš„é‡æž„和并行演化，但它也å¯ä»¥å¸®åŠ©é¿å…常è§ä»£ç 模å¼ä¸å‡ºçŽ°çš„æŸ + 些错误。å¯ç”¨çš„测试类型包括API测试ã€å†…æ ¸è¿ä»£å™¨çš„æ£ç¡®ä½¿ç”¨æµ‹è¯•ã€è‡ªç”±æ“ + 作的åˆç†æ€§æ£€æŸ¥ã€é”定行为的分æžï¼Œä»¥åŠå·²çŸ¥çš„有助于ä¿æŒå†…æ ¸ä½¿ç”¨ä¸€è‡´æ€§çš„ + 进一æ¥æµ‹è¯•ã€‚详情请è§Documentation/dev-tools/coccinelle.rst。 + + ä¸è¿‡è¦æ³¨æ„的是，é™æ€åˆ†æžå·¥å…·å˜åœ¨**å‡é˜³æ€§**的问题。在试图修å¤é”™è¯¯å’Œè¦ + 告之å‰ï¼Œéœ€è¦ä»”细评估它们。 diff --git a/Documentation/translations/zh_CN/devicetree/index.rst b/Documentation/translations/zh_CN/devicetree/index.rst index 23d0b6fccd58..3fc355fe0037 100644 --- a/Documentation/translations/zh_CN/devicetree/index.rst +++ b/Documentation/translations/zh_CN/devicetree/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/Devicetree/index.rst +:Original: Documentation/devicetree/index.rst :翻译: diff --git a/Documentation/translations/zh_CN/devicetree/of_unittest.rst b/Documentation/translations/zh_CN/devicetree/of_unittest.rst index abd94e771ef8..11eb08ca8866 100644 --- a/Documentation/translations/zh_CN/devicetree/of_unittest.rst +++ b/Documentation/translations/zh_CN/devicetree/of_unittest.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/Devicetree/of_unittest.rst +:Original: Documentation/devicetree/of_unittest.rst :翻译: diff --git a/Documentation/translations/zh_CN/devicetree/usage-model.rst b/Documentation/translations/zh_CN/devicetree/usage-model.rst index accdc33475a0..c6aee82c7e6e 100644 --- a/Documentation/translations/zh_CN/devicetree/usage-model.rst +++ b/Documentation/translations/zh_CN/devicetree/usage-model.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/Devicetree/usage-model.rst +:Original: Documentation/devicetree/usage-model.rst :翻译: diff --git a/Documentation/translations/zh_CN/doc-guide/kernel-doc.rst b/Documentation/translations/zh_CN/doc-guide/kernel-doc.rst index 82ec84470c0b..ccfb9b8329c2 100644 --- a/Documentation/translations/zh_CN/doc-guide/kernel-doc.rst +++ b/Documentation/translations/zh_CN/doc-guide/kernel-doc.rst @@ -14,7 +14,7 @@ Linuxå†…æ ¸æºæ–‡ä»¶å¯ä»¥åŒ…å«kernel-docæ ¼å¼çš„ç»“æž„åŒ–æ–‡æ¡£æ³¨é‡Šï¼Œç”¨ä» å®žé™…æœ‰ç€æ˜Žæ˜¾çš„ä¸åŒã€‚å†…æ ¸æºåŒ…å«æˆåƒä¸Šä¸‡ä¸ªkernel-doc注释。请åšæŒéµå¾ª æ¤å¤„æè¿°çš„é£Žæ ¼ã€‚ -.. note:: kernel-docæ— æ³•åŒ…å«Rust代ç ：请å‚考 Documentation/rust/docs.rst 。 +.. note:: kernel-docæ— æ³•åŒ…å«Rust代ç ：请å‚考 Documentation/rust/general-information.rst 。 从注释ä¸æå–kernel-doc结构，并从ä¸ç”Ÿæˆé€‚当的 `Sphinx C 域`_ 函数和带有锚点的 类型æ述。这些注释将被过滤以生æˆç‰¹æ®Škernel-doc高亮和交å‰å¼•ç”¨ã€‚详è§ä¸‹æ–‡ã€‚ diff --git a/Documentation/translations/zh_CN/iio/iio_configfs.rst b/Documentation/translations/zh_CN/iio/iio_configfs.rst index d5460e951804..eccaf1c644b4 100644 --- a/Documentation/translations/zh_CN/iio/iio_configfs.rst +++ b/Documentation/translations/zh_CN/iio/iio_configfs.rst @@ -37,10 +37,10 @@ configfsè½»æ¾é…置的对象（例如：设备，触å‘器）。 3. 软件触å‘器 ============= -IIO默认configfs组之一是“触å‘器â€ç»„。 挂载configfsåŽå¯ä»¥è‡ªåŠ¨è®¿é—®å®ƒï¼Œå¹¶ä¸”å¯ +IIO默认configfs组之一是“触å‘器â€ç»„。挂载configfsåŽå¯ä»¥è‡ªåŠ¨è®¿é—®å®ƒï¼Œå¹¶ä¸”å¯ ä»¥åœ¨/config/iio/triggers下找到。 -IIO软件触å‘器为创建多ç§è§¦å‘器类型æ供了支æŒã€‚ 通常在include/linux/iio +IIO软件触å‘器为创建多ç§è§¦å‘器类型æ供了支æŒã€‚通常在include/linux/iio /sw_trigger.h：ä¸çš„接å£ä¸‹å°†æ–°çš„触å‘器类型实现为å•ç‹¬çš„å†…æ ¸æ¨¡å—： :: @@ -76,10 +76,10 @@ IIO软件触å‘器为创建多ç§è§¦å‘器类型æ供了支æŒã€‚ 通常在incl .ops = &iio_trig_sample_ops, }; -module_iio_sw_trigger_driver(iio_trig_sample); + module_iio_sw_trigger_driver(iio_trig_sample); -æ¯ç§è§¦å‘器类型在/config/iio/triggers下都有其自己的目录。 åŠ è½½iio-trig-sample -模å—将创建“ trig-sampleâ€è§¦å‘器类型目录/config/iio/triggers/trig-sample. +æ¯ç§è§¦å‘器类型在/config/iio/triggersä¸‹éƒ½æœ‰å…¶è‡ªå·±çš„ç›®å½•ã€‚åŠ è½½iio-trig-sample +模å—将创建“trig-sampleâ€è§¦å‘器类型目录/config/iio/triggers/trig-sample. 我们支æŒä»¥ä¸‹ä¸æ–æºï¼ˆè§¦å‘器类型） @@ -102,3 +102,5 @@ module_iio_sw_trigger_driver(iio_trig_sample); ---------------------------- "hrtimerâ€è§¦å‘器类型没有æ¥è‡ª/config dir的任何å¯é…置属性。 +它确实引入了触å‘目录的sampling_frequency属性。 +该属性以Hz为å•ä½è®¾ç½®è½®è¯¢é¢‘率，精度为mHz。
\ No newline at end of file diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index ad7bb8c17562..bf85baca8b3e 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -118,7 +118,7 @@ TODOList: sound/index filesystems/index scheduler/index - vm/index + mm/index peci/index TODOList: diff --git a/Documentation/translations/zh_CN/kernel-hacking/hacking.rst b/Documentation/translations/zh_CN/kernel-hacking/hacking.rst index f2bc154c5bcc..9112949b993c 100644 --- a/Documentation/translations/zh_CN/kernel-hacking/hacking.rst +++ b/Documentation/translations/zh_CN/kernel-hacking/hacking.rst @@ -81,7 +81,7 @@ 过硬件ä¸æ–）的“软件ä¸æ–â€å°†è¿è¡Œï¼ˆ ``kernel/softirq.c`` ）。 æ¤å¤„完æˆäº†è®¸å¤šçœŸæ£çš„ä¸æ–处ç†å·¥ä½œã€‚在å‘SMP过渡的早期，åªæœ‰â€œbottom halvesä¸‹åŠ -部â€ï¼ˆBHsï¼‰æœºåˆ¶ï¼Œæ— æ³•åˆ©ç”¨å¤šä¸ªCPU的优势。在从那些一团糟的就电脑切æ¢è¿‡æ¥åŽä¸ä¹…， +部â€ï¼ˆBHsï¼‰æœºåˆ¶ï¼Œæ— æ³•åˆ©ç”¨å¤šä¸ªCPU的优势。在从那些一团糟的旧电脑切æ¢è¿‡æ¥åŽä¸ä¹…， 我们放弃了这个é™åˆ¶ï¼Œè½¬è€Œä½¿ç”¨â€œè½¯ä¸æ–â€ã€‚ ``include/linux/interrupt.h`` 列出了ä¸åŒçš„软ä¸æ–。定时器软ä¸æ–是一个éžå¸¸é‡è¦ @@ -95,8 +95,7 @@ .. warning:: - “taskletâ€è¿™ä¸ªåå—是误导性的：它们与“任务â€æ— 关，å¯èƒ½æ›´å¤šä¸Žå½“æ—¶ - 阿列克谢·库兹涅ä½å¤«äº«ç”¨çš„糟糕ä¼ç‰¹åŠ 有关。 + “taskletâ€è¿™ä¸ªåå—是误导性的：它们与“任务â€æ— 关。 ä½ å¯ä»¥ä½¿ç”¨ :c:func:`in_softirq()` å®ï¼ˆ ``include/linux/preempt.h`` ）æ¥ç¡®è®¤ 是å¦å¤„于软ä¸æ–（或å任务）ä¸ã€‚ @@ -247,7 +246,7 @@ Provide mechanism not policyâ€ã€‚ 与 :c:func:`put_user()` å’Œ :c:func:`get_user()` ä¸åŒï¼Œå®ƒä»¬è¿”回未å¤åˆ¶çš„ æ•°æ®é‡ï¼ˆå³0ä»ç„¶æ„味ç€æˆåŠŸï¼‰ã€‚ -ã€æ˜¯çš„ï¼Œè¿™ä¸ªæ„šè ¢çš„æŽ¥å£çœŸå¿ƒè®©æˆ‘尴尬。ç«çˆ†çš„å£æ°´ä»—大概æ¯å¹´éƒ½ä¼šå‘生。 +ã€æ˜¯çš„，这个讨厌的接å£çœŸå¿ƒè®©æˆ‘尴尬。ç«çˆ†çš„å£æ°´ä»—大概æ¯å¹´éƒ½ä¼šå‘生。 —— Rusty Russell】 这些函数å¯ä»¥éšå¼ç¡çœ 。它ä¸åº”该在用户上下文之外调用（没有æ„义）ã€è°ƒç”¨æ—¶ç¦ç”¨ä¸æ– @@ -538,9 +537,9 @@ Documentation/core-api/symbol-namespaces.rst 。 Linus和其他开å‘人员有时会更改开å‘å†…æ ¸ä¸çš„函数或结构体åç§°ï¼›è¿™æ ·åšä¸ä»…是为了 让æ¯ä¸ªäººéƒ½ä¿æŒè¦æƒ•ï¼Œè¿˜åæ˜ äº†ä¸€ä¸ªé‡å¤§çš„更改（例如，ä¸èƒ½å†åœ¨æ‰“å¼€ä¸æ–的情况下 -调用，或者执行é¢å¤–的检查，或者ä¸æ‰§è¡Œä»¥å‰æ•èŽ·çš„检查）。通常这会附带一个linux -å†…æ ¸é‚®ä»¶åˆ—è¡¨ä¸ç›¸å½“å…¨é¢çš„注释；请æœç´¢å˜æ¡£ä»¥æŸ¥çœ‹ã€‚简å•åœ°å¯¹æ–‡ä»¶è¿›è¡Œå…¨å±€æ›¿æ¢é€šå¸¸ -会让事情å˜å¾— **更糟** 。 +调用，或者执行é¢å¤–的检查，或者ä¸æ‰§è¡Œä»¥å‰æ•èŽ·çš„检查）。通常这会附带å‘é€ä¸€ä¸ª +相当全é¢çš„æ³¨é‡Šåˆ°ç›¸åº”çš„å†…æ ¸é‚®ä»¶åˆ—è¡¨ä¸ï¼›è¯·æœç´¢å˜æ¡£ä»¥æŸ¥çœ‹ã€‚简å•åœ°å¯¹æ–‡ä»¶è¿›è¡Œå…¨å±€ +替æ¢é€šå¸¸åªä¼šè®©äº‹æƒ…å˜å¾— **更糟** 。 åˆå§‹åŒ–结构体æˆå‘˜ ------------------ @@ -610,7 +609,7 @@ C++ ä¸ºäº†è®©ä½ çš„ä¸œè¥¿æ›´æ£å¼ã€è¡¥ä¸æ›´æ•´æ´ï¼Œè¿˜æœ‰ä¸€äº›å·¥ä½œè¦åšï¼š -- æžæ¸…æ¥šä½ åœ¨è°çš„地界儿上干活。查看æºæ–‡ä»¶çš„顶部〠``MAINTAINERS`` æ–‡ä»¶ä»¥åŠ +- æžæ¸…æ¥šä½ ä¿®æ”¹çš„ä»£ç 属于è°ã€‚查看æºæ–‡ä»¶çš„æ ¹ç›®å½•ã€ ``MAINTAINERS`` æ–‡ä»¶ä»¥åŠ ``CREDITS`` 文件的最åŽä¸€éƒ¨åˆ†ã€‚ä½ åº”è¯¥å’Œæ¤äººå调，确ä¿ä½ 没有é‡æ–°å‘明轮å， 或者å°è¯•ä¸€äº›å·²ç»è¢«æ‹’ç»çš„东西。 @@ -629,12 +628,12 @@ C++ “obj-$(CONFIG_xxx) += xxx.oâ€ã€‚è¯æ³•è®°å½•åœ¨ Documentation/kbuild/makefiles.rst 。 -- å¦‚æžœä½ åšäº†ä¸€äº›æœ‰æ„义的事情，那å¯ä»¥æŠŠè‡ªå·±æ”¾è¿› ``CREDITS`` ，通常ä¸æ¢ä¸€ä¸ª - æ–‡ä»¶ï¼ˆæ— è®ºå¦‚ä½•ä½ çš„åå—都应该在æºæ–‡ä»¶çš„顶部）。维护人员æ„味ç€æ‚¨å¸Œæœ›åœ¨å¯¹ - å系统进行更改时得到询问，并了解缺陷；这æ„味ç€å¯¹æŸéƒ¨åˆ†ä»£ç åšå‡ºæ›´å¤šæ‰¿è¯ºã€‚ +- å¦‚æžœä½ è®¤ä¸ºè‡ªå·±åšäº†ä¸€äº›æœ‰æ„义的事情，å¯ä»¥æŠŠè‡ªå·±æ”¾è¿› ``CREDITS`` ï¼Œé€šå¸¸ä¸ + æ¢ä¸€ä¸ªæ–‡ä»¶ï¼ˆæ— è®ºå¦‚ä½•ä½ çš„åå—都应该在æºæ–‡ä»¶çš„顶部）。 ``MAINTAINERS`` + æ„味ç€æ‚¨å¸Œæœ›åœ¨å¯¹å系统进行更改时得到询问，并了解缺陷；这æ„味ç€å¯¹æŸéƒ¨åˆ† + 代ç åšå‡ºæ›´å¤šæ‰¿è¯ºã€‚ -- 最åŽï¼Œåˆ«å¿˜è®°åŽ»é˜…读 Documentation/process/submitting-patches.rst ， - 也许还有 Documentation/process/submitting-drivers.rst 。 +- 最åŽï¼Œåˆ«å¿˜è®°åŽ»é˜…读 Documentation/process/submitting-patches.rst。 Kernel 仙女棒 =============== diff --git a/Documentation/translations/zh_CN/locking/index.rst b/Documentation/translations/zh_CN/locking/index.rst index 700df8a2bb70..f0b10707668d 100644 --- a/Documentation/translations/zh_CN/locking/index.rst +++ b/Documentation/translations/zh_CN/locking/index.rst @@ -14,17 +14,18 @@ .. toctree:: :maxdepth: 1 + mutex-design + spinlocks + TODOList: * locktypes * lockdep-design * lockstat * locktorture - * mutex-design * rt-mutex-design * rt-mutex * seqlock - * spinlocks * ww-mutex-design * preempt-locking * pi-futex diff --git a/Documentation/translations/zh_CN/locking/mutex-design.rst b/Documentation/translations/zh_CN/locking/mutex-design.rst new file mode 100644 index 000000000000..6aad54372a6c --- /dev/null +++ b/Documentation/translations/zh_CN/locking/mutex-design.rst @@ -0,0 +1,145 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/locking/mutex-design.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +================ +通用互斥é”å系统 +================ + +:åˆç¨¿: + + Ingo Molnar <mingo@redhat.com> + +:æ›´æ–°: + + Davidlohr Bueso <davidlohr@hp.com> + +什么是互斥é”？ +-------------- + +在Linuxå†…æ ¸ä¸ï¼Œäº’æ–¥é”（mutexï¼‰æŒ‡çš„æ˜¯ä¸€ä¸ªç‰¹æ®Šçš„åŠ é”原è¯ï¼Œå®ƒåœ¨å…±äº«å†…å˜ç³»ç»Ÿä¸Š +强制ä¿è¯åºåˆ—化，而ä¸ä»…仅是指在å¦æœ¯ç•Œæˆ–类似的ç†è®ºæ•™ç§‘书ä¸å‡ºçŽ°çš„通用术è¯â€œç›¸äº’ +排斥â€ã€‚互斥é”是一ç§ç¡çœ é”，它的行为类似于二进制信å·é‡ï¼ˆsemaphores），在 +2006年被引入时[1]，作为åŽè€…的替代å“。这ç§æ–°çš„æ•°æ®ç»“æž„æ供了许多优点，包括更 +简å•çš„接å£ï¼Œä»¥åŠåœ¨å½“时更少的代ç é‡ï¼ˆè§ç¼ºé™·ï¼‰ã€‚ + +[1] https://lwn.net/Articles/164802/ + +实现 +---- + +互斥é”由“struct mutexâ€è¡¨ç¤ºï¼Œåœ¨include/linux/mutex.hä¸å®šä¹‰ï¼Œå¹¶åœ¨ +kernel/locking/mutex.cä¸å®žçŽ°ã€‚这些é”使用一个原åå˜é‡ï¼ˆ->owner）æ¥è·Ÿè¸ª +它们生命周期内的é”状æ€ã€‚å—段owner实际上包å«çš„是指å‘当å‰é”所有者的 +`struct task_struct *` æŒ‡é’ˆï¼Œå› æ¤å¦‚æžœæ— äººæŒæœ‰é”，则它的值为空（NULL）。 +由于task_struct的指针至少按L1_CACHE_BYTES对é½ï¼Œä½Žä½ï¼ˆ3）被用æ¥å˜å‚¨é¢å¤– +的状æ€ï¼ˆä¾‹å¦‚，ç‰å¾…者列表éžç©ºï¼‰ã€‚在其最基本的形å¼ä¸ï¼Œå®ƒè¿˜åŒ…括一个ç‰å¾…队列和 +一个确ä¿å¯¹å…¶åºåˆ—化访问的自旋é”。æ¤å¤–，CONFIG_MUTEX_SPIN_ON_OWNER=yçš„ +系统使用一个自旋MCSé”（->osq，译注：MCS是两个人åçš„åˆå¹¶ç¼©å†™ï¼‰ï¼Œåœ¨ä¸‹æ–‡çš„ +（ii）ä¸æ述。 + +准备获得一把自旋é”时，有三ç§å¯èƒ½ç»è¿‡çš„路径，å–决于é”的状æ€ï¼š + +(i) 快速路径：试图通过调用cmpxchg()修改é”的所有者为当å‰ä»»åŠ¡ï¼Œä»¥æ¤åŽŸå化地 + 获å–é”。这åªåœ¨æ— 竞争的情况下有效（cmpxchg()检查值是å¦ä¸º0，所以3ä¸ªçŠ¶æ€ + 比特必须为0）。如果é”处在竞争状æ€ï¼Œä»£ç 进入下一个å¯èƒ½çš„路径。 + +(ii) ä¸é€Ÿè·¯å¾„：也就是ä¹è§‚自旋，当é”的所有者æ£åœ¨è¿è¡Œå¹¶ä¸”没有其它优先级更高的 + 任务（need_resched，需è¦é‡æ–°è°ƒåº¦ï¼‰å‡†å¤‡è¿è¡Œæ—¶ï¼Œå½“å‰ä»»åŠ¡è¯•å›¾è‡ªæ—‹æ¥èŽ·å¾— + é”。原ç†æ˜¯ï¼Œå¦‚æžœé”的所有者æ£åœ¨è¿è¡Œï¼Œå®ƒå¾ˆå¯èƒ½ä¸ä¹…就会释放é”。互斥é”自旋体 + 使用MCSé”æŽ’é˜Ÿï¼Œè¿™æ ·åªæœ‰ä¸€ä¸ªè‡ªæ—‹ä½“å¯ä»¥ç«žäº‰äº’æ–¥é”。 + + MCSé”（由Mellor-Crummeyå’ŒScottæ出）是一个简å•çš„自旋é”，它具有一些 + ç†æƒ³çš„特性，比如公平，以åŠæ¯ä¸ªCPU在试图获得é”时在一个本地å˜é‡ä¸Šè‡ªæ—‹ã€‚ + 它é¿å…了常è§çš„“检测-设置â€è‡ªæ—‹é”实现导致的（CPUæ ¸é—´ï¼‰ç¼“å˜è¡Œå›žå¼¹ + （cacheline bouncing）这ç§æ˜‚贵的开销。一个类MCSé”是为实现ç¡çœ é”çš„ + ä¹è§‚自旋而专门定制的。这ç§å®šåˆ¶MCSé”的一个é‡è¦ç‰¹æ€§æ˜¯ï¼Œå®ƒæœ‰ä¸€ä¸ªé¢å¤–的属性， + 当自旋体需è¦é‡æ–°è°ƒåº¦æ—¶ï¼Œå®ƒä»¬èƒ½å¤Ÿé€€å‡ºMCS自旋é”队列。这进一æ¥æœ‰åŠ©äºŽé¿å… + 以下场景：需è¦é‡æ–°è°ƒåº¦çš„MCS自旋体将继ç»è‡ªæ—‹ç‰å¾…自旋体所有者，å³å°†èŽ·å¾— + MCSé”æ—¶å´ç›´æŽ¥è¿›å…¥æ…¢é€Ÿè·¯å¾„。 + +(iii) 慢速路径：最åŽçš„手段，如果ä»ç„¶æ— 法获得é”ï¼Œè¯¥ä»»åŠ¡ä¼šè¢«æ·»åŠ åˆ°ç‰å¾…队列ä¸ï¼Œ + ä¼‘çœ ç›´åˆ°è¢«è§£é”路径唤醒。在通常情况下，它以TASK_UNINTERRUPTIBLEçŠ¶æ€ + 阻塞。 + +虽然从形å¼ä¸Šçœ‹ï¼Œå†…æ ¸äº’æ–¥é”是å¯ç¡çœ çš„é”，路径(ii)使它实际上æˆä¸ºæ··åˆç±»åž‹ã€‚通过 +简å•åœ°ä¸ä¸æ–一个任务并忙ç€ç‰å¾…å‡ ä¸ªå‘¨æœŸï¼Œè€Œä¸æ˜¯ç«‹å³ç¡çœ ，这ç§é”å·²ç»è¢«è®¤ä¸ºæ˜¾è‘— +改善一些工作负载的性能。注æ„，这ç§æŠ€æœ¯ä¹Ÿè¢«ç”¨äºŽè¯»å†™ä¿¡å·é‡ï¼ˆrw-semaphores）。 + +è¯ä¹‰ +---- + +互斥é”å系统检查并强制执行以下规则: + + - æ¯æ¬¡åªæœ‰ä¸€ä¸ªä»»åŠ¡å¯ä»¥æŒæœ‰è¯¥äº’æ–¥é”。 + - åªæœ‰é”的所有者å¯ä»¥è§£é”该互斥é”。 + - ä¸å…许多次解é”。 + - ä¸å…è®¸é€’å½’åŠ é”/解é”。 + - 互斥é”åªèƒ½é€šè¿‡API进行åˆå§‹åŒ–（è§ä¸‹æ–‡ï¼‰ã€‚ + - 一个任务ä¸èƒ½åœ¨æŒæœ‰äº’æ–¥é”的情况下退出。 + - æŒæœ‰é”的内å˜åŒºåŸŸä¸å¾—被释放。 + - 被æŒæœ‰çš„é”ä¸èƒ½è¢«é‡æ–°åˆå§‹åŒ–。 + - 互斥é”ä¸èƒ½ç”¨äºŽç¡¬ä»¶æˆ–软件ä¸æ–上下文，如å°ä»»åŠ¡ï¼ˆtasklet）和定时器。 + +当CONFIG DEBUG_MUTEXES被å¯ç”¨æ—¶ï¼Œè¿™äº›è¯ä¹‰å°†è¢«å®Œå…¨å¼ºåˆ¶æ‰§è¡Œã€‚æ¤å¤–ï¼Œäº’æ–¥é” +调试代ç 还实现了一些其它特性，使é”的调试更容易ã€æ›´å¿«é€Ÿï¼š + + - 当打å°åˆ°è°ƒè¯•è¾“出时，总是使用互斥é”的符å·å称。 + - åŠ é”点跟踪，函数å符å·åŒ–查找，系统æŒæœ‰çš„全部é”的列表，打å°å‡ºå®ƒä»¬ã€‚ + - 所有者跟踪。 + - 检测自我递归的é”并打å°æ‰€æœ‰ç›¸å…³ä¿¡æ¯ã€‚ + - 检测多任务环形ä¾èµ–æ»é”，并打å°æ‰€æœ‰å—å½±å“çš„é”和任务（并且åªé™äºŽè¿™äº›ä»»åŠ¡ï¼‰ã€‚ + + +æŽ¥å£ +---- +é™æ€å®šä¹‰äº’æ–¥é”:: + + DEFINE_MUTEX(name); + +动æ€åˆå§‹åŒ–互斥é”:: + + mutex_init(mutex); + +以ä¸å¯ä¸æ–æ–¹å¼ï¼ˆuninterruptible）获å–互斥é”:: + + void mutex_lock(struct mutex *lock); + void mutex_lock_nested(struct mutex *lock, unsigned int subclass); + int mutex_trylock(struct mutex *lock); + +以å¯ä¸æ–æ–¹å¼ï¼ˆinterruptible）获å–互斥é”:: + + int mutex_lock_interruptible_nested(struct mutex *lock, + unsigned int subclass); + int mutex_lock_interruptible(struct mutex *lock); + +当原åå˜é‡å‡ä¸º0时，以å¯ä¸æ–æ–¹å¼ï¼ˆinterruptible）获å–互斥é”:: + + int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); + +释放互斥é”:: + + void mutex_unlock(struct mutex *lock); + +检测是å¦å·²ç»èŽ·å–互斥é”:: + + int mutex_is_locked(struct mutex *lock); + +缺陷 +---- + +与它最åˆçš„设计和目的ä¸åŒï¼Œ'struct mutex' æ˜¯å†…æ ¸ä¸æœ€å¤§çš„é”之一。例如：在 +x86-64上它是32å—节，而 'struct semaphore' 是24å—节，rw_semaphore是 +40å—节。更大的结构体大å°æ„味ç€æ›´å¤šçš„CPU缓å˜å’Œå†…å˜å 用。 + + +ä½•æ—¶ä½¿ç”¨äº’æ–¥é” +-------------- + +总是优先选择互斥é”而ä¸æ˜¯ä»»ä½•å…¶å®ƒé”原è¯ï¼Œé™¤éžäº’æ–¥é”çš„ä¸¥æ ¼è¯ä¹‰ä¸åˆé€‚，和/或临界区 +阻æ¢é”被共享。 diff --git a/Documentation/translations/zh_CN/loongarch/introduction.rst b/Documentation/translations/zh_CN/loongarch/introduction.rst index 11686ee0caeb..128878f5bb70 100644 --- a/Documentation/translations/zh_CN/loongarch/introduction.rst +++ b/Documentation/translations/zh_CN/loongarch/introduction.rst @@ -190,8 +190,8 @@ I26 Opcode + I26L + I26H =========== ========================== Opcode是指令æ“作ç ，Rjå’ŒRk是æºæ“作数（寄å˜å™¨ï¼‰ï¼ŒRdæ˜¯ç›®æ ‡æ“作数（寄å˜å™¨ï¼‰ï¼ŒRa是 -4R-typeæ ¼å¼ç‰¹æœ‰çš„é™„åŠ æ“作数（寄å˜å™¨ï¼‰ã€‚I8/I12/I16/I21/I26分别是8ä½/12ä½/16ä½/ -21ä½/26ä½çš„ç«‹å³æ•°ã€‚å…¶ä¸è¾ƒé•¿çš„21ä½å’Œ26ä½ç«‹å³æ•°åœ¨æŒ‡ä»¤å—ä¸è¢«åˆ†å‰²ä¸ºé«˜ä½éƒ¨åˆ†ä¸Žä½Žä½ +4R-typeæ ¼å¼ç‰¹æœ‰çš„é™„åŠ æ“作数（寄å˜å™¨ï¼‰ã€‚I8/I12/I14/I16/I21/I26分别是8ä½/12ä½/14ä½/ +16ä½/21ä½/26ä½çš„ç«‹å³æ•°ã€‚å…¶ä¸è¾ƒé•¿çš„21ä½å’Œ26ä½ç«‹å³æ•°åœ¨æŒ‡ä»¤å—ä¸è¢«åˆ†å‰²ä¸ºé«˜ä½éƒ¨åˆ†ä¸Žä½Žä½ éƒ¨åˆ†ï¼Œæ‰€ä»¥ä½ ä»¬åœ¨è¿™é‡Œçš„æ ¼å¼æè¿°ä¸èƒ½å¤Ÿçœ‹åˆ°I21L/I21Hå’ŒI26L/I26Hè¿™æ ·å¸¦åŽç¼€çš„表述。 指令列表 diff --git a/Documentation/translations/zh_CN/vm/active_mm.rst b/Documentation/translations/zh_CN/mm/active_mm.rst index 366609ea4f37..c2816f523bd7 100644 --- a/Documentation/translations/zh_CN/vm/active_mm.rst +++ b/Documentation/translations/zh_CN/mm/active_mm.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/vm/active_mm.rst +:Original: Documentation/mm/active_mm.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/balance.rst b/Documentation/translations/zh_CN/mm/balance.rst index e98a47ef24a8..6fd79209c307 100644 --- a/Documentation/translations/zh_CN/vm/balance.rst +++ b/Documentation/translations/zh_CN/mm/balance.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/vm/balance.rst +:Original: Documentation/mm/balance.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/damon/api.rst b/Documentation/translations/zh_CN/mm/damon/api.rst index 21143eea4ebe..5593a83c86bc 100644 --- a/Documentation/translations/zh_CN/vm/damon/api.rst +++ b/Documentation/translations/zh_CN/mm/damon/api.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -:Original: Documentation/vm/damon/api.rst +:Original: Documentation/mm/damon/api.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/damon/design.rst b/Documentation/translations/zh_CN/mm/damon/design.rst index 46128b77c2b3..16e3db34a7dd 100644 --- a/Documentation/translations/zh_CN/vm/damon/design.rst +++ b/Documentation/translations/zh_CN/mm/damon/design.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -:Original: Documentation/vm/damon/design.rst +:Original: Documentation/mm/damon/design.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/damon/faq.rst b/Documentation/translations/zh_CN/mm/damon/faq.rst index 07b4ac19407d..de4be417494a 100644 --- a/Documentation/translations/zh_CN/vm/damon/faq.rst +++ b/Documentation/translations/zh_CN/mm/damon/faq.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -:Original: Documentation/vm/damon/faq.rst +:Original: Documentation/mm/damon/faq.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/damon/index.rst b/Documentation/translations/zh_CN/mm/damon/index.rst index 84d36d90c9b0..b03bf307204f 100644 --- a/Documentation/translations/zh_CN/vm/damon/index.rst +++ b/Documentation/translations/zh_CN/mm/damon/index.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -:Original: Documentation/vm/damon/index.rst +:Original: Documentation/mm/damon/index.rst :翻译: @@ -14,7 +14,7 @@ DAMON:æ•°æ®è®¿é—®ç›‘视器 ========================== DAMON是Linuxå†…æ ¸çš„ä¸€ä¸ªæ•°æ®è®¿é—®ç›‘控框架å系统。DAMONçš„æ ¸å¿ƒæœºåˆ¶ä½¿å…¶æˆä¸º -ï¼ˆè¯¥æ ¸å¿ƒæœºåˆ¶è¯¦è§(Documentation/translations/zh_CN/vm/damon/design.rst)） +ï¼ˆè¯¥æ ¸å¿ƒæœºåˆ¶è¯¦è§(Documentation/translations/zh_CN/mm/damon/design.rst)） - *准确度* （监测输出对DRAM级别的内å˜ç®¡ç†è¶³å¤Ÿæœ‰ç”¨ï¼›ä½†å¯èƒ½ä¸é€‚åˆCPU Cache级别）， - *è½»é‡çº§* （监控开销低到å¯ä»¥åœ¨çº¿åº”ç”¨ï¼‰ï¼Œä»¥åŠ @@ -30,4 +30,3 @@ DAMON是Linuxå†…æ ¸çš„ä¸€ä¸ªæ•°æ®è®¿é—®ç›‘控框架å系统。DAMONçš„æ ¸å¿ƒæœ faq design api - diff --git a/Documentation/translations/zh_CN/vm/free_page_reporting.rst b/Documentation/translations/zh_CN/mm/free_page_reporting.rst index 31d6c34b956b..5bfd58014c94 100644 --- a/Documentation/translations/zh_CN/vm/free_page_reporting.rst +++ b/Documentation/translations/zh_CN/mm/free_page_reporting.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/vm/_free_page_reporting.rst +:Original: Documentation/mm/free_page_reporting.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/frontswap.rst b/Documentation/translations/zh_CN/mm/frontswap.rst index 3eb07870e2ef..434975390b48 100644 --- a/Documentation/translations/zh_CN/vm/frontswap.rst +++ b/Documentation/translations/zh_CN/mm/frontswap.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/_free_page_reporting.rst +:Original: Documentation/mm/frontswap.rst :翻译: diff --git a/Documentation/translations/zh_CN/mm/highmem.rst b/Documentation/translations/zh_CN/mm/highmem.rst new file mode 100644 index 000000000000..f74800a6d9a7 --- /dev/null +++ b/Documentation/translations/zh_CN/mm/highmem.rst @@ -0,0 +1,137 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/mm/highmem.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +========== +高内å˜å¤„ç† +========== + +作者: Peter Zijlstra <a.p.zijlstra@chello.nl> + +.. contents:: :local: + +高内å˜æ˜¯ä»€ä¹ˆï¼Ÿ +============== + +当物ç†å†…å˜çš„大å°æŽ¥è¿‘或超过虚拟内å˜çš„最大大å°æ—¶ï¼Œå°±ä¼šä½¿ç”¨é«˜å†…å˜ï¼ˆhighmem）。在这一点上，内 +æ ¸ä¸å¯èƒ½åœ¨ä»»ä½•æ—¶å€™éƒ½ä¿æŒæ‰€æœ‰å¯ç”¨çš„物ç†å†…å˜çš„æ˜ å°„ã€‚è¿™æ„味ç€å†…æ ¸éœ€è¦å¼€å§‹ä½¿ç”¨å®ƒæƒ³è®¿é—®çš„物ç†å†… +å˜çš„ä¸´æ—¶æ˜ å°„ã€‚ + +æ²¡æœ‰è¢«æ°¸ä¹…æ˜ å°„è¦†ç›–çš„é‚£éƒ¨åˆ†ï¼ˆç‰©ç†ï¼‰å†…å˜å°±æ˜¯æˆ‘们所说的 "高内å˜"。对于这个边界的确切ä½ç½®ï¼Œæœ‰ +å„ç§æž¶æž„上的é™åˆ¶ã€‚ + +例如，在i386架构ä¸ï¼Œæˆ‘ä»¬é€‰æ‹©å°†å†…æ ¸æ˜ å°„åˆ°æ¯ä¸ªè¿›ç¨‹çš„è™šæ‹Ÿç©ºé—´ï¼Œè¿™æ ·æˆ‘ä»¬å°±ä¸å¿…ä¸ºå†…æ ¸çš„è¿›å…¥/退 +出付出全部的TLB作废代价。这æ„味ç€å¯ç”¨çš„虚拟内å˜ç©ºé—´ï¼ˆi386上为4GiBï¼‰å¿…é¡»åœ¨ç”¨æˆ·å’Œå†…æ ¸ç©ºé—´ä¹‹ +间进行划分。 + +使用这ç§æ–¹æ³•çš„æž¶æž„çš„ä¼ ç»Ÿåˆ†é…æ–¹å¼æ˜¯3:1，3GiB用于用户空间，顶部的1GiBç”¨äºŽå†…æ ¸ç©ºé—´ã€‚:: + + +--------+ 0xffffffff + | Kernel | + +--------+ 0xc0000000 + | | + | User | + | | + +--------+ 0x00000000 + +è¿™æ„味ç€å†…æ ¸åœ¨ä»»ä½•æ—¶å€™æœ€å¤šå¯ä»¥æ˜ å°„1GiB的物ç†å†…å˜ï¼Œä½†æ˜¯ç”±äºŽæˆ‘们需è¦è™šæ‹Ÿåœ°å€ç©ºé—´æ¥åšå…¶ä»–事 +情--包括访问其余物ç†å†…å˜çš„ä¸´æ—¶æ˜ å°„--å®žé™…çš„ç›´æŽ¥æ˜ å°„é€šå¸¸ä¼šæ›´å°‘ï¼ˆé€šå¸¸åœ¨~896MiBå·¦å³ï¼‰ã€‚ + +其他有mmä¸Šä¸‹æ–‡æ ‡ç¾çš„TLB的架构å¯ä»¥æœ‰ç‹¬ç«‹çš„å†…æ ¸å’Œç”¨æˆ·æ˜ å°„ã€‚ç„¶è€Œï¼Œä¸€äº›ç¡¬ä»¶ï¼ˆå¦‚ä¸€äº›ARM）在使 +用mmä¸Šä¸‹æ–‡æ ‡ç¾æ—¶ï¼Œå…¶è™šæ‹Ÿç©ºé—´æœ‰é™ã€‚ + + +ä¸´æ—¶è™šæ‹Ÿæ˜ å°„ +============ + +å†…æ ¸åŒ…å«å‡ ç§åˆ›å»ºä¸´æ—¶æ˜ 射的方法。下é¢çš„列表按照使用的优先顺åºæ˜¾ç¤ºäº†å®ƒä»¬ã€‚ + +* kmap_local_page()。这个函数是用æ¥è¦æ±‚çŸæœŸæ˜ 射的。它å¯ä»¥ä»Žä»»ä½•ä¸Šä¸‹æ–‡ï¼ˆåŒ…括ä¸æ–）ä¸è°ƒç”¨ï¼Œ + ä½†æ˜¯æ˜ å°„åªèƒ½åœ¨èŽ·å–它们的上下文ä¸ä½¿ç”¨ã€‚ + + 在å¯è¡Œçš„情况下，这个函数应该比其他所有的函数优先使用。 + + è¿™äº›æ˜ å°„æ˜¯çº¿ç¨‹æœ¬åœ°å’ŒCPU本地的，这æ„味ç€æ˜ å°„åªèƒ½ä»Žè¿™ä¸ªçº¿ç¨‹ä¸è®¿é—®ï¼Œå¹¶ä¸”å½“æ˜ å°„å¤„äºŽæ´»åŠ¨çŠ¶ + æ€æ—¶ï¼Œè¯¥çº¿ç¨‹ä¸ŽCPU绑定。å³ä½¿çº¿ç¨‹è¢«æŠ¢å äº†ï¼ˆå› ä¸ºæŠ¢å 永远ä¸ä¼šè¢«å‡½æ•°ç¦ç”¨ï¼‰ï¼ŒCPU也ä¸èƒ½é€šè¿‡ + CPU-hotplug从系统ä¸æ‹”å‡ºï¼Œç›´åˆ°æ˜ å°„è¢«å¤„ç†æŽ‰ã€‚ + + 在本地的kmap区域ä¸é‡‡å–pagefaults是有效的，除éžèŽ·å–æœ¬åœ°æ˜ å°„çš„ä¸Šä¸‹æ–‡ç”±äºŽå…¶ä»–åŽŸå› ä¸å…许 + è¿™æ ·åšã€‚ + + kmap_local_page()总是返回一个有效的虚拟地å€ï¼Œå¹¶ä¸”å‡å®škunmap_local()ä¸ä¼šå¤±è´¥ã€‚ + + 嵌套kmap_local_page()å’Œkmap_atomic()æ˜ å°„åœ¨ä¸€å®šç¨‹åº¦ä¸Šæ˜¯å…许的（最多到KMAP_TYPE_NR）， + ä½†æ˜¯å®ƒä»¬çš„è°ƒç”¨å¿…é¡»ä¸¥æ ¼æŽ’åºï¼Œå› ä¸ºæ˜ å°„çš„å®žçŽ°æ˜¯åŸºäºŽå †æ ˆçš„ã€‚å…³äºŽå¦‚ä½•ç®¡ç†åµŒå¥—æ˜ å°„çš„ç»†èŠ‚ï¼Œ + 请å‚è§kmap_local_page() kdocs（包å«åœ¨ "函数 "部分）。 + +* kmap_atomic(). è¿™å…许对å•ä¸ªé¡µé¢è¿›è¡Œéžå¸¸çŸçš„æ—¶é—´æ˜ å°„ã€‚ç”±äºŽæ˜ å°„è¢«é™åˆ¶åœ¨å‘布它的CPU上， + 它表现得很好，但å‘å¸ƒçš„ä»»åŠ¡å› æ¤è¢«è¦æ±‚留在该CPU上直到它完æˆï¼Œä»¥å…其他任务å–ä»£å®ƒçš„æ˜ å°„ã€‚ + + kmap_atomic()也å¯ä»¥è¢«ä¸æ–ä¸Šä¸‹æ–‡ä½¿ç”¨ï¼Œå› ä¸ºå®ƒä¸ç¡çœ ，调用者也å¯èƒ½åœ¨è°ƒç”¨kunmap_atomic() + åŽæ‰ç¡çœ 。 + + å†…æ ¸ä¸å¯¹kmap_atomic()çš„æ¯æ¬¡è°ƒç”¨éƒ½ä¼šåˆ›å»ºä¸€ä¸ªä¸å¯æŠ¢å 的段，并ç¦ç”¨ç¼ºé¡µå¼‚常。这å¯èƒ½æ˜¯ + 未预期延迟的æ¥æºä¹‹ä¸€ã€‚å› æ¤ç”¨æˆ·åº”该选择kmap_local_page()而ä¸æ˜¯kmap_atomic()。 + + å‡è®¾k[un]map_atomic()ä¸ä¼šå¤±è´¥ã€‚ + +* kmap()。这应该被用æ¥å¯¹å•ä¸ªé¡µé¢è¿›è¡ŒçŸæ—¶é—´çš„æ˜ å°„ï¼Œå¯¹æŠ¢å 或è¿ç§»æ²¡æœ‰é™åˆ¶ã€‚它会带æ¥å¼€é”€ï¼Œ + å› ä¸ºæ˜ å°„ç©ºé—´æ˜¯å—é™åˆ¶çš„，并且å—到全局é”çš„ä¿æŠ¤ï¼Œä»¥å®žçŽ°åŒæ¥ã€‚当ä¸å†éœ€è¦æ˜ 射时，必须用 + kunmap()é‡Šæ”¾è¯¥é¡µè¢«æ˜ å°„çš„åœ°å€ã€‚ + + æ˜ å°„å˜åŒ–必须广æ’到所有CPUï¼ˆæ ¸ï¼‰ä¸Šï¼Œkmap()还需è¦åœ¨kmapçš„æ± è¢«å›žç»•ï¼ˆTLB项用光了，需è¦ä»Žç¬¬ + 一项å¤ç”¨ï¼‰æ—¶è¿›è¡Œå…¨å±€TLBæ— æ•ˆåŒ–ï¼Œå½“æ˜ å°„ç©ºé—´è¢«å®Œå…¨åˆ©ç”¨æ—¶ï¼Œå®ƒå¯èƒ½ä¼šé˜»å¡žï¼Œç›´åˆ°æœ‰ä¸€ä¸ªå¯ç”¨çš„ + æ§½å‡ºçŽ°ã€‚å› æ¤ï¼Œkmap()åªèƒ½ä»Žå¯æŠ¢å 的上下文ä¸è°ƒç”¨ã€‚ + + å¦‚æžœä¸€ä¸ªæ˜ å°„å¿…é¡»æŒç»ç›¸å¯¹è¾ƒé•¿çš„时间，上述所有的工作都是必è¦çš„ï¼Œä½†æ˜¯å†…æ ¸ä¸å¤§éƒ¨åˆ†çš„ + 高内å˜æ˜ 射都是çŸæš‚的，而且åªåœ¨ä¸€ä¸ªåœ°æ–¹ä½¿ç”¨ã€‚è¿™æ„味ç€åœ¨è¿™ç§æƒ…况下，kmap()çš„æˆæœ¬å¤§ + 多被浪费了。kmap()并ä¸æ˜¯ä¸ºé•¿æœŸæ˜ 射而设计的，但是它已ç»æœç€è¿™ä¸ªæ–¹å‘å‘展了，在较新 + 的代ç ä¸å¼ºçƒˆä¸é¼“励使用它，å‰é¢çš„函数集应该是首选。 + + 在64ä½ç³»ç»Ÿä¸ï¼Œè°ƒç”¨kmap_local_page()ã€kmap_atomic()å’Œkmap()æ²¡æœ‰å®žé™…ä½œç”¨ï¼Œå› ä¸º64ä½ + 地å€ç©ºé—´è¶³ä»¥æ°¸ä¹…æ˜ å°„æ‰€æœ‰ç‰©ç†å†…å˜é¡µé¢ã€‚ + +* vmap()。这å¯ä»¥ç”¨æ¥å°†å¤šä¸ªç‰©ç†é¡µé•¿æœŸæ˜ 射到一个连ç»çš„虚拟空间。它需è¦å…¨å±€åŒæ¥æ¥è§£é™¤ + æ˜ å°„ã€‚ + +ä¸´æ—¶æ˜ å°„çš„æˆæœ¬ +============== + +åˆ›å»ºä¸´æ—¶æ˜ å°„çš„ä»£ä»·å¯èƒ½ç›¸å½“高。体系架构必须æ“ä½œå†…æ ¸çš„é¡µè¡¨ã€æ•°æ®TLBå’Œ/或MMU的寄å˜å™¨ã€‚ + +如果CONFIG_HIGHMEMæ²¡æœ‰è¢«è®¾ç½®ï¼Œé‚£ä¹ˆå†…æ ¸ä¼šå°è¯•ç”¨ä¸€ç‚¹è®¡ç®—æ¥åˆ›å»ºæ˜ 射，将页é¢ç»“构地å€è½¬æ¢æˆ +指å‘页é¢å†…容的指针，而ä¸æ˜¯åŽ»æ£é¼“æ˜ å°„ã€‚åœ¨è¿™ç§æƒ…å†µä¸‹ï¼Œè§£æ˜ å°„æ“作å¯èƒ½æ˜¯ä¸€ä¸ªç©ºæ“作。 + +如果CONFIG_MMU没有被设置，那么就ä¸å¯èƒ½æœ‰ä¸´æ—¶æ˜ 射和高内å˜ã€‚在这ç§æƒ…况下，也将使用计算方法。 + + +i386 PAE +======== + +在æŸäº›æƒ…况下，i386 架构将å…è®¸ä½ åœ¨ 32 ä½æœºå™¨ä¸Šå®‰è£…多达 64GiB 的内å˜ã€‚但这有一些åŽæžœ: + +* Linux需è¦ä¸ºç³»ç»Ÿä¸çš„æ¯ä¸ªé¡µé¢å»ºç«‹ä¸€ä¸ªé¡µå¸§ç»“构，而且页帧需è¦é©»åœ¨æ°¸ä¹…æ˜ å°„ä¸ï¼Œè¿™æ„味ç€ï¼š + +* ä½ æœ€å¤šå¯ä»¥æœ‰896M/sizeof(struct page)页帧；由于页结构体是32å—节的，所以最终会有 + 112Gçš„é¡µï¼›ç„¶è€Œï¼Œå†…æ ¸éœ€è¦åœ¨å†…å˜ä¸å˜å‚¨æ›´å¤šçš„页帧...... + +* PAEä½¿ä½ çš„é¡µè¡¨å˜å¤§--这使系统å˜æ…¢ï¼Œå› 为更多的数æ®éœ€è¦åœ¨TLBå¡«å……ç‰æ–¹é¢è¢«è®¿é—®ã€‚一个好处 + 是，PAE有更多的PTEä½ï¼Œå¯ä»¥æä¾›åƒNXå’ŒPATè¿™æ ·çš„é«˜çº§åŠŸèƒ½ã€‚ + +ä¸€èˆ¬çš„å»ºè®®æ˜¯ï¼Œä½ ä¸è¦åœ¨32ä½æœºå™¨ä¸Šä½¿ç”¨è¶…过8GiB的空间--尽管更多的空间å¯èƒ½å¯¹ä½ å’Œä½ çš„å·¥ä½œ +é‡æœ‰ç”¨ï¼Œä½†ä½ å‡ ä¹Žæ˜¯é ä½ è‡ªå·±--ä¸è¦æŒ‡æœ›å†…æ ¸å¼€å‘者真的会很关心事情的进展情况。 + +函数 +==== + +该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: + +include/linux/highmem.h + +include/linux/highmem-internal.h diff --git a/Documentation/translations/zh_CN/vm/hmm.rst b/Documentation/translations/zh_CN/mm/hmm.rst index 2379df95aa58..5024a8a15516 100644 --- a/Documentation/translations/zh_CN/vm/hmm.rst +++ b/Documentation/translations/zh_CN/mm/hmm.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/vm/hmm.rst +:Original: Documentation/mm/hmm.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/hugetlbfs_reserv.rst b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst index c6d471ce2131..752e5696cd47 100644 --- a/Documentation/translations/zh_CN/vm/hugetlbfs_reserv.rst +++ b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/vm/hugetlbfs_reserv.rst +:Original: Documentation/mm/hugetlbfs_reserv.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/hwpoison.rst b/Documentation/translations/zh_CN/mm/hwpoison.rst index c6e1e7bdb05b..310862edc937 100644 --- a/Documentation/translations/zh_CN/vm/hwpoison.rst +++ b/Documentation/translations/zh_CN/mm/hwpoison.rst @@ -1,5 +1,5 @@ -:Original: Documentation/vm/hwpoison.rst +:Original: Documentation/mm/hwpoison.rst :翻译: diff --git a/Documentation/translations/zh_CN/mm/index.rst b/Documentation/translations/zh_CN/mm/index.rst new file mode 100644 index 000000000000..2f53e37b8049 --- /dev/null +++ b/Documentation/translations/zh_CN/mm/index.rst @@ -0,0 +1,69 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/mm/index.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +================= +Linux内å˜ç®¡ç†æ–‡æ¡£ +================= + +这是一份关于了解Linux的内å˜ç®¡ç†å系统的指å—ã€‚å¦‚æžœä½ æ£åœ¨å¯»æ‰¾å…³äºŽç®€å•åˆ†é…内å˜çš„ +建议，请å‚阅内å˜åˆ†é…æŒ‡å— +(Documentation/translations/zh_CN/core-api/memory-allocation.rst)。 +关于控制和调整的指å—，请看管ç†æŒ‡å— +(Documentation/translations/zh_CN/admin-guide/mm/index.rst)。 + + +.. toctree:: + :maxdepth: 1 + + highmem + +该处剩余文档待原始文档有内容åŽç¿»è¯‘。 + + +é—留文档 +======== + +这是一个关于Linux内å˜ç®¡ç†ï¼ˆMM）å系统内部的旧文档的集åˆï¼Œå…¶ä¸æœ‰ä¸åŒå±‚次的细节， +包括注释和邮件列表的回å¤ï¼Œç”¨äºŽé˜è¿°æ•°æ®ç»“构和算法的æ述。它应该被很好地整åˆåˆ°ä¸Šè¿° +结构化的文档ä¸ï¼Œå¦‚果它已ç»å®Œæˆäº†å®ƒçš„使命，å¯ä»¥åˆ 除。 + +.. toctree:: + :maxdepth: 1 + + active_mm + balance + damon/index + free_page_reporting + ksm + frontswap + hmm + hwpoison + hugetlbfs_reserv + memory-model + mmu_notifier + numa + overcommit-accounting + page_frags + page_migration + page_owner + page_table_check + remap_file_pages + split_page_table_lock + vmalloced-kernel-stacks + z3fold + zsmalloc + +TODOLIST: +* arch_pgtable_helpers +* free_page_reporting +* hugetlbfs_reserv +* slub +* transhuge +* unevictable-lru diff --git a/Documentation/translations/zh_CN/vm/ksm.rst b/Documentation/translations/zh_CN/mm/ksm.rst index 83b0c73984da..d1f82e857ad7 100644 --- a/Documentation/translations/zh_CN/vm/ksm.rst +++ b/Documentation/translations/zh_CN/mm/ksm.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/vm/ksm.rst +:Original: Documentation/mm/ksm.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/memory-model.rst b/Documentation/translations/zh_CN/mm/memory-model.rst index 013e30c88d72..77ec149a970c 100644 --- a/Documentation/translations/zh_CN/vm/memory-model.rst +++ b/Documentation/translations/zh_CN/mm/memory-model.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -:Original: Documentation/vm/memory-model.rst +:Original: Documentation/mm/memory-model.rst :翻译: @@ -129,7 +129,7 @@ ZONE_DEVICE * pmem: 通过DAXæ˜ å°„å°†å¹³å°æŒä¹…性内å˜ä½œä¸ºç›´æŽ¥I/Oç›®æ ‡ä½¿ç”¨ã€‚ * hmm: 用 `->page_fault()` å’Œ `->page_free()` 事件回调扩展 `ZONE_DEVICE` ， - 以å…许设备驱动程åºå调与设备内å˜ç›¸å…³çš„内å˜ç®¡ç†äº‹ä»¶ï¼Œé€šå¸¸æ˜¯GPU内å˜ã€‚å‚è§/vm/hmm.rst。 + 以å…许设备驱动程åºå调与设备内å˜ç›¸å…³çš„内å˜ç®¡ç†äº‹ä»¶ï¼Œé€šå¸¸æ˜¯GPU内å˜ã€‚å‚è§Documentation/mm/hmm.rst。 * p2pdma: 创建 `struct page` 对象，å…许PCI/E拓扑结构ä¸çš„peer设备å调它们之间的 直接DMAæ“作，å³ç»•è¿‡ä¸»æœºå†…å˜ã€‚ diff --git a/Documentation/translations/zh_CN/vm/mmu_notifier.rst b/Documentation/translations/zh_CN/mm/mmu_notifier.rst index b29a37b33628..ce3664d1a410 100644 --- a/Documentation/translations/zh_CN/vm/mmu_notifier.rst +++ b/Documentation/translations/zh_CN/mm/mmu_notifier.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/mmu_notifier.rst +:Original: Documentation/mm/mmu_notifier.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/numa.rst b/Documentation/translations/zh_CN/mm/numa.rst index 6af412b924ad..b15cfeeb6dfb 100644 --- a/Documentation/translations/zh_CN/vm/numa.rst +++ b/Documentation/translations/zh_CN/mm/numa.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/numa.rst +:Original: Documentation/mm/numa.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/overcommit-accounting.rst b/Documentation/translations/zh_CN/mm/overcommit-accounting.rst index 8765cb118f24..d8452d8b7fbb 100644 --- a/Documentation/translations/zh_CN/vm/overcommit-accounting.rst +++ b/Documentation/translations/zh_CN/mm/overcommit-accounting.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/overcommit-accounting.rst +:Original: Documentation/mm/overcommit-accounting.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/page_frags.rst b/Documentation/translations/zh_CN/mm/page_frags.rst index ad27fed33634..20bd3fafdc8c 100644 --- a/Documentation/translations/zh_CN/vm/page_frags.rst +++ b/Documentation/translations/zh_CN/mm/page_frags.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/page_frag.rst +:Original: Documentation/mm/page_frags.rst :翻译: diff --git a/Documentation/translations/zh_CN/mm/page_migration.rst b/Documentation/translations/zh_CN/mm/page_migration.rst new file mode 100644 index 000000000000..076081dc1635 --- /dev/null +++ b/Documentation/translations/zh_CN/mm/page_migration.rst @@ -0,0 +1,228 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/mm/page_migration.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +======== +页é¢è¿ç§» +======== + +页é¢è¿ç§»å…许在进程è¿è¡Œæ—¶åœ¨NUMA系统的节点之间移动页é¢çš„物ç†ä½ç½®ã€‚è¿™æ„味ç€è¿›ç¨‹æ‰€çœ‹åˆ°çš„虚拟地 +å€å¹¶æ²¡æœ‰æ”¹å˜ã€‚然而，系统会é‡æ–°å®‰æŽ’这些页é¢çš„物ç†ä½ç½®ã€‚ + +也å¯ä»¥å‚è§ :ref: `<异构内å˜ç®¡ç† (HMM)>` 以了解将页é¢è¿ç§»åˆ°è®¾å¤‡ç§æœ‰å†…å˜æˆ–从设备ç§æœ‰å†…å˜ä¸è¿ç§»ã€‚ + +页é¢è¿ç§»çš„主è¦ç›®çš„是通过将页é¢ç§»åˆ°è®¿é—®è¯¥å†…å˜çš„进程所è¿è¡Œçš„处ç†å™¨é™„è¿‘æ¥å‡å°‘内å˜è®¿é—®çš„延迟。 + +页é¢è¿ç§»å…许进程通过MF_MOVEå’ŒMF_MOVE_ALL选项手动é‡æ–°å®šä½å…¶é¡µé¢æ‰€åœ¨çš„节点，åŒæ—¶é€šè¿‡ +mbind()设置一个新的内å˜ç–略。一个进程的页é¢ä¹Ÿå¯ä»¥é€šè¿‡sys_migrate_pages()å‡½æ•°è°ƒç”¨ä»Žå¦ +一个进程é‡æ–°å®šä½ã€‚migrate_pages()函数调用接收两组节点，并将一个进程ä½äºŽæ—§èŠ‚点上的页é¢ç§» +åŠ¨åˆ°ç›®æ ‡èŠ‚ç‚¹ä¸Šã€‚é¡µé¢è¿ç§»åŠŸèƒ½ç”±Andi Kleençš„numactl包æä¾›(需è¦0.9.3以上的版本，其仓库 +地å€https://github.com/numactl/numactl.git)。numactlæ供了libnuma，它为页é¢è¿ç§» +æ供了与其他NUMA功能类似的接å£ã€‚执行 cat ``/proc/<pid>/numa_maps`` å…许轻æ¾æŸ¥çœ‹è¿› +程的页é¢ä½ç½®ã€‚å‚è§proc(5)手册ä¸çš„numa_maps文档。 + +如果调度程åºå°†ä¸€ä¸ªè¿›ç¨‹é‡æ–°å®‰ç½®åˆ°ä¸€ä¸ªé¥è¿œçš„节点上的处ç†å™¨ï¼Œæ‰‹åŠ¨è¿ç§»æ˜¯å¾ˆæœ‰ç”¨çš„。批é‡è°ƒåº¦ç¨‹åº +或管ç†å‘˜å¯ä»¥æ£€æµ‹åˆ°è¿™ç§æƒ…况，并将进程的页é¢ç§»åˆ°æ–°å¤„ç†å™¨é™„è¿‘ã€‚å†…æ ¸æœ¬èº«åªæ供手动的页è¿ç§»æ”¯æŒã€‚ +自动的页é¢è¿ç§»å¯ä»¥é€šè¿‡ç”¨æˆ·ç©ºé—´çš„进程移动页é¢æ¥å®žçŽ°ã€‚一个特殊的函数调用 "move_pages" å…许 +在一个进程ä¸ç§»åŠ¨å•ä¸ªé¡µé¢ã€‚例如，NUMA分æžå™¨å¯ä»¥èŽ·å¾—一个显示频ç¹çš„节点外访问的日志，并å¯ä»¥ä½¿ +用这个结果将页é¢ç§»åŠ¨åˆ°æ›´æœ‰åˆ©çš„ä½ç½®ã€‚ + +较大型的设备通常使用cpusets将系统分割æˆè‹¥å¹²ä¸ªèŠ‚点。Paul Jackson为cpusetsé…备了当任务被 +转移到å¦ä¸€ä¸ªcpuset时移动页é¢çš„能力(è§:ref:`CPUSETS <cpusets>`)。Cpusetså…许进程定 +ä½çš„自动化。如果一个任务被移到一个新的cpuset上，那么它的所有页é¢ä¹Ÿä¼šéšä¹‹ç§»åŠ¨ï¼Œè¿™æ ·è¿›ç¨‹çš„ +性能就ä¸ä¼šæ€¥å‰§ä¸‹é™ã€‚如果cpusetå…许的内å˜èŠ‚点å‘生å˜åŒ–，cpusetä¸çš„进程页也会被移动。 + +页é¢è¿ç§»å…许为所有è¿ç§»æŠ€æœ¯ä¿ç•™ä¸€ç»„节点ä¸é¡µé¢çš„相对ä½ç½®ï¼Œè¿™å°†ä¿ç•™ç”Ÿæˆçš„特定内å˜åˆ†é…模å¼å³ä½¿ +进程已被è¿ç§»ã€‚为了ä¿ç•™å†…å˜å»¶è¿Ÿï¼Œè¿™ä¸€ç‚¹æ˜¯å¿…è¦çš„。è¿ç§»åŽçš„进程将以类似的性能è¿è¡Œã€‚ + +页é¢è¿ç§»åˆ†å‡ 个æ¥éª¤è¿›è¡Œã€‚é¦–å…ˆä¸ºé‚£äº›è¯•å›¾ä»Žå†…æ ¸ä¸ä½¿ç”¨migrate_pages()的进程åšä¸€ä¸ªé«˜å±‚次的 +æ述（对于用户空间的使用，å¯ä»¥å‚考上é¢æ到的Andi Kleençš„numactl包），然åŽå¯¹ä½Žæ°´å¹³çš„细 +节工作åšä¸€ä¸ªä½Žæ°´å¹³æ述。 + +åœ¨å†…æ ¸ä¸ä½¿ç”¨ migrate_pages() +============================ + +1. 从LRUä¸ç§»é™¤é¡µé¢ã€‚ + + è¦è¿ç§»çš„页é¢åˆ—表是通过扫æ页é¢å¹¶æŠŠå®ƒä»¬ç§»åˆ°åˆ—表ä¸æ¥ç”Ÿæˆçš„。这是通过调用 isolate_lru_page() + æ¥å®Œæˆçš„。调用isolate_lru_page()å¢žåŠ äº†å¯¹è¯¥é¡µçš„å¼•ç”¨ï¼Œè¿™æ ·åœ¨é¡µé¢è¿ç§»å‘生时它就ä¸ä¼š + 消失。它还å¯ä»¥é˜²æ¢äº¤æ¢å™¨æˆ–其他扫æ器é‡åˆ°è¯¥é¡µã€‚ + + +2. 我们需è¦æœ‰ä¸€ä¸ªnew_page_t类型的函数，å¯ä»¥ä¼ 递给migrate_pages()。这个函数应该计算 + 出如何在给定的旧页é¢ä¸åˆ†é…æ£ç¡®çš„新页é¢ã€‚ + +3. migrate_pages()函数被调用，它试图进行è¿ç§»ã€‚它将调用该函数为æ¯ä¸ªè¢«è€ƒè™‘è¿ç§»çš„页é¢åˆ† + é…新的页é¢ã€‚ + +migrate_pages()如何工作 +======================= + +migrate_pages()对它的页é¢åˆ—表进行了多次处ç†ã€‚如果当时对一个页é¢çš„所有引用都å¯ä»¥è¢«ç§»é™¤ï¼Œ +那么这个页é¢å°±ä¼šè¢«ç§»åŠ¨ã€‚该页已ç»é€šè¿‡isolate_lru_page()从LRUä¸ç§»é™¤ï¼Œå¹¶ä¸”refcount被 +å¢žåŠ ï¼Œä»¥ä¾¿åœ¨é¡µé¢è¿ç§»å‘生时ä¸é‡Šæ”¾è¯¥é¡µã€‚ + +æ¥éª¤: + +1. é”定è¦è¿ç§»çš„页é¢ã€‚ + +2. ç¡®ä¿å›žå†™å·²ç»å®Œæˆã€‚ + +3. é”定我们è¦è¿ç§»åˆ°çš„新页é¢ã€‚é”定它是为了在è¿ç§»è¿‡ç¨‹ä¸ç«‹å³é˜»æ¢å¯¹è¿™ä¸ªï¼ˆå°šæœªæ›´æ–°çš„）页é¢çš„ + 访问。 + +4. 所有对该页的页表引用都被转æ¢ä¸ºè¿ç§»æ¡ç›®ã€‚这就å‡å°‘了一个页é¢çš„mapcount。如果产生的 + mapcountä¸æ˜¯é›¶ï¼Œé‚£ä¹ˆæˆ‘们就ä¸è¿ç§»è¯¥é¡µã€‚所有试图访问该页的用户空间进程现在将ç‰å¾…页 + é¢é”或者ç‰å¾…è¿ç§»é¡µè¡¨é¡¹è¢«ç§»é™¤ã€‚ + +5. i_pagesçš„é”被æŒæœ‰ã€‚è¿™å°†å¯¼è‡´æ‰€æœ‰è¯•å›¾é€šè¿‡æ˜ å°„è®¿é—®è¯¥é¡µçš„è¿›ç¨‹åœ¨è‡ªæ—‹é”上阻塞。 + +6. 检查该页的Refcount，如果还有引用，我们就退出。å¦åˆ™ï¼Œæˆ‘们知é“我们是唯一引用这个页 + é¢çš„人。 + +7. æ£€æŸ¥åŸºæ•°æ ‘ï¼Œå¦‚æžœå®ƒä¸åŒ…å«æŒ‡å‘这个页é¢çš„æŒ‡é’ˆï¼Œé‚£ä¹ˆæˆ‘ä»¬å°±é€€å‡ºï¼Œå› ä¸ºå…¶ä»–äººä¿®æ”¹äº†åŸºæ•°æ ‘ã€‚ + +8. 新的页é¢è¦ç”¨æ—§çš„页é¢çš„一些设置进行预处ç†ï¼Œè¿™æ ·è®¿é—®æ–°çš„页é¢å°±ä¼šå‘现一个具有æ£ç¡®è®¾ç½® + 的页é¢ã€‚ + +9. åŸºæ•°æ ‘è¢«æ”¹å˜ä»¥æŒ‡å‘新的页é¢ã€‚ + +10. æ—§é¡µçš„å¼•ç”¨è®¡æ•°è¢«åˆ é™¤ï¼Œå› ä¸ºåœ°å€ç©ºé—´çš„引用已ç»æ¶ˆå¤±ã€‚å¯¹æ–°é¡µçš„å¼•ç”¨è¢«å»ºç«‹ï¼Œå› ä¸ºæ–°é¡µè¢« + 地å€ç©ºé—´å¼•ç”¨ã€‚ + +11. i_pagesé”è¢«æ”¾å¼ƒã€‚è¿™æ ·ä¸€æ¥ï¼Œåœ¨æ˜ å°„ä¸çš„查找åˆå˜å¾—å¯èƒ½äº†ã€‚进程将从在é”上自旋到在 + 被é”的新页上ç¡çœ 。 + +12. 页é¢å†…容被å¤åˆ¶åˆ°æ–°çš„页é¢ä¸Šã€‚ + +13. 剩余的页é¢æ ‡å¿—被å¤åˆ¶åˆ°æ–°çš„页é¢ä¸Šã€‚ + +14. 旧的页é¢æ ‡å¿—被清除，以表明该页é¢ä¸å†æ供任何信æ¯ã€‚ + +15. 新页é¢ä¸Šçš„回写队列被触å‘了。 + +16. 如果è¿ç§»æ¡ç›®è¢«æ’入到页表ä¸ï¼Œé‚£ä¹ˆå°±ç”¨çœŸæ£çš„ptes替æ¢å®ƒä»¬ã€‚è¿™æ ·åšå°†ä½¿é‚£äº›å°šæœªç‰å¾…页 + é”的用户空间进程能够访问。 + +17. 页é¢é”从新旧页é¢ä¸Šè¢«æ’¤é”€ã€‚ç‰å¾…页é”的进程将é‡åšä»–们的缺页异常，并将到达新的页é¢ã€‚ + +18. 新的页é¢è¢«ç§»åˆ°LRUä¸ï¼Œå¯ä»¥è¢«äº¤æ¢å™¨ç‰å†æ¬¡æ‰«æ。 + +éžLRU页é¢è¿ç§» +============= + +尽管è¿ç§»æœ€åˆçš„目的是为了å‡å°‘NUMA的内å˜è®¿é—®å»¶è¿Ÿï¼Œä½†åŽ‹ç¼©ä¹Ÿä½¿ç”¨è¿ç§»æ¥åˆ›å»ºé«˜é˜¶é¡µé¢ã€‚ + +ç›®å‰å®žçŽ°çš„问题是，它被设计为åªè¿ç§»*LRU*页。然而，有一些潜在的éžLRU页é¢å¯ä»¥åœ¨é©±åŠ¨ä¸ +被è¿ç§»ï¼Œä¾‹å¦‚，zsmalloc，virtio-balloon页é¢ã€‚ + +对于virtio-balloon页é¢ï¼Œè¿ç§»ä»£ç 路径的æŸäº›éƒ¨åˆ†å·²ç»è¢«é’©ä½ï¼Œå¹¶æ·»åŠ 了virtio-balloon +的特定函数æ¥æ‹¦æˆªè¿ç§»é€»è¾‘。这对一个驱动æ¥è¯´å¤ªç‰¹æ®Šäº†ï¼Œæ‰€ä»¥å…¶ä»–想让自己的页é¢å¯ç§»åŠ¨çš„驱 +动就必须在è¿ç§»è·¯å¾„ä¸æ·»åŠ 自己的特定钩å。 + +为了克æœè¿™ä¸ªé—®é¢˜ï¼ŒVM支æŒéžLRU页é¢è¿ç§»ï¼Œå®ƒä¸ºéžLRUå¯ç§»åŠ¨é¡µé¢æ供了通用函数，而在è¿ç§» +路径ä¸æ²¡æœ‰ç‰¹å®šçš„驱动程åºé’©å。 + +如果一个驱动程åºæƒ³è®©å®ƒçš„页é¢å¯ç§»åŠ¨ï¼Œå®ƒåº”该定义三个函数，这些函数是 +struct address_space_operations的函数指针。 + +1. ``bool (*isolate_page) (struct page *page, isolate_mode_t mode);`` + + VM对驱动的isolate_page()函数的期望是，如果驱动æˆåŠŸéš”离了该页，则返回*true*。 + 返回trueåŽï¼ŒVMä¼šå°†è¯¥é¡µæ ‡è®°ä¸ºPG_isolatedï¼Œè¿™æ ·å¤šä¸ªCPU的并å‘隔离就会跳过该 + 页进行隔离。如果驱动程åºä¸èƒ½éš”离该页，它应该返回*false*。 + + 一旦页é¢è¢«æˆåŠŸéš”离，VM就会使用page.lruå—æ®µï¼Œå› æ¤é©±åŠ¨ç¨‹åºä¸åº”期望ä¿ç•™è¿™äº›å—段的值。 + +2. ``int (*migratepage) (struct address_space *mapping,`` +| ``struct page *newpage, struct page *oldpage, enum migrate_mode);`` + + 隔离åŽï¼Œè™šæ‹Ÿæœºç”¨éš”离的页é¢è°ƒç”¨é©±åŠ¨çš„migratepage()。migratepage()的功能是将旧页 + 的内容移动到新页，并设置struct page newpageçš„å—段。请记ä½ï¼Œå¦‚æžœä½ æˆåŠŸè¿ç§»äº†æ—§é¡µ + 并返回MIGRATEPAGE_SUCCESSï¼Œä½ åº”è¯¥é€šè¿‡page_lock下的__ClearPageMovable()å‘虚 + 拟机表明旧页ä¸å†å¯ç§»åŠ¨ã€‚如果驱动暂时ä¸èƒ½è¿ç§»è¯¥é¡µï¼Œé©±åŠ¨å¯ä»¥è¿”回-EAGAIN。在-EAGAIN + 时，VM会在çŸæ—¶é—´å†…é‡è¯•é¡µé¢è¿ç§»ï¼Œå› 为VMå°†-EAGAINç†è§£ä¸º "临时è¿ç§»å¤±è´¥"。在返回除 + -EAGAIN以外的任何错误时，VM将放弃页é¢è¿ç§»è€Œä¸é‡è¯•ã€‚ + + 在migratepage()函数ä¸ï¼Œé©±åŠ¨ç¨‹åºä¸åº”该接触page.lruå—段。 + +3. ``void (*putback_page)(struct page *);`` + + 如果在隔离页上è¿ç§»å¤±è´¥ï¼ŒVMåº”è¯¥å°†éš”ç¦»é¡µè¿”å›žç»™é©±åŠ¨ï¼Œå› æ¤VM用隔离页调用驱动的 + putback_page()。在这个函数ä¸ï¼Œé©±åŠ¨åº”该把隔离页放回自己的数æ®ç»“æž„ä¸ã€‚ + +éžLRUå¯ç§»åŠ¨é¡µæ ‡å¿— + + 有两个页é¢æ ‡å¿—用于支æŒéžLRUå¯ç§»åŠ¨é¡µé¢ã€‚ + + * PG_movable + + 驱动应该使用下é¢çš„函数æ¥ä½¿é¡µé¢åœ¨page_lock下å¯ç§»åŠ¨ã€‚:: + + void __SetPageMovable(struct page *page, struct address_space *mapping) + + 它需è¦address_spaceçš„å‚æ•°æ¥æ³¨å†Œå°†è¢«VM调用的migration family函数。确切地说， + PG_movableä¸æ˜¯struct page的一个真æ£çš„æ ‡å¿—ã€‚ç›¸å，VMå¤ç”¨äº†page->mapping的低 + ä½æ¥è¡¨ç¤ºå®ƒ:: + + #define PAGE_MAPPING_MOVABLE 0x2 + page->mapping = page->mapping | PAGE_MAPPING_MOVABLE; + + 所以驱动ä¸åº”该直接访问page->mapping。相å，驱动应该使用page_mapping()ï¼Œå®ƒå¯ + 以在页é¢é”下å±è”½æŽ‰page->mapping的低2ä½ï¼Œä»Žè€ŒèŽ·å¾—æ£ç¡®çš„struct address_space。 + + 对于éžLRUå¯ç§»åŠ¨é¡µé¢çš„测试，VM支æŒ__PageMovable()函数。然而，它并ä¸èƒ½ä¿è¯è¯†åˆ« + éžLRUå¯ç§»åŠ¨é¡µé¢ï¼Œå› 为page->mappingå—段与struct pageä¸çš„其他å˜é‡æ˜¯ç»Ÿä¸€çš„。如 + 果驱动程åºåœ¨è¢«è™šæ‹Ÿæœºéš”离åŽé‡Šæ”¾äº†é¡µé¢ï¼Œå°½ç®¡page->mapping设置了PAGE_MAPPING_MOVABLE， + 但它并没有一个稳定的值（看看__ClearPageMovable）。但是__PageMovable()在页 + é¢è¢«éš”离åŽï¼Œæ— 论页é¢æ˜¯LRU还是éžLRUå¯ç§»åŠ¨çš„ï¼Œè°ƒç”¨å®ƒå¼€é”€éƒ½å¾ˆä½Žï¼Œå› ä¸ºLRU页é¢åœ¨ + page->mappingä¸ä¸å¯èƒ½æœ‰PAGE_MAPPING_MOVABLE设置。在用pfn扫æä¸çš„lock_page() + 进行更大开销的检查æ¥é€‰æ‹©å—害者之å‰ï¼Œå®ƒä¹Ÿå¾ˆé€‚åˆåªæ˜¯çž¥ä¸€çœ¼æ¥æµ‹è¯•éžLRUå¯ç§»åŠ¨çš„页é¢ã€‚ + + 为了ä¿è¯éžLRUçš„å¯ç§»åŠ¨é¡µé¢ï¼ŒVMæ供了PageMovable()函数。与__PageMovable()ä¸ + åŒï¼ŒPageMovable()在lock_page()下验è¯page->mappingå’Œ + mapping->a_ops->isolate_page。lock_page()å¯ä»¥é˜²æ¢çªç„¶ç ´åpage->mapping。 + + 使用__SetPageMovable()的驱动应该在释放页é¢ä¹‹å‰é€šè¿‡page_lock()下的 + __ClearMovablePage()æ¸…é™¤è¯¥æ ‡å¿—ã€‚ + + * PG_isolated + + 为了防æ¢å‡ 个CPUåŒæ—¶è¿›è¡Œéš”离，VM在lock_page()下将隔离的页é¢æ ‡è®°ä¸ºPG_isolated。 + å› æ¤ï¼Œå¦‚果一个CPUé‡åˆ°PG_isolatedéžLRUå¯ç§»åŠ¨é¡µé¢ï¼Œå®ƒå¯ä»¥è·³è¿‡å®ƒã€‚驱动程åºä¸éœ€è¦ + æ“ä½œè¿™ä¸ªæ ‡å¿—ï¼Œå› ä¸ºVM会自动设置/清除它。请记ä½ï¼Œå¦‚果驱动程åºçœ‹åˆ°PG_isolated页， + è¿™æ„味ç€è¯¥é¡µå·²ç»è¢«VM隔离，所以它ä¸åº”该碰page.lruå—段。PG_isolatedæ ‡å¿—ä¸Ž + PG_reclaimæ ‡å¿—æ˜¯åŒä¹‰çš„，所以驱动程åºä¸åº”该为自己的目的使用PG_isolated。 + +监测è¿ç§» +======== + +以下事件（计数器）å¯ç”¨äºŽç›‘控页é¢è¿ç§»ã€‚ + +1. PGMIGRATE_SUCCESS: æ£å¸¸çš„页é¢è¿ç§»æˆåŠŸã€‚æ¯ä¸ªè®¡æ•°å™¨æ„味ç€ä¸€ä¸ªé¡µé¢è¢«è¿ç§»äº†ã€‚如果该 + 页是一个éžTHPå’Œéžhugetlbé¡µï¼Œé‚£ä¹ˆè¿™ä¸ªè®¡æ•°å™¨ä¼šå¢žåŠ 1。如果该页é¢æ˜¯ä¸€ä¸ªTHP或hugetlb + 页é¢ï¼Œé‚£ä¹ˆè¿™ä¸ªè®¡æ•°å™¨ä¼šéšç€THP或hugetlbå页é¢çš„æ•°é‡è€Œå¢žåŠ 。例如，è¿ç§»ä¸€ä¸ªæœ‰4KBå¤§å° + 的基础页（å页）的2MB THPï¼Œå°†å¯¼è‡´è¿™ä¸ªè®¡æ•°å™¨å¢žåŠ 512。 + +2. PGMIGRATE_FAIL: æ£å¸¸çš„页é¢è¿ç§»å¤±è´¥ã€‚与上é¢PGMIGRATE_SUCCESS的计数规则相åŒï¼šå¦‚ + 果是THP或hugetlb，这个计数将被å页的数é‡å¢žåŠ 。 + +3. THP_MIGRATION_SUCCESS: 一个THP被è¿ç§»è€Œæ²¡æœ‰è¢«åˆ†å‰²ã€‚ + +4. THP_MIGRATION_FAIL: 一个THPä¸èƒ½è¢«è¿ç§»ï¼Œä¹Ÿä¸èƒ½è¢«åˆ†å‰²ã€‚ + +5. THP_MIGRATION_SPLIT: 一个THP被è¿ç§»äº†ï¼Œä½†ä¸æ˜¯è¿™æ ·çš„：首先，这个THP必须被分割。 + 在拆分之åŽï¼Œå¯¹å®ƒçš„å页é¢è¿›è¡Œäº†è¿ç§»é‡è¯•ã€‚ + +THP_MIGRATION_* 事件也会更新相应的PGMIGRATE_SUCCESS或PGMIGRATE_FAIL事件。 +例如，一个THPè¿ç§»å¤±è´¥å°†å¯¼è‡´THP_MIGRATION_FAILå’ŒPGMIGRATE_FAILå¢žåŠ ã€‚ + +Christoph Lameter，2006å¹´5月8日。 + +Minchan Kim，2016å¹´3月28日。 diff --git a/Documentation/translations/zh_CN/vm/page_owner.rst b/Documentation/translations/zh_CN/mm/page_owner.rst index 9e951fabba9d..b7f81d7a6589 100644 --- a/Documentation/translations/zh_CN/vm/page_owner.rst +++ b/Documentation/translations/zh_CN/mm/page_owner.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/page_owner.rst +:Original: Documentation/mm/page_owner.rst :翻译: @@ -96,21 +96,82 @@ page owner在默认情况下是ç¦ç”¨çš„ã€‚æ‰€ä»¥ï¼Œå¦‚æžœä½ æƒ³ä½¿ç”¨å®ƒï¼Œä½ é 默认情况下， ``page_owner_sort`` æ˜¯æ ¹æ®buf的时间æ¥æŽ’åºçš„ã€‚å¦‚æžœä½ æƒ³ 按buf的页数排åºï¼Œè¯·ä½¿ç”¨-må‚数。详细的å‚数是: - 基本函数: + 基本函数:: - Sort: + 排åº: -a 按内å˜åˆ†é…æ—¶é—´æŽ’åº -m 按总内å˜æŽ’åº -p 按pid排åºã€‚ -P 按tgid排åºã€‚ + -n 按任务命令å称排åºã€‚ -r 按内å˜é‡Šæ”¾æ—¶é—´æŽ’åºã€‚ -s æŒ‰å †æ ˆè·Ÿè¸ªæŽ’åºã€‚ -t 按时间排åºï¼ˆé»˜è®¤ï¼‰ã€‚ - - 其它函数: - - Cull: - -c é€šè¿‡æ¯”è¾ƒå †æ ˆè·Ÿè¸ªè€Œä¸æ˜¯æ€»å—æ¥è¿›è¡Œå‰”除。 - - Filter: + --sort <order> 指定排åºé¡ºåºã€‚排åºçš„è¯æ³•æ˜¯[+|-]key[,[+|-]key[,...]]。从 + **æ ‡å‡†æ ¼å¼æŒ‡å®šå™¨**那一节选择一个键。"+"是å¯é€‰çš„ï¼Œå› ä¸ºé»˜è®¤çš„æ–¹å‘是数å—或 + è¯æ³•çš„å¢žåŠ ã€‚å…许混åˆä½¿ç”¨ç¼©å†™å’Œå®Œæ•´æ ¼å¼çš„键。 + + 例å: + ./page_owner_sort <input> <output> --sort=n,+pid,-tgid + ./page_owner_sort <input> <output> --sort=at + + 其它函数:: + + 剔除: + --cull <rules> + 指定剔除规则。剔除的è¯æ³•æ˜¯key[,key[,...]]。从**æ ‡å‡†æ ¼å¼æŒ‡å®šå™¨** + 部分选择一个多å—æ¯é”®ã€‚ + <rules>是一个以逗å·åˆ†éš”的列表形å¼çš„å•ä¸€å‚数，它æ供了一ç§æŒ‡å®šå•ä¸ªå‰”除规则的 + 方法。 识别的关键å—在下é¢çš„**æ ‡å‡†æ ¼å¼æŒ‡å®šå™¨**部分有æ述。<规则>å¯ä»¥é€šè¿‡é”®çš„ + åºåˆ—k1,k2,...æ¥æŒ‡å®šï¼Œåœ¨ä¸‹é¢çš„æ ‡å‡†æŽ’åºé”®éƒ¨åˆ†æœ‰æ述。å…许混åˆä½¿ç”¨ç®€å†™å’Œå®Œæ•´å½¢ + å¼çš„键。 + + Examples: + ./page_owner_sort <input> <output> --cull=stacktrace + ./page_owner_sort <input> <output> --cull=st,pid,name + ./page_owner_sort <input> <output> --cull=n,f + + 过滤: -f 过滤掉内å˜å·²è¢«é‡Šæ”¾çš„å—çš„ä¿¡æ¯ã€‚ + + 选择: + --pid <pidlist> 按pid选择。这将选择进程IDå·å‡ºçŽ°åœ¨<pidlist>ä¸çš„å—。 + --tgid <tgidlist> 按tgid选择。这将选择其线程组IDå·å‡ºçŽ°åœ¨<tgidlist> + ä¸çš„å—。 + --name <cmdlist> 按任务命令å称选择。这将选择其任务命令å称出现在 + <cmdlist>ä¸çš„区å—。 + + <pidlist>, <tgidlist>, <cmdlist>是以逗å·åˆ†éš”的列表形å¼çš„å•ä¸ªå‚数， + 它æ供了一ç§æŒ‡å®šå•ä¸ªé€‰æ‹©è§„则的方法。 + + + 例å: + ./page_owner_sort <input> <output> --pid=1 + ./page_owner_sort <input> <output> --tgid=1,2,3 + ./page_owner_sort <input> <output> --name name1,name2 + +æ ‡å‡†æ ¼å¼æŒ‡å®šå™¨ +============== +:: + + --sort的选项: + + çŸé”® é•¿é”® æè¿° + p pid 进程ID + tg tgid 线程组ID + n name 任务命令å称 + st stacktrace 页é¢åˆ†é…çš„å †æ ˆè·Ÿè¸ª + T txt å—的全文 + ft free_ts 页é¢é‡Šæ”¾æ—¶çš„时间戳 + at alloc_ts 页é¢è¢«åˆ†é…时的时间戳 + ator allocator 页é¢çš„内å˜åˆ†é…器 + + --curl的选项: + + çŸé”® é•¿é”® æè¿° + p pid 进程ID + tg tgid 线程组ID + n name 任务命令å称 + f free 该页是å¦å·²ç»é‡Šæ”¾ + st stacktrace 页é¢åˆ†é…çš„å †æ ˆè·Ÿè¸ª + ator allocator 页é¢çš„内å˜åˆ†é…器 diff --git a/Documentation/translations/zh_CN/vm/page_table_check.rst b/Documentation/translations/zh_CN/mm/page_table_check.rst index a29fc1b360e6..e8077310a76c 100644 --- a/Documentation/translations/zh_CN/vm/page_table_check.rst +++ b/Documentation/translations/zh_CN/mm/page_table_check.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -:Original: Documentation/vm/page_table_check.rst +:Original: Documentation/mm/page_table_check.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/remap_file_pages.rst b/Documentation/translations/zh_CN/mm/remap_file_pages.rst index af6b7e28af23..31e0c54dc36f 100644 --- a/Documentation/translations/zh_CN/vm/remap_file_pages.rst +++ b/Documentation/translations/zh_CN/mm/remap_file_pages.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/remap_file_pages.rst +:Original: Documentation/mm/remap_file_pages.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/split_page_table_lock.rst b/Documentation/translations/zh_CN/mm/split_page_table_lock.rst index 50694d97c426..4fb7aa666037 100644 --- a/Documentation/translations/zh_CN/vm/split_page_table_lock.rst +++ b/Documentation/translations/zh_CN/mm/split_page_table_lock.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/split_page_table_lock.rst +:Original: Documentation/mm/split_page_table_lock.rst :翻译: diff --git a/Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst b/Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst new file mode 100644 index 000000000000..d02a23f7f07e --- /dev/null +++ b/Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst @@ -0,0 +1,133 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/mm/vmalloced-kernel-stacks.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +==================== +支æŒè™šæ‹Ÿæ˜ å°„çš„å†…æ ¸æ ˆ +==================== + +:作者: Shuah Khan <skhan@linuxfoundation.org> + +.. contents:: :local: + +概览 +---- + +è¿™æ˜¯ä»‹ç» `è™šæ‹Ÿæ˜ å°„å†…æ ¸æ ˆåŠŸèƒ½ <https://lwn.net/Articles/694348/>` 的代ç +和原始补ä¸ç³»åˆ—çš„ä¿¡æ¯æ±‡æ€»ã€‚ + +简介 +---- + +å†…æ ¸å †æ ˆæº¢å‡ºé€šå¸¸éš¾ä»¥è°ƒè¯•ï¼Œå¹¶ä½¿å†…æ ¸å®¹æ˜“è¢«ï¼ˆæ¶æ„）利用。问题å¯èƒ½åœ¨ç¨åŽçš„时间出现，使其难以 +éš”ç¦»å’Œç©¶å…¶æ ¹æœ¬åŽŸå› ã€‚ + +带有ä¿æŠ¤é¡µçš„è™šæ‹Ÿæ˜ å°„å†…æ ¸å †æ ˆå¦‚æžœæº¢å‡ºï¼Œä¼šè¢«ç«‹å³æ•èŽ·ï¼Œè€Œä¸ä¼šæ”¾ä»»å…¶å¯¼è‡´éš¾ä»¥è¯Šæ–çš„æŸ +å。 + +HAVE_ARCH_VMAP_STACKå’ŒVMAP_STACKé…置选项能够支æŒå¸¦æœ‰ä¿æŠ¤é¡µçš„è™šæ‹Ÿæ˜ å°„å †æ ˆã€‚ +å½“å †æ ˆæº¢å‡ºæ—¶ï¼Œè¿™ä¸ªç‰¹æ€§ä¼šå¼•å‘å¯é 的异常。溢出åŽå †æ ˆè·Ÿè¸ªçš„å¯ç”¨æ€§ä»¥åŠå¯¹æº¢å‡ºæœ¬èº«çš„ +å“应å–决于架构。 + +.. note:: + 截至本文撰写时， arm64, powerpc, riscv, s390, um, å’Œ x86 支æŒVMAP_STACK。 + +HAVE_ARCH_VMAP_STACK +-------------------- + +能够支æŒè™šæ‹Ÿæ˜ å°„å†…æ ¸æ ˆçš„æž¶æž„åº”è¯¥å¯ç”¨è¿™ä¸ªboolé…置选项。è¦æ±‚是: + +- vmallocç©ºé—´å¿…é¡»å¤§åˆ°è¶³ä»¥å®¹çº³è®¸å¤šå†…æ ¸å †æ ˆã€‚è¿™å¯èƒ½æŽ’除了许多32ä½æž¶æž„。 +- vmallocç©ºé—´çš„å †æ ˆéœ€è¦å¯é 地工作。例如，如果vmapé¡µè¡¨æ˜¯æŒ‰éœ€åˆ›å»ºçš„ï¼Œå½“å †æ ˆæŒ‡å‘ + 具有未填充页表的虚拟地å€æ—¶ï¼Œè¿™ç§æœºåˆ¶éœ€è¦å·¥ä½œï¼Œæˆ–者架构代ç （switch_to()å’Œ + switch_mm()，很å¯èƒ½ï¼‰éœ€è¦ç¡®ä¿å †æ ˆçš„页表项在å¯èƒ½æœªå¡«å……çš„å †æ ˆä¸Šè¿è¡Œä¹‹å‰å·²ç»å¡« + 充。 +- å¦‚æžœå †æ ˆæº¢å‡ºåˆ°ä¸€ä¸ªä¿æŠ¤é¡µï¼Œå°±åº”该å‘生一些åˆç†çš„事情。“åˆç†â€çš„定义是çµæ´»çš„，但 + 在没有记录任何东西的情况下立å³é‡å¯æ˜¯ä¸å‹å¥½çš„。 + +VMAP_STACK +---------- + +VMAP_STACK boolé…置选项在å¯ç”¨æ—¶åˆ†é…è™šæ‹Ÿæ˜ å°„çš„ä»»åŠ¡æ ˆã€‚è¿™ä¸ªé€‰é¡¹ä¾èµ–于 +HAVE_ARCH_VMAP_STACK。 + +- å¦‚æžœä½ æƒ³ä½¿ç”¨å¸¦æœ‰ä¿æŠ¤é¡µçš„è™šæ‹Ÿæ˜ å°„çš„å†…æ ¸å †æ ˆï¼Œè¯·å¯ç”¨è¯¥é€‰é¡¹ã€‚è¿™å°†å¯¼è‡´å†…æ ¸æ ˆæº¢å‡º + 被立å³æ•èŽ·ï¼Œè€Œä¸æ˜¯éš¾ä»¥è¯Šæ–çš„æŸå。 + +.. note:: + + 使用KASAN的这个功能需è¦æž¶æž„支æŒç”¨çœŸå®žçš„å½±å内å˜æ¥æ”¯æŒè™šæ‹Ÿæ˜ 射，并且 + å¿…é¡»å¯ç”¨KASAN_VMALLOC。 + +.. note:: + + å¯ç”¨VMAP_STACKæ—¶ï¼Œæ— æ³•åœ¨å †æ ˆåˆ†é…çš„æ•°æ®ä¸Šè¿è¡ŒDMA。 + +å†…æ ¸é…置选项和ä¾èµ–性ä¸æ–å˜åŒ–。请å‚考最新的代ç 库: + +`Kconfig <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/Kconfig>` + +分é…方法 +-------- + +å½“ä¸€ä¸ªæ–°çš„å†…æ ¸çº¿ç¨‹è¢«åˆ›å»ºæ—¶ï¼Œçº¿ç¨‹å †æ ˆæ˜¯ç”±é¡µçº§åˆ†é…器分é…的虚拟连ç»çš„内å˜é¡µç»„æˆã€‚è¿™ +些页é¢è¢«æ˜ 射到有PAGE_KERNELä¿æŠ¤çš„è¿žç»çš„å†…æ ¸è™šæ‹Ÿç©ºé—´ã€‚ + +alloc_thread_stack_node()调用__vmalloc_node_range()æ¥åˆ†é…带有PAGE_KERNEL +ä¿æŠ¤çš„æ ˆã€‚ + +- 分é…çš„å †æ ˆè¢«ç¼“å˜èµ·æ¥ï¼Œä»¥åŽä¼šè¢«æ–°çš„线程é‡ç”¨ï¼Œæ‰€ä»¥åœ¨åˆ†é…/é‡Šæ”¾å †æ ˆç»™ä»»åŠ¡æ—¶ï¼Œè¦æ‰‹åŠ¨ + 进行memcgæ ¸ç®—ã€‚å› æ¤ï¼Œ__vmalloc_node_range被调用时没有__GFP_ACCOUNT。 +- vm_struct被缓å˜èµ·æ¥ï¼Œä»¥ä¾¿èƒ½å¤Ÿæ‰¾åˆ°åœ¨ä¸æ–上下文ä¸å¯åŠ¨çš„空闲线程。 free_thread_stack() + å¯ä»¥åœ¨ä¸æ–上下文ä¸è°ƒç”¨ã€‚ +- 在arm64上，所有VMAPçš„å †æ ˆéƒ½éœ€è¦æœ‰ç›¸åŒçš„对é½æ–¹å¼ï¼Œä»¥ç¡®ä¿VMAPçš„å †æ ˆæº¢å‡ºæ£€æµ‹æ£å¸¸ + 工作。架构特定的vmapå †æ ˆåˆ†é…器照顾到了这个细节。 +- 这并ä¸æ¶‰åŠä¸æ–å †æ ˆ--å‚è€ƒåŽŸå§‹è¡¥ä¸ + +çº¿ç¨‹æ ˆåˆ†é…是由clone()ã€fork()ã€vfork()ã€kernel_thread()通过kernel_clone() +å¯åŠ¨çš„。留点æ示在这，以便æœç´¢ä»£ç åº“ï¼Œäº†è§£çº¿ç¨‹æ ˆä½•æ—¶ä»¥åŠå¦‚何分é…。 + +大é‡çš„代ç 是在: +`kernel/fork.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c>`. + +task_structä¸çš„stack_vm_area指针å¯ä»¥è·Ÿè¸ªè™šæ‹Ÿåˆ†é…çš„å †æ ˆï¼Œä¸€ä¸ªéžç©ºçš„stack_vm_area +指针å¯ä»¥è¡¨æ˜Žè™šæ‹Ÿæ˜ å°„çš„å†…æ ¸å †æ ˆå·²ç»å¯ç”¨ã€‚ + +:: + + struct vm_struct *stack_vm_area; + +å †æ ˆæº¢å‡ºå¤„ç† +------------ + +å‰å®ˆæŠ¤é¡µå’ŒåŽå®ˆæŠ¤é¡µæœ‰åŠ©äºŽæ£€æµ‹å †æ ˆæº¢å‡ºã€‚å½“å †æ ˆæº¢å‡ºåˆ°å®ˆæŠ¤é¡µæ—¶ï¼Œå¤„ç†ç¨‹åºå¿…é¡»å°å¿ƒä¸è¦å† +æ¬¡æº¢å‡ºå †æ ˆã€‚å½“å¤„ç†ç¨‹åºè¢«è°ƒç”¨æ—¶ï¼Œå¾ˆå¯èƒ½åªç•™ä¸‹å¾ˆå°‘çš„å †æ ˆç©ºé—´ã€‚ + +在x86上，这是通过处ç†è¡¨æ˜Žå†…æ ¸å †æ ˆæº¢å‡ºçš„åŒå¼‚å¸¸å †æ ˆçš„ç¼ºé¡µå¼‚å¸¸æ¥å®žçŽ°çš„。 + +用守护页测试VMAPåˆ†é… +-------------------- + +我们如何确ä¿VMAP_STACK在分é…时确实有å‰å®ˆæŠ¤é¡µå’ŒåŽå®ˆæŠ¤é¡µçš„ä¿æŠ¤ï¼Ÿä¸‹é¢çš„ lkdtm 测试 +å¯ä»¥å¸®åŠ©æ£€æµ‹ä»»ä½•å›žå½’。 + +:: + + void lkdtm_STACK_GUARD_PAGE_LEADING() + void lkdtm_STACK_GUARD_PAGE_TRAILING() + +结论 +---- + +- vmallocedå †æ ˆçš„percpu缓å˜ä¼¼ä¹Žæ¯”é«˜é˜¶å †æ ˆåˆ†é…è¦å¿«ä¸€äº›ï¼Œè‡³å°‘在缓å˜å‘½ä¸æ—¶æ˜¯è¿™æ ·ã€‚ +- THREAD_INFO_IN_TASK完全摆脱了arch-specific thread_info，并简å•åœ°å°† + thread_info（仅包å«æ ‡å¿—）和'int cpu'嵌入task_structä¸ã€‚ +- 一旦任务æ»äº¡ï¼Œçº¿ç¨‹æ ˆå°±å¯ä»¥è¢«é‡Šæ”¾ï¼ˆæ— 需ç‰å¾…RCU），然åŽï¼Œå¦‚果使用vmappedæ ˆï¼Œå°± + å¯ä»¥å°†æ•´ä¸ªæ ˆç¼“å˜èµ·æ¥ï¼Œä»¥ä¾¿åœ¨åŒä¸€cpu上é‡å¤ä½¿ç”¨ã€‚ diff --git a/Documentation/translations/zh_CN/vm/z3fold.rst b/Documentation/translations/zh_CN/mm/z3fold.rst index 57204aa08caa..9569a6d88270 100644 --- a/Documentation/translations/zh_CN/vm/z3fold.rst +++ b/Documentation/translations/zh_CN/mm/z3fold.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/z3fold.rst +:Original: Documentation/mm/z3fold.rst :翻译: diff --git a/Documentation/translations/zh_CN/vm/zsmalloc.rst b/Documentation/translations/zh_CN/mm/zsmalloc.rst index 29e9c70a8eb6..4c8c9b1006a9 100644 --- a/Documentation/translations/zh_CN/vm/zsmalloc.rst +++ b/Documentation/translations/zh_CN/mm/zsmalloc.rst @@ -1,4 +1,4 @@ -:Original: Documentation/vm/zs_malloc.rst +:Original: Documentation/mm/zsmalloc.rst :翻译: diff --git a/Documentation/translations/zh_CN/process/5.Posting.rst b/Documentation/translations/zh_CN/process/5.Posting.rst index 4ee7de13f373..6a469e1c7deb 100644 --- a/Documentation/translations/zh_CN/process/5.Posting.rst +++ b/Documentation/translations/zh_CN/process/5.Posting.rst @@ -19,8 +19,7 @@ å†…æ ¸å¼€å‘社区已ç»å‘展出一套用于å‘布补ä¸çš„约定和过程；éµå¾ªè¿™äº›çº¦å®šå’Œè¿‡ç¨‹å°†ä½¿ å‚与其ä¸çš„æ¯ä¸ªäººçš„ç”Ÿæ´»æ›´åŠ è½»æ¾ã€‚本文档试图æè¿°è¿™äº›çº¦å®šçš„éƒ¨åˆ†ç»†èŠ‚ï¼›æ›´å¤šä¿¡æ¯ ä¹Ÿå¯åœ¨ä»¥ä¸‹æ–‡æ¡£ä¸æ‰¾åˆ° -:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`， -:ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>` +:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>` å’Œ :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`。 ä½•æ—¶å¯„é€ diff --git a/Documentation/translations/zh_CN/process/8.Conclusion.rst b/Documentation/translations/zh_CN/process/8.Conclusion.rst index 4707f0101964..643b88af97bb 100644 --- a/Documentation/translations/zh_CN/process/8.Conclusion.rst +++ b/Documentation/translations/zh_CN/process/8.Conclusion.rst @@ -19,7 +19,6 @@ :ref:`Documentation/translations/zh_CN/process/howto.rst <cn_process_howto>` 文件是一个é‡è¦çš„起点； :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>` -å’Œ :ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>` ä¹Ÿæ˜¯æ‰€æœ‰å†…æ ¸å¼€å‘äººå‘˜éƒ½åº”è¯¥é˜…è¯»çš„å†…å®¹ã€‚è®¸å¤šå†…éƒ¨å†…æ ¸API都是使用kerneldoc机制 记录的；“make htmldocsâ€æˆ–“make pdfdocsâ€å¯ç”¨äºŽä»¥HTML或PDFæ ¼å¼ç”Ÿæˆè¿™äº›æ–‡æ¡£ （尽管æŸäº›å‘行版æ供的tex版本会é‡åˆ°å†…部é™åˆ¶ï¼Œæ— 法æ£ç¡®å¤„ç†æ–‡æ¡£ï¼‰ã€‚ diff --git a/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst index 88273ebe7823..cf5f1fca3d92 100644 --- a/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst +++ b/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst @@ -174,7 +174,7 @@ CVEåˆ†é… ============= ======================================================== ARM - AMD Tom Lendacky <tom.lendacky@amd.com> + AMD Tom Lendacky <thomas.lendacky@amd.com> IBM Intel Tony Luck <tony.luck@intel.com> Qualcomm Trilok Soni <tsoni@codeaurora.org> diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 1334cdb32a3c..1455190dc087 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -96,7 +96,6 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与 的代ç 。 :ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>` - :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` 这两份文档明确æ述如何创建和å‘é€è¡¥ä¸ï¼Œå…¶ä¸åŒ…括（但ä¸ä»…é™äºŽ)： - 邮件内容 diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst index 39e9c88fbaa6..a683dbea0c83 100644 --- a/Documentation/translations/zh_CN/process/index.rst +++ b/Documentation/translations/zh_CN/process/index.rst @@ -40,7 +40,6 @@ .. toctree:: :maxdepth: 1 - submitting-drivers submit-checklist stable-api-nonsense stable-kernel-rules diff --git a/Documentation/translations/zh_CN/process/submitting-drivers.rst b/Documentation/translations/zh_CN/process/submitting-drivers.rst deleted file mode 100644 index 98341e7cd812..000000000000 --- a/Documentation/translations/zh_CN/process/submitting-drivers.rst +++ /dev/null @@ -1,160 +0,0 @@ -.. _cn_submittingdrivers: - -.. include:: ../disclaimer-zh_CN.rst - -:Original: :ref:`Documentation/process/submitting-drivers.rst - <submittingdrivers>` - -如果想评论或更新本文的内容，请直接è”ç³»åŽŸæ–‡æ¡£çš„ç»´æŠ¤è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡ -交æµæœ‰å›°éš¾çš„è¯ï¼Œä¹Ÿå¯ä»¥å‘ä¸æ–‡ç‰ˆç»´æŠ¤è€…求助。如果本翻译更新ä¸åŠæ—¶æˆ–者翻 -译å˜åœ¨é—®é¢˜ï¼Œè¯·è”ç³»ä¸æ–‡ç‰ˆç»´æŠ¤è€…:: - - ä¸æ–‡ç‰ˆç»´æŠ¤è€…： æŽé˜³ Li Yang <leoyang.li@nxp.com> - ä¸æ–‡ç‰ˆç¿»è¯‘者： æŽé˜³ Li Yang <leoyang.li@nxp.com> - ä¸æ–‡ç‰ˆæ ¡è¯‘者： é™ˆç¦ Maggie Chen <chenqi@beyondsoft.com> - çŽ‹èª Wang Cong <xiyou.wangcong@gmail.com> - å¼ å· Zhang Wei <wezhang@outlook.com> - -å¦‚ä½•å‘ Linux å†…æ ¸æäº¤é©±åŠ¨ç¨‹åº -============================= - -这篇文档将会解释如何å‘ä¸åŒçš„å†…æ ¸æºç æ ‘æ交设备驱动程åºã€‚请注æ„ï¼Œå¦‚æžœä½ æ„Ÿ -兴趣的是显å¡é©±åŠ¨ç¨‹åºï¼Œä½ 也许应该访问 XFree86 项目(https://www.xfree86.org/) -å’Œï¼æˆ– X.org 项目 (https://x.org)。 - -å¦è¯·å‚阅 Documentation/translations/zh_CN/process/submitting-patches.rst 文档。 - - -分é…è®¾å¤‡å· ----------- - -å—设备和å—符设备的主设备å·ä¸Žä»Žè®¾å¤‡å·æ˜¯ç”± Linux 命åç¼–å·åˆ†é…æƒå¨ LANANA（ -现在是 Torben Mathiasen）负责分é…。申请的网å€æ˜¯ https://www.lanana.org/。 -å³ä½¿ä¸å‡†å¤‡æ交到主æµå†…æ ¸çš„è®¾å¤‡é©±åŠ¨ä¹Ÿéœ€è¦åœ¨è¿™é‡Œåˆ†é…设备å·ã€‚有关详细信æ¯ï¼Œ -请å‚阅 Documentation/admin-guide/devices.rst。 - -å¦‚æžœä½ ä½¿ç”¨çš„ä¸æ˜¯å·²ç»åˆ†é…的设备å·ï¼Œé‚£ä¹ˆå½“ä½ æ交设备驱动的时候，它将会被强 -制分é…一个新的设备å·ï¼Œå³ä¾¿è¿™ä¸ªè®¾å¤‡å·å’Œä½ 之å‰å‘给客户的截然ä¸åŒã€‚ - -设备驱动的æ交对象 ------------------- - -Linux 2.0: - æ¤å†…æ ¸æºç æ ‘ä¸æŽ¥å—新的驱动程åºã€‚ - -Linux 2.2: - æ¤å†…æ ¸æºç æ ‘ä¸æŽ¥å—新的驱动程åºã€‚ - -Linux 2.4: - 如果所属的代ç é¢†åŸŸåœ¨å†…æ ¸çš„ MAINTAINERS 文件ä¸åˆ—有一个总维护者， - 那么请将驱动程åºæ交给他。如果æ¤ç»´æŠ¤è€…æ²¡æœ‰å›žåº”æˆ–è€…ä½ æ‰¾ä¸åˆ°æ°å½“çš„ - 维护者，那么请è”ç³» Willy Tarreau <w@1wt.eu>。 - -Linux 2.6: - 除了éµå¾ªå’Œ 2.4 ç‰ˆå†…æ ¸åŒæ ·çš„è§„åˆ™å¤–ï¼Œä½ è¿˜éœ€è¦åœ¨ linux-kernel 邮件 - 列表上跟踪最新的 API å˜åŒ–ã€‚å‘ Linux 2.6 å†…æ ¸æ交驱动的顶级è”系人 - 是 Andrew Morton <akpm@linux-foundation.org>。 - -决定设备驱动能å¦è¢«æŽ¥å—çš„æ¡ä»¶ ----------------------------- - -许å¯ï¼š 代ç 必须使用 GNU 通用公开许å¯è¯ (GPL) æ交给 Linux，但是 - 我们并ä¸è¦æ±‚ GPL 是唯一的许å¯ã€‚ä½ æˆ–è®¸ä¼šå¸Œæœ›åŒæ—¶ä½¿ç”¨å¤šç§ - 许å¯è¯å‘布，如果希望驱动程åºå¯ä»¥è¢«å…¶ä»–å¼€æºç¤¾åŒºï¼ˆæ¯”如BSD） - 使用。请å‚考 include/linux/module.h 文件ä¸æ‰€åˆ—出的å¯è¢« - 接å—å…±å˜çš„许å¯ã€‚ - -版æƒï¼š 版æƒæ‰€æœ‰è€…å¿…é¡»åŒæ„使用 GPL 许å¯ã€‚最好æ交者和版æƒæ‰€æœ‰è€… - 是相åŒä¸ªäººæˆ–实体。å¦åˆ™ï¼Œå¿…需列出授æƒä½¿ç”¨ GPL 的版æƒæ‰€æœ‰ - 人或实体，以备验è¯ä¹‹éœ€ã€‚ - -接å£ï¼š å¦‚æžœä½ çš„é©±åŠ¨ç¨‹åºä½¿ç”¨çŽ°æˆçš„接å£å¹¶ä¸”和其他åŒç±»çš„驱动程åºè¡Œ - 为相似，而ä¸æ˜¯åŽ»å‘æ˜Žæ— è°“çš„æ–°æŽ¥å£ï¼Œé‚£ä¹ˆå®ƒå°†ä¼šæ›´å®¹æ˜“被接å—。 - å¦‚æžœä½ éœ€è¦ä¸€ä¸ª Linux å’Œ NT 的通用驱动接å£ï¼Œé‚£ä¹ˆè¯·åœ¨ç”¨ - 户空间实现它。 - -代ç ： 请使用 Documentation/process/coding-style.rst ä¸æ‰€æè¿°çš„ Linux 代ç 风 - æ ¼ã€‚å¦‚æžœä½ çš„æŸäº›ä»£ç 段（例如那些与 Windows 驱动程åºåŒ…å…± - 享的代ç 段）需è¦ä½¿ç”¨å…¶ä»–æ ¼å¼ï¼Œè€Œä½ å´åªå¸Œæœ›ç»´æŠ¤ä¸€ä»½ä»£ç ， - 那么请将它们很好地区分出æ¥ï¼Œå¹¶ä¸”æ³¨æ˜ŽåŽŸå› ã€‚ - -å¯ç§»æ¤æ€§ï¼š 请注æ„，指针并ä¸æ°¸è¿œæ˜¯ 32 ä½çš„，ä¸æ˜¯æ‰€æœ‰çš„è®¡ç®—æœºéƒ½ä½¿ç”¨å° - å°¾æ¨¡å¼ (little endian) å˜å‚¨æ•°æ®ï¼Œä¸æ˜¯æ‰€æœ‰çš„人都拥有浮点 - å•å…ƒï¼Œä¸è¦éšä¾¿åœ¨ä½ 的驱动程åºé‡ŒåµŒå…¥ x86 汇编指令。åªèƒ½åœ¨ - x86 上è¿è¡Œçš„驱动程åºä¸€èˆ¬æ˜¯ä¸å—æ¬¢è¿Žçš„ã€‚è™½ç„¶ä½ å¯èƒ½åªæœ‰ x86 - 硬件，很难测试驱动程åºåœ¨å…¶ä»–å¹³å°ä¸Šæ˜¯å¦å¯ç”¨ï¼Œä½†æ˜¯ç¡®ä¿ä»£ç - å¯ä»¥è¢«è½»æ¾åœ°ç§»æ¤å´æ˜¯å¾ˆç®€å•çš„。 - -清晰度： åšåˆ°æ‰€æœ‰äººéƒ½èƒ½ä¿®è¡¥è¿™ä¸ªé©±åŠ¨ç¨‹åºå°†ä¼šå¾ˆæœ‰å¥½å¤„ï¼Œå› ä¸ºè¿™æ ·ä½ å°† - 会直接收到修å¤çš„è¡¥ä¸è€Œä¸æ˜¯ bug æŠ¥å‘Šã€‚å¦‚æžœä½ æ交一个试图 - éšè—硬件工作机ç†çš„驱动程åºï¼Œé‚£ä¹ˆå®ƒå°†ä¼šè¢«æ‰”进废纸篓。 - -电æºç®¡ç†ï¼š å› ä¸º Linux æ£åœ¨è¢«å¾ˆå¤šç§»åŠ¨è®¾å¤‡å’Œæ¡Œé¢ç³»ç»Ÿä½¿ç”¨ï¼Œæ‰€ä»¥ä½ 的驱 - 动程åºä¹Ÿå¾ˆæœ‰å¯èƒ½è¢«ä½¿ç”¨åœ¨è¿™äº›è®¾å¤‡ä¸Šã€‚它应该支æŒæœ€åŸºæœ¬çš„电 - æºç®¡ç†ï¼Œå³åœ¨éœ€è¦çš„æƒ…å†µä¸‹å®žçŽ°ç³»ç»Ÿçº§ä¼‘çœ å’Œå”¤é†’è¦ç”¨åˆ°çš„ - .suspend å’Œ .resume å‡½æ•°ã€‚ä½ åº”è¯¥æ£€æŸ¥ä½ çš„é©±åŠ¨ç¨‹åºæ˜¯å¦èƒ½æ£ - 确地处ç†ä¼‘çœ ä¸Žå”¤é†’ï¼Œå¦‚æžœå®žåœ¨æ— æ³•ç¡®è®¤ï¼Œè¯·è‡³å°‘æŠŠ .suspend - 函数定义æˆè¿”回 -ENOSYSï¼ˆåŠŸèƒ½æœªå®žçŽ°ï¼‰é”™è¯¯ã€‚ä½ è¿˜åº”è¯¥å°è¯•ç¡® - ä¿ä½ 的驱动在什么都ä¸å¹²çš„情况下将耗电é™åˆ°æœ€ä½Žã€‚è¦èŽ·å¾—驱动 - 程åºæµ‹è¯•çš„指导，请å‚阅 - Documentation/power/drivers-testing.rst。有关驱动程åºç”µ - æºç®¡ç†é—®é¢˜ç›¸å¯¹å…¨é¢çš„概述，请å‚阅 - Documentation/driver-api/pm/devices.rst。 - -管ç†ï¼š 如果一个驱动程åºçš„作者还在进行有效的维护，那么通常除了那 - 些明显æ£ç¡®ä¸”ä¸éœ€è¦ä»»ä½•æ£€æŸ¥çš„è¡¥ä¸ä»¥å¤–，其他所有的补ä¸éƒ½ä¼š - 被转å‘ç»™ä½œè€…ã€‚å¦‚æžœä½ å¸Œæœ›æˆä¸ºé©±åŠ¨ç¨‹åºçš„è”系人和更新者，最 - 好在代ç 注释ä¸å†™æ˜Žå¹¶ä¸”在 MAINTAINERS 文件ä¸åŠ 入这个驱动 - 程åºçš„æ¡ç›®ã€‚ - -ä¸å½±å“设备驱动能å¦è¢«æŽ¥å—çš„æ¡ä»¶ ------------------------------- - -供应商： 由硬件供应商æ¥ç»´æŠ¤é©±åŠ¨ç¨‹åºé€šå¸¸æ˜¯ä¸€ä»¶å¥½äº‹ã€‚ä¸è¿‡ï¼Œå¦‚æžœæºç - æ ‘é‡Œå·²ç»æœ‰å…¶ä»–人æ供了å¯ç¨³å®šå·¥ä½œçš„驱动程åºï¼Œé‚£ä¹ˆè¯·ä¸è¦æœŸ - 望“我是供应商â€ä¼šæˆä¸ºå†…æ ¸æ”¹ç”¨ä½ çš„é©±åŠ¨ç¨‹åºçš„ç†ç”±ã€‚ç†æƒ³çš„情 - 况是：供应商与现有驱动程åºçš„作者åˆä½œï¼Œæž„建一个统一完美的 - 驱动程åºã€‚ - -作者： 驱动程åºæ˜¯ç”±å¤§çš„ Linux å…¬å¸ç ”å‘è¿˜æ˜¯ç”±ä½ ä¸ªäººç¼–å†™ï¼Œå¹¶ä¸å½± - å“其是å¦èƒ½è¢«å†…æ ¸æŽ¥å—ã€‚æ²¡æœ‰äººå¯¹å†…æ ¸æºç æ ‘äº«æœ‰ç‰¹æƒã€‚åªè¦ä½ - å……åˆ†äº†è§£å†…æ ¸ç¤¾åŒºï¼Œä½ å°±ä¼šå‘现这一点。 - - -资æºåˆ—表 --------- - -Linux å†…æ ¸ä¸»æºç æ ‘ï¼š - ftp.??.kernel.org:/pub/linux/kernel/... - ?? == ä½ çš„å›½å®¶ä»£ç ，例如 "cn"ã€"us"ã€"uk"ã€"fr" ç‰ç‰ - -Linux å†…æ ¸é‚®ä»¶åˆ—è¡¨ï¼š - linux-kernel@vger.kernel.org - [å¯é€šè¿‡å‘majordomo@vger.kernel.orgå‘邮件æ¥è®¢é˜…] - -Linux 设备驱动程åºï¼Œç¬¬ä¸‰ç‰ˆï¼ˆæŽ¢è®¨ 2.6.10 ç‰ˆå†…æ ¸ï¼‰ï¼š - https://lwn.net/Kernel/LDD3/ （å…费版） - -LWN.net: - æ¯å‘¨å†…æ ¸å¼€å‘æ´»åŠ¨æ‘˜è¦ - https://lwn.net/ - - 2.6 ç‰ˆä¸ API çš„å˜æ›´ï¼š - - https://lwn.net/Articles/2.6-kernel-api/ - - å°†æ—§ç‰ˆå†…æ ¸çš„é©±åŠ¨ç¨‹åºç§»æ¤åˆ° 2.6 版： - - https://lwn.net/Articles/driver-porting/ - -å†…æ ¸æ–°æ‰‹(KernelNewbies): - ä¸ºæ–°çš„å†…æ ¸å¼€å‘者æ供文档和帮助 - https://kernelnewbies.org/ - -Linux USB项目： - http://www.linux-usb.org/ - -å†™å†…æ ¸é©±åŠ¨çš„â€œä¸è¦â€ï¼ˆArjan van de Ven著）: - http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf - -å†…æ ¸æ¸…æ´å·¥ (Kernel Janitor): - https://kernelnewbies.org/KernelJanitors diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index a9570165582a..ebb7f37575c1 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -23,9 +23,7 @@ 以下文档å«æœ‰å¤§é‡ç®€æ´çš„建议， 具体请è§ï¼š :ref:`Documentation/process <development_process_main>` åŒæ ·ï¼Œ:ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>` -给出在æ交代ç å‰éœ€è¦æ£€æŸ¥çš„é¡¹ç›®çš„åˆ—è¡¨ã€‚å¦‚æžœä½ åœ¨æ交一个驱动程åºï¼Œé‚£ä¹ˆ -åŒæ—¶é˜…读一下: -:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` +给出在æ交代ç å‰éœ€è¦æ£€æŸ¥çš„项目的列表。 å…¶ä¸è®¸å¤šæ¥éª¤æ述了Git版本控制系统的默认行为；如果您使用Gitæ¥å‡†å¤‡è¡¥ä¸ï¼Œ 您将å‘现它为您完æˆçš„大部分机械工作，尽管您ä»ç„¶éœ€è¦å‡†å¤‡å’Œè®°å½•ä¸€ç»„åˆç†çš„ diff --git a/Documentation/translations/zh_CN/riscv/index.rst b/Documentation/translations/zh_CN/riscv/index.rst index 614cde0c0997..131e405aa857 100644 --- a/Documentation/translations/zh_CN/riscv/index.rst +++ b/Documentation/translations/zh_CN/riscv/index.rst @@ -19,7 +19,6 @@ RISC-V 体系结构 boot-image-header vm-layout - pmu patch-acceptance diff --git a/Documentation/translations/zh_CN/riscv/pmu.rst b/Documentation/translations/zh_CN/riscv/pmu.rst deleted file mode 100644 index 7ec801026c4d..000000000000 --- a/Documentation/translations/zh_CN/riscv/pmu.rst +++ /dev/null @@ -1,235 +0,0 @@ -.. include:: ../disclaimer-zh_CN.rst - -:Original: Documentation/riscv/pmu.rst - -:翻译: - - å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> - -.. _cn_riscv_pmu: - -======================== -RISC-Vå¹³å°ä¸Šå¯¹PMUsçš„æ”¯æŒ -======================== - -Alan Kao <alankao@andestech.com>, Mar 2018 - -简介 ------------- - -截æ¢æœ¬æ–‡æ’°å†™æ—¶ï¼Œåœ¨The RISC-V ISA Privileged Version 1.10ä¸æ到的 perf_event -相关特性如下: -（详情请查阅手册） - -* [m|s]counteren -* mcycle[h], cycle[h] -* minstret[h], instret[h] -* mhpeventx, mhpcounterx[h] - -仅有以上这些功能，移æ¤perf需è¦åšå¾ˆå¤šå·¥ä½œï¼Œç©¶å…¶åŽŸå› 是缺少以下通用架构的性能 -监测特性: - -* å¯ç”¨/åœç”¨è®¡æ•°å™¨ - 在我们这里，计数器一直在自由è¿è¡Œã€‚ -* 计数器溢出引起的ä¸æ– - 规范ä¸æ²¡æœ‰è¿™ç§åŠŸèƒ½ã€‚ -* ä¸æ–指示器 - ä¸å¯èƒ½æ‰€æœ‰çš„计数器都有很多的ä¸æ–端å£ï¼Œæ‰€ä»¥éœ€è¦ä¸€ä¸ªä¸æ–指示器让软件æ¥åˆ¤æ– - 哪个计数器刚好溢出。 -* 写入计数器 - ç”±äºŽå†…æ ¸ä¸èƒ½ä¿®æ”¹è®¡æ•°å™¨ï¼Œæ‰€ä»¥ä¼šæœ‰ä¸€ä¸ªSBIæ¥æ”¯æŒè¿™ä¸ªåŠŸèƒ½[1]。 å¦å¤–，一些厂商 - 考虑实现M-S-Uåž‹å·æœºå™¨çš„硬件扩展æ¥ç›´æŽ¥å†™å…¥è®¡æ•°å™¨ã€‚ - -这篇文档旨在为开å‘者æä¾›ä¸€ä¸ªåœ¨å†…æ ¸ä¸æ”¯æŒPMU的简è¦æŒ‡å—。下é¢çš„ç« èŠ‚ç®€è¦è§£é‡Šäº† -perf' 机制和待办事项。 - -ä½ å¯ä»¥åœ¨è¿™é‡ŒæŸ¥çœ‹ä»¥å‰çš„讨论[1][2]。 å¦å¤–，查看附录ä¸çš„ç›¸å…³å†…æ ¸ç»“æž„ä½“å¯èƒ½ä¼šæœ‰ -帮助。 - - -1. åˆå§‹åŒ– ---------- - -*riscv_pmu* 是一个类型为 *struct riscv_pmu* 的全局指针，它包å«äº†æ ¹æ®perf内部 -约定的å„ç§æ–¹æ³•å’ŒPMU-specificå‚æ•°ã€‚äººä»¬åº”è¯¥å£°æ˜Žè¿™æ ·çš„å®žä¾‹æ¥ä»£è¡¨PMU。 默认情况 -下， *riscv_pmu* 指å‘一个常é‡ç»“构体 *riscv_base_pmu* ，它对基准QEMU模型有éžå¸¸ -基础的支æŒã€‚ - - -然åŽä»–/她å¯ä»¥å°†å®žä¾‹çš„指针分é…ç»™ *riscv_pmu* ï¼Œè¿™æ ·å°±å¯ä»¥åˆ©ç”¨å·²ç»å®žçŽ°çš„最å°é€» -辑，或者创建他/她自己的 *riscv_init_platform_pmu* 实现。 - -æ¢å¥è¯è¯´ï¼ŒçŽ°æœ‰çš„ *riscv_base_pmu* æºåªæ˜¯æ供了一个å‚考实现。 å¼€å‘者å¯ä»¥çµæ´»åœ° -决定多少部分å¯ç”¨ï¼Œåœ¨æœ€æžç«¯çš„情况下，他们å¯ä»¥æ ¹æ®è‡ªå·±çš„需è¦å®šåˆ¶æ¯ä¸€ä¸ªå‡½æ•°ã€‚ - - -2. Event Initialization ------------------------ - -当用户å¯åŠ¨perf命令æ¥ç›‘控一些事件时，首先会被用户空间的perf工具解释为多个 -*perf_event_open* 系统调用，然åŽè¿›ä¸€æ¥è°ƒç”¨ä¸Šä¸€æ¥åˆ†é…çš„ *event_init* æˆå‘˜å‡½æ•° -的主体。 在 *riscv_base_pmu* 的情况下，就是 *riscv_event_init* 。 - -该功能的主è¦ç›®çš„是将用户æ供的事件翻译æˆæ˜ 射图，从而å¯ä»¥ç›´æŽ¥å¯¹HW-related的控 -制寄å˜å™¨æˆ–计数器进行æ“作。该翻译基于 *riscv_pmu* ä¸æä¾›çš„æ˜ å°„å’Œæ–¹æ³•ã€‚ - -注æ„，有些功能也å¯ä»¥åœ¨è¿™ä¸ªé˜¶æ®µå®Œæˆ: - -(1) ä¸æ–设置，这个在下一节说； -(2) 特é™çº§è®¾ç½®(仅用户空间ã€ä»…å†…æ ¸ç©ºé—´ã€ä¸¤è€…都有)ï¼› -(3) æžæž„函数设置。 通常应用 *riscv_destroy_event* å³å¯ï¼› -(4) 对éžé‡‡æ ·äº‹ä»¶çš„调整，这将被函数应用，如 *perf_adjust_period* ，通常如下:: - - if (!is_sampling_event(event)) { - hwc->sample_period = x86_pmu.max_period; - hwc->last_period = hwc->sample_period; - local64_set(&hwc->period_left, hwc->sample_period); - } - - -在 *riscv_base_pmu* 的情况下，目å‰åªæ供了（3）。 - - -3. ä¸æ– -------- - -3.1. ä¸æ–åˆå§‹åŒ– - -è¿™ç§æƒ…况ç»å¸¸å‡ºçŽ°åœ¨ *event_init* 方案的开头。通常情况下，这应该是一个代ç 段，如:: - - int x86_reserve_hardware(void) - { - int err = 0; - - if (!atomic_inc_not_zero(&pmc_refcount)) { - mutex_lock(&pmc_reserve_mutex); - if (atomic_read(&pmc_refcount) == 0) { - if (!reserve_pmc_hardware()) - err = -EBUSY; - else - reserve_ds_buffers(); - } - if (!err) - atomic_inc(&pmc_refcount); - mutex_unlock(&pmc_reserve_mutex); - } - - return err; - } - -而神奇的是 *reserve_pmc_hardware* ，它通常åšåŽŸåæ“作，使实现的IRQå¯ä»¥ä»ŽæŸä¸ªå…¨å±€å‡½ -数指针访问。 而 *release_pmc_hardware* 的作用æ£å¥½ç›¸å，它用在上一节æåˆ°çš„äº‹ä»¶åˆ†é… -器ä¸ã€‚ - - (注：从所有架构的实现æ¥çœ‹ï¼Œ*reserve/release* 对总是IRQ设置，所以 *pmc_hardware* - 似乎有些误导。 它并ä¸å¤„ç†äº‹ä»¶å’Œç‰©ç†è®¡æ•°å™¨ä¹‹é—´çš„绑定，这一点将在下一节介ç»ã€‚) - -3.2. IRQ结构体 - -基本上，一个IRQè¿è¡Œä»¥ä¸‹ä¼ªä»£ç :: - - for each hardware counter that triggered this overflow - - get the event of this counter - - // following two steps are defined as *read()*, - // check the section Reading/Writing Counters for details. - count the delta value since previous interrupt - update the event->count (# event occurs) by adding delta, and - event->hw.period_left by subtracting delta - - if the event overflows - sample data - set the counter appropriately for the next overflow - - if the event overflows again - too frequently, throttle this event - fi - fi - - end for - - 然而截至目å‰ï¼Œæ²¡æœ‰ä¸€ä¸ªRISC-V的实现为perf设计了ä¸æ–，所以具体的实现è¦åœ¨æœªæ¥å®Œæˆã€‚ - -4. Reading/Writing 计数 ------------------------ - -它们看似差ä¸å¤šï¼Œä½†perf对待它们的æ€åº¦å´æˆªç„¶ä¸åŒã€‚ 对于读，在 *struct pmu* ä¸æœ‰ä¸€ä¸ª -*read* 接å£ï¼Œä½†å®ƒçš„作用ä¸ä»…仅是读。 æ ¹æ®ä¸Šä¸‹æ–‡ï¼Œ*read* 函数ä¸ä»…è¦è¯»å–计数器的内容 -（event->count），还è¦æ›´æ–°å·¦å‘¨æœŸåˆ°ä¸‹ä¸€ä¸ªä¸æ–（event->hw.period_left）。 - - 但 perf çš„æ ¸å¿ƒä¸éœ€è¦ç›´æŽ¥å†™è®¡æ•°å™¨ã€‚ 写计数器éšè—在以下两点的抽象化之åŽï¼Œ - 1） *pmu->start* ，从å—é¢ä¸Šçœ‹å°±æ˜¯å¼€å§‹è®¡æ•°ï¼Œæ‰€ä»¥å¿…须把计数器设置æˆä¸€ä¸ªåˆé€‚的值，以 - 便下一次ä¸æ–ï¼› - 2）在IRQ里é¢ï¼Œåº”该把计数器设置æˆåŒæ ·çš„åˆç†å€¼ã€‚ - -在RISC-Vä¸ï¼Œè¯»æ“作ä¸æ˜¯é—®é¢˜ï¼Œä½†å†™æ“作就需è¦è´¹äº›åŠ›æ°”äº†ï¼Œå› ä¸ºS模å¼ä¸å…许写计数器。 - - -5. add()/del()/start()/stop() ------------------------------ - -基本æ€æƒ³: add()/del() å‘PMUæ·»åŠ /åˆ é™¤äº‹ä»¶ï¼Œstart()/stop() å¯åŠ¨/åœæ¢PMUä¸æŸä¸ªäº‹ä»¶ -的计数器。 所有这些函数都使用相åŒçš„å‚æ•°: *struct perf_event *event* å’Œ *int flag* 。 - -把 perf 看作一个状æ€æœºï¼Œé‚£ä¹ˆä½ 会å‘现这些函数作为这些状æ€ä¹‹é—´çš„状æ€è½¬æ¢è¿‡ç¨‹ã€‚ -定义了三ç§çŠ¶æ€ï¼ˆevent->hw.state）: - -* PERF_HES_STOPPED: 计数åœæ¢ -* PERF_HES_UPTODATE: event->count是最新的 -* PERF_HES_ARCH: ä¾èµ–于体系结构的用法，。。。我们现在并ä¸éœ€è¦å®ƒã€‚ - -这些状æ€è½¬æ¢çš„æ£å¸¸æµç¨‹å¦‚下: - -* 用户å¯åŠ¨ä¸€ä¸ª perf 事件，导致调用 *event_init* 。 -* 当被上下文切æ¢è¿›æ¥çš„时候，*add* 会被 perf core è°ƒç”¨ï¼Œå¹¶å¸¦æœ‰ä¸€ä¸ªæ ‡å¿— PERF_EF_START， - ä¹Ÿå°±æ˜¯è¯´äº‹ä»¶è¢«æ·»åŠ åŽåº”该被å¯åŠ¨ã€‚ 在这个阶段，如果有的è¯ï¼Œä¸€èˆ¬äº‹ä»¶ä¼šè¢«ç»‘定到一个物 - ç†è®¡æ•°å™¨ä¸Šã€‚当状æ€å˜ä¸ºPERF_HES_STOPPEDå’ŒPERF_HES_UPTODATEï¼Œå› ä¸ºçŽ°åœ¨å·²ç»åœæ¢äº†, - （软件）事件计数ä¸éœ€è¦æ›´æ–°ã€‚ - - - 然åŽè°ƒç”¨ *start* ，并å¯ç”¨è®¡æ•°å™¨ã€‚ - 通过PERF_EF_RELOADæ ‡å¿—ï¼Œå®ƒå‘计数器写入一个适当的值（详细情况请å‚考上一节）。 - å¦‚æžœæ ‡å¿—ä¸åŒ…å«PERF_EF_RELOAD，则ä¸ä¼šå†™å…¥ä»»ä½•å†…容。 - 现在状æ€è¢«é‡ç½®ä¸ºnoneï¼Œå› ä¸ºå®ƒæ—¢æ²¡æœ‰åœæ¢ä¹Ÿæ²¡æœ‰æ›´æ–°ï¼ˆè®¡æ•°å·²ç»å¼€å§‹ï¼‰ã€‚ - -*当被上下文切æ¢å‡ºæ¥æ—¶è¢«è°ƒç”¨ã€‚ 然åŽï¼Œå®ƒæ£€æŸ¥å‡ºPMUä¸çš„所有事件，并调用 *stop* æ¥æ›´æ–°å®ƒä»¬ - 的计数。 - - - *stop* 被 *del* å’Œperfæ ¸å¿ƒè°ƒç”¨ï¼Œæ ‡å¿—ä¸ºPERF_EF_UPDATE，它ç»å¸¸ä»¥ç›¸åŒçš„逻辑和 *read* - 共用åŒä¸€ä¸ªå程åºã€‚ - 状æ€åˆä¸€æ¬¡å˜ä¸ºPERF_HES_STOPPEDå’ŒPERF_HES_UPTODATE。 - - - 这两对程åºçš„生命周期: *add* å’Œ *del* 在任务切æ¢æ—¶è¢«åå¤è°ƒç”¨ï¼›*start* å’Œ *stop* 在 - perfæ ¸å¿ƒéœ€è¦å¿«é€Ÿåœæ¢å’Œå¯åŠ¨æ—¶ä¹Ÿä¼šè¢«è°ƒç”¨ï¼Œæ¯”如在调整ä¸æ–周期时。 - -ç›®å‰çš„实现已ç»è¶³å¤Ÿäº†ï¼Œå°†æ¥å¯ä»¥å¾ˆå®¹æ˜“地扩展到功能。 - -A. 相关结构体 -------------- - -* struct pmu: include/linux/perf_event.h -* struct riscv_pmu: arch/riscv/include/asm/perf_event.h - - 两个结构体都被设计为åªè¯»ã€‚ - - *struct pmu* 定义了一些函数指针接å£ï¼Œå®ƒä»¬å¤§å¤šä»¥ *struct perf_event* 作为主å‚æ•°ï¼Œæ ¹æ® - perf的内部状æ€æœºå¤„ç†perf事件（详情请查看kernel/events/core.c）。 - - *struct riscv_pmu* 定义了PMU的具体å‚数。 命åéµå¾ªæ‰€æœ‰å…¶å®ƒæž¶æž„的惯例。 - -* struct perf_event: include/linux/perf_event.h -* struct hw_perf_event - - 表示 perf 事件的通用结构体，以åŠç¡¬ä»¶ç›¸å…³çš„细节。 - -* struct riscv_hw_events: arch/riscv/include/asm/perf_event.h - - ä¿å˜äº‹ä»¶çŠ¶æ€çš„结构有两个固定æˆå‘˜ã€‚ - 事件的数é‡å’Œäº‹ä»¶çš„数组。 - -å‚考文献 --------- - -[1] https://github.com/riscv/riscv-linux/pull/124 - -[2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/f19TmCNP6yA diff --git a/Documentation/translations/zh_CN/riscv/vm-layout.rst b/Documentation/translations/zh_CN/riscv/vm-layout.rst index 585cb89317a3..91884e2dfff8 100644 --- a/Documentation/translations/zh_CN/riscv/vm-layout.rst +++ b/Documentation/translations/zh_CN/riscv/vm-layout.rst @@ -6,6 +6,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + Binbin Zhou <zhoubinbin@loongson.cn> ============================ RISC-V Linux上的虚拟内å˜å¸ƒå±€ @@ -65,3 +66,39 @@ RISC-V Linux Kernel SV39 ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel __________________|____________|__________________|_________|____________________________________________________________ + + +RISC-V Linux Kernel SV48 +------------------------ + +:: + + ======================================================================================================================== + å¼€å§‹åœ°å€ | å移 | 结æŸåœ°å€ | å¤§å° | 虚拟内å˜åŒºåŸŸæè¿° + ======================================================================================================================== + | | | | + 0000000000000000 | 0 | 00007fffffffffff | 128 TB | 用户空间虚拟内å˜ï¼Œæ¯ä¸ªå†…å˜ç®¡ç†å™¨ä¸åŒ + __________________|____________|__________________|_________|___________________________________________________________ + | | | | + 0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... 巨大的ã€å‡ 乎64ä½å®½çš„ç›´åˆ°å†…æ ¸æ˜ å°„çš„-128TB地方 + | | | | 开始å移的éžç»å…¸è™šæ‹Ÿå†…å˜åœ°å€ç©ºæ´žã€‚ + | | | | + __________________|____________|__________________|_________|___________________________________________________________ + | + | å†…æ ¸ç©ºé—´çš„è™šæ‹Ÿå†…å˜ï¼Œåœ¨æ‰€æœ‰è¿›ç¨‹ä¹‹é—´å…±äº«: + ____________________________________________________________|___________________________________________________________ + | | | | + ffff8d7ffee00000 | -114.5 TB | ffff8d7ffeffffff | 2 MB | fixmap + ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io + ffff8d8000000000 | -114.5 TB | ffff8f7fffffffff | 2 TB | vmemmap + ffff8f8000000000 | -112.5 TB | ffffaf7fffffffff | 32 TB | vmalloc/ioremap space + ffffaf8000000000 | -80.5 TB | ffffef7fffffffff | 64 TB | ç›´æŽ¥æ˜ å°„æ‰€æœ‰ç‰©ç†å†…å˜ + ffffef8000000000 | -16.5 TB | fffffffeffffffff | 16.5 TB | kasan + __________________|____________|__________________|_________|____________________________________________________________ + | + | 从æ¤å¤„开始，与39-bit布局相åŒï¼š + ____________________________________________________________|____________________________________________________________ + | | | | + ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF + ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel + __________________|____________|__________________|_________|____________________________________________________________ diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst index 1c68c3d1c283..c5e0be663837 100644 --- a/Documentation/translations/zh_CN/scheduler/sched-stats.rst +++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst @@ -57,8 +57,8 @@ cpu<N> 1 2 3 4 5 6 7 8 9 接下æ¥çš„三个统计数æ®æ述了调度延迟： - 7) 本处ç†å™¨è¿è¡Œä»»åŠ¡çš„总时间，å•ä½æ˜¯jiffies - 8) 本处ç†å™¨ä»»åŠ¡ç‰å¾…è¿è¡Œçš„时间，å•ä½æ˜¯jiffies + 7) 本处ç†å™¨è¿è¡Œä»»åŠ¡çš„总时间，å•ä½æ˜¯çº³ç§’ + 8) 本处ç†å™¨ä»»åŠ¡ç‰å¾…è¿è¡Œçš„时间，å•ä½æ˜¯çº³ç§’ 9) 本CPUè¿è¡Œäº†#个时间片 åŸŸç»Ÿè®¡æ•°æ® @@ -146,8 +146,8 @@ domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 schedstatsè¿˜æ·»åŠ äº†ä¸€ä¸ªæ–°çš„/proc/<pid>/schedstat文件，æ¥æ供一些进程级的 相åŒä¿¡æ¯ã€‚这个文件ä¸ï¼Œæœ‰ä¸‰ä¸ªå—段与该进程相关： - 1) 在CPU上è¿è¡ŒèŠ±è´¹çš„时间 - 2) 在è¿è¡Œé˜Ÿåˆ—上ç‰å¾…的时间 + 1) 在CPU上è¿è¡ŒèŠ±è´¹çš„时间(å•ä½æ˜¯çº³ç§’) + 2) 在è¿è¡Œé˜Ÿåˆ—上ç‰å¾…的时间(å•ä½æ˜¯çº³ç§’) 3) 在CPU上è¿è¡Œäº†#个时间片 å¯ä»¥å¾ˆå®¹æ˜“地编写一个程åºï¼Œåˆ©ç”¨è¿™äº›é¢å¤–çš„å—段æ¥æŠ¥å‘Šä¸€ä¸ªç‰¹å®šçš„进程或一组进程在 diff --git a/Documentation/translations/zh_CN/vm/highmem.rst b/Documentation/translations/zh_CN/vm/highmem.rst deleted file mode 100644 index 018838e58c3e..000000000000 --- a/Documentation/translations/zh_CN/vm/highmem.rst +++ /dev/null @@ -1,128 +0,0 @@ -.. include:: ../disclaimer-zh_CN.rst - -:Original: Documentation/vm/highmem.rst - -:翻译: - - å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> - -:æ ¡è¯‘: - -========== -高内å˜å¤„ç† -========== - -作者: Peter Zijlstra <a.p.zijlstra@chello.nl> - -.. contents:: :local: - -高内å˜æ˜¯ä»€ä¹ˆï¼Ÿ -============== - -当物ç†å†…å˜çš„大å°æŽ¥è¿‘或超过虚拟内å˜çš„最大大å°æ—¶ï¼Œå°±ä¼šä½¿ç”¨é«˜å†…å˜ï¼ˆhighmem）。在这一点上，内 -æ ¸ä¸å¯èƒ½åœ¨ä»»ä½•æ—¶å€™éƒ½ä¿æŒæ‰€æœ‰å¯ç”¨çš„物ç†å†…å˜çš„æ˜ å°„ã€‚è¿™æ„味ç€å†…æ ¸éœ€è¦å¼€å§‹ä½¿ç”¨å®ƒæƒ³è®¿é—®çš„物ç†å†… -å˜çš„ä¸´æ—¶æ˜ å°„ã€‚ - -æ²¡æœ‰è¢«æ°¸ä¹…æ˜ å°„è¦†ç›–çš„é‚£éƒ¨åˆ†ï¼ˆç‰©ç†ï¼‰å†…å˜å°±æ˜¯æˆ‘们所说的 "高内å˜"。对于这个边界的确切ä½ç½®ï¼Œæœ‰ -å„ç§æž¶æž„上的é™åˆ¶ã€‚ - -例如，在i386架构ä¸ï¼Œæˆ‘ä»¬é€‰æ‹©å°†å†…æ ¸æ˜ å°„åˆ°æ¯ä¸ªè¿›ç¨‹çš„è™šæ‹Ÿç©ºé—´ï¼Œè¿™æ ·æˆ‘ä»¬å°±ä¸å¿…ä¸ºå†…æ ¸çš„è¿›å…¥/退 -出付出全部的TLB作废代价。这æ„味ç€å¯ç”¨çš„虚拟内å˜ç©ºé—´ï¼ˆi386上为4GiBï¼‰å¿…é¡»åœ¨ç”¨æˆ·å’Œå†…æ ¸ç©ºé—´ä¹‹ -间进行划分。 - -使用这ç§æ–¹æ³•çš„æž¶æž„çš„ä¼ ç»Ÿåˆ†é…æ–¹å¼æ˜¯3:1，3GiB用于用户空间，顶部的1GiBç”¨äºŽå†…æ ¸ç©ºé—´ã€‚:: - - +--------+ 0xffffffff - | Kernel | - +--------+ 0xc0000000 - | | - | User | - | | - +--------+ 0x00000000 - -è¿™æ„味ç€å†…æ ¸åœ¨ä»»ä½•æ—¶å€™æœ€å¤šå¯ä»¥æ˜ å°„1GiB的物ç†å†…å˜ï¼Œä½†æ˜¯ç”±äºŽæˆ‘们需è¦è™šæ‹Ÿåœ°å€ç©ºé—´æ¥åšå…¶ä»–事 -情--包括访问其余物ç†å†…å˜çš„ä¸´æ—¶æ˜ å°„--å®žé™…çš„ç›´æŽ¥æ˜ å°„é€šå¸¸ä¼šæ›´å°‘ï¼ˆé€šå¸¸åœ¨~896MiBå·¦å³ï¼‰ã€‚ - -其他有mmä¸Šä¸‹æ–‡æ ‡ç¾çš„TLB的架构å¯ä»¥æœ‰ç‹¬ç«‹çš„å†…æ ¸å’Œç”¨æˆ·æ˜ å°„ã€‚ç„¶è€Œï¼Œä¸€äº›ç¡¬ä»¶ï¼ˆå¦‚ä¸€äº›ARM）在使 -用mmä¸Šä¸‹æ–‡æ ‡ç¾æ—¶ï¼Œå…¶è™šæ‹Ÿç©ºé—´æœ‰é™ã€‚ - - -ä¸´æ—¶è™šæ‹Ÿæ˜ å°„ -============ - -å†…æ ¸åŒ…å«å‡ ç§åˆ›å»ºä¸´æ—¶æ˜ 射的方法。: - -* vmap(). è¿™å¯ä»¥ç”¨æ¥å°†å¤šä¸ªç‰©ç†é¡µé•¿æœŸæ˜ 射到一个连ç»çš„虚拟空间。它需è¦synchronization - æ¥è§£é™¤æ˜ 射。 - -* kmap(). è¿™å…许对å•ä¸ªé¡µé¢è¿›è¡ŒçŸæœŸæ˜ 射。它需è¦synchronization，但在一定程度上被摊销。 - 当以嵌套方å¼ä½¿ç”¨æ—¶ï¼Œå®ƒä¹Ÿå¾ˆå®¹æ˜“出现æ»é”ï¼Œå› æ¤ä¸å»ºè®®åœ¨æ–°ä»£ç ä¸ä½¿ç”¨å®ƒã€‚ - -* kmap_atomic(). è¿™å…许对å•ä¸ªé¡µé¢è¿›è¡Œéžå¸¸çŸçš„æ—¶é—´æ˜ å°„ã€‚ç”±äºŽæ˜ å°„è¢«é™åˆ¶åœ¨å‘布它的CPU上， - 它表现得很好，但å‘å¸ƒä»»åŠ¡å› æ¤è¢«è¦æ±‚留在该CPU上直到它完æˆï¼Œä»¥å…其他任务å–ä»£å®ƒçš„æ˜ å°„ã€‚ - - kmap_atomic() 也å¯ä»¥ç”±ä¸æ–ä¸Šä¸‹æ–‡ä½¿ç”¨ï¼Œå› ä¸ºå®ƒä¸ç¡çœ ，而且调用者å¯èƒ½åœ¨è°ƒç”¨kunmap_atomic() - 之åŽæ‰ç¡çœ 。 - - å¯ä»¥å‡è®¾k[un]map_atomic()ä¸ä¼šå¤±è´¥ã€‚ - - -使用kmap_atomic -=============== - -何时何地使用 kmap_atomic() 是很直接的。当代ç 想è¦è®¿é—®ä¸€ä¸ªå¯èƒ½ä»Žé«˜å†…å˜ï¼ˆè§__GFP_HIGHMEM） -分é…的页é¢çš„内容时，例如在页缓å˜ä¸çš„页é¢ï¼Œå°±ä¼šä½¿ç”¨å®ƒã€‚该API有两个函数，它们的使用方å¼ä¸Ž -下é¢ç±»ä¼¼:: - - /* 找到感兴趣的页é¢ã€‚ */ - struct page *page = find_get_page(mapping, offset); - - /* 获得对该页内容的访问æƒã€‚ */ - void *vaddr = kmap_atomic(page); - - /* 对该页的内容åšä¸€äº›å¤„ç†ã€‚ */ - memset(vaddr, 0, PAGE_SIZE); - - /* 解除该页é¢çš„æ˜ å°„ã€‚ */ - kunmap_atomic(vaddr); - -注æ„，kunmap_atomic()调用的是kmap_atomic()调用的结果而ä¸æ˜¯å‚数。 - -å¦‚æžœä½ éœ€è¦æ˜ 射两个页é¢ï¼Œå› ä¸ºä½ æƒ³ä»Žä¸€ä¸ªé¡µé¢å¤åˆ¶åˆ°å¦ä¸€ä¸ªé¡µé¢ï¼Œä½ 需è¦ä¿æŒkmap_atomic调用严 -æ ¼åµŒå¥—ï¼Œå¦‚:: - - vaddr1 = kmap_atomic(page1); - vaddr2 = kmap_atomic(page2); - - memcpy(vaddr1, vaddr2, PAGE_SIZE); - - kunmap_atomic(vaddr2); - kunmap_atomic(vaddr1); - - -ä¸´æ—¶æ˜ å°„çš„æˆæœ¬ -============== - -åˆ›å»ºä¸´æ—¶æ˜ å°„çš„ä»£ä»·å¯èƒ½ç›¸å½“高。体系架构必须æ“ä½œå†…æ ¸çš„é¡µè¡¨ã€æ•°æ®TLBå’Œ/或MMU的寄å˜å™¨ã€‚ - -如果CONFIG_HIGHMEMæ²¡æœ‰è¢«è®¾ç½®ï¼Œé‚£ä¹ˆå†…æ ¸ä¼šå°è¯•ç”¨ä¸€ç‚¹è®¡ç®—æ¥åˆ›å»ºæ˜ 射，将页é¢ç»“构地å€è½¬æ¢æˆ -指å‘页é¢å†…容的指针，而ä¸æ˜¯åŽ»æ£é¼“æ˜ å°„ã€‚åœ¨è¿™ç§æƒ…å†µä¸‹ï¼Œè§£æ˜ å°„æ“作å¯èƒ½æ˜¯ä¸€ä¸ªç©ºæ“作。 - -如果CONFIG_MMU没有被设置，那么就ä¸å¯èƒ½æœ‰ä¸´æ—¶æ˜ 射和高内å˜ã€‚在这ç§æƒ…况下，也将使用计算方法。 - - -i386 PAE -======== - -在æŸäº›æƒ…况下，i386 架构将å…è®¸ä½ åœ¨ 32 ä½æœºå™¨ä¸Šå®‰è£…多达 64GiB 的内å˜ã€‚但这有一些åŽæžœ: - -* Linux需è¦ä¸ºç³»ç»Ÿä¸çš„æ¯ä¸ªé¡µé¢å»ºç«‹ä¸€ä¸ªé¡µå¸§ç»“构，而且页帧需è¦é©»åœ¨æ°¸ä¹…æ˜ å°„ä¸ï¼Œè¿™æ„味ç€ï¼š - -* ä½ æœ€å¤šå¯ä»¥æœ‰896M/sizeof(struct page)页帧；由于页结构体是32å—节的，所以最终会有 - 112Gçš„é¡µï¼›ç„¶è€Œï¼Œå†…æ ¸éœ€è¦åœ¨å†…å˜ä¸å˜å‚¨æ›´å¤šçš„页帧...... - -* PAEä½¿ä½ çš„é¡µè¡¨å˜å¤§--这使系统å˜æ…¢ï¼Œå› 为更多的数æ®éœ€è¦åœ¨TLBå¡«å……ç‰æ–¹é¢è¢«è®¿é—®ã€‚一个好处 - 是，PAE有更多的PTEä½ï¼Œå¯ä»¥æä¾›åƒNXå’ŒPATè¿™æ ·çš„é«˜çº§åŠŸèƒ½ã€‚ - -ä¸€èˆ¬çš„å»ºè®®æ˜¯ï¼Œä½ ä¸è¦åœ¨32ä½æœºå™¨ä¸Šä½¿ç”¨è¶…过8GiB的空间--尽管更多的空间å¯èƒ½å¯¹ä½ å’Œä½ çš„å·¥ä½œ -é‡æœ‰ç”¨ï¼Œä½†ä½ å‡ ä¹Žæ˜¯é ä½ è‡ªå·±--ä¸è¦æŒ‡æœ›å†…æ ¸å¼€å‘者真的会很关心事情的进展情况。 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst deleted file mode 100644 index a1c6d529b6ff..000000000000 --- a/Documentation/translations/zh_CN/vm/index.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. include:: ../disclaimer-zh_CN.rst - -:Original: Documentation/vm/index.rst - -:翻译: - - å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> - -:æ ¡è¯‘: - -================= -Linux内å˜ç®¡ç†æ–‡æ¡£ -================= - -这是一个关于Linux内å˜ç®¡ç†ï¼ˆmm）å系统内部的文档集，其ä¸æœ‰ä¸åŒå±‚次的细节，包括注释 -和邮件列表的回å¤ï¼Œç”¨äºŽé˜è¿°æ•°æ®ç»“æž„å’Œç®—æ³•çš„åŸºæœ¬æƒ…å†µã€‚å¦‚æžœä½ æ£åœ¨å¯»æ‰¾å…³äºŽç®€å•åˆ†é…内å˜çš„建 -议，请å‚阅(Documentation/translations/zh_CN/core-api/memory-allocation.rst)。 -对于控制和调整指å—，请å‚阅(Documentation/admin-guide/mm/index)。 -TODO:待引用文档集被翻译完毕åŽè¯·åŠæ—¶ä¿®æ”¹æ¤å¤„） - -.. toctree:: - :maxdepth: 1 - - active_mm - balance - damon/index - free_page_reporting - highmem - ksm - frontswap - hmm - hwpoison - hugetlbfs_reserv - memory-model - mmu_notifier - numa - overcommit-accounting - page_frags - page_owner - page_table_check - remap_file_pages - split_page_table_lock - z3fold - zsmalloc - -TODOLIST: -* arch_pgtable_helpers -* free_page_reporting -* hugetlbfs_reserv -* page_migration -* slub -* transhuge -* unevictable-lru -* vmalloced-kernel-stacks diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index e1ce9d8c06f8..e97d7d578751 100644 --- a/Documentation/translations/zh_TW/index.rst +++ b/Documentation/translations/zh_TW/index.rst @@ -128,7 +128,7 @@ TODOList: * security/index * sound/index * crypto/index -* vm/index +* mm/index * bpf/index * usb/index * PCI/index diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst index 5578bca403e6..280a8832ecc0 100644 --- a/Documentation/translations/zh_TW/process/5.Posting.rst +++ b/Documentation/translations/zh_TW/process/5.Posting.rst @@ -22,8 +22,7 @@ å…§æ ¸é–‹ç™¼ç¤¾å€å·²ç¶“發展出一套用於發布補ä¸çš„約定和éŽç¨‹ï¼›éµå¾ªé€™äº›ç´„定和éŽç¨‹å°‡ä½¿ åƒèˆ‡å…¶ä¸çš„æ¯å€‹äººçš„ç”Ÿæ´»æ›´åŠ è¼•é¬†ã€‚æœ¬æ–‡æª”è©¦åœ–æè¿°é€™äº›ç´„å®šçš„éƒ¨åˆ†ç´°ç¯€ï¼›æ›´å¤šä¿¡æ¯ ä¹Ÿå¯åœ¨ä»¥ä¸‹æ–‡æª”ä¸æ‰¾åˆ° -:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`， -:ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst <tw_submittingdrivers>` +:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>` å’Œ :ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`。 何時郵寄 diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst index 7572b17667d9..044fcc118bef 100644 --- a/Documentation/translations/zh_TW/process/8.Conclusion.rst +++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst @@ -22,7 +22,6 @@ :ref:`Documentation/translations/zh_TW/process/howto.rst <tw_process_howto>` 文件是一個é‡è¦çš„起點； :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>` -å’Œ :ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst <tw_submittingdrivers>` ä¹Ÿæ˜¯æ‰€æœ‰å…§æ ¸é–‹ç™¼äººå“¡éƒ½æ‡‰è©²é–±è®€çš„å…§å®¹ã€‚è¨±å¤šå…§éƒ¨å…§æ ¸API都是使用kerneldoc機制 記錄的；「make htmldocsã€æˆ–「make pdfdocsã€å¯ç”¨æ–¼ä»¥HTML或PDFæ ¼å¼ç”Ÿæˆé€™äº›æ–‡æª” （儘管æŸäº›ç™¼è¡Œç‰ˆæ供的tex版本會é‡åˆ°å…§éƒ¨é™åˆ¶ï¼Œç„¡æ³•æ£ç¢ºè™•ç†æ–‡æª”）。 diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst index 6c76fc96131a..fbde3e26eda5 100644 --- a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst +++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst @@ -177,7 +177,7 @@ CVEåˆ†é… ============= ======================================================== ARM - AMD Tom Lendacky <tom.lendacky@amd.com> + AMD Tom Lendacky <thomas.lendacky@amd.com> IBM Intel Tony Luck <tony.luck@intel.com> Qualcomm Trilok Soni <tsoni@codeaurora.org> diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst index 2043691b92e3..68ae4411285b 100644 --- a/Documentation/translations/zh_TW/process/howto.rst +++ b/Documentation/translations/zh_TW/process/howto.rst @@ -99,7 +99,6 @@ Linuxå…§æ ¸ä»£ç¢¼ä¸åŒ…å«æœ‰å¤§é‡çš„文檔。這些文檔å°æ–¼å¸ç¿’如何與 的代碼。 :ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>` - :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` 這兩份文檔明確æ述如何創建和發é€è£œä¸ï¼Œå…¶ä¸åŒ…括（但ä¸åƒ…é™æ–¼)： - 郵件內容 diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst index ec7ad14bfd13..c5c59b4fd595 100644 --- a/Documentation/translations/zh_TW/process/index.rst +++ b/Documentation/translations/zh_TW/process/index.rst @@ -43,7 +43,6 @@ .. toctree:: :maxdepth: 1 - submitting-drivers submit-checklist stable-api-nonsense stable-kernel-rules diff --git a/Documentation/translations/zh_TW/process/submitting-drivers.rst b/Documentation/translations/zh_TW/process/submitting-drivers.rst deleted file mode 100644 index 2fdd742318ba..000000000000 --- a/Documentation/translations/zh_TW/process/submitting-drivers.rst +++ /dev/null @@ -1,164 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. _tw_submittingdrivers: - -.. include:: ../disclaimer-zh_TW.rst - -:Original: :ref:`Documentation/process/submitting-drivers.rst - <submittingdrivers>` - -如果想評論或更新本文的內容，請直接è¯ç¹«åŽŸæ–‡æª”çš„ç¶è·è€…ã€‚å¦‚æžœä½ ä½¿ç”¨è‹±æ–‡ -交æµæœ‰å›°é›£çš„話，也å¯ä»¥å‘ä¸æ–‡ç‰ˆç¶è·è€…求助。如果本翻è¯æ›´æ–°ä¸åŠæ™‚或者翻 -è¯å˜åœ¨å•é¡Œï¼Œè«‹è¯ç¹«ä¸æ–‡ç‰ˆç¶è·è€…:: - - ä¸æ–‡ç‰ˆç¶è·è€…： æŽé™½ Li Yang <leoyang.li@nxp.com> - ä¸æ–‡ç‰ˆç¿»è¯è€…： æŽé™½ Li Yang <leoyang.li@nxp.com> - ä¸æ–‡ç‰ˆæ ¡è¯è€…： é™³ç¦ Maggie Chen <chenqi@beyondsoft.com> - çŽ‹è° Wang Cong <xiyou.wangcong@gmail.com> - å¼µå· Zhang Wei <wezhang@outlook.com> - 胡皓文 Hu Haowen <src.res@email.cn> - -å¦‚ä½•å‘ Linux å…§æ ¸æäº¤é©…å‹•ç¨‹åº -============================= - -這篇文檔將會解釋如何å‘ä¸åŒçš„å…§æ ¸æºç¢¼æ¨¹æ交è¨å‚™é©…動程åºã€‚請注æ„ï¼Œå¦‚æžœä½ æ„Ÿ -興趣的是顯å¡é©…動程åºï¼Œä½ ä¹Ÿè¨±æ‡‰è©²è¨ªå• XFree86 é …ç›®(https://www.xfree86.org/) -å’Œï¼æˆ– X.org é …ç›® (https://x.org)。 - -å¦è«‹åƒé–± Documentation/translations/zh_TW/process/submitting-patches.rst 文檔。 - - -分é…è¨å‚™è™Ÿ ----------- - -å¡Šè¨å‚™å’Œå—符è¨å‚™çš„主è¨å‚™è™Ÿèˆ‡å¾žè¨å‚™è™Ÿæ˜¯ç”± Linux 命å編號分é…æ¬Šå¨ LANANA（ -ç¾åœ¨æ˜¯ Torben Mathiasenï¼‰è² è²¬åˆ†é…。申請的網å€æ˜¯ https://www.lanana.org/。 -å³ä½¿ä¸æº–å‚™æ交到主æµå…§æ ¸çš„è¨å‚™é©…動也需è¦åœ¨é€™è£¡åˆ†é…è¨å‚™è™Ÿã€‚有關詳細信æ¯ï¼Œ -è«‹åƒé–± Documentation/admin-guide/devices.rst。 - -å¦‚æžœä½ ä½¿ç”¨çš„ä¸æ˜¯å·²ç¶“分é…çš„è¨å‚™è™Ÿï¼Œé‚£éº¼ç•¶ä½ æ交è¨å‚™é©…動的時候，它將會被強 -制分é…一個新的è¨å‚™è™Ÿï¼Œå³ä¾¿é€™å€‹è¨å‚™è™Ÿå’Œä½ 之å‰ç™¼çµ¦å®¢æˆ¶çš„截然ä¸åŒã€‚ - -è¨å‚™é©…å‹•çš„æ交å°è±¡ ------------------- - -Linux 2.0: - æ¤å…§æ ¸æºç¢¼æ¨¹ä¸æŽ¥å—新的驅動程åºã€‚ - -Linux 2.2: - æ¤å…§æ ¸æºç¢¼æ¨¹ä¸æŽ¥å—新的驅動程åºã€‚ - -Linux 2.4: - å¦‚æžœæ‰€å±¬çš„ä»£ç¢¼é ˜åŸŸåœ¨å…§æ ¸çš„ MAINTAINERS 文件ä¸åˆ—有一個總ç¶è·è€…， - 那麼請將驅動程åºæ交給他。如果æ¤ç¶è·è€…æ²’æœ‰å›žæ‡‰æˆ–è€…ä½ æ‰¾ä¸åˆ°æ°ç•¶çš„ - ç¶è·è€…，那麼請è¯ç¹« Willy Tarreau <w@1wt.eu>。 - -Linux 2.6: - 除了éµå¾ªå’Œ 2.4 ç‰ˆå…§æ ¸åŒæ¨£çš„è¦å‰‡å¤–ï¼Œä½ é‚„éœ€è¦åœ¨ linux-kernel 郵件 - 列表上跟蹤最新的 API è®ŠåŒ–ã€‚å‘ Linux 2.6 å…§æ ¸æäº¤é©…å‹•çš„é ‚ç´šè¯ç¹«äºº - 是 Andrew Morton <akpm@linux-foundation.org>。 - -決定è¨å‚™é©…動能å¦è¢«æŽ¥å—çš„æ¢ä»¶ ----------------------------- - -許å¯ï¼š ä»£ç¢¼å¿…é ˆä½¿ç”¨ GNU 通用公開許å¯è‰ (GPL) æ交給 Linux，但是 - 我們並ä¸è¦æ±‚ GPL 是唯一的許å¯ã€‚ä½ æˆ–è¨±æœƒå¸Œæœ›åŒæ™‚使用多種 - 許å¯è‰ç™¼å¸ƒï¼Œå¦‚果希望驅動程åºå¯ä»¥è¢«å…¶ä»–é–‹æºç¤¾å€ï¼ˆæ¯”如BSD） - 使用。請åƒè€ƒ include/linux/module.h 文件ä¸æ‰€åˆ—出的å¯è¢« - 接å—å…±å˜çš„許å¯ã€‚ - -版權： ç‰ˆæ¬Šæ‰€æœ‰è€…å¿…é ˆåŒæ„使用 GPL 許å¯ã€‚最好æ交者和版權所有者 - 是相åŒå€‹äººæˆ–實體。å¦å‰‡ï¼Œå¿…需列出授權使用 GPL 的版權所有 - 人或實體，以備驗è‰ä¹‹éœ€ã€‚ - -接å£ï¼š å¦‚æžœä½ çš„é©…å‹•ç¨‹åºä½¿ç”¨ç¾æˆçš„接å£ä¸¦ä¸”和其他åŒé¡žçš„驅動程åºè¡Œ - 爲相似，而ä¸æ˜¯åŽ»ç™¼æ˜Žç„¡è¬‚的新接å£ï¼Œé‚£éº¼å®ƒå°‡æœƒæ›´å®¹æ˜“被接å—。 - å¦‚æžœä½ éœ€è¦ä¸€å€‹ Linux å’Œ NT 的通用驅動接å£ï¼Œé‚£éº¼è«‹åœ¨ç”¨ - 戶空間實ç¾å®ƒã€‚ - -代碼： 請使用 Documentation/process/coding-style.rst ä¸æ‰€æè¿°çš„ Linux 代碼風 - æ ¼ã€‚å¦‚æžœä½ çš„æŸäº›ä»£ç¢¼æ®µï¼ˆä¾‹å¦‚那些與 Windows 驅動程åºåŒ…å…± - 享的代碼段）需è¦ä½¿ç”¨å…¶ä»–æ ¼å¼ï¼Œè€Œä½ å»åªå¸Œæœ›ç¶è·ä¸€ä»½ä»£ç¢¼ï¼Œ - 那麼請將它們很好地å€åˆ†å‡ºä¾†ï¼Œä¸¦ä¸”è¨»æ˜ŽåŽŸå› ã€‚ - -å¯ç§»æ¤æ€§ï¼š 請注æ„，指é‡ä¸¦ä¸æ°¸é 是 32 ä½çš„，ä¸æ˜¯æ‰€æœ‰çš„è¨ˆç®—æ©Ÿéƒ½ä½¿ç”¨å° - å°¾æ¨¡å¼ (little endian) å˜å„²æ•¸æ“šï¼Œä¸æ˜¯æ‰€æœ‰çš„人都æ“有浮點 - 單元，ä¸è¦éš¨ä¾¿åœ¨ä½ 的驅動程åºé‡ŒåµŒå…¥ x86 彙編指令。åªèƒ½åœ¨ - x86 上é‹è¡Œçš„驅動程åºä¸€èˆ¬æ˜¯ä¸å—æ¡è¿Žçš„ã€‚é›–ç„¶ä½ å¯èƒ½åªæœ‰ x86 - 硬體，很難測試驅動程åºåœ¨å…¶ä»–å¹³å°ä¸Šæ˜¯å¦å¯ç”¨ï¼Œä½†æ˜¯ç¢ºä¿ä»£ç¢¼ - å¯ä»¥è¢«è¼•é¬†åœ°ç§»æ¤å»æ˜¯å¾ˆç°¡å–®çš„。 - -清晰度： åšåˆ°æ‰€æœ‰äººéƒ½èƒ½ä¿®è£œé€™å€‹é©…動程åºå°‡æœƒå¾ˆæœ‰å¥½è™•ï¼Œå› çˆ²é€™æ¨£ä½ å°‡ - 會直接收到修復的補ä¸è€Œä¸æ˜¯ bug å ±å‘Šã€‚å¦‚æžœä½ æ交一個試圖 - éš±è—硬體工作機ç†çš„驅動程åºï¼Œé‚£éº¼å®ƒå°‡æœƒè¢«æ‰”進廢紙ç°ã€‚ - -é›»æºç®¡ç†ï¼š å› çˆ² Linux æ£åœ¨è¢«å¾ˆå¤šè¡Œå‹•è£ç½®å’Œæ¡Œé¢ç³»çµ±ä½¿ç”¨ï¼Œæ‰€ä»¥ä½ çš„é©… - 動程åºä¹Ÿå¾ˆæœ‰å¯èƒ½è¢«ä½¿ç”¨åœ¨é€™äº›è¨å‚™ä¸Šã€‚它應該支æŒæœ€åŸºæœ¬çš„é›» - æºç®¡ç†ï¼Œå³åœ¨éœ€è¦çš„情æ³ä¸‹å¯¦ç¾ç³»çµ±ç´šä¼‘çœ å’Œå–šé†’è¦ç”¨åˆ°çš„ - .suspend å’Œ .resume å‡½æ•¸ã€‚ä½ æ‡‰è©²æª¢æŸ¥ä½ çš„é©…å‹•ç¨‹åºæ˜¯å¦èƒ½æ£ - 確地處ç†ä¼‘çœ èˆ‡å–šé†’ï¼Œå¦‚æžœå¯¦åœ¨ç„¡æ³•ç¢ºèªï¼Œè«‹è‡³å°‘把 .suspend - 函數定義æˆè¿”回 -ENOSYS（功能未實ç¾ï¼‰éŒ¯èª¤ã€‚ä½ é‚„æ‡‰è©²å˜—è©¦ç¢º - ä¿ä½ 的驅動在什麼都ä¸ä¹¾çš„情æ³ä¸‹å°‡è€—é›»é™åˆ°æœ€ä½Žã€‚è¦ç²å¾—é©…å‹• - 程åºæ¸¬è©¦çš„指導，請åƒé–± - Documentation/power/drivers-testing.rst。有關驅動程åºé›» - æºç®¡ç†å•é¡Œç›¸å°å…¨é¢çš„概述，請åƒé–± - Documentation/driver-api/pm/devices.rst。 - -管ç†ï¼š 如果一個驅動程åºçš„作者還在進行有效的ç¶è·ï¼Œé‚£éº¼é€šå¸¸é™¤äº†é‚£ - 些明顯æ£ç¢ºä¸”ä¸éœ€è¦ä»»ä½•æª¢æŸ¥çš„補ä¸ä»¥å¤–，其他所有的補ä¸éƒ½æœƒ - è¢«è½‰ç™¼çµ¦ä½œè€…ã€‚å¦‚æžœä½ å¸Œæœ›æˆçˆ²é©…動程åºçš„è¯ç¹«äººå’Œæ›´æ–°è€…，最 - 好在代碼注釋ä¸å¯«æ˜Žä¸¦ä¸”在 MAINTAINERS 文件ä¸åŠ 入這個驅動 - 程åºçš„æ¢ç›®ã€‚ - -ä¸å½±éŸ¿è¨å‚™é©…動能å¦è¢«æŽ¥å—çš„æ¢ä»¶ ------------------------------- - -供應商： 由硬體供應商來ç¶è·é©…動程åºé€šå¸¸æ˜¯ä¸€ä»¶å¥½äº‹ã€‚ä¸éŽï¼Œå¦‚æžœæºç¢¼ - 樹里已經有其他人æ供了å¯ç©©å®šå·¥ä½œçš„驅動程åºï¼Œé‚£éº¼è«‹ä¸è¦æœŸ - 望「我是供應商ã€æœƒæˆçˆ²å…§æ ¸æ”¹ç”¨ä½ 的驅動程åºçš„ç†ç”±ã€‚ç†æƒ³çš„情 - æ³æ˜¯ï¼šä¾›æ‡‰å•†èˆ‡ç¾æœ‰é©…動程åºçš„作者åˆä½œï¼Œæ§‹å»ºä¸€å€‹çµ±ä¸€å®Œç¾Žçš„ - 驅動程åºã€‚ - -作者： 驅動程åºæ˜¯ç”±å¤§çš„ Linux å…¬å¸ç ”ç™¼é‚„æ˜¯ç”±ä½ å€‹äººç·¨å¯«ï¼Œä¸¦ä¸å½± - 響其是å¦èƒ½è¢«å…§æ ¸æŽ¥å—。沒有人å°å…§æ ¸æºç¢¼æ¨¹äº«æœ‰ç‰¹æ¬Šã€‚åªè¦ä½ - å……åˆ†äº†è§£å…§æ ¸ç¤¾å€ï¼Œä½ 就會發ç¾é€™ä¸€é»žã€‚ - - -資æºåˆ—表 --------- - -Linux å…§æ ¸ä¸»æºç¢¼æ¨¹ï¼š - ftp.??.kernel.org:/pub/linux/kernel/... - ?? == ä½ çš„åœ‹å®¶ä»£ç¢¼ï¼Œä¾‹å¦‚ "cn"ã€"us"ã€"uk"ã€"fr" ç‰ç‰ - -Linux å…§æ ¸éƒµä»¶åˆ—è¡¨ï¼š - linux-kernel@vger.kernel.org - [å¯é€šéŽå‘majordomo@vger.kernel.org發郵件來訂閱] - -Linux è¨å‚™é©…動程åºï¼Œç¬¬ä¸‰ç‰ˆï¼ˆæŽ¢è¨Ž 2.6.10 ç‰ˆå…§æ ¸ï¼‰ï¼š - https://lwn.net/Kernel/LDD3/ （å…費版） - -LWN.net: - æ¯å‘¨å…§æ ¸é–‹ç™¼æ´»å‹•æ‘˜è¦ - https://lwn.net/ - - 2.6 ç‰ˆä¸ API 的變更： - - https://lwn.net/Articles/2.6-kernel-api/ - - å°‡èˆŠç‰ˆå…§æ ¸çš„é©…å‹•ç¨‹åºç§»æ¤åˆ° 2.6 版： - - https://lwn.net/Articles/driver-porting/ - -å…§æ ¸æ–°æ‰‹(KernelNewbies): - çˆ²æ–°çš„å…§æ ¸é–‹ç™¼è€…æ供文檔和幫助 - https://kernelnewbies.org/ - -Linux USBé …ç›®ï¼š - http://www.linux-usb.org/ - -å¯«å…§æ ¸é©…å‹•çš„ã€Œä¸è¦ã€ï¼ˆArjan van de Ven著）: - http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf - -å…§æ ¸æ¸…æ½”å·¥ (Kernel Janitor): - https://kernelnewbies.org/KernelJanitors - diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst index c4fd48f5bd8b..3f77ef5d48a0 100644 --- a/Documentation/translations/zh_TW/process/submitting-patches.rst +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst @@ -26,9 +26,7 @@ 以下文檔å«æœ‰å¤§é‡ç°¡æ½”的建è°ï¼Œ 具體請見： :ref:`Documentation/process <development_process_main>` åŒæ¨£ï¼Œ:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>` -給出在æ交代碼å‰éœ€è¦æª¢æŸ¥çš„é …ç›®çš„åˆ—è¡¨ã€‚å¦‚æžœä½ åœ¨æ交一個驅動程åºï¼Œé‚£éº¼ -åŒæ™‚閱讀一下: -:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` +給出在æ交代碼å‰éœ€è¦æª¢æŸ¥çš„é …ç›®çš„åˆ—è¡¨ã€‚ å…¶ä¸è¨±å¤šæ¥é©Ÿæ述了Git版本控制系統的默èªè¡Œçˆ²ï¼›å¦‚果您使用Git來準備補ä¸ï¼Œ 您將發ç¾å®ƒçˆ²æ‚¨å®Œæˆçš„大部分機械工作，儘管您ä»ç„¶éœ€è¦æº–備和記錄一組åˆç†çš„ diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 1c37159fa171..2278c9ffb74a 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -333,6 +333,12 @@ In each lun directory there are the following attribute files: being a CD-ROM. nofua Flag specifying that FUA flag in SCSI WRITE(10,12) + forced_eject This write-only file is useful only when + the function is active. It causes the backing + file to be forcibly detached from the LUN, + regardless of whether the host has allowed it. + Any non-zero number of bytes written will + result in ejection. =============== ============================================== Testing the MASS STORAGE function diff --git a/Documentation/usb/mass-storage.rst b/Documentation/usb/mass-storage.rst index d181b47c3cb6..f399ec631599 100644 --- a/Documentation/usb/mass-storage.rst +++ b/Documentation/usb/mass-storage.rst @@ -181,6 +181,15 @@ sysfs entries Reflects the state of nofua flag for given logical unit. It can be read and written. + - forced_eject + + When written into, it causes the backing file to be forcibly + detached from the LUN, regardless of whether the host has allowed + it. The content doesn't matter, any non-zero number of bytes + written will result in ejection. + + Can not be read. + Other then those, as usual, the values of module parameters can be read from /sys/module/g_mass_storage/parameters/* files. diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index fcab013e47c9..3b985b19f39d 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -120,7 +120,7 @@ Code Seq# Include File Comments 'C' 01-2F linux/capi.h conflict! 'C' F0-FF drivers/net/wan/cosa.h conflict! 'D' all arch/s390/include/asm/dasd.h -'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h +'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h Dead since 2022 'D' 05 drivers/scsi/pmcraid.h 'E' all linux/input.h conflict! 'E' 00-0F xen/evtchn.h conflict! diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst deleted file mode 100644 index cd9754b4e005..000000000000 --- a/Documentation/userspace-api/media/drivers/hantro.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -Hantro video decoder driver -=========================== - -The Hantro video decoder driver implements the following driver-specific controls: - -``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)`` - Specifies to Hantro HEVC video decoder driver the number of data (in bits) to - skip in the slice segment header. - If non-IDR, the bits to be skipped go from syntax element "pic_output_flag" - to before syntax element "slice_temporal_mvp_enabled_flag". - If IDR, the skipped bits are just "pic_output_flag" - (separate_colour_plane_flag is not supported). - -.. note:: - - This control is not yet part of the public kernel API and - it is expected to change. diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst index 12e3c512d718..1a9038f5f9fa 100644 --- a/Documentation/userspace-api/media/drivers/index.rst +++ b/Documentation/userspace-api/media/drivers/index.rst @@ -33,7 +33,6 @@ For more details see the file COPYING in the source distribution of Linux. ccs cx2341x-uapi - hantro imx-uapi max2175 meye-uapi diff --git a/Documentation/userspace-api/media/v4l/control.rst b/Documentation/userspace-api/media/v4l/control.rst index 3eec65174260..4463fce694b0 100644 --- a/Documentation/userspace-api/media/v4l/control.rst +++ b/Documentation/userspace-api/media/v4l/control.rst @@ -461,10 +461,10 @@ Example: Changing controls perror("VIDIOC_QUERYCTRL"); exit(EXIT_FAILURE); } else { - printf("V4L2_CID_BRIGHTNESS is not supportedn"); + printf("V4L2_CID_BRIGHTNESS is not supported\n"); } } else if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) { - printf("V4L2_CID_BRIGHTNESS is not supportedn"); + printf("V4L2_CID_BRIGHTNESS is not supported\n"); } else { memset(&control, 0, sizeof (control)); control.id = V4L2_CID_BRIGHTNESS; diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index bee73065e993..cd33857d947d 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -2048,3 +2048,905 @@ This structure contains all loop filter related parameters. See sections - 0x2 - When set, the bitstream contains additional syntax elements that specify which mode and reference frame deltas are to be updated. + +.. _v4l2-codec-stateless-hevc: + +``V4L2_CID_STATELESS_HEVC_SPS (struct)`` + Specifies the Sequence Parameter Set fields (as extracted from the + bitstream) for the associated HEVC slice data. + These bitstream parameters are defined according to :ref:`hevc`. + They are described in section 7.4.3.2 "Sequence parameter set RBSP + semantics" of the specification. + +.. c:type:: v4l2_ctrl_hevc_sps + +.. raw:: latex + + \small + +.. tabularcolumns:: |p{1.2cm}|p{9.2cm}|p{6.9cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_sps + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``video_parameter_set_id`` + - Specifies the value of the vps_video_parameter_set_id of the active VPS + as described in section "7.4.3.2.1 General sequence parameter set RBSP semantics" + of H.265 specifications. + * - __u8 + - ``seq_parameter_set_id`` + - Provides an identifier for the SPS for reference by other syntax elements + as described in section "7.4.3.2.1 General sequence parameter set RBSP semantics" + of H.265 specifications. + * - __u16 + - ``pic_width_in_luma_samples`` + - Specifies the width of each decoded picture in units of luma samples. + * - __u16 + - ``pic_height_in_luma_samples`` + - Specifies the height of each decoded picture in units of luma samples. + * - __u8 + - ``bit_depth_luma_minus8`` + - This value plus 8 specifies the bit depth of the samples of the luma array. + * - __u8 + - ``bit_depth_chroma_minus8`` + - This value plus 8 specifies the bit depth of the samples of the chroma arrays. + * - __u8 + - ``log2_max_pic_order_cnt_lsb_minus4`` + - Specifies the value of the variable MaxPicOrderCntLsb. + * - __u8 + - ``sps_max_dec_pic_buffering_minus1`` + - This value plus 1 specifies the maximum required size of the decoded picture buffer for + the coded video sequence (CVS). + * - __u8 + - ``sps_max_num_reorder_pics`` + - Indicates the maximum allowed number of pictures. + * - __u8 + - ``sps_max_latency_increase_plus1`` + - Used to signal MaxLatencyPictures, which indicates the maximum number of + pictures that can precede any picture in output order and follow that + picture in decoding order. + * - __u8 + - ``log2_min_luma_coding_block_size_minus3`` + - This value plus 3 specifies the minimum luma coding block size. + * - __u8 + - ``log2_diff_max_min_luma_coding_block_size`` + - Specifies the difference between the maximum and minimum luma coding block size. + * - __u8 + - ``log2_min_luma_transform_block_size_minus2`` + - This value plus 2 specifies the minimum luma transform block size. + * - __u8 + - ``log2_diff_max_min_luma_transform_block_size`` + - Specifies the difference between the maximum and minimum luma transform block size. + * - __u8 + - ``max_transform_hierarchy_depth_inter`` + - Specifies the maximum hierarchy depth for transform units of coding units coded + in inter prediction mode. + * - __u8 + - ``max_transform_hierarchy_depth_intra`` + - Specifies the maximum hierarchy depth for transform units of coding units coded in + intra prediction mode. + * - __u8 + - ``pcm_sample_bit_depth_luma_minus1`` + - This value plus 1 specifies the number of bits used to represent each of PCM sample values of the + luma component. + * - __u8 + - ``pcm_sample_bit_depth_chroma_minus1`` + - Specifies the number of bits used to represent each of PCM sample values of + the chroma components. + * - __u8 + - ``log2_min_pcm_luma_coding_block_size_minus3`` + - Plus 3 specifies the minimum size of coding blocks. + * - __u8 + - ``log2_diff_max_min_pcm_luma_coding_block_size`` + - Specifies the difference between the maximum and minimum size of coding blocks. + * - __u8 + - ``num_short_term_ref_pic_sets`` + - Specifies the number of st_ref_pic_set() syntax structures included in the SPS. + * - __u8 + - ``num_long_term_ref_pics_sps`` + - Specifies the number of candidate long-term reference pictures that are + specified in the SPS. + * - __u8 + - ``chroma_format_idc`` + - Specifies the chroma sampling. + * - __u8 + - ``sps_max_sub_layers_minus1`` + - This value plus 1 specifies the maximum number of temporal sub-layers. + * - __u64 + - ``flags`` + - See :ref:`Sequence Parameter Set Flags <hevc_sps_flags>` + +.. raw:: latex + + \normalsize + +.. _hevc_sps_flags: + +``Sequence Parameter Set Flags`` + +.. raw:: latex + + \small + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_SPS_FLAG_SEPARATE_COLOUR_PLANE`` + - 0x00000001 + - + * - ``V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED`` + - 0x00000002 + - + * - ``V4L2_HEVC_SPS_FLAG_AMP_ENABLED`` + - 0x00000004 + - + * - ``V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET`` + - 0x00000008 + - + * - ``V4L2_HEVC_SPS_FLAG_PCM_ENABLED`` + - 0x00000010 + - + * - ``V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED`` + - 0x00000020 + - + * - ``V4L2_HEVC_SPS_FLAG_LONG_TERM_REF_PICS_PRESENT`` + - 0x00000040 + - + * - ``V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED`` + - 0x00000080 + - + * - ``V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED`` + - 0x00000100 + - + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_HEVC_PPS (struct)`` + Specifies the Picture Parameter Set fields (as extracted from the + bitstream) for the associated HEVC slice data. + These bitstream parameters are defined according to :ref:`hevc`. + They are described in section 7.4.3.3 "Picture parameter set RBSP + semantics" of the specification. + +.. c:type:: v4l2_ctrl_hevc_pps + +.. tabularcolumns:: |p{1.2cm}|p{8.6cm}|p{7.5cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_pps + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``pic_parameter_set_id`` + - Identifies the PPS for reference by other syntax elements. + * - __u8 + - ``num_extra_slice_header_bits`` + - Specifies the number of extra slice header bits that are present + in the slice header RBSP for coded pictures referring to the PPS. + * - __u8 + - ``num_ref_idx_l0_default_active_minus1`` + - This value plus 1 specifies the inferred value of num_ref_idx_l0_active_minus1. + * - __u8 + - ``num_ref_idx_l1_default_active_minus1`` + - This value plus 1 specifies the inferred value of num_ref_idx_l1_active_minus1. + * - __s8 + - ``init_qp_minus26`` + - This value plus 26 specifies the initial value of SliceQp Y for each slice + referring to the PPS. + * - __u8 + - ``diff_cu_qp_delta_depth`` + - Specifies the difference between the luma coding tree block size + and the minimum luma coding block size of coding units that + convey cu_qp_delta_abs and cu_qp_delta_sign_flag. + * - __s8 + - ``pps_cb_qp_offset`` + - Specifies the offsets to the luma quantization parameter Cb. + * - __s8 + - ``pps_cr_qp_offset`` + - Specifies the offsets to the luma quantization parameter Cr. + * - __u8 + - ``num_tile_columns_minus1`` + - This value plus 1 specifies the number of tile columns partitioning the picture. + * - __u8 + - ``num_tile_rows_minus1`` + - This value plus 1 specifies the number of tile rows partitioning the picture. + * - __u8 + - ``column_width_minus1[20]`` + - This value plus 1 specifies the width of the i-th tile column in units of + coding tree blocks. + * - __u8 + - ``row_height_minus1[22]`` + - This value plus 1 specifies the height of the i-th tile row in units of coding + tree blocks. + * - __s8 + - ``pps_beta_offset_div2`` + - Specifies the default deblocking parameter offsets for beta divided by 2. + * - __s8 + - ``pps_tc_offset_div2`` + - Specifies the default deblocking parameter offsets for tC divided by 2. + * - __u8 + - ``log2_parallel_merge_level_minus2`` + - This value plus 2 specifies the value of the variable Log2ParMrgLevel. + * - __u8 + - ``padding[4]`` + - Applications and drivers must set this to zero. + * - __u64 + - ``flags`` + - See :ref:`Picture Parameter Set Flags <hevc_pps_flags>` + +.. _hevc_pps_flags: + +``Picture Parameter Set Flags`` + +.. raw:: latex + + \small + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED`` + - 0x00000001 + - + * - ``V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT`` + - 0x00000002 + - + * - ``V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED`` + - 0x00000004 + - + * - ``V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT`` + - 0x00000008 + - + * - ``V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED`` + - 0x00000010 + - + * - ``V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED`` + - 0x00000020 + - + * - ``V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED`` + - 0x00000040 + - + * - ``V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT`` + - 0x00000080 + - + * - ``V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED`` + - 0x00000100 + - + * - ``V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED`` + - 0x00000200 + - + * - ``V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED`` + - 0x00000400 + - + * - ``V4L2_HEVC_PPS_FLAG_TILES_ENABLED`` + - 0x00000800 + - + * - ``V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED`` + - 0x00001000 + - + * - ``V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED`` + - 0x00002000 + - + * - ``V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED`` + - 0x00004000 + - + * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED`` + - 0x00008000 + - + * - ``V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER`` + - 0x00010000 + - + * - ``V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT`` + - 0x00020000 + - + * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT`` + - 0x00040000 + - + * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT`` + - 0x00080000 + - Specifies the presence of deblocking filter control syntax elements in + the PPS + * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING`` + - 0x00100000 + - Specifies that tile column boundaries and likewise tile row boundaries + are distributed uniformly across the picture + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_HEVC_SLICE_PARAMS (struct)`` + Specifies various slice-specific parameters, especially from the NAL unit + header, general slice segment header and weighted prediction parameter + parts of the bitstream. + These bitstream parameters are defined according to :ref:`hevc`. + They are described in section 7.4.7 "General slice segment header + semantics" of the specification. + This control is a dynamically sized 1-dimensional array, + V4L2_CTRL_FLAG_DYNAMIC_ARRAY flag must be set when using it. + +.. c:type:: v4l2_ctrl_hevc_slice_params + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{5.4cm}|p{6.8cm}|p{5.1cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_slice_params + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u32 + - ``bit_size`` + - Size (in bits) of the current slice data. + * - __u32 + - ``data_byte_offset`` + - Offset (in byte) to the video data in the current slice data. + * - __u32 + - ``num_entry_point_offsets`` + - Specifies the number of entry point offset syntax elements in the slice header. + When the driver supports it, the ``V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS`` + must be set. + * - __u8 + - ``nal_unit_type`` + - Specifies the coding type of the slice (B, P or I). + * - __u8 + - ``nuh_temporal_id_plus1`` + - Minus 1 specifies a temporal identifier for the NAL unit. + * - __u8 + - ``slice_type`` + - + (V4L2_HEVC_SLICE_TYPE_I, V4L2_HEVC_SLICE_TYPE_P or + V4L2_HEVC_SLICE_TYPE_B). + * - __u8 + - ``colour_plane_id`` + - Specifies the colour plane associated with the current slice. + * - __s32 + - ``slice_pic_order_cnt`` + - Specifies the picture order count. + * - __u8 + - ``num_ref_idx_l0_active_minus1`` + - This value plus 1 specifies the maximum reference index for reference picture list 0 + that may be used to decode the slice. + * - __u8 + - ``num_ref_idx_l1_active_minus1`` + - This value plus 1 specifies the maximum reference index for reference picture list 1 + that may be used to decode the slice. + * - __u8 + - ``collocated_ref_idx`` + - Specifies the reference index of the collocated picture used for + temporal motion vector prediction. + * - __u8 + - ``five_minus_max_num_merge_cand`` + - Specifies the maximum number of merging motion vector prediction + candidates supported in the slice subtracted from 5. + * - __s8 + - ``slice_qp_delta`` + - Specifies the initial value of QpY to be used for the coding blocks in the slice. + * - __s8 + - ``slice_cb_qp_offset`` + - Specifies a difference to be added to the value of pps_cb_qp_offset. + * - __s8 + - ``slice_cr_qp_offset`` + - Specifies a difference to be added to the value of pps_cr_qp_offset. + * - __s8 + - ``slice_act_y_qp_offset`` + - Specifies the offset to the luma of quantization parameter qP derived in section 8.6.2 + * - __s8 + - ``slice_act_cb_qp_offset`` + - Specifies the offset to the cb of quantization parameter qP derived in section 8.6.2 + * - __s8 + - ``slice_act_cr_qp_offset`` + - Specifies the offset to the cr of quantization parameter qP derived in section 8.6.2 + * - __s8 + - ``slice_beta_offset_div2`` + - Specifies the deblocking parameter offsets for beta divided by 2. + * - __s8 + - ``slice_tc_offset_div2`` + - Specifies the deblocking parameter offsets for tC divided by 2. + * - __u8 + - ``pic_struct`` + - Indicates whether a picture should be displayed as a frame or as one or more fields. + * - __u32 + - ``slice_segment_addr`` + - Specifies the address of the first coding tree block in the slice segment. + * - __u8 + - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The list of L0 reference elements as indices in the DPB. + * - __u8 + - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The list of L1 reference elements as indices in the DPB. + * - __u16 + - ``short_term_ref_pic_set_size`` + - Specifies the size, in bits, of the short-term reference picture set, described as st_ref_pic_set() + in the specification, included in the slice header or SPS (section 7.3.6.1). + * - __u16 + - ``long_term_ref_pic_set_size`` + - Specifies the size, in bits, of the long-term reference picture set include in the slice header + or SPS. It is the number of bits in the conditional block if(long_term_ref_pics_present_flag) + in section 7.3.6.1 of the specification. + * - __u8 + - ``padding`` + - Applications and drivers must set this to zero. + * - struct :c:type:`v4l2_hevc_pred_weight_table` + - ``pred_weight_table`` + - The prediction weight coefficients for inter-picture prediction. + * - __u64 + - ``flags`` + - See :ref:`Slice Parameters Flags <hevc_slice_params_flags>` + +.. raw:: latex + + \normalsize + +.. _hevc_slice_params_flags: + +``Slice Parameters Flags`` + +.. raw:: latex + + \scriptsize + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_LUMA`` + - 0x00000001 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_CHROMA`` + - 0x00000002 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_TEMPORAL_MVP_ENABLED`` + - 0x00000004 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_MVD_L1_ZERO`` + - 0x00000008 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_CABAC_INIT`` + - 0x00000010 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_COLLOCATED_FROM_L0`` + - 0x00000020 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_USE_INTEGER_MV`` + - 0x00000040 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_DEBLOCKING_FILTER_DISABLED`` + - 0x00000080 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED`` + - 0x00000100 + - + * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT`` + - 0x00000200 + - + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS (integer)`` + Specifies entry point offsets in bytes. + This control is a dynamically sized array. The number of entry point + offsets is reported by the ``elems`` field. + This bitstream parameter is defined according to :ref:`hevc`. + They are described in section 7.4.7.1 "General slice segment header + semantics" of the specification. + When multiple slices are submitted in a request, the length of + this array must be the sum of num_entry_point_offsets of all the + slices in the request. + +``V4L2_CID_STATELESS_HEVC_SCALING_MATRIX (struct)`` + Specifies the HEVC scaling matrix parameters used for the scaling process + for transform coefficients. + These matrix and parameters are defined according to :ref:`hevc`. + They are described in section 7.4.5 "Scaling list data semantics" of + the specification. + +.. c:type:: v4l2_ctrl_hevc_scaling_matrix + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{5.4cm}|p{6.8cm}|p{5.1cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_scaling_matrix + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``scaling_list_4x4[6][16]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_8x8[6][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_16x16[6][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_32x32[2][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_dc_coef_16x16[6]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_dc_coef_32x32[2]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + +.. raw:: latex + + \normalsize + +.. c:type:: v4l2_hevc_dpb_entry + +.. raw:: latex + + \small + +.. tabularcolumns:: |p{1.0cm}|p{4.2cm}|p{12.1cm}| + +.. flat-table:: struct v4l2_hevc_dpb_entry + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u64 + - ``timestamp`` + - Timestamp of the V4L2 capture buffer to use as reference, used + with B-coded and P-coded frames. The timestamp refers to the + ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the + :c:func:`v4l2_timeval_to_ns()` function to convert the struct + :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. + * - __u8 + - ``flags`` + - Long term flag for the reference frame + (V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE). The flag is set as + described in the ITU HEVC specification chapter "8.3.2 Decoding + process for reference picture set". + * - __u8 + - ``field_pic`` + - Whether the reference is a field picture or a frame. + See :ref:`HEVC dpb field pic Flags <hevc_dpb_field_pic_flags>` + * - __s32 + - ``pic_order_cnt_val`` + - The picture order count of the current picture. + * - __u8 + - ``padding[2]`` + - Applications and drivers must set this to zero. + +.. raw:: latex + + \normalsize + +.. _hevc_dpb_field_pic_flags: + +``HEVC dpb field pic Flags`` + +.. raw:: latex + + \scriptsize + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_SEI_PIC_STRUCT_FRAME`` + - 0 + - (progressive) Frame + * - ``V4L2_HEVC_SEI_PIC_STRUCT_TOP_FIELD`` + - 1 + - Top field + * - ``V4L2_HEVC_SEI_PIC_STRUCT_BOTTOM_FIELD`` + - 2 + - Bottom field + * - ``V4L2_HEVC_SEI_PIC_STRUCT_TOP_BOTTOM`` + - 3 + - Top field, bottom field, in that order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_BOTTOM_TOP`` + - 4 + - Bottom field, top field, in that order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_TOP_BOTTOM_TOP`` + - 5 + - Top field, bottom field, top field repeated, in that order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_BOTTOM_TOP_BOTTOM`` + - 6 + - Bottom field, top field, bottom field repeated, in that order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_FRAME_DOUBLING`` + - 7 + - Frame doubling + * - ``V4L2_HEVC_SEI_PIC_STRUCT_FRAME_TRIPLING`` + - 8 + - Frame tripling + * - ``V4L2_HEVC_SEI_PIC_STRUCT_TOP_PAIRED_PREVIOUS_BOTTOM`` + - 9 + - Top field paired with previous bottom field in output order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_BOTTOM_PAIRED_PREVIOUS_TOP`` + - 10 + - Bottom field paired with previous top field in output order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_TOP_PAIRED_NEXT_BOTTOM`` + - 11 + - Top field paired with next bottom field in output order + * - ``V4L2_HEVC_SEI_PIC_STRUCT_BOTTOM_PAIRED_NEXT_TOP`` + - 12 + - Bottom field paired with next top field in output order + +.. c:type:: v4l2_hevc_pred_weight_table + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{0.8cm}|p{10.6cm}|p{5.9cm}| + +.. flat-table:: struct v4l2_hevc_pred_weight_table + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __s8 + - ``delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The difference of the weighting factor applied to the luma + prediction value for list 0. + * - __s8 + - ``luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The additive offset applied to the luma prediction value for list 0. + * - __s8 + - ``delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` + - The difference of the weighting factor applied to the chroma + prediction value for list 0. + * - __s8 + - ``chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` + - The difference of the additive offset applied to the chroma + prediction values for list 0. + * - __s8 + - ``delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The difference of the weighting factor applied to the luma + prediction value for list 1. + * - __s8 + - ``luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The additive offset applied to the luma prediction value for list 1. + * - __s8 + - ``delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` + - The difference of the weighting factor applied to the chroma + prediction value for list 1. + * - __s8 + - ``chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` + - The difference of the additive offset applied to the chroma + prediction values for list 1. + * - __u8 + - ``luma_log2_weight_denom`` + - The base 2 logarithm of the denominator for all luma weighting + factors. + * - __s8 + - ``delta_chroma_log2_weight_denom`` + - The difference of the base 2 logarithm of the denominator for + all chroma weighting factors. + * - __u8 + - ``padding[6]`` + - Applications and drivers must set this to zero. + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_HEVC_DECODE_MODE (enum)`` + Specifies the decoding mode to use. Currently exposes slice-based and + frame-based decoding but new modes might be added later on. + This control is used as a modifier for V4L2_PIX_FMT_HEVC_SLICE + pixel format. Applications that support V4L2_PIX_FMT_HEVC_SLICE + are required to set this control in order to specify the decoding mode + that is expected for the buffer. + Drivers may expose a single or multiple decoding modes, depending + on what they can support. + +.. c:type:: v4l2_stateless_hevc_decode_mode + +.. raw:: latex + + \small + +.. tabularcolumns:: |p{9.4cm}|p{0.6cm}|p{7.3cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_STATELESS_HEVC_DECODE_MODE_SLICE_BASED`` + - 0 + - Decoding is done at the slice granularity. + The OUTPUT buffer must contain a single slice. + * - ``V4L2_STATELESS_HEVC_DECODE_MODE_FRAME_BASED`` + - 1 + - Decoding is done at the frame granularity. + The OUTPUT buffer must contain all slices needed to decode the + frame. + +.. raw:: latex + + \normalsize + +``V4L2_CID_STATELESS_HEVC_START_CODE (enum)`` + Specifies the HEVC slice start code expected for each slice. + This control is used as a modifier for V4L2_PIX_FMT_HEVC_SLICE + pixel format. Applications that support V4L2_PIX_FMT_HEVC_SLICE + are required to set this control in order to specify the start code + that is expected for the buffer. + Drivers may expose a single or multiple start codes, depending + on what they can support. + +.. c:type:: v4l2_stateless_hevc_start_code + +.. tabularcolumns:: |p{9.2cm}|p{0.6cm}|p{7.5cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_STATELESS_HEVC_START_CODE_NONE`` + - 0 + - Selecting this value specifies that HEVC slices are passed + to the driver without any start code. The bitstream data should be + according to :ref:`hevc` 7.3.1.1 General NAL unit syntax, hence + contains emulation prevention bytes when required. + * - ``V4L2_STATELESS_HEVC_START_CODE_ANNEX_B`` + - 1 + - Selecting this value specifies that HEVC slices are expected + to be prefixed by Annex B start codes. According to :ref:`hevc` + valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001. + +.. raw:: latex + + \normalsize + +``V4L2_CID_MPEG_VIDEO_BASELAYER_PRIORITY_ID (integer)`` + Specifies a priority identifier for the NAL unit, which will be applied to + the base layer. By default this value is set to 0 for the base layer, + and the next layer will have the priority ID assigned as 1, 2, 3 and so on. + The video encoder can't decide the priority id to be applied to a layer, + so this has to come from client. + This is applicable to H264 and valid Range is from 0 to 63. + Source Rec. ITU-T H.264 (06/2019); G.7.4.1.1, G.8.8.1. + +``V4L2_CID_MPEG_VIDEO_LTR_COUNT (integer)`` + Specifies the maximum number of Long Term Reference (LTR) frames at any + given time that the encoder can keep. + This is applicable to the H264 and HEVC encoders. + +``V4L2_CID_MPEG_VIDEO_FRAME_LTR_INDEX (integer)`` + After setting this control the frame that will be queued next + will be marked as a Long Term Reference (LTR) frame + and given this LTR index which ranges from 0 to LTR_COUNT-1. + This is applicable to the H264 and HEVC encoders. + Source Rec. ITU-T H.264 (06/2019); Table 7.9 + +``V4L2_CID_MPEG_VIDEO_USE_LTR_FRAMES (bitmask)`` + Specifies the Long Term Reference (LTR) frame(s) to be used for + encoding the next frame queued after setting this control. + This provides a bitmask which consists of bits [0, LTR_COUNT-1]. + This is applicable to the H264 and HEVC encoders. + +``V4L2_CID_STATELESS_HEVC_DECODE_PARAMS (struct)`` + Specifies various decode parameters, especially the references picture order + count (POC) for all the lists (short, long, before, current, after) and the + number of entries for each of them. + These parameters are defined according to :ref:`hevc`. + They are described in section 8.3 "Slice decoding process" of the + specification. + +.. c:type:: v4l2_ctrl_hevc_decode_params + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_decode_params + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __s32 + - ``pic_order_cnt_val`` + - PicOrderCntVal as described in section 8.3.1 "Decoding process + for picture order count" of the specification. + * - __u16 + - ``short_term_ref_pic_set_size`` + - Specifies the size, in bits, of the short-term reference picture set, of the first slice + described as st_ref_pic_set() in the specification, included in the slice header + or SPS (section 7.3.6.1). + * - __u16 + - ``long_term_ref_pic_set_size`` + - Specifies the size, in bits, of the long-term reference picture set, of the first slice + included in the slice header or SPS. It is the number of bits in the conditional block + if(long_term_ref_pics_present_flag) in section 7.3.6.1 of the specification. + * - __u8 + - ``num_active_dpb_entries`` + - The number of entries in ``dpb``. + * - __u8 + - ``num_poc_st_curr_before`` + - The number of reference pictures in the short-term set that come before + the current frame. + * - __u8 + - ``num_poc_st_curr_after`` + - The number of reference pictures in the short-term set that come after + the current frame. + * - __u8 + - ``num_poc_lt_curr`` + - The number of reference pictures in the long-term set. + * - __u8 + - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference + picture set": provides the index of the short term before references in DPB array. + * - __u8 + - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference + picture set": provides the index of the short term after references in DPB array. + * - __u8 + - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - PocLtCurr as described in section 8.3.2 "Decoding process for reference + picture set": provides the index of the long term references in DPB array. + * - struct :c:type:`v4l2_hevc_dpb_entry` + - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` + - The decoded picture buffer, for meta-data about reference frames. + * - __u64 + - ``flags`` + - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>` + +.. _hevc_decode_params_flags: + +``Decode Parameters Flags`` + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC`` + - 0x00000001 + - + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC`` + - 0x00000002 + - + * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR`` + - 0x00000004 + - diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 6183f43f4d73..2a165ae063fb 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -2658,783 +2658,3 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - Indicates whether to generate SPS and PPS at every IDR. Setting it to 0 disables generating SPS and PPS at every IDR. Setting it to one enables generating SPS and PPS at every IDR. - -.. _v4l2-mpeg-hevc: - -``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)`` - Specifies the Sequence Parameter Set fields (as extracted from the - bitstream) for the associated HEVC slice data. - These bitstream parameters are defined according to :ref:`hevc`. - They are described in section 7.4.3.2 "Sequence parameter set RBSP - semantics" of the specification. - -.. c:type:: v4l2_ctrl_hevc_sps - -.. raw:: latex - - \small - -.. tabularcolumns:: |p{1.2cm}|p{9.2cm}|p{6.9cm}| - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_hevc_sps - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u16 - - ``pic_width_in_luma_samples`` - - - * - __u16 - - ``pic_height_in_luma_samples`` - - - * - __u8 - - ``bit_depth_luma_minus8`` - - - * - __u8 - - ``bit_depth_chroma_minus8`` - - - * - __u8 - - ``log2_max_pic_order_cnt_lsb_minus4`` - - - * - __u8 - - ``sps_max_dec_pic_buffering_minus1`` - - - * - __u8 - - ``sps_max_num_reorder_pics`` - - - * - __u8 - - ``sps_max_latency_increase_plus1`` - - - * - __u8 - - ``log2_min_luma_coding_block_size_minus3`` - - - * - __u8 - - ``log2_diff_max_min_luma_coding_block_size`` - - - * - __u8 - - ``log2_min_luma_transform_block_size_minus2`` - - - * - __u8 - - ``log2_diff_max_min_luma_transform_block_size`` - - - * - __u8 - - ``max_transform_hierarchy_depth_inter`` - - - * - __u8 - - ``max_transform_hierarchy_depth_intra`` - - - * - __u8 - - ``pcm_sample_bit_depth_luma_minus1`` - - - * - __u8 - - ``pcm_sample_bit_depth_chroma_minus1`` - - - * - __u8 - - ``log2_min_pcm_luma_coding_block_size_minus3`` - - - * - __u8 - - ``log2_diff_max_min_pcm_luma_coding_block_size`` - - - * - __u8 - - ``num_short_term_ref_pic_sets`` - - - * - __u8 - - ``num_long_term_ref_pics_sps`` - - - * - __u8 - - ``chroma_format_idc`` - - - * - __u8 - - ``sps_max_sub_layers_minus1`` - - - * - __u64 - - ``flags`` - - See :ref:`Sequence Parameter Set Flags <hevc_sps_flags>` - -.. raw:: latex - - \normalsize - -.. _hevc_sps_flags: - -``Sequence Parameter Set Flags`` - -.. raw:: latex - - \small - -.. cssclass:: longtable - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_HEVC_SPS_FLAG_SEPARATE_COLOUR_PLANE`` - - 0x00000001 - - - * - ``V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED`` - - 0x00000002 - - - * - ``V4L2_HEVC_SPS_FLAG_AMP_ENABLED`` - - 0x00000004 - - - * - ``V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET`` - - 0x00000008 - - - * - ``V4L2_HEVC_SPS_FLAG_PCM_ENABLED`` - - 0x00000010 - - - * - ``V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED`` - - 0x00000020 - - - * - ``V4L2_HEVC_SPS_FLAG_LONG_TERM_REF_PICS_PRESENT`` - - 0x00000040 - - - * - ``V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED`` - - 0x00000080 - - - * - ``V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED`` - - 0x00000100 - - - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_HEVC_PPS (struct)`` - Specifies the Picture Parameter Set fields (as extracted from the - bitstream) for the associated HEVC slice data. - These bitstream parameters are defined according to :ref:`hevc`. - They are described in section 7.4.3.3 "Picture parameter set RBSP - semantics" of the specification. - -.. c:type:: v4l2_ctrl_hevc_pps - -.. tabularcolumns:: |p{1.2cm}|p{8.6cm}|p{7.5cm}| - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_hevc_pps - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u8 - - ``num_extra_slice_header_bits`` - - - * - __u8 - - ``num_ref_idx_l0_default_active_minus1`` - - Specifies the inferred value of num_ref_idx_l0_active_minus1 - * - __u8 - - ``num_ref_idx_l1_default_active_minus1`` - - Specifies the inferred value of num_ref_idx_l1_active_minus1 - * - __s8 - - ``init_qp_minus26`` - - - * - __u8 - - ``diff_cu_qp_delta_depth`` - - - * - __s8 - - ``pps_cb_qp_offset`` - - - * - __s8 - - ``pps_cr_qp_offset`` - - - * - __u8 - - ``num_tile_columns_minus1`` - - - * - __u8 - - ``num_tile_rows_minus1`` - - - * - __u8 - - ``column_width_minus1[20]`` - - - * - __u8 - - ``row_height_minus1[22]`` - - - * - __s8 - - ``pps_beta_offset_div2`` - - - * - __s8 - - ``pps_tc_offset_div2`` - - - * - __u8 - - ``log2_parallel_merge_level_minus2`` - - - * - __u8 - - ``padding[4]`` - - Applications and drivers must set this to zero. - * - __u64 - - ``flags`` - - See :ref:`Picture Parameter Set Flags <hevc_pps_flags>` - -.. _hevc_pps_flags: - -``Picture Parameter Set Flags`` - -.. raw:: latex - - \small - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED`` - - 0x00000001 - - - * - ``V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT`` - - 0x00000002 - - - * - ``V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED`` - - 0x00000004 - - - * - ``V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT`` - - 0x00000008 - - - * - ``V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED`` - - 0x00000010 - - - * - ``V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED`` - - 0x00000020 - - - * - ``V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED`` - - 0x00000040 - - - * - ``V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT`` - - 0x00000080 - - - * - ``V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED`` - - 0x00000100 - - - * - ``V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED`` - - 0x00000200 - - - * - ``V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED`` - - 0x00000400 - - - * - ``V4L2_HEVC_PPS_FLAG_TILES_ENABLED`` - - 0x00000800 - - - * - ``V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED`` - - 0x00001000 - - - * - ``V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED`` - - 0x00002000 - - - * - ``V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED`` - - 0x00004000 - - - * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED`` - - 0x00008000 - - - * - ``V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER`` - - 0x00010000 - - - * - ``V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT`` - - 0x00020000 - - - * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT`` - - 0x00040000 - - - * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT`` - - 0x00080000 - - Specifies the presence of deblocking filter control syntax elements in - the PPS - * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING`` - - 0x00100000 - - Specifies that tile column boundaries and likewise tile row boundaries - are distributed uniformly across the picture - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS (struct)`` - Specifies various slice-specific parameters, especially from the NAL unit - header, general slice segment header and weighted prediction parameter - parts of the bitstream. - These bitstream parameters are defined according to :ref:`hevc`. - They are described in section 7.4.7 "General slice segment header - semantics" of the specification. - -.. c:type:: v4l2_ctrl_hevc_slice_params - -.. raw:: latex - - \scriptsize - -.. tabularcolumns:: |p{5.4cm}|p{6.8cm}|p{5.1cm}| - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_hevc_slice_params - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u32 - - ``bit_size`` - - Size (in bits) of the current slice data. - * - __u32 - - ``data_bit_offset`` - - Offset (in bits) to the video data in the current slice data. - * - __u8 - - ``nal_unit_type`` - - - * - __u8 - - ``nuh_temporal_id_plus1`` - - - * - __u8 - - ``slice_type`` - - - (V4L2_HEVC_SLICE_TYPE_I, V4L2_HEVC_SLICE_TYPE_P or - V4L2_HEVC_SLICE_TYPE_B). - * - __u8 - - ``colour_plane_id`` - - - * - __u16 - - ``slice_pic_order_cnt`` - - - * - __u8 - - ``num_ref_idx_l0_active_minus1`` - - - * - __u8 - - ``num_ref_idx_l1_active_minus1`` - - - * - __u8 - - ``collocated_ref_idx`` - - - * - __u8 - - ``five_minus_max_num_merge_cand`` - - - * - __s8 - - ``slice_qp_delta`` - - - * - __s8 - - ``slice_cb_qp_offset`` - - - * - __s8 - - ``slice_cr_qp_offset`` - - - * - __s8 - - ``slice_act_y_qp_offset`` - - - * - __s8 - - ``slice_act_cb_qp_offset`` - - - * - __s8 - - ``slice_act_cr_qp_offset`` - - - * - __s8 - - ``slice_beta_offset_div2`` - - - * - __s8 - - ``slice_tc_offset_div2`` - - - * - __u8 - - ``pic_struct`` - - - * - __u32 - - ``slice_segment_addr`` - - - * - __u8 - - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - The list of L0 reference elements as indices in the DPB. - * - __u8 - - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - The list of L1 reference elements as indices in the DPB. - * - __u8 - - ``padding`` - - Applications and drivers must set this to zero. - * - struct :c:type:`v4l2_hevc_pred_weight_table` - - ``pred_weight_table`` - - The prediction weight coefficients for inter-picture prediction. - * - __u64 - - ``flags`` - - See :ref:`Slice Parameters Flags <hevc_slice_params_flags>` - -.. raw:: latex - - \normalsize - -.. _hevc_slice_params_flags: - -``Slice Parameters Flags`` - -.. raw:: latex - - \scriptsize - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_LUMA`` - - 0x00000001 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_SAO_CHROMA`` - - 0x00000002 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_TEMPORAL_MVP_ENABLED`` - - 0x00000004 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_MVD_L1_ZERO`` - - 0x00000008 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_CABAC_INIT`` - - 0x00000010 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_COLLOCATED_FROM_L0`` - - 0x00000020 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_USE_INTEGER_MV`` - - 0x00000040 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_DEBLOCKING_FILTER_DISABLED`` - - 0x00000080 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED`` - - 0x00000100 - - - * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT`` - - 0x00000200 - - - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX (struct)`` - Specifies the HEVC scaling matrix parameters used for the scaling process - for transform coefficients. - These matrix and parameters are defined according to :ref:`hevc`. - They are described in section 7.4.5 "Scaling list data semantics" of - the specification. - -.. c:type:: v4l2_ctrl_hevc_scaling_matrix - -.. raw:: latex - - \scriptsize - -.. tabularcolumns:: |p{5.4cm}|p{6.8cm}|p{5.1cm}| - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_hevc_scaling_matrix - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u8 - - ``scaling_list_4x4[6][16]`` - - Scaling list is used for the scaling process for transform - coefficients. The values on each scaling list are expected - in raster scan order. - * - __u8 - - ``scaling_list_8x8[6][64]`` - - Scaling list is used for the scaling process for transform - coefficients. The values on each scaling list are expected - in raster scan order. - * - __u8 - - ``scaling_list_16x16[6][64]`` - - Scaling list is used for the scaling process for transform - coefficients. The values on each scaling list are expected - in raster scan order. - * - __u8 - - ``scaling_list_32x32[2][64]`` - - Scaling list is used for the scaling process for transform - coefficients. The values on each scaling list are expected - in raster scan order. - * - __u8 - - ``scaling_list_dc_coef_16x16[6]`` - - Scaling list is used for the scaling process for transform - coefficients. The values on each scaling list are expected - in raster scan order. - * - __u8 - - ``scaling_list_dc_coef_32x32[2]`` - - Scaling list is used for the scaling process for transform - coefficients. The values on each scaling list are expected - in raster scan order. - -.. raw:: latex - - \normalsize - -.. c:type:: v4l2_hevc_dpb_entry - -.. raw:: latex - - \small - -.. tabularcolumns:: |p{1.0cm}|p{4.2cm}|p{12.1cm}| - -.. flat-table:: struct v4l2_hevc_dpb_entry - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u64 - - ``timestamp`` - - Timestamp of the V4L2 capture buffer to use as reference, used - with B-coded and P-coded frames. The timestamp refers to the - ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the - :c:func:`v4l2_timeval_to_ns()` function to convert the struct - :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. - * - __u8 - - ``flags`` - - Long term flag for the reference frame - (V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE). The flag is set as - described in the ITU HEVC specification chapter "8.3.2 Decoding - process for reference picture set". - * - __u8 - - ``field_pic`` - - Whether the reference is a field picture or a frame. - * - __u16 - - ``pic_order_cnt[2]`` - - The picture order count of the reference. Only the first element of the - array is used for frame pictures, while the first element identifies the - top field and the second the bottom field in field-coded pictures. - * - __u8 - - ``padding[2]`` - - Applications and drivers must set this to zero. - -.. raw:: latex - - \normalsize - -.. c:type:: v4l2_hevc_pred_weight_table - -.. raw:: latex - - \footnotesize - -.. tabularcolumns:: |p{0.8cm}|p{10.6cm}|p{5.9cm}| - -.. flat-table:: struct v4l2_hevc_pred_weight_table - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __u8 - - ``luma_log2_weight_denom`` - - - * - __s8 - - ``delta_chroma_log2_weight_denom`` - - - * - __s8 - - ``delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - - * - __s8 - - ``luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - - * - __s8 - - ``delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` - - - * - __s8 - - ``chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` - - - * - __s8 - - ``delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - - * - __s8 - - ``luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - - * - __s8 - - ``delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` - - - * - __s8 - - ``chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2]`` - - - * - __u8 - - ``padding[6]`` - - Applications and drivers must set this to zero. - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE (enum)`` - Specifies the decoding mode to use. Currently exposes slice-based and - frame-based decoding but new modes might be added later on. - This control is used as a modifier for V4L2_PIX_FMT_HEVC_SLICE - pixel format. Applications that support V4L2_PIX_FMT_HEVC_SLICE - are required to set this control in order to specify the decoding mode - that is expected for the buffer. - Drivers may expose a single or multiple decoding modes, depending - on what they can support. - - .. note:: - - This menu control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_mpeg_video_hevc_decode_mode - -.. raw:: latex - - \small - -.. tabularcolumns:: |p{9.4cm}|p{0.6cm}|p{7.3cm}| - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED`` - - 0 - - Decoding is done at the slice granularity. - The OUTPUT buffer must contain a single slice. - * - ``V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED`` - - 1 - - Decoding is done at the frame granularity. - The OUTPUT buffer must contain all slices needed to decode the - frame. The OUTPUT buffer must also contain both fields. - -.. raw:: latex - - \normalsize - -``V4L2_CID_MPEG_VIDEO_HEVC_START_CODE (enum)`` - Specifies the HEVC slice start code expected for each slice. - This control is used as a modifier for V4L2_PIX_FMT_HEVC_SLICE - pixel format. Applications that support V4L2_PIX_FMT_HEVC_SLICE - are required to set this control in order to specify the start code - that is expected for the buffer. - Drivers may expose a single or multiple start codes, depending - on what they can support. - - .. note:: - - This menu control is not yet part of the public kernel API and - it is expected to change. - -.. c:type:: v4l2_mpeg_video_hevc_start_code - -.. tabularcolumns:: |p{9.2cm}|p{0.6cm}|p{7.5cm}| - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_MPEG_VIDEO_HEVC_START_CODE_NONE`` - - 0 - - Selecting this value specifies that HEVC slices are passed - to the driver without any start code. The bitstream data should be - according to :ref:`hevc` 7.3.1.1 General NAL unit syntax, hence - contains emulation prevention bytes when required. - * - ``V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B`` - - 1 - - Selecting this value specifies that HEVC slices are expected - to be prefixed by Annex B start codes. According to :ref:`hevc` - valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001. - -``V4L2_CID_MPEG_VIDEO_BASELAYER_PRIORITY_ID (integer)`` - Specifies a priority identifier for the NAL unit, which will be applied to - the base layer. By default this value is set to 0 for the base layer, - and the next layer will have the priority ID assigned as 1, 2, 3 and so on. - The video encoder can't decide the priority id to be applied to a layer, - so this has to come from client. - This is applicable to H264 and valid Range is from 0 to 63. - Source Rec. ITU-T H.264 (06/2019); G.7.4.1.1, G.8.8.1. - -``V4L2_CID_MPEG_VIDEO_LTR_COUNT (integer)`` - Specifies the maximum number of Long Term Reference (LTR) frames at any - given time that the encoder can keep. - This is applicable to the H264 and HEVC encoders. - -``V4L2_CID_MPEG_VIDEO_FRAME_LTR_INDEX (integer)`` - After setting this control the frame that will be queued next - will be marked as a Long Term Reference (LTR) frame - and given this LTR index which ranges from 0 to LTR_COUNT-1. - This is applicable to the H264 and HEVC encoders. - Source Rec. ITU-T H.264 (06/2019); Table 7.9 - -``V4L2_CID_MPEG_VIDEO_USE_LTR_FRAMES (bitmask)`` - Specifies the Long Term Reference (LTR) frame(s) to be used for - encoding the next frame queued after setting this control. - This provides a bitmask which consists of bits [0, LTR_COUNT-1]. - This is applicable to the H264 and HEVC encoders. - -``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)`` - Specifies various decode parameters, especially the references picture order - count (POC) for all the lists (short, long, before, current, after) and the - number of entries for each of them. - These parameters are defined according to :ref:`hevc`. - They are described in section 8.3 "Slice decoding process" of the - specification. - -.. c:type:: v4l2_ctrl_hevc_decode_params - -.. cssclass:: longtable - -.. flat-table:: struct v4l2_ctrl_hevc_decode_params - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - __s32 - - ``pic_order_cnt_val`` - - PicOrderCntVal as described in section 8.3.1 "Decoding process - for picture order count" of the specification. - * - __u8 - - ``num_active_dpb_entries`` - - The number of entries in ``dpb``. - * - struct :c:type:`v4l2_hevc_dpb_entry` - - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - The decoded picture buffer, for meta-data about reference frames. - * - __u8 - - ``num_poc_st_curr_before`` - - The number of reference pictures in the short-term set that come before - the current frame. - * - __u8 - - ``num_poc_st_curr_after`` - - The number of reference pictures in the short-term set that come after - the current frame. - * - __u8 - - ``num_poc_lt_curr`` - - The number of reference pictures in the long-term set. - * - __u8 - - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference - picture set": provides the index of the short term before references in DPB array. - * - __u8 - - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference - picture set": provides the index of the short term after references in DPB array. - * - __u8 - - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - - PocLtCurr as described in section 8.3.2 "Decoding process for reference - picture set": provides the index of the long term references in DPB array. - * - __u64 - - ``flags`` - - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>` - -.. _hevc_decode_params_flags: - -``Decode Parameters Flags`` - -.. cssclass:: longtable - -.. flat-table:: - :header-rows: 0 - :stub-columns: 0 - :widths: 1 1 2 - - * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC`` - - 0x00000001 - - - * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC`` - - 0x00000002 - - - * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR`` - - 0x00000004 - - diff --git a/Documentation/userspace-api/media/v4l/mmap.rst b/Documentation/userspace-api/media/v4l/mmap.rst index 16b1e13b029f..a5672573dd6f 100644 --- a/Documentation/userspace-api/media/v4l/mmap.rst +++ b/Documentation/userspace-api/media/v4l/mmap.rst @@ -232,7 +232,7 @@ In the write loop, when the application runs out of free buffers, it must wait until an empty buffer can be dequeued and reused. To enqueue and dequeue a buffer applications use the -:ref:`VIVIOC_QBUF <VIDIOC_QBUF>` and :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` +:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. The status of a buffer being mapped, enqueued, full or empty can be determined at any time using the :ref:`VIDIOC_QUERYBUF` ioctl. Two methods exist to suspend execution of the application until one or more diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 967fc803ef94..506dd3c98884 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -212,14 +212,9 @@ Compressed Formats ``V4L2_CID_MPEG_VIDEO_HEVC_SPS``, ``V4L2_CID_MPEG_VIDEO_HEVC_PPS``, and ``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS``. - See the :ref:`associated Codec Control IDs <v4l2-mpeg-hevc>`. + See the :ref:`associated Codec Control IDs <v4l2-codec-stateless-hevc>`. Buffers associated with this pixel format must contain the appropriate number of macroblocks to decode a full corresponding frame. - - .. note:: - - This format is not yet part of the public kernel API and it - is expected to change. * .. _V4L2-PIX-FMT-FWHT: - ``V4L2_PIX_FMT_FWHT`` diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst index 65520c3af7cf..bf283a1b5581 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst @@ -220,6 +220,26 @@ the second byte and Y'\ :sub:`7-0` in the third byte. - Y'\ :sub:`7-0` - X\ :sub:`7-0` + * .. _V4L2-PIX-FMT-YUVA32: + + - ``V4L2_PIX_FMT_YUVA32`` + - 'YUVA' + + - Y'\ :sub:`7-0` + - Cb\ :sub:`7-0` + - Cr\ :sub:`7-0` + - A\ :sub:`7-0` + + * .. _V4L2-PIX-FMT-YUVX32: + + - ``V4L2_PIX_FMT_YUVX32`` + - 'YUVX' + + - Y'\ :sub:`7-0` + - Cb\ :sub:`7-0` + - Cr\ :sub:`7-0` + - X\ :sub:`7-0` + * .. _V4L2-PIX-FMT-YUV24: - ``V4L2_PIX_FMT_YUV24`` diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 8dff5906639b..10b1feeb0b57 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -109,6 +109,20 @@ All components are stored with the same number of bits per component. - Cb, Cr - No - 16x16 tiles + * - V4L2_PIX_FMT_P010 + - 'P010' + - 10 + - 4:2:0 + - Cb, Cr + - Yes + - Linear + * - V4L2_PIX_FMT_P010_4L4 + - 'T010' + - 10 + - 4:2:0 + - Cb, Cr + - Yes + - 4x4 tiles * - V4L2_PIX_FMT_NV16 - 'NV16' - 8 @@ -171,6 +185,7 @@ horizontally. .. _V4L2-PIX-FMT-NV21: .. _V4L2-PIX-FMT-NV12M: .. _V4L2-PIX-FMT-NV21M: +.. _V4L2-PIX-FMT-P010: NV12, NV21, NV12M and NV21M --------------------------- @@ -519,6 +534,50 @@ number of lines as the luma plane. - Cb\ :sub:`33` - Cr\ :sub:`33` +.. _V4L2_PIX_FMT_P010: +.. _V4L2-PIX-FMT-P010-4L4: + +P010 and tiled P010 +------------------- + +P010 is like NV12 with 10 bits per component, expanded to 16 bits. +Data in the 10 high bits, zeros in the 6 low bits, arranged in little endian order. + +.. flat-table:: Sample 4x4 P010 Image + :header-rows: 0 + :stub-columns: 0 + + * - start + 0: + - Y'\ :sub:`00` + - Y'\ :sub:`01` + - Y'\ :sub:`02` + - Y'\ :sub:`03` + * - start + 8: + - Y'\ :sub:`10` + - Y'\ :sub:`11` + - Y'\ :sub:`12` + - Y'\ :sub:`13` + * - start + 16: + - Y'\ :sub:`20` + - Y'\ :sub:`21` + - Y'\ :sub:`22` + - Y'\ :sub:`23` + * - start + 24: + - Y'\ :sub:`30` + - Y'\ :sub:`31` + - Y'\ :sub:`32` + - Y'\ :sub:`33` + * - start + 32: + - Cb\ :sub:`00` + - Cr\ :sub:`00` + - Cb\ :sub:`01` + - Cr\ :sub:`01` + * - start + 40: + - Cb\ :sub:`10` + - Cr\ :sub:`10` + - Cb\ :sub:`11` + - Cr\ :sub:`11` + Fully Planar YUV Formats ======================== @@ -538,6 +597,10 @@ relationship between the luma and chroma line padding and stride. All components are stored with the same number of bits per component. +``V4L2_PIX_FMT_P010_4L4`` stores pixels in 4x4 tiles, and stores tiles linearly +in memory. The line stride must be aligned to multiple of 8 and image height to +a multiple of 4. The layouts of the luma and chroma planes are identical. + .. raw:: latex \small diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index 0cbc045d5df6..d21d532eee15 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -1492,6 +1492,80 @@ The following tables list existing packed RGB formats. - b\ :sub:`2` - b\ :sub:`1` - b\ :sub:`0` + * .. _MEDIA-BUS-FMT-RGB666-1X30-CPADLO: + + - MEDIA_BUS_FMT_RGB666_1X30-CPADLO + - 0x101e + - + - + - + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + * .. _MEDIA-BUS-FMT-RGB888-1X30-CPADLO: + + - MEDIA_BUS_FMT_RGB888_1X30-CPADLO + - 0x101f + - + - + - + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - 0 + - 0 + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - 0 + - 0 + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - 0 + - 0 * .. _MEDIA-BUS-FMT-ARGB888-1X32: - MEDIA_BUS_FMT_ARGB888_1X32 @@ -1669,6 +1743,88 @@ The following table list existing packed 36bit wide RGB formats. - 2 - 1 - 0 + * .. _MEDIA-BUS-FMT-RGB666-1X36-CPADLO: + + - MEDIA_BUS_FMT_RGB666_1X36_CPADLO + - 0x1020 + - + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - 0 + - 0 + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - 0 + - 0 + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - 0 + - 0 + * .. _MEDIA-BUS-FMT-RGB888-1X36-CPADLO: + + - MEDIA_BUS_FMT_RGB888_1X36_CPADLO + - 0x1021 + - + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - 0 + - 0 + - 0 + - 0 + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + - 0 + - 0 + - 0 + - 0 * .. _MEDIA-BUS-FMT-RGB121212-1X36: - MEDIA_BUS_FMT_RGB121212_1X36 diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 29971a45a2d4..892cfeb8b988 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -249,6 +249,26 @@ still cause this situation. - ``p_hdr10_mastering`` - A pointer to a struct :c:type:`v4l2_ctrl_hdr10_mastering_display`. Valid if this control is of type ``V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY``. + * - struct :c:type:`v4l2_ctrl_hevc_sps` * + - ``p_hevc_sps`` + - A pointer to a struct :c:type:`v4l2_ctrl_hevc_sps`. Valid if this + control is of type ``V4L2_CTRL_TYPE_HEVC_SPS``. + * - struct :c:type:`v4l2_ctrl_hevc_pps` * + - ``p_hevc_pps`` + - A pointer to a struct :c:type:`v4l2_ctrl_hevc_pps`. Valid if this + control is of type ``V4L2_CTRL_TYPE_HEVC_PPS``. + * - struct :c:type:`v4l2_ctrl_hevc_slice_params` * + - ``p_hevc_slice_params`` + - A pointer to a struct :c:type:`v4l2_ctrl_hevc_slice_params`. Valid if this + control is of type ``V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS``. + * - struct :c:type:`v4l2_ctrl_hevc_scaling_matrix` * + - ``p_hevc_scaling_matrix`` + - A pointer to a struct :c:type:`v4l2_ctrl_hevc_scaling_matrix`. Valid if this + control is of type ``V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX``. + * - struct :c:type:`v4l2_ctrl_hevc_decode_params` * + - ``p_hevc_decode_params`` + - A pointer to a struct :c:type:`v4l2_ctrl_hevc_decode_params`. Valid if this + control is of type ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS``. * - void * - ``ptr`` - A pointer to a compound type which can be an N-dimensional array diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 88f630252d98..a20dfa2a933b 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -625,6 +625,14 @@ See also the examples in :ref:`control`. ``V4L2_CTRL_FLAG_GRABBED`` flag when buffers are allocated or streaming is in progress since most drivers do not support changing the format in that case. + * - ``V4L2_CTRL_FLAG_DYNAMIC_ARRAY`` + - 0x0800 + - This control is a dynamically sized 1-dimensional array. It + behaves the same as a regular array, except that the number + of elements as reported by the ``elems`` field is between 1 and + ``dims[0]``. So setting the control with a differently sized + array will change the ``elems`` field when the control is + queried afterwards. Return Value ============ diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 9cbb7a0c354a..64b2c0b1f666 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -70,6 +70,7 @@ replace symbol V4L2_COLORSPACE_REC709 :c:type:`v4l2_colorspace` replace symbol V4L2_COLORSPACE_SMPTE170M :c:type:`v4l2_colorspace` replace symbol V4L2_COLORSPACE_SMPTE240M :c:type:`v4l2_colorspace` replace symbol V4L2_COLORSPACE_SRGB :c:type:`v4l2_colorspace` +replace symbol V4L2_COLORSPACE_LAST :c:type:`v4l2_colorspace` # Documented enum v4l2_xfer_func replace symbol V4L2_XFER_FUNC_709 :c:type:`v4l2_xfer_func` @@ -81,6 +82,7 @@ replace symbol V4L2_XFER_FUNC_NONE :c:type:`v4l2_xfer_func` replace symbol V4L2_XFER_FUNC_SMPTE2084 :c:type:`v4l2_xfer_func` replace symbol V4L2_XFER_FUNC_SMPTE240M :c:type:`v4l2_xfer_func` replace symbol V4L2_XFER_FUNC_SRGB :c:type:`v4l2_xfer_func` +replace symbol V4L2_XFER_FUNC_LAST :c:type:`v4l2_xfer_func` # Documented enum v4l2_ycbcr_encoding replace symbol V4L2_YCBCR_ENC_601 :c:type:`v4l2_ycbcr_encoding` @@ -92,6 +94,7 @@ replace symbol V4L2_YCBCR_ENC_SYCC :c:type:`v4l2_ycbcr_encoding` replace symbol V4L2_YCBCR_ENC_XV601 :c:type:`v4l2_ycbcr_encoding` replace symbol V4L2_YCBCR_ENC_XV709 :c:type:`v4l2_ycbcr_encoding` replace symbol V4L2_YCBCR_ENC_SMPTE240M :c:type:`v4l2_ycbcr_encoding` +replace symbol V4L2_YCBCR_ENC_LAST :c:type:`v4l2_ycbcr_encoding` # Documented enum v4l2_hsv_encoding replace symbol V4L2_HSV_ENC_180 :c:type:`v4l2_hsv_encoding` @@ -153,6 +156,11 @@ replace symbol V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_VP9_FRAME :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HDR10_CLL_INFO :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_HEVC_SPS :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_HEVC_PPS :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS :c:type:`v4l2_ctrl_type` # V4L2 capability defines replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities @@ -379,6 +387,7 @@ replace define V4L2_CTRL_FLAG_VOLATILE control-flags replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags +replace define V4L2_CTRL_FLAG_DYNAMIC_ARRAY control-flags replace define V4L2_CTRL_FLAG_NEXT_CTRL control replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control diff --git a/Documentation/virt/hyperv/clocks.rst b/Documentation/virt/hyperv/clocks.rst new file mode 100644 index 000000000000..2da2879fad52 --- /dev/null +++ b/Documentation/virt/hyperv/clocks.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Clocks and Timers +================= + +arm64 +----- +On arm64, Hyper-V virtualizes the ARMv8 architectural system counter +and timer. Guest VMs use this virtualized hardware as the Linux +clocksource and clockevents via the standard arm_arch_timer.c +driver, just as they would on bare metal. Linux vDSO support for the +architectural system counter is functional in guest VMs on Hyper-V. +While Hyper-V also provides a synthetic system clock and four synthetic +per-CPU timers as described in the TLFS, they are not used by the +Linux kernel in a Hyper-V guest on arm64. However, older versions +of Hyper-V for arm64 only partially virtualize the ARMv8 +architectural timer, such that the timer does not generate +interrupts in the VM. Because of this limitation, running current +Linux kernel versions on these older Hyper-V versions requires an +out-of-tree patch to use the Hyper-V synthetic clocks/timers instead. + +x86/x64 +------- +On x86/x64, Hyper-V provides guest VMs with a synthetic system clock +and four synthetic per-CPU timers as described in the TLFS. Hyper-V +also provides access to the virtualized TSC via the RDTSC and +related instructions. These TSC instructions do not trap to +the hypervisor and so provide excellent performance in a VM. +Hyper-V performs TSC calibration, and provides the TSC frequency +to the guest VM via a synthetic MSR. Hyper-V initialization code +in Linux reads this MSR to get the frequency, so it skips TSC +calibration and sets tsc_reliable. Hyper-V provides virtualized +versions of the PIT (in Hyper-V Generation 1 VMs only), local +APIC timer, and RTC. Hyper-V does not provide a virtualized HPET in +guest VMs. + +The Hyper-V synthetic system clock can be read via a synthetic MSR, +but this access traps to the hypervisor. As a faster alternative, +the guest can configure a memory page to be shared between the guest +and the hypervisor. Hyper-V populates this memory page with a +64-bit scale value and offset value. To read the synthetic clock +value, the guest reads the TSC and then applies the scale and offset +as described in the Hyper-V TLFS. The resulting value advances +at a constant 10 MHz frequency. In the case of a live migration +to a host with a different TSC frequency, Hyper-V adjusts the +scale and offset values in the shared page so that the 10 MHz +frequency is maintained. + +Starting with Windows Server 2022 Hyper-V, Hyper-V uses hardware +support for TSC frequency scaling to enable live migration of VMs +across Hyper-V hosts where the TSC frequency may be different. +When a Linux guest detects that this Hyper-V functionality is +available, it prefers to use Linux's standard TSC-based clocksource. +Otherwise, it uses the clocksource for the Hyper-V synthetic system +clock implemented via the shared page (identified as +"hyperv_clocksource_tsc_page"). + +The Hyper-V synthetic system clock is available to user space via +vDSO, and gettimeofday() and related system calls can execute +entirely in user space. The vDSO is implemented by mapping the +shared page with scale and offset values into user space. User +space code performs the same algorithm of reading the TSC and +appying the scale and offset to get the constant 10 MHz clock. + +Linux clockevents are based on Hyper-V synthetic timer 0. While +Hyper-V offers 4 synthetic timers for each CPU, Linux only uses +timer 0. Interrupts from stimer0 are recorded on the "HVS" line in +/proc/interrupts. Clockevents based on the virtualized PIT and +local APIC timer also work, but the Hyper-V synthetic timer is +preferred. + +The driver for the Hyper-V synthetic system clock and timers is +drivers/clocksource/hyperv_timer.c. diff --git a/Documentation/virt/hyperv/index.rst b/Documentation/virt/hyperv/index.rst new file mode 100644 index 000000000000..4a7a1b738bbe --- /dev/null +++ b/Documentation/virt/hyperv/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +Hyper-V Enlightenments +====================== + +.. toctree:: + :maxdepth: 1 + + overview + vmbus + clocks diff --git a/Documentation/virt/hyperv/overview.rst b/Documentation/virt/hyperv/overview.rst new file mode 100644 index 000000000000..cd493332c88a --- /dev/null +++ b/Documentation/virt/hyperv/overview.rst @@ -0,0 +1,207 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Overview +======== +The Linux kernel contains a variety of code for running as a fully +enlightened guest on Microsoft's Hyper-V hypervisor. Hyper-V +consists primarily of a bare-metal hypervisor plus a virtual machine +management service running in the parent partition (roughly +equivalent to KVM and QEMU, for example). Guest VMs run in child +partitions. In this documentation, references to Hyper-V usually +encompass both the hypervisor and the VMM service without making a +distinction about which functionality is provided by which +component. + +Hyper-V runs on x86/x64 and arm64 architectures, and Linux guests +are supported on both. The functionality and behavior of Hyper-V is +generally the same on both architectures unless noted otherwise. + +Linux Guest Communication with Hyper-V +-------------------------------------- +Linux guests communicate with Hyper-V in four different ways: + +* Implicit traps: As defined by the x86/x64 or arm64 architecture, + some guest actions trap to Hyper-V. Hyper-V emulates the action and + returns control to the guest. This behavior is generally invisible + to the Linux kernel. + +* Explicit hypercalls: Linux makes an explicit function call to + Hyper-V, passing parameters. Hyper-V performs the requested action + and returns control to the caller. Parameters are passed in + processor registers or in memory shared between the Linux guest and + Hyper-V. On x86/x64, hypercalls use a Hyper-V specific calling + sequence. On arm64, hypercalls use the ARM standard SMCCC calling + sequence. + +* Synthetic register access: Hyper-V implements a variety of + synthetic registers. On x86/x64 these registers appear as MSRs in + the guest, and the Linux kernel can read or write these MSRs using + the normal mechanisms defined by the x86/x64 architecture. On + arm64, these synthetic registers must be accessed using explicit + hypercalls. + +* VMbus: VMbus is a higher-level software construct that is built on + the other 3 mechanisms. It is a message passing interface between + the Hyper-V host and the Linux guest. It uses memory that is shared + between Hyper-V and the guest, along with various signaling + mechanisms. + +The first three communication mechanisms are documented in the +`Hyper-V Top Level Functional Spec (TLFS)`_. The TLFS describes +general Hyper-V functionality and provides details on the hypercalls +and synthetic registers. The TLFS is currently written for the +x86/x64 architecture only. + +.. _Hyper-V Top Level Functional Spec (TLFS): https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs + +VMbus is not documented. This documentation provides a high-level +overview of VMbus and how it works, but the details can be discerned +only from the code. + +Sharing Memory +-------------- +Many aspects are communication between Hyper-V and Linux are based +on sharing memory. Such sharing is generally accomplished as +follows: + +* Linux allocates memory from its physical address space using + standard Linux mechanisms. + +* Linux tells Hyper-V the guest physical address (GPA) of the + allocated memory. Many shared areas are kept to 1 page so that a + single GPA is sufficient. Larger shared areas require a list of + GPAs, which usually do not need to be contiguous in the guest + physical address space. How Hyper-V is told about the GPA or list + of GPAs varies. In some cases, a single GPA is written to a + synthetic register. In other cases, a GPA or list of GPAs is sent + in a VMbus message. + +* Hyper-V translates the GPAs into "real" physical memory addresses, + and creates a virtual mapping that it can use to access the memory. + +* Linux can later revoke sharing it has previously established by + telling Hyper-V to set the shared GPA to zero. + +Hyper-V operates with a page size of 4 Kbytes. GPAs communicated to +Hyper-V may be in the form of page numbers, and always describe a +range of 4 Kbytes. Since the Linux guest page size on x86/x64 is +also 4 Kbytes, the mapping from guest page to Hyper-V page is 1-to-1. +On arm64, Hyper-V supports guests with 4/16/64 Kbyte pages as +defined by the arm64 architecture. If Linux is using 16 or 64 +Kbyte pages, Linux code must be careful to communicate with Hyper-V +only in terms of 4 Kbyte pages. HV_HYP_PAGE_SIZE and related macros +are used in code that communicates with Hyper-V so that it works +correctly in all configurations. + +As described in the TLFS, a few memory pages shared between Hyper-V +and the Linux guest are "overlay" pages. With overlay pages, Linux +uses the usual approach of allocating guest memory and telling +Hyper-V the GPA of the allocated memory. But Hyper-V then replaces +that physical memory page with a page it has allocated, and the +original physical memory page is no longer accessible in the guest +VM. Linux may access the memory normally as if it were the memory +that it originally allocated. The "overlay" behavior is visible +only because the contents of the page (as seen by Linux) change at +the time that Linux originally establishes the sharing and the +overlay page is inserted. Similarly, the contents change if Linux +revokes the sharing, in which case Hyper-V removes the overlay page, +and the guest page originally allocated by Linux becomes visible +again. + +Before Linux does a kexec to a kdump kernel or any other kernel, +memory shared with Hyper-V should be revoked. Hyper-V could modify +a shared page or remove an overlay page after the new kernel is +using the page for a different purpose, corrupting the new kernel. +Hyper-V does not provide a single "set everything" operation to +guest VMs, so Linux code must individually revoke all sharing before +doing kexec. See hv_kexec_handler() and hv_crash_handler(). But +the crash/panic path still has holes in cleanup because some shared +pages are set using per-CPU synthetic registers and there's no +mechanism to revoke the shared pages for CPUs other than the CPU +running the panic path. + +CPU Management +-------------- +Hyper-V does not have a ability to hot-add or hot-remove a CPU +from a running VM. However, Windows Server 2019 Hyper-V and +earlier versions may provide guests with ACPI tables that indicate +more CPUs than are actually present in the VM. As is normal, Linux +treats these additional CPUs as potential hot-add CPUs, and reports +them as such even though Hyper-V will never actually hot-add them. +Starting in Windows Server 2022 Hyper-V, the ACPI tables reflect +only the CPUs actually present in the VM, so Linux does not report +any hot-add CPUs. + +A Linux guest CPU may be taken offline using the normal Linux +mechanisms, provided no VMbus channel interrupts are assigned to +the CPU. See the section on VMbus Interrupts for more details +on how VMbus channel interrupts can be re-assigned to permit +taking a CPU offline. + +32-bit and 64-bit +----------------- +On x86/x64, Hyper-V supports 32-bit and 64-bit guests, and Linux +will build and run in either version. While the 32-bit version is +expected to work, it is used rarely and may suffer from undetected +regressions. + +On arm64, Hyper-V supports only 64-bit guests. + +Endian-ness +----------- +All communication between Hyper-V and guest VMs uses Little-Endian +format on both x86/x64 and arm64. Big-endian format on arm64 is not +supported by Hyper-V, and Linux code does not use endian-ness macros +when accessing data shared with Hyper-V. + +Versioning +---------- +Current Linux kernels operate correctly with older versions of +Hyper-V back to Windows Server 2012 Hyper-V. Support for running +on the original Hyper-V release in Windows Server 2008/2008 R2 +has been removed. + +A Linux guest on Hyper-V outputs in dmesg the version of Hyper-V +it is running on. This version is in the form of a Windows build +number and is for display purposes only. Linux code does not +test this version number at runtime to determine available features +and functionality. Hyper-V indicates feature/function availability +via flags in synthetic MSRs that Hyper-V provides to the guest, +and the guest code tests these flags. + +VMbus has its own protocol version that is negotiated during the +initial VMbus connection from the guest to Hyper-V. This version +number is also output to dmesg during boot. This version number +is checked in a few places in the code to determine if specific +functionality is present. + +Furthermore, each synthetic device on VMbus also has a protocol +version that is separate from the VMbus protocol version. Device +drivers for these synthetic devices typically negotiate the device +protocol version, and may test that protocol version to determine +if specific device functionality is present. + +Code Packaging +-------------- +Hyper-V related code appears in the Linux kernel code tree in three +main areas: + +1. drivers/hv + +2. arch/x86/hyperv and arch/arm64/hyperv + +3. individual device driver areas such as drivers/scsi, drivers/net, + drivers/clocksource, etc. + +A few miscellaneous files appear elsewhere. See the full list under +"Hyper-V/Azure CORE AND DRIVERS" and "DRM DRIVER FOR HYPERV +SYNTHETIC VIDEO DEVICE" in the MAINTAINERS file. + +The code in #1 and #2 is built only when CONFIG_HYPERV is set. +Similarly, the code for most Hyper-V related drivers is built only +when CONFIG_HYPERV is set. + +Most Hyper-V related code in #1 and #3 can be built as a module. +The architecture specific code in #2 must be built-in. Also, +drivers/hv/hv_common.c is low-level code that is common across +architectures and must be built-in. diff --git a/Documentation/virt/hyperv/vmbus.rst b/Documentation/virt/hyperv/vmbus.rst new file mode 100644 index 000000000000..d2012d9022c5 --- /dev/null +++ b/Documentation/virt/hyperv/vmbus.rst @@ -0,0 +1,303 @@ +.. SPDX-License-Identifier: GPL-2.0 + +VMbus +===== +VMbus is a software construct provided by Hyper-V to guest VMs. It +consists of a control path and common facilities used by synthetic +devices that Hyper-V presents to guest VMs. The control path is +used to offer synthetic devices to the guest VM and, in some cases, +to rescind those devices. The common facilities include software +channels for communicating between the device driver in the guest VM +and the synthetic device implementation that is part of Hyper-V, and +signaling primitives to allow Hyper-V and the guest to interrupt +each other. + +VMbus is modeled in Linux as a bus, with the expected /sys/bus/vmbus +entry in a running Linux guest. The VMbus driver (drivers/hv/vmbus_drv.c) +establishes the VMbus control path with the Hyper-V host, then +registers itself as a Linux bus driver. It implements the standard +bus functions for adding and removing devices to/from the bus. + +Most synthetic devices offered by Hyper-V have a corresponding Linux +device driver. These devices include: + +* SCSI controller +* NIC +* Graphics frame buffer +* Keyboard +* Mouse +* PCI device pass-thru +* Heartbeat +* Time Sync +* Shutdown +* Memory balloon +* Key/Value Pair (KVP) exchange with Hyper-V +* Hyper-V online backup (a.k.a. VSS) + +Guest VMs may have multiple instances of the synthetic SCSI +controller, synthetic NIC, and PCI pass-thru devices. Other +synthetic devices are limited to a single instance per VM. Not +listed above are a small number of synthetic devices offered by +Hyper-V that are used only by Windows guests and for which Linux +does not have a driver. + +Hyper-V uses the terms "VSP" and "VSC" in describing synthetic +devices. "VSP" refers to the Hyper-V code that implements a +particular synthetic device, while "VSC" refers to the driver for +the device in the guest VM. For example, the Linux driver for the +synthetic NIC is referred to as "netvsc" and the Linux driver for +the synthetic SCSI controller is "storvsc". These drivers contain +functions with names like "storvsc_connect_to_vsp". + +VMbus channels +-------------- +An instance of a synthetic device uses VMbus channels to communicate +between the VSP and the VSC. Channels are bi-directional and used +for passing messages. Most synthetic devices use a single channel, +but the synthetic SCSI controller and synthetic NIC may use multiple +channels to achieve higher performance and greater parallelism. + +Each channel consists of two ring buffers. These are classic ring +buffers from a university data structures textbook. If the read +and writes pointers are equal, the ring buffer is considered to be +empty, so a full ring buffer always has at least one byte unused. +The "in" ring buffer is for messages from the Hyper-V host to the +guest, and the "out" ring buffer is for messages from the guest to +the Hyper-V host. In Linux, the "in" and "out" designations are as +viewed by the guest side. The ring buffers are memory that is +shared between the guest and the host, and they follow the standard +paradigm where the memory is allocated by the guest, with the list +of GPAs that make up the ring buffer communicated to the host. Each +ring buffer consists of a header page (4 Kbytes) with the read and +write indices and some control flags, followed by the memory for the +actual ring. The size of the ring is determined by the VSC in the +guest and is specific to each synthetic device. The list of GPAs +making up the ring is communicated to the Hyper-V host over the +VMbus control path as a GPA Descriptor List (GPADL). See function +vmbus_establish_gpadl(). + +Each ring buffer is mapped into contiguous Linux kernel virtual +space in three parts: 1) the 4 Kbyte header page, 2) the memory +that makes up the ring itself, and 3) a second mapping of the memory +that makes up the ring itself. Because (2) and (3) are contiguous +in kernel virtual space, the code that copies data to and from the +ring buffer need not be concerned with ring buffer wrap-around. +Once a copy operation has completed, the read or write index may +need to be reset to point back into the first mapping, but the +actual data copy does not need to be broken into two parts. This +approach also allows complex data structures to be easily accessed +directly in the ring without handling wrap-around. + +On arm64 with page sizes > 4 Kbytes, the header page must still be +passed to Hyper-V as a 4 Kbyte area. But the memory for the actual +ring must be aligned to PAGE_SIZE and have a size that is a multiple +of PAGE_SIZE so that the duplicate mapping trick can be done. Hence +a portion of the header page is unused and not communicated to +Hyper-V. This case is handled by vmbus_establish_gpadl(). + +Hyper-V enforces a limit on the aggregate amount of guest memory +that can be shared with the host via GPADLs. This limit ensures +that a rogue guest can't force the consumption of excessive host +resources. For Windows Server 2019 and later, this limit is +approximately 1280 Mbytes. For versions prior to Windows Server +2019, the limit is approximately 384 Mbytes. + +VMbus messages +-------------- +All VMbus messages have a standard header that includes the message +length, the offset of the message payload, some flags, and a +transactionID. The portion of the message after the header is +unique to each VSP/VSC pair. + +Messages follow one of two patterns: + +* Unidirectional: Either side sends a message and does not + expect a response message +* Request/response: One side (usually the guest) sends a message + and expects a response + +The transactionID (a.k.a. "requestID") is for matching requests & +responses. Some synthetic devices allow multiple requests to be in- +flight simultaneously, so the guest specifies a transactionID when +sending a request. Hyper-V sends back the same transactionID in the +matching response. + +Messages passed between the VSP and VSC are control messages. For +example, a message sent from the storvsc driver might be "execute +this SCSI command". If a message also implies some data transfer +between the guest and the Hyper-V host, the actual data to be +transferred may be embedded with the control message, or it may be +specified as a separate data buffer that the Hyper-V host will +access as a DMA operation. The former case is used when the size of +the data is small and the cost of copying the data to and from the +ring buffer is minimal. For example, time sync messages from the +Hyper-V host to the guest contain the actual time value. When the +data is larger, a separate data buffer is used. In this case, the +control message contains a list of GPAs that describe the data +buffer. For example, the storvsc driver uses this approach to +specify the data buffers to/from which disk I/O is done. + +Three functions exist to send VMbus messages: + +1. vmbus_sendpacket(): Control-only messages and messages with + embedded data -- no GPAs +2. vmbus_sendpacket_pagebuffer(): Message with list of GPAs + identifying data to transfer. An offset and length is + associated with each GPA so that multiple discontinuous areas + of guest memory can be targeted. +3. vmbus_sendpacket_mpb_desc(): Message with list of GPAs + identifying data to transfer. A single offset and length is + associated with a list of GPAs. The GPAs must describe a + single logical area of guest memory to be targeted. + +Historically, Linux guests have trusted Hyper-V to send well-formed +and valid messages, and Linux drivers for synthetic devices did not +fully validate messages. With the introduction of processor +technologies that fully encrypt guest memory and that allow the +guest to not trust the hypervisor (AMD SNP-SEV, Intel TDX), trusting +the Hyper-V host is no longer a valid assumption. The drivers for +VMbus synthetic devices are being updated to fully validate any +values read from memory that is shared with Hyper-V, which includes +messages from VMbus devices. To facilitate such validation, +messages read by the guest from the "in" ring buffer are copied to a +temporary buffer that is not shared with Hyper-V. Validation is +performed in this temporary buffer without the risk of Hyper-V +maliciously modifying the message after it is validated but before +it is used. + +VMbus interrupts +---------------- +VMbus provides a mechanism for the guest to interrupt the host when +the guest has queued new messages in a ring buffer. The host +expects that the guest will send an interrupt only when an "out" +ring buffer transitions from empty to non-empty. If the guest sends +interrupts at other times, the host deems such interrupts to be +unnecessary. If a guest sends an excessive number of unnecessary +interrupts, the host may throttle that guest by suspending its +execution for a few seconds to prevent a denial-of-service attack. + +Similarly, the host will interrupt the guest when it sends a new +message on the VMbus control path, or when a VMbus channel "in" ring +buffer transitions from empty to non-empty. Each CPU in the guest +may receive VMbus interrupts, so they are best modeled as per-CPU +interrupts in Linux. This model works well on arm64 where a single +per-CPU IRQ is allocated for VMbus. Since x86/x64 lacks support for +per-CPU IRQs, an x86 interrupt vector is statically allocated (see +HYPERVISOR_CALLBACK_VECTOR) across all CPUs and explicitly coded to +call the VMbus interrupt service routine. These interrupts are +visible in /proc/interrupts on the "HYP" line. + +The guest CPU that a VMbus channel will interrupt is selected by the +guest when the channel is created, and the host is informed of that +selection. VMbus devices are broadly grouped into two categories: + +1. "Slow" devices that need only one VMbus channel. The devices + (such as keyboard, mouse, heartbeat, and timesync) generate + relatively few interrupts. Their VMbus channels are all + assigned to interrupt the VMBUS_CONNECT_CPU, which is always + CPU 0. + +2. "High speed" devices that may use multiple VMbus channels for + higher parallelism and performance. These devices include the + synthetic SCSI controller and synthetic NIC. Their VMbus + channels interrupts are assigned to CPUs that are spread out + among the available CPUs in the VM so that interrupts on + multiple channels can be processed in parallel. + +The assignment of VMbus channel interrupts to CPUs is done in the +function init_vp_index(). This assignment is done outside of the +normal Linux interrupt affinity mechanism, so the interrupts are +neither "unmanaged" nor "managed" interrupts. + +The CPU that a VMbus channel will interrupt can be seen in +/sys/bus/vmbus/devices/<deviceGUID>/ channels/<channelRelID>/cpu. +When running on later versions of Hyper-V, the CPU can be changed +by writing a new value to this sysfs entry. Because the interrupt +assignment is done outside of the normal Linux affinity mechanism, +there are no entries in /proc/irq corresponding to individual +VMbus channel interrupts. + +An online CPU in a Linux guest may not be taken offline if it has +VMbus channel interrupts assigned to it. Any such channel +interrupts must first be manually reassigned to another CPU as +described above. When no channel interrupts are assigned to the +CPU, it can be taken offline. + +When a guest CPU receives a VMbus interrupt from the host, the +function vmbus_isr() handles the interrupt. It first checks for +channel interrupts by calling vmbus_chan_sched(), which looks at a +bitmap setup by the host to determine which channels have pending +interrupts on this CPU. If multiple channels have pending +interrupts for this CPU, they are processed sequentially. When all +channel interrupts have been processed, vmbus_isr() checks for and +processes any message received on the VMbus control path. + +The VMbus channel interrupt handling code is designed to work +correctly even if an interrupt is received on a CPU other than the +CPU assigned to the channel. Specifically, the code does not use +CPU-based exclusion for correctness. In normal operation, Hyper-V +will interrupt the assigned CPU. But when the CPU assigned to a +channel is being changed via sysfs, the guest doesn't know exactly +when Hyper-V will make the transition. The code must work correctly +even if there is a time lag before Hyper-V starts interrupting the +new CPU. See comments in target_cpu_store(). + +VMbus device creation/deletion +------------------------------ +Hyper-V and the Linux guest have a separate message-passing path +that is used for synthetic device creation and deletion. This +path does not use a VMbus channel. See vmbus_post_msg() and +vmbus_on_msg_dpc(). + +The first step is for the guest to connect to the generic +Hyper-V VMbus mechanism. As part of establishing this connection, +the guest and Hyper-V agree on a VMbus protocol version they will +use. This negotiation allows newer Linux kernels to run on older +Hyper-V versions, and vice versa. + +The guest then tells Hyper-V to "send offers". Hyper-V sends an +offer message to the guest for each synthetic device that the VM +is configured to have. Each VMbus device type has a fixed GUID +known as the "class ID", and each VMbus device instance is also +identified by a GUID. The offer message from Hyper-V contains +both GUIDs to uniquely (within the VM) identify the device. +There is one offer message for each device instance, so a VM with +two synthetic NICs will get two offers messages with the NIC +class ID. The ordering of offer messages can vary from boot-to-boot +and must not be assumed to be consistent in Linux code. Offer +messages may also arrive long after Linux has initially booted +because Hyper-V supports adding devices, such as synthetic NICs, +to running VMs. A new offer message is processed by +vmbus_process_offer(), which indirectly invokes vmbus_add_channel_work(). + +Upon receipt of an offer message, the guest identifies the device +type based on the class ID, and invokes the correct driver to set up +the device. Driver/device matching is performed using the standard +Linux mechanism. + +The device driver probe function opens the primary VMbus channel to +the corresponding VSP. It allocates guest memory for the channel +ring buffers and shares the ring buffer with the Hyper-V host by +giving the host a list of GPAs for the ring buffer memory. See +vmbus_establish_gpadl(). + +Once the ring buffer is set up, the device driver and VSP exchange +setup messages via the primary channel. These messages may include +negotiating the device protocol version to be used between the Linux +VSC and the VSP on the Hyper-V host. The setup messages may also +include creating additional VMbus channels, which are somewhat +mis-named as "sub-channels" since they are functionally +equivalent to the primary channel once they are created. + +Finally, the device driver may create entries in /dev as with +any device driver. + +The Hyper-V host can send a "rescind" message to the guest to +remove a device that was previously offered. Linux drivers must +handle such a rescind message at any time. Rescinding a device +invokes the device driver "remove" function to cleanly shut +down the device and remove it. Once a synthetic device is +rescinded, neither Hyper-V nor Linux retains any state about +its previous existence. Such a device might be re-added later, +in which case it is treated as an entirely new device. See +vmbus_onoffer_rescind(). diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst index 492f0920b988..2f1cffa87b1b 100644 --- a/Documentation/virt/index.rst +++ b/Documentation/virt/index.rst @@ -14,6 +14,7 @@ Linux Virtualization Support ne_overview acrn/index coco/sev-guest + hyperv/index .. only:: html and subproject diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 11e00a46c610..abd7c32126ce 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -1150,6 +1150,10 @@ The following bits are defined in the flags field: fields contain a valid state. This bit will be set whenever KVM_CAP_EXCEPTION_PAYLOAD is enabled. +- KVM_VCPUEVENT_VALID_TRIPLE_FAULT may be set to signal that the + triple_fault_pending field contains a valid state. This bit will + be set whenever KVM_CAP_X86_TRIPLE_FAULT_EVENT is enabled. + ARM64: ^^^^^^ @@ -1245,6 +1249,10 @@ can be set in the flags field to signal that the exception_has_payload, exception_payload, and exception.pending fields contain a valid state and shall be written into the VCPU. +If KVM_CAP_X86_TRIPLE_FAULT_EVENT is enabled, KVM_VCPUEVENT_VALID_TRIPLE_FAULT +can be set in flags field to signal that the triple_fault field contains +a valid state and shall be written into the VCPU. + ARM64: ^^^^^^ @@ -2998,7 +3006,9 @@ KVM_CREATE_PIT2. The state is returned in the following structure:: Valid flags are:: /* disable PIT in HPET legacy mode */ - #define KVM_PIT_FLAGS_HPET_LEGACY 0x00000001 + #define KVM_PIT_FLAGS_HPET_LEGACY 0x00000001 + /* speaker port data bit enabled */ + #define KVM_PIT_FLAGS_SPEAKER_DATA_ON 0x00000002 This IOCTL replaces the obsolete KVM_GET_PIT. @@ -4667,7 +4677,7 @@ encrypted VMs. Currently, this ioctl is used for issuing Secure Encrypted Virtualization (SEV) commands on AMD Processors. The SEV commands are defined in -Documentation/virt/kvm/amd-memory-encryption.rst. +Documentation/virt/kvm/x86/amd-memory-encryption.rst. 4.111 KVM_MEMORY_ENCRYPT_REG_REGION ----------------------------------- @@ -5127,7 +5137,15 @@ into ESA mode. This reset is a superset of the initial reset. __u32 reserved[3]; }; -cmd values: +**Ultravisor return codes** +The Ultravisor return (reason) codes are provided by the kernel if a +Ultravisor call has been executed to achieve the results expected by +the command. Therefore they are independent of the IOCTL return +code. If KVM changes `rc`, its value will always be greater than 0 +hence setting it to 0 before issuing a PV command is advised to be +able to detect a change of `rc`. + +**cmd values:** KVM_PV_ENABLE Allocate memory and register the VM with the Ultravisor, thereby @@ -5143,7 +5161,6 @@ KVM_PV_ENABLE ===== ============================= KVM_PV_DISABLE - Deregister the VM from the Ultravisor and reclaim the memory that had been donated to the Ultravisor, making it usable by the kernel again. All registered VCPUs are converted back to non-protected @@ -5160,6 +5177,117 @@ KVM_PV_VM_VERIFY Verify the integrity of the unpacked image. Only if this succeeds, KVM is allowed to start protected VCPUs. +KVM_PV_INFO + :Capability: KVM_CAP_S390_PROTECTED_DUMP + + Presents an API that provides Ultravisor related data to userspace + via subcommands. len_max is the size of the user space buffer, + len_written is KVM's indication of how much bytes of that buffer + were actually written to. len_written can be used to determine the + valid fields if more response fields are added in the future. + + :: + + enum pv_cmd_info_id { + KVM_PV_INFO_VM, + KVM_PV_INFO_DUMP, + }; + + struct kvm_s390_pv_info_header { + __u32 id; + __u32 len_max; + __u32 len_written; + __u32 reserved; + }; + + struct kvm_s390_pv_info { + struct kvm_s390_pv_info_header header; + struct kvm_s390_pv_info_dump dump; + struct kvm_s390_pv_info_vm vm; + }; + +**subcommands:** + + KVM_PV_INFO_VM + This subcommand provides basic Ultravisor information for PV + hosts. These values are likely also exported as files in the sysfs + firmware UV query interface but they are more easily available to + programs in this API. + + The installed calls and feature_indication members provide the + installed UV calls and the UV's other feature indications. + + The max_* members provide information about the maximum number of PV + vcpus, PV guests and PV guest memory size. + + :: + + struct kvm_s390_pv_info_vm { + __u64 inst_calls_list[4]; + __u64 max_cpus; + __u64 max_guests; + __u64 max_guest_addr; + __u64 feature_indication; + }; + + + KVM_PV_INFO_DUMP + This subcommand provides information related to dumping PV guests. + + :: + + struct kvm_s390_pv_info_dump { + __u64 dump_cpu_buffer_len; + __u64 dump_config_mem_buffer_per_1m; + __u64 dump_config_finalize_len; + }; + +KVM_PV_DUMP + :Capability: KVM_CAP_S390_PROTECTED_DUMP + + Presents an API that provides calls which facilitate dumping a + protected VM. + + :: + + struct kvm_s390_pv_dmp { + __u64 subcmd; + __u64 buff_addr; + __u64 buff_len; + __u64 gaddr; /* For dump storage state */ + }; + + **subcommands:** + + KVM_PV_DUMP_INIT + Initializes the dump process of a protected VM. If this call does + not succeed all other subcommands will fail with -EINVAL. This + subcommand will return -EINVAL if a dump process has not yet been + completed. + + Not all PV vms can be dumped, the owner needs to set `dump + allowed` PCF bit 34 in the SE header to allow dumping. + + KVM_PV_DUMP_CONFIG_STOR_STATE + Stores `buff_len` bytes of tweak component values starting with + the 1MB block specified by the absolute guest address + (`gaddr`). `buff_len` needs to be `conf_dump_storage_state_len` + aligned and at least >= the `conf_dump_storage_state_len` value + provided by the dump uv_info data. buff_user might be written to + even if an error rc is returned. For instance if we encounter a + fault after writing the first page of data. + + KVM_PV_DUMP_COMPLETE + If the subcommand succeeds it completes the dump process and lets + KVM_PV_DUMP_INIT be called again. + + On success `conf_dump_finalize_len` bytes of completion data will be + stored to the `buff_addr`. The completion data contains a key + derivation seed, IV, tweak nonce and encryption keys as well as an + authentication tag all of which are needed to decrypt the dump at a + later time. + + 4.126 KVM_X86_SET_MSR_FILTER ---------------------------- @@ -5657,7 +5785,8 @@ by a string of size ``name_size``. #define KVM_STATS_UNIT_BYTES (0x1 << KVM_STATS_UNIT_SHIFT) #define KVM_STATS_UNIT_SECONDS (0x2 << KVM_STATS_UNIT_SHIFT) #define KVM_STATS_UNIT_CYCLES (0x3 << KVM_STATS_UNIT_SHIFT) - #define KVM_STATS_UNIT_MAX KVM_STATS_UNIT_CYCLES + #define KVM_STATS_UNIT_BOOLEAN (0x4 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_MAX KVM_STATS_UNIT_BOOLEAN #define KVM_STATS_BASE_SHIFT 8 #define KVM_STATS_BASE_MASK (0xF << KVM_STATS_BASE_SHIFT) @@ -5702,14 +5831,13 @@ Bits 0-3 of ``flags`` encode the type: by the ``hist_param`` field. The range of the Nth bucket (1 <= N < ``size``) is [``hist_param``*(N-1), ``hist_param``*N), while the range of the last bucket is [``hist_param``*(``size``-1), +INF). (+INF means positive infinity - value.) The bucket value indicates how many samples fell in the bucket's range. + value.) * ``KVM_STATS_TYPE_LOG_HIST`` The statistic is reported as a logarithmic histogram. The number of buckets is specified by the ``size`` field. The range of the first bucket is [0, 1), while the range of the last bucket is [pow(2, ``size``-2), +INF). Otherwise, The Nth bucket (1 < N < ``size``) covers - [pow(2, N-2), pow(2, N-1)). The bucket value indicates how many samples fell - in the bucket's range. + [pow(2, N-2), pow(2, N-1)). Bits 4-7 of ``flags`` encode the unit: @@ -5724,6 +5852,15 @@ Bits 4-7 of ``flags`` encode the unit: It indicates that the statistics data is used to measure time or latency. * ``KVM_STATS_UNIT_CYCLES`` It indicates that the statistics data is used to measure CPU clock cycles. + * ``KVM_STATS_UNIT_BOOLEAN`` + It indicates that the statistic will always be either 0 or 1. Boolean + statistics of "peak" type will never go back from 1 to 0. Boolean + statistics can be linear histograms (with two buckets) but not logarithmic + histograms. + +Note that, in the case of histograms, the unit applies to the bucket +ranges, while the bucket value indicates how many samples fell in the +bucket's range. Bits 8-11 of ``flags``, together with ``exponent``, encode the scale of the unit: @@ -5746,7 +5883,7 @@ the corresponding statistics data. The ``bucket_size`` field is used as a parameter for histogram statistics data. It is only used by linear histogram statistics data, specifying the size of a -bucket. +bucket in the unit expressed by bits 4-11 of ``flags`` together with ``exponent``. The ``name`` field is the name string of the statistics data. The name string starts at the end of ``struct kvm_stats_desc``. The maximum length including @@ -5802,6 +5939,78 @@ of CPUID leaf 0xD on the host. This ioctl injects an event channel interrupt directly to the guest vCPU. +4.136 KVM_S390_PV_CPU_COMMAND +----------------------------- + +:Capability: KVM_CAP_S390_PROTECTED_DUMP +:Architectures: s390 +:Type: vcpu ioctl +:Parameters: none +:Returns: 0 on success, < 0 on error + +This ioctl closely mirrors `KVM_S390_PV_COMMAND` but handles requests +for vcpus. It re-uses the kvm_s390_pv_dmp struct and hence also shares +the command ids. + +**command:** + +KVM_PV_DUMP + Presents an API that provides calls which facilitate dumping a vcpu + of a protected VM. + +**subcommand:** + +KVM_PV_DUMP_CPU + Provides encrypted dump data like register values. + The length of the returned data is provided by uv_info.guest_cpu_stor_len. + +4.137 KVM_S390_ZPCI_OP +---------------------- + +:Capability: KVM_CAP_S390_ZPCI_OP +:Architectures: s390 +:Type: vm ioctl +:Parameters: struct kvm_s390_zpci_op (in) +:Returns: 0 on success, <0 on error + +Used to manage hardware-assisted virtualization features for zPCI devices. + +Parameters are specified via the following structure:: + + struct kvm_s390_zpci_op { + /* in */ + __u32 fh; /* target device */ + __u8 op; /* operation to perform */ + __u8 pad[3]; + union { + /* for KVM_S390_ZPCIOP_REG_AEN */ + struct { + __u64 ibv; /* Guest addr of interrupt bit vector */ + __u64 sb; /* Guest addr of summary bit */ + __u32 flags; + __u32 noi; /* Number of interrupts */ + __u8 isc; /* Guest interrupt subclass */ + __u8 sbo; /* Offset of guest summary bit vector */ + __u16 pad; + } reg_aen; + __u64 reserved[8]; + } u; + }; + +The type of operation is specified in the "op" field. +KVM_S390_ZPCIOP_REG_AEN is used to register the VM for adapter event +notification interpretation, which will allow firmware delivery of adapter +events directly to the vm, with KVM providing a backup delivery mechanism; +KVM_S390_ZPCIOP_DEREG_AEN is used to subsequently disable interpretation of +adapter event notifications. + +The target zPCI function must also be specified via the "fh" field. For the +KVM_S390_ZPCIOP_REG_AEN operation, additional information to establish firmware +delivery must be provided via the "reg_aen" struct. + +The "pad" and "reserved" fields may be used for future extensions and should be +set to 0s by userspace. + 5. The kvm_run structure ======================== @@ -6407,6 +6616,26 @@ spec refer, https://github.com/riscv/riscv-sbi-doc. :: + /* KVM_EXIT_NOTIFY */ + struct { + #define KVM_NOTIFY_CONTEXT_INVALID (1 << 0) + __u32 flags; + } notify; + +Used on x86 systems. When the VM capability KVM_CAP_X86_NOTIFY_VMEXIT is +enabled, a VM exit generated if no event window occurs in VM non-root mode +for a specified amount of time. Once KVM_X86_NOTIFY_VMEXIT_USER is set when +enabling the cap, it would exit to userspace with the exit reason +KVM_EXIT_NOTIFY for further handling. The "flags" field contains more +detailed info. + +The valid value for 'flags' is: + + - KVM_NOTIFY_CONTEXT_INVALID -- the VM context is corrupted and not valid + in VMCS. It would run into unknown result if resume the target VM. + +:: + /* Fix the size of the union. */ char padding[256]; }; @@ -7348,8 +7577,71 @@ The valid bits in cap.args[0] are: hypercall instructions. Executing the incorrect hypercall instruction will generate a #UD within the guest. + +KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS By default, KVM emulates MONITOR/MWAIT (if + they are intercepted) as NOPs regardless of + whether or not MONITOR/MWAIT are supported + according to guest CPUID. When this quirk + is disabled and KVM_X86_DISABLE_EXITS_MWAIT + is not set (MONITOR/MWAIT are intercepted), + KVM will inject a #UD on MONITOR/MWAIT if + they're unsupported per guest CPUID. Note, + KVM will modify MONITOR/MWAIT support in + guest CPUID on writes to MISC_ENABLE if + KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is + disabled. =================================== ============================================ +7.32 KVM_CAP_MAX_VCPU_ID +------------------------ + +:Architectures: x86 +:Target: VM +:Parameters: args[0] - maximum APIC ID value set for current VM +:Returns: 0 on success, -EINVAL if args[0] is beyond KVM_MAX_VCPU_IDS + supported in KVM or if it has been set. + +This capability allows userspace to specify maximum possible APIC ID +assigned for current VM session prior to the creation of vCPUs, saving +memory for data structures indexed by the APIC ID. Userspace is able +to calculate the limit to APIC ID values from designated +CPU topology. + +The value can be changed only until KVM_ENABLE_CAP is set to a nonzero +value or until a vCPU is created. Upon creation of the first vCPU, +if the value was set to zero or KVM_ENABLE_CAP was not invoked, KVM +uses the return value of KVM_CHECK_EXTENSION(KVM_CAP_MAX_VCPU_ID) as +the maximum APIC ID. + +7.33 KVM_CAP_X86_NOTIFY_VMEXIT +------------------------------ + +:Architectures: x86 +:Target: VM +:Parameters: args[0] is the value of notify window as well as some flags +:Returns: 0 on success, -EINVAL if args[0] contains invalid flags or notify + VM exit is unsupported. + +Bits 63:32 of args[0] are used for notify window. +Bits 31:0 of args[0] are for some flags. Valid bits are:: + + #define KVM_X86_NOTIFY_VMEXIT_ENABLED (1 << 0) + #define KVM_X86_NOTIFY_VMEXIT_USER (1 << 1) + +This capability allows userspace to configure the notify VM exit on/off +in per-VM scope during VM creation. Notify VM exit is disabled by default. +When userspace sets KVM_X86_NOTIFY_VMEXIT_ENABLED bit in args[0], VMM will +enable this feature with the notify window provided, which will generate +a VM exit if no event window occurs in VM non-root mode for a specified of +time (notify window). + +If KVM_X86_NOTIFY_VMEXIT_USER is set in args[0], upon notify VM exits happen, +KVM would exit to userspace for handling. + +This capability is aimed to mitigate the threat that malicious VMs can +cause CPU stuck (due to event windows don't open up) and make the CPU +unavailable to host or other VMs. + 8. Other capabilities. ====================== @@ -7670,7 +7962,7 @@ architecture-specific interfaces. This capability and the architecture- specific interfaces must be consistent, i.e. if one says the feature is supported, than the other should as well and vice versa. For arm64 see Documentation/virt/kvm/devices/vcpu.rst "KVM_ARM_VCPU_PVTIME_CTRL". -For x86 see Documentation/virt/kvm/msr.rst "MSR_KVM_STEAL_TIME". +For x86 see Documentation/virt/kvm/x86/msr.rst "MSR_KVM_STEAL_TIME". 8.25 KVM_CAP_S390_DIAG318 ------------------------- @@ -7956,6 +8248,61 @@ should adjust CPUID leaf 0xA to reflect that the PMU is disabled. When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. +8.37 KVM_CAP_S390_PROTECTED_DUMP +-------------------------------- + +:Capability: KVM_CAP_S390_PROTECTED_DUMP +:Architectures: s390 +:Type: vm + +This capability indicates that KVM and the Ultravisor support dumping +PV guests. The `KVM_PV_DUMP` command is available for the +`KVM_S390_PV_COMMAND` ioctl and the `KVM_PV_INFO` command provides +dump related UV data. Also the vcpu ioctl `KVM_S390_PV_CPU_COMMAND` is +available and supports the `KVM_PV_DUMP_CPU` subcommand. + +8.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES +------------------------------------- + +:Capability: KVM_CAP_VM_DISABLE_NX_HUGE_PAGES +:Architectures: x86 +:Type: vm +:Parameters: arg[0] must be 0. +:Returns: 0 on success, -EPERM if the userspace process does not + have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been + created. + +This capability disables the NX huge pages mitigation for iTLB MULTIHIT. + +The capability has no effect if the nx_huge_pages module parameter is not set. + +This capability may only be set before any vCPUs are created. + +8.39 KVM_CAP_S390_CPU_TOPOLOGY +------------------------------ + +:Capability: KVM_CAP_S390_CPU_TOPOLOGY +:Architectures: s390 +:Type: vm + +This capability indicates that KVM will provide the S390 CPU Topology +facility which consist of the interpretation of the PTF instruction for +the function code 2 along with interception and forwarding of both the +PTF instruction with function codes 0 or 1 and the STSI(15,1,x) +instruction to the userland hypervisor. + +The stfle facility 11, CPU Topology facility, should not be indicated +to the guest without this capability. + +When this capability is present, KVM provides a new attribute group +on vm fd, KVM_S390_VM_CPU_TOPOLOGY. +This new attribute allows to get, set or clear the Modified Change +Topology Report (MTCR) bit of the SCA through the kvm_device_attr +structure. + +When getting the Modified Change Topology Report value, the attr->addr +must point to a byte where the value will be stored or retrieved from. + 9. Known KVM API problems ========================= diff --git a/Documentation/virt/kvm/arm/hyp-abi.rst b/Documentation/virt/kvm/arm/hyp-abi.rst index 4d43fbc25195..412b276449d3 100644 --- a/Documentation/virt/kvm/arm/hyp-abi.rst +++ b/Documentation/virt/kvm/arm/hyp-abi.rst @@ -60,12 +60,13 @@ these functions (see arch/arm{,64}/include/asm/virt.h): * :: - x0 = HVC_VHE_RESTART (arm64 only) + x0 = HVC_FINALISE_EL2 (arm64 only) - Attempt to upgrade the kernel's exception level from EL1 to EL2 by enabling - the VHE mode. This is conditioned by the CPU supporting VHE, the EL2 MMU - being off, and VHE not being disabled by any other means (command line - option, for example). + Finish configuring EL2 depending on the command-line options, + including an attempt to upgrade the kernel's exception level from + EL1 to EL2 by enabling the VHE mode. This is conditioned by the CPU + supporting VHE, the EL2 MMU being off, and VHE not being disabled by + any other means (command line option, for example). Any other value of r0/x0 triggers a hypervisor-specific handling, which is not documented here. diff --git a/Documentation/virt/kvm/s390/index.rst b/Documentation/virt/kvm/s390/index.rst index 605f488f0cc5..44ec9ab14b59 100644 --- a/Documentation/virt/kvm/s390/index.rst +++ b/Documentation/virt/kvm/s390/index.rst @@ -10,3 +10,4 @@ KVM for s390 systems s390-diag s390-pv s390-pv-boot + s390-pv-dump diff --git a/Documentation/virt/kvm/s390/s390-pv-boot.rst b/Documentation/virt/kvm/s390/s390-pv-boot.rst index 73a6083cb5e7..96c48480a360 100644 --- a/Documentation/virt/kvm/s390/s390-pv-boot.rst +++ b/Documentation/virt/kvm/s390/s390-pv-boot.rst @@ -10,7 +10,7 @@ The memory of Protected Virtual Machines (PVMs) is not accessible to I/O or the hypervisor. In those cases where the hypervisor needs to access the memory of a PVM, that memory must be made accessible. Memory made accessible to the hypervisor will be encrypted. See -Documentation/virt/kvm/s390-pv.rst for details." +Documentation/virt/kvm/s390/s390-pv.rst for details." On IPL (boot) a small plaintext bootloader is started, which provides information about the encrypted components and necessary metadata to diff --git a/Documentation/virt/kvm/s390/s390-pv-dump.rst b/Documentation/virt/kvm/s390/s390-pv-dump.rst new file mode 100644 index 000000000000..e542f06048f3 --- /dev/null +++ b/Documentation/virt/kvm/s390/s390-pv-dump.rst @@ -0,0 +1,64 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================== +s390 (IBM Z) Protected Virtualization dumps +=========================================== + +Summary +------- + +Dumping a VM is an essential tool for debugging problems inside +it. This is especially true when a protected VM runs into trouble as +there's no way to access its memory and registers from the outside +while it's running. + +However when dumping a protected VM we need to maintain its +confidentiality until the dump is in the hands of the VM owner who +should be the only one capable of analysing it. + +The confidentiality of the VM dump is ensured by the Ultravisor who +provides an interface to KVM over which encrypted CPU and memory data +can be requested. The encryption is based on the Customer +Communication Key which is the key that's used to encrypt VM data in a +way that the customer is able to decrypt. + + +Dump process +------------ + +A dump is done in 3 steps: + +**Initiation** + +This step initializes the dump process, generates cryptographic seeds +and extracts dump keys with which the VM dump data will be encrypted. + +**Data gathering** + +Currently there are two types of data that can be gathered from a VM: +the memory and the vcpu state. + +The vcpu state contains all the important registers, general, floating +point, vector, control and tod/timers of a vcpu. The vcpu dump can +contain incomplete data if a vcpu is dumped while an instruction is +emulated with help of the hypervisor. This is indicated by a flag bit +in the dump data. For the same reason it is very important to not only +write out the encrypted vcpu state, but also the unencrypted state +from the hypervisor. + +The memory state is further divided into the encrypted memory and its +metadata comprised of the encryption tweaks and status flags. The +encrypted memory can simply be read once it has been exported. The +time of the export does not matter as no re-encryption is +needed. Memory that has been swapped out and hence was exported can be +read from the swap and written to the dump target without need for any +special actions. + +The tweaks / status flags for the exported pages need to be requested +from the Ultravisor. + +**Finalization** + +The finalization step will provide the data needed to be able to +decrypt the vcpu and memory data and end the dump process. When this +step completes successfully a new dump initiation can be started. diff --git a/Documentation/virt/kvm/x86/hypercalls.rst b/Documentation/virt/kvm/x86/hypercalls.rst index e56fa8b9cfca..10db7924720f 100644 --- a/Documentation/virt/kvm/x86/hypercalls.rst +++ b/Documentation/virt/kvm/x86/hypercalls.rst @@ -22,7 +22,7 @@ S390: number in R1. For further information on the S390 diagnose call as supported by KVM, - refer to Documentation/virt/kvm/s390-diag.rst. + refer to Documentation/virt/kvm/s390/s390-diag.rst. PowerPC: It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers. diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 863f67b72c05..af2a97429692 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -322,7 +322,7 @@ Shared Options * ``v6=[0,1]`` to specify if a v6 connection is desired for all transports which operate over IP. Additionally, for transports that have some differences in the way they operate over v4 and v6 (for example - EoL2TPv3), sets the correct mode of operation. In the absense of this + EoL2TPv3), sets the correct mode of operation. In the absence of this option, the socket type is determined based on what do the src and dst arguments resolve/parse to. diff --git a/Documentation/vm/.gitignore b/Documentation/vm/.gitignore deleted file mode 100644 index bc74f5643008..000000000000 --- a/Documentation/vm/.gitignore +++ /dev/null @@ -1,3 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0-only -page-types -slabinfo diff --git a/Documentation/watchdog/watchdog-parameters.rst b/Documentation/watchdog/watchdog-parameters.rst index 223c99361a30..29153eed6689 100644 --- a/Documentation/watchdog/watchdog-parameters.rst +++ b/Documentation/watchdog/watchdog-parameters.rst @@ -425,6 +425,18 @@ pnx833x_wdt: ------------------------------------------------- +pseries-wdt: + action: + Action taken when watchdog expires: 0 (power off), 1 (restart), + 2 (dump and restart). (default=1) + timeout: + Initial watchdog timeout in seconds. (default=60) + nowayout: + Watchdog cannot be stopped once started. + (default=kernel config parameter) + +------------------------------------------------- + rc32434_wdt: timeout: Watchdog timeout value, in seconds (default=20) diff --git a/Documentation/x86/orc-unwinder.rst b/Documentation/x86/orc-unwinder.rst index 9a66a88be765..cdb257015bd9 100644 --- a/Documentation/x86/orc-unwinder.rst +++ b/Documentation/x86/orc-unwinder.rst @@ -140,7 +140,7 @@ Unwinder implementation details Objtool generates the ORC data by integrating with the compile-time stack metadata validation feature, which is described in detail in -tools/objtool/Documentation/stack-validation.txt. After analyzing all +tools/objtool/Documentation/objtool.txt. After analyzing all the code paths of a .o file, it creates an array of orc_entry structs, and a parallel array of instruction addresses associated with those structs, and writes them to the .orc_unwind and .orc_unwind_ip sections diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst index 265568a9292c..2bcbffacbed5 100644 --- a/Documentation/x86/sgx.rst +++ b/Documentation/x86/sgx.rst @@ -100,6 +100,21 @@ pages and establish enclave page permissions. sgx_ioc_enclave_init sgx_ioc_enclave_provision +Enclave runtime management +-------------------------- + +Systems supporting SGX2 additionally support changes to initialized +enclaves: modifying enclave page permissions and type, and dynamically +adding and removing of enclave pages. When an enclave accesses an address +within its address range that does not have a backing page then a new +regular page will be dynamically added to the enclave. The enclave is +still required to run EACCEPT on the new page before it can be used. + +.. kernel-doc:: arch/x86/kernel/cpu/sgx/ioctl.c + :functions: sgx_ioc_enclave_restrict_permissions + sgx_ioc_enclave_modify_types + sgx_ioc_enclave_remove_pages + Enclave vDSO ------------ diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 03ec9cf01181..cbd14124a667 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -287,11 +287,13 @@ iommu options only relevant to the AMD GART hardware IOMMU: iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU implementation: - swiotlb=<pages>[,force] - <pages> - Prereserve that many 128K pages for the software IO bounce buffering. + swiotlb=<slots>[,force,noforce] + <slots> + Prereserve that many 2K slots for the software IO bounce buffering. force Force all IO through the software TLB. + noforce + Do not initialize the software TLB. Miscellaneous diff --git a/Documentation/x86/x86_64/uefi.rst b/Documentation/x86/x86_64/uefi.rst index 3b894103a734..fbc30c9a071d 100644 --- a/Documentation/x86/x86_64/uefi.rst +++ b/Documentation/x86/x86_64/uefi.rst @@ -29,7 +29,7 @@ Mechanics be selected:: CONFIG_EFI=y - CONFIG_EFI_VARS=y or m # optional + CONFIG_EFIVAR_FS=y or m # optional - Create a VFAT partition on the disk - Copy the following to the VFAT partition: |