diff options
Diffstat (limited to 'Documentation')
154 files changed, 7971 insertions, 2219 deletions
diff --git a/Documentation/ABI/testing/debugfs-pcie-ptm b/Documentation/ABI/testing/debugfs-pcie-ptm new file mode 100644 index 000000000000..602d41363571 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-pcie-ptm @@ -0,0 +1,70 @@ +What: /sys/kernel/debug/pcie_ptm_*/local_clock +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RO) PTM local clock in nanoseconds. Applicable for both Root + Complex and Endpoint controllers. + +What: /sys/kernel/debug/pcie_ptm_*/master_clock +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RO) PTM master clock in nanoseconds. Applicable only for + Endpoint controllers. + +What: /sys/kernel/debug/pcie_ptm_*/t1 +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RO) PTM T1 timestamp in nanoseconds. Applicable only for + Endpoint controllers. + +What: /sys/kernel/debug/pcie_ptm_*/t2 +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RO) PTM T2 timestamp in nanoseconds. Applicable only for + Root Complex controllers. + +What: /sys/kernel/debug/pcie_ptm_*/t3 +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RO) PTM T3 timestamp in nanoseconds. Applicable only for + Root Complex controllers. + +What: /sys/kernel/debug/pcie_ptm_*/t4 +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RO) PTM T4 timestamp in nanoseconds. Applicable only for + Endpoint controllers. + +What: /sys/kernel/debug/pcie_ptm_*/context_update +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RW) Control the PTM context update mode. Applicable only for + Endpoint controllers. + + Following values are supported: + + * auto = PTM context auto update trigger for every 10ms + + * manual = PTM context manual update. Writing 'manual' to this + file triggers PTM context update (default) + +What: /sys/kernel/debug/pcie_ptm_*/context_valid +Date: May 2025 +Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> +Description: + (RW) Control the PTM context validity (local clock timing). + Applicable only for Root Complex controllers. PTM context is + invalidated by hardware if the Root Complex enters low power + mode or changes link frequency. + + Following values are supported: + + * 0 = PTM context invalid (default) + + * 1 = PTM context valid diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 99bb3faf7a0e..6b4e8c7a963d 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -242,7 +242,7 @@ Description: decoding a Host Physical Address range. Note that this number may be elevated without any regionX objects active or even enumerated, as this may be due to decoders established by - platform firwmare or a previous kernel (kexec). + platform firmware or a previous kernel (kexec). What: /sys/bus/cxl/devices/decoderX.Y @@ -572,7 +572,7 @@ Description: What: /sys/bus/cxl/devices/regionZ/accessY/read_bandwidth - /sys/bus/cxl/devices/regionZ/accessY/write_banwidth + /sys/bus/cxl/devices/regionZ/accessY/write_bandwidth Date: Jan, 2024 KernelVersion: v6.9 Contact: linux-cxl@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer index d1f67bb81d5d..5ed284523956 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer @@ -117,3 +117,47 @@ Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_NONFATAL messages reported to rootport. + +PCIe AER ratelimits +------------------- + +These attributes show up under all the devices that are AER capable. +They represent configurable ratelimits of logs per error type. + +See Documentation/PCI/pcieaer-howto.rst for more info on ratelimits. + +What: /sys/bus/pci/devices/<dev>/aer/correctable_ratelimit_interval_ms +Date: May 2025 +KernelVersion: 6.16.0 +Contact: linux-pci@vger.kernel.org +Description: Writing 0 disables AER correctable error log ratelimiting. + Writing a positive value sets the ratelimit interval in ms. + Default is DEFAULT_RATELIMIT_INTERVAL (5000 ms). + +What: /sys/bus/pci/devices/<dev>/aer/correctable_ratelimit_burst +Date: May 2025 +KernelVersion: 6.16.0 +Contact: linux-pci@vger.kernel.org +Description: Ratelimit burst for correctable error logs. Writing a value + changes the number of errors (burst) allowed per interval + before ratelimiting. Reading gets the current ratelimit + burst. Default is DEFAULT_RATELIMIT_BURST (10). + +What: /sys/bus/pci/devices/<dev>/aer/nonfatal_ratelimit_interval_ms +Date: May 2025 +KernelVersion: 6.16.0 +Contact: linux-pci@vger.kernel.org +Description: Writing 0 disables AER non-fatal uncorrectable error log + ratelimiting. Writing a positive value sets the ratelimit + interval in ms. Default is DEFAULT_RATELIMIT_INTERVAL + (5000 ms). + +What: /sys/bus/pci/devices/<dev>/aer/nonfatal_ratelimit_burst +Date: May 2025 +KernelVersion: 6.16.0 +Contact: linux-pci@vger.kernel.org +Description: Ratelimit burst for non-fatal uncorrectable error logs. + Writing a value changes the number of errors (burst) + allowed per interval before ratelimiting. Reading gets the + current ratelimit burst. Default is DEFAULT_RATELIMIT_BURST + (10). diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 2e24ac3bd7ef..0313b82644f2 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -72,6 +72,12 @@ Description: /sys/class/leds/<led> once a given trigger is selected. For their documentation see `sysfs-class-led-trigger-*`. + Writing "none" removes the trigger for this LED. + + Writing "default" sets the trigger to the LED's default trigger + (which would often be configured in the device tree for the + hardware). + What: /sys/class/leds/<led>/inverted Date: January 2011 KernelVersion: 2.6.38 diff --git a/Documentation/PCI/controller/index.rst b/Documentation/PCI/controller/index.rst new file mode 100644 index 000000000000..c2ce9ccdcfa0 --- /dev/null +++ b/Documentation/PCI/controller/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================== +PCI Native Host Bridge and Endpoint Drivers +=========================================== + +.. toctree:: + :maxdepth: 2 + + rcar-pcie-firmware diff --git a/Documentation/PCI/controller/rcar-pcie-firmware.rst b/Documentation/PCI/controller/rcar-pcie-firmware.rst new file mode 100644 index 000000000000..67d3bf66e315 --- /dev/null +++ b/Documentation/PCI/controller/rcar-pcie-firmware.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================= +Firmware of PCIe controller for Renesas R-Car V4H +================================================= + +Renesas R-Car V4H (r8a779g0) has a PCIe controller, requiring a specific +firmware download during startup. + +However, Renesas currently cannot distribute the firmware free of charge. + +The firmware file "104_PCIe_fw_addr_data_ver1.05.txt" (note that the file name +might be different between different datasheet revisions) can be found in the +datasheet encoded as text, and as such, the file's content must be converted +back to binary form. This can be achieved using the following example script: + +.. code-block:: sh + + $ awk '/^\s*0x[0-9A-Fa-f]{4}\s+0x[0-9A-Fa-f]{4}/ { print substr($2,5,2) substr($2,3,2) }' \ + 104_PCIe_fw_addr_data_ver1.05.txt | \ + xxd -p -r > rcar_gen4_pcie.bin + +Once the text content has been converted into a binary firmware file, verify +its checksum as follows: + +.. code-block:: sh + + $ sha1sum rcar_gen4_pcie.bin + 1d0bd4b189b4eb009f5d564b1f93a79112994945 rcar_gen4_pcie.bin + +The resulting binary file called "rcar_gen4_pcie.bin" should be placed in the +"/lib/firmware" directory before the driver runs. diff --git a/Documentation/PCI/endpoint/pci-nvme-function.rst b/Documentation/PCI/endpoint/pci-nvme-function.rst index df57b8e7d066..a68015317f7f 100644 --- a/Documentation/PCI/endpoint/pci-nvme-function.rst +++ b/Documentation/PCI/endpoint/pci-nvme-function.rst @@ -8,6 +8,6 @@ PCI NVMe Function The PCI NVMe endpoint function implements a PCI NVMe controller using the NVMe subsystem target core code. The driver for this function resides with the NVMe -subsystem as drivers/nvme/target/nvmet-pciep.c. +subsystem as drivers/nvme/target/pci-epf.c. See Documentation/nvme/nvme-pci-endpoint-target.rst for more details. diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst index 5e7c4e6e726b..5d720d2a415e 100644 --- a/Documentation/PCI/index.rst +++ b/Documentation/PCI/index.rst @@ -17,5 +17,6 @@ PCI Bus Subsystem pci-error-recovery pcieaer-howto endpoint/index + controller/index boot-interrupts tph diff --git a/Documentation/PCI/pcieaer-howto.rst b/Documentation/PCI/pcieaer-howto.rst index f013f3b27c82..4b71e2f43ca7 100644 --- a/Documentation/PCI/pcieaer-howto.rst +++ b/Documentation/PCI/pcieaer-howto.rst @@ -85,12 +85,27 @@ In the example, 'Requester ID' means the ID of the device that sent the error message to the Root Port. Please refer to PCIe specs for other fields. +AER Ratelimits +-------------- + +Since error messages can be generated for each transaction, we may see +large volumes of errors reported. To prevent spammy devices from flooding +the console/stalling execution, messages are throttled by device and error +type (correctable vs. non-fatal uncorrectable). Fatal errors, including +DPC errors, are not ratelimited. + +AER uses the default ratelimit of DEFAULT_RATELIMIT_BURST (10 events) over +DEFAULT_RATELIMIT_INTERVAL (5 seconds). + +Ratelimits are exposed in the form of sysfs attributes and configurable. +See Documentation/ABI/testing/sysfs-bus-pci-devices-aer. + AER Statistics / Counters ------------------------- When PCIe AER errors are captured, the counters / statistics are also exposed in the form of sysfs attributes which are documented at -Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats +Documentation/ABI/testing/sysfs-bus-pci-devices-aer. Developer Guide =============== diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index bd98ea3175ec..0cc35a14afbe 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1732,6 +1732,12 @@ The following nested keys are defined. numa_hint_faults (npn) Number of NUMA hinting faults. + numa_task_migrated (npn) + Number of task migration by NUMA balancing. + + numa_task_swapped (npn) + Number of task swap by NUMA balancing. + pgdemote_kswapd Number of pages demoted by kswapd. diff --git a/Documentation/core-api/folio_queue.rst b/Documentation/core-api/folio_queue.rst index 1fe7a9bc4b8d..83cfbc157e49 100644 --- a/Documentation/core-api/folio_queue.rst +++ b/Documentation/core-api/folio_queue.rst @@ -151,19 +151,16 @@ The marks can be set by:: void folioq_mark(struct folio_queue *folioq, unsigned int slot); void folioq_mark2(struct folio_queue *folioq, unsigned int slot); - void folioq_mark3(struct folio_queue *folioq, unsigned int slot); Cleared by:: void folioq_unmark(struct folio_queue *folioq, unsigned int slot); void folioq_unmark2(struct folio_queue *folioq, unsigned int slot); - void folioq_unmark3(struct folio_queue *folioq, unsigned int slot); And the marks can be queried by:: bool folioq_is_marked(const struct folio_queue *folioq, unsigned int slot); bool folioq_is_marked2(const struct folio_queue *folioq, unsigned int slot); - bool folioq_is_marked3(const struct folio_queue *folioq, unsigned int slot); The marks can be used for any purpose and are not interpreted by this API. diff --git a/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml b/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml new file mode 100644 index 000000000000..ad4a98a4ee67 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/atmel,sama5d2-secumod.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip AT91 Security Module (SECUMOD) + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + +description: + The Security Module also offers the PIOBU pins which can be used as GPIO pins. + Note that they maintain their voltage during Backup/Self-refresh. + +properties: + compatible: + oneOf: + - items: + - const: atmel,sama5d2-secumod + - const: syscon + - items: + - enum: + - microchip,sama7d65-secumod + - microchip,sama7g5-secumod + - const: atmel,sama5d2-secumod + - const: syscon + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + security-module@fc040000 { + compatible = "atmel,sama5d2-secumod", "syscon"; + reg = <0xfc040000 0x100>; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index d3821f651e72..5ce54f9befe6 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -46,28 +46,3 @@ Examples: reg = <0xffffe800 0x200>; }; -Security Module (SECUMOD) - -The Security Module macrocell provides all necessary secure functions to avoid -voltage, temperature, frequency and mechanical attacks on the chip. It also -embeds secure memories that can be scrambled. - -The Security Module also offers the PIOBU pins which can be used as GPIO pins. -Note that they maintain their voltage during Backup/Self-refresh. - -required properties: -- compatible: Should be "atmel,<chip>-secumod", "syscon". - <chip> can be "sama5d2". -- reg: Should contain registers location and length -- gpio-controller: Marks the port as GPIO controller. -- #gpio-cells: There are 2. The pin number is the - first, the second represents additional - parameters such as GPIO_ACTIVE_HIGH/LOW. - - - secumod@fc040000 { - compatible = "atmel,sama5d2-secumod", "syscon"; - reg = <0xfc040000 0x100>; - gpio-controller; - #gpio-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/ata/ahci-dm816.txt b/Documentation/devicetree/bindings/ata/ahci-dm816.txt deleted file mode 100644 index f8c535f3541f..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-dm816.txt +++ /dev/null @@ -1,21 +0,0 @@ -Device tree binding for the TI DM816 AHCI SATA Controller ---------------------------------------------------------- - -Required properties: - - compatible: must be "ti,dm816-ahci" - - reg: physical base address and size of the register region used by - the controller (as defined by the AHCI 1.1 standard) - - interrupts: interrupt specifier (refer to the interrupt binding) - - clocks: list of phandle and clock specifier pairs (or only - phandles for clock providers with '0' defined for - #clock-cells); two clocks must be specified: the functional - clock and an external reference clock - -Example: - - sata: sata@4a140000 { - compatible = "ti,dm816-ahci"; - reg = <0x4a140000 0x10000>; - interrupts = <16>; - clocks = <&sysclk5_ck>, <&sata_refclk>; - }; diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt deleted file mode 100644 index 909c9935360d..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-st.txt +++ /dev/null @@ -1,35 +0,0 @@ -STMicroelectronics STi SATA controller - -This binding describes a SATA device. - -Required properties: - - compatible : Must be "st,ahci" - - reg : Physical base addresses and length of register sets - - interrupts : Interrupt associated with the SATA device - - interrupt-names : Associated name must be; "hostc" - - clocks : The phandle for the clock - - clock-names : Associated name must be; "ahci_clk" - - phys : The phandle for the PHY port - - phy-names : Associated name must be; "ahci_phy" - -Optional properties: - - resets : The power-down, soft-reset and power-reset lines of SATA IP - - reset-names : Associated names must be; "pwr-dwn", "sw-rst" and "pwr-rst" - -Example: - - /* Example for stih407 family silicon */ - sata0: sata@9b20000 { - compatible = "st,ahci"; - reg = <0x9b20000 0x1000>; - interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>; - interrupt-names = "hostc"; - phys = <&phy_port0 PHY_TYPE_SATA>; - phy-names = "ahci_phy"; - resets = <&powerdown STIH407_SATA0_POWERDOWN>, - <&softreset STIH407_SATA0_SOFTRESET>, - <&softreset STIH407_SATA0_PWR_SOFTRESET>; - reset-names = "pwr-dwn", "sw-rst", "pwr-rst"; - clocks = <&clk_s_c0_flexgen CLK_ICN_REG>; - clock-names = "ahci_clk"; - }; diff --git a/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml b/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml new file mode 100644 index 000000000000..7dc942808656 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/apm,xgene-ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: APM X-Gene 6.0 Gb/s SATA host controller + +maintainers: + - Rob Herring <robh@kernel.org> + +allOf: + - $ref: ahci-common.yaml# + +properties: + compatible: + enum: + - apm,xgene-ahci + - apm,xgene-ahci-pcie + + reg: + minItems: 4 + items: + - description: AHCI memory resource + - description: Host controller core + - description: Host controller diagnostic + - description: Host controller AXI + - description: Host controller MUX + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - clocks + - phys + - phy-names + +unevaluatedProperties: false + +examples: + - | + sata@1a400000 { + compatible = "apm,xgene-ahci"; + reg = <0x1a400000 0x1000>, + <0x1f220000 0x1000>, + <0x1f22d000 0x1000>, + <0x1f22e000 0x1000>, + <0x1f227000 0x1000>; + clocks = <&sataclk 0>; + dma-coherent; + interrupts = <0x0 0x87 0x4>; + phys = <&phy2 0>; + phy-names = "sata-phy"; + }; diff --git a/Documentation/devicetree/bindings/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt deleted file mode 100644 index 02e690a675db..000000000000 --- a/Documentation/devicetree/bindings/ata/apm-xgene.txt +++ /dev/null @@ -1,77 +0,0 @@ -* APM X-Gene 6.0 Gb/s SATA host controller nodes - -SATA host controller nodes are defined to describe on-chip Serial ATA -controllers. Each SATA controller (pair of ports) have its own node. - -Required properties: -- compatible : Shall contain: - * "apm,xgene-ahci" -- reg : First memory resource shall be the AHCI memory - resource. - Second memory resource shall be the host controller - core memory resource. - Third memory resource shall be the host controller - diagnostic memory resource. - 4th memory resource shall be the host controller - AXI memory resource. - 5th optional memory resource shall be the host - controller MUX memory resource if required. -- interrupts : Interrupt-specifier for SATA host controller IRQ. -- clocks : Reference to the clock entry. -- phys : A list of phandles + phy-specifiers, one for each - entry in phy-names. -- phy-names : Should contain: - * "sata-phy" for the SATA 6.0Gbps PHY - -Optional properties: -- dma-coherent : Present if dma operations are coherent -- status : Shall be "ok" if enabled or "disabled" if disabled. - Default is "ok". - -Example: - sataclk: sataclk { - compatible = "fixed-clock"; - #clock-cells = <1>; - clock-frequency = <100000000>; - clock-output-names = "sataclk"; - }; - - phy2: phy@1f22a000 { - compatible = "apm,xgene-phy"; - reg = <0x0 0x1f22a000 0x0 0x100>; - #phy-cells = <1>; - }; - - phy3: phy@1f23a000 { - compatible = "apm,xgene-phy"; - reg = <0x0 0x1f23a000 0x0 0x100>; - #phy-cells = <1>; - }; - - sata2: sata@1a400000 { - compatible = "apm,xgene-ahci"; - reg = <0x0 0x1a400000 0x0 0x1000>, - <0x0 0x1f220000 0x0 0x1000>, - <0x0 0x1f22d000 0x0 0x1000>, - <0x0 0x1f22e000 0x0 0x1000>, - <0x0 0x1f227000 0x0 0x1000>; - interrupts = <0x0 0x87 0x4>; - dma-coherent; - clocks = <&sataclk 0>; - phys = <&phy2 0>; - phy-names = "sata-phy"; - }; - - sata3: sata@1a800000 { - compatible = "apm,xgene-ahci-pcie"; - reg = <0x0 0x1a800000 0x0 0x1000>, - <0x0 0x1f230000 0x0 0x1000>, - <0x0 0x1f23d000 0x0 0x1000>, - <0x0 0x1f23e000 0x0 0x1000>, - <0x0 0x1f237000 0x0 0x1000>; - interrupts = <0x0 0x88 0x4>; - dma-coherent; - clocks = <&sataclk 0>; - phys = <&phy3 0>; - phy-names = "sata-phy"; - }; diff --git a/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml b/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml new file mode 100644 index 000000000000..4d7017452dda --- /dev/null +++ b/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/arasan,cf-spear1340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arasan PATA Compact Flash Controller + +maintainers: + - Viresh Kumar <viresh.kumar@linaro.org> + +properties: + compatible: + const: arasan,cf-spear1340 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + arasan,broken-udma: + description: UDMA mode is unusable + type: boolean + + arasan,broken-mwdma: + description: MWDMA mode is unusable + type: boolean + + arasan,broken-pio: + description: PIO mode is unusable + type: boolean + + dmas: + maxItems: 1 + + dma-names: + items: + - const: data + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + not: + required: + - arasan,broken-udma + - arasan,broken-mwdma + then: + required: + - dmas + - dma-names + +examples: + - | + cf@fc000000 { + compatible = "arasan,cf-spear1340"; + reg = <0xfc000000 0x1000>; + interrupts = <12>; + dmas = <&dma 23>; + dma-names = "data"; + }; diff --git a/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml b/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml new file mode 100644 index 000000000000..349f289b81e6 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/cavium,ebt3000-compact-flash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cavium Compact Flash + +maintainers: + - Rob Herring <robh@kernel.org> + +description: + The Cavium Compact Flash device is connected to the Octeon Boot Bus, and is + thus a child of the Boot Bus device. It can read and write industry standard + compact flash devices. + +properties: + compatible: + const: cavium,ebt3000-compact-flash + + reg: + description: The base address of the CF chip select banks. + items: + - description: CF chip select bank 0 + - description: CF chip select bank 1 + + cavium,bus-width: + description: The width of the connection to the CF devices. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + + cavium,true-ide: + description: True IDE mode when present. + type: boolean + + cavium,dma-engine-handle: + description: A phandle for the DMA Engine connected to this device. + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <1>; + + compact-flash@5,0 { + compatible = "cavium,ebt3000-compact-flash"; + reg = <5 0 0x10000>, <6 0 0x10000>; + cavium,bus-width = <16>; + cavium,true-ide; + cavium,dma-engine-handle = <&dma0>; + }; + }; diff --git a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt b/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt deleted file mode 100644 index 3bacc8e0931e..000000000000 --- a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Compact Flash - -The Cavium Compact Flash device is connected to the Octeon Boot Bus, -and is thus a child of the Boot Bus device. It can read and write -industry standard compact flash devices. - -Properties: -- compatible: "cavium,ebt3000-compact-flash"; - - Compatibility with many Cavium evaluation boards. - -- reg: The base address of the CF chip select banks. Depending on - the device configuration, there may be one or two banks. - -- cavium,bus-width: The width of the connection to the CF devices. Valid - values are 8 and 16. - -- cavium,true-ide: Optional, if present the CF connection is in True IDE mode. - -- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected - to this device. - -Example: - compact-flash@5,0 { - compatible = "cavium,ebt3000-compact-flash"; - reg = <5 0 0x10000>, <6 0 0x10000>; - cavium,bus-width = <16>; - cavium,true-ide; - cavium,dma-engine-handle = <&dma0>; - }; diff --git a/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml b/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml new file mode 100644 index 000000000000..f656ea9223d6 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/marvell,orion-sata.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Orion SATA + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Gregory Clement <gregory.clement@bootlin.com> + +allOf: + - $ref: sata-common.yaml# + +properties: + compatible: + enum: + - marvell,orion-sata + - marvell,armada-370-sata + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 8 + + clock-names: + minItems: 1 + items: + - const: '0' + - const: '1' + - const: '2' + - const: '3' + - const: '4' + - const: '5' + - const: '6' + - const: '7' + + interrupts: + maxItems: 1 + + nr-ports: + description: + Number of SATA ports in use. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 8 + + phys: + minItems: 1 + maxItems: 8 + + phy-names: + minItems: 1 + items: + - const: port0 + - const: port1 + - const: port2 + - const: port3 + - const: port4 + - const: port5 + - const: port6 + - const: port7 + +required: + - compatible + - reg + - interrupts + - nr-ports + +unevaluatedProperties: false + +examples: + - | + sata@80000 { + compatible = "marvell,orion-sata"; + reg = <0x80000 0x5000>; + interrupts = <21>; + phys = <&sata_phy0>, <&sata_phy1>; + phy-names = "port0", "port1"; + nr-ports = <2>; + }; diff --git a/Documentation/devicetree/bindings/ata/marvell.txt b/Documentation/devicetree/bindings/ata/marvell.txt deleted file mode 100644 index b460edd12766..000000000000 --- a/Documentation/devicetree/bindings/ata/marvell.txt +++ /dev/null @@ -1,22 +0,0 @@ -* Marvell Orion SATA - -Required Properties: -- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata" -- reg : Address range of controller -- interrupts : Interrupt controller is using -- nr-ports : Number of SATA ports in use. - -Optional Properties: -- phys : List of phandles to sata phys -- phy-names : Should be "0", "1", etc, one number per phandle - -Example: - - sata@80000 { - compatible = "marvell,orion-sata"; - reg = <0x80000 0x5000>; - interrupts = <21>; - phys = <&sata_phy0>, <&sata_phy1>; - phy-names = "0", "1"; - nr-ports = <2>; - } diff --git a/Documentation/devicetree/bindings/ata/pata-arasan.txt b/Documentation/devicetree/bindings/ata/pata-arasan.txt deleted file mode 100644 index 872edc105680..000000000000 --- a/Documentation/devicetree/bindings/ata/pata-arasan.txt +++ /dev/null @@ -1,37 +0,0 @@ -* ARASAN PATA COMPACT FLASH CONTROLLER - -Required properties: -- compatible: "arasan,cf-spear1340" -- reg: Address range of the CF registers -- interrupt: Should contain the CF interrupt number -- clock-frequency: Interface clock rate, in Hz, one of - 25000000 - 33000000 - 40000000 - 50000000 - 66000000 - 75000000 - 100000000 - 125000000 - 150000000 - 166000000 - 200000000 - -Optional properties: -- arasan,broken-udma: if present, UDMA mode is unusable -- arasan,broken-mwdma: if present, MWDMA mode is unusable -- arasan,broken-pio: if present, PIO mode is unusable -- dmas: one DMA channel, as described in bindings/dma/dma.txt - required unless both UDMA and MWDMA mode are broken -- dma-names: the corresponding channel name, must be "data" - -Example: - - cf@fc000000 { - compatible = "arasan,cf-spear1340"; - reg = <0xfc000000 0x1000>; - interrupt-parent = <&vic1>; - interrupts = <12>; - dmas = <&dma-controller 23>; - dma-names = "data"; - }; diff --git a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml index 13eaa8d9a16e..b5ecaabfe2e2 100644 --- a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml +++ b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml @@ -20,6 +20,7 @@ select: contains: enum: - rockchip,rk3568-dwc-ahci + - rockchip,rk3576-dwc-ahci - rockchip,rk3588-dwc-ahci required: - compatible @@ -29,6 +30,7 @@ properties: items: - enum: - rockchip,rk3568-dwc-ahci + - rockchip,rk3576-dwc-ahci - rockchip,rk3588-dwc-ahci - const: snps,dwc-ahci @@ -83,6 +85,7 @@ allOf: contains: enum: - rockchip,rk3568-dwc-ahci + - rockchip,rk3576-dwc-ahci then: properties: clocks: diff --git a/Documentation/devicetree/bindings/ata/st,ahci.yaml b/Documentation/devicetree/bindings/ata/st,ahci.yaml new file mode 100644 index 000000000000..6e8e4b4f3d6c --- /dev/null +++ b/Documentation/devicetree/bindings/ata/st,ahci.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/st,ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STi SATA controller + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +allOf: + - $ref: ahci-common.yaml# + +properties: + compatible: + const: st,ahci + + interrupt-names: + items: + - const: hostc + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ahci_clk + + resets: + items: + - description: Power-down line + - description: Soft-reset line + - description: Power-reset line + + reset-names: + items: + - const: pwr-dwn + - const: sw-rst + - const: pwr-rst + +required: + - compatible + - interrupt-names + - phys + - phy-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/phy/phy.h> + #include <dt-bindings/reset/stih407-resets.h> + #include <dt-bindings/clock/stih407-clks.h> + + sata@9b20000 { + compatible = "st,ahci"; + reg = <0x9b20000 0x1000>; + interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>; + interrupt-names = "hostc"; + phys = <&phy_port0 PHY_TYPE_SATA>; + phy-names = "sata-phy"; + resets = <&powerdown STIH407_SATA0_POWERDOWN>, + <&softreset STIH407_SATA0_SOFTRESET>, + <&softreset STIH407_SATA0_PWR_SOFTRESET>; + reset-names = "pwr-dwn", "sw-rst", "pwr-rst"; + clocks = <&clk_s_c0_flexgen CLK_ICN_REG>; + clock-names = "ahci_clk"; + }; diff --git a/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml new file mode 100644 index 000000000000..d0ff9e78afe6 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/ti,dm816-ahci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI DM816 AHCI SATA Controller + +maintainers: + - Bartosz Golaszewski <brgl@bgdev.pl> + +allOf: + - $ref: ahci-common.yaml# + +properties: + compatible: + const: ti,dm816-ahci + + reg: + maxItems: 1 + + clocks: + items: + - description: functional clock + - description: external reference clock + + ti,hwmods: + const: sata + +required: + - compatible + - clocks + +unevaluatedProperties: false + +examples: + - | + sata@4a140000 { + compatible = "ti,dm816-ahci"; + reg = <0x4a140000 0x10000>; + interrupts = <16>; + clocks = <&sysclk5_ck>, <&sata_refclk>; + }; diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml index a8d40c766dcd..0bea4f5287ce 100644 --- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml @@ -10,8 +10,8 @@ maintainers: - Saurabh Sengar <ssengar@linux.microsoft.com> description: - VMBus is a software bus that implement the protocols for communication - between the root or host OS and guest OSs (virtual machines). + VMBus is a software bus that implements the protocols for communication + between the root or host OS and guest OS'es (virtual machines). properties: compatible: @@ -25,9 +25,16 @@ properties: '#size-cells': const: 1 + dma-coherent: true + + interrupts: + maxItems: 1 + description: Interrupt is used to report a message from the host. + required: - compatible - ranges + - interrupts - '#address-cells' - '#size-cells' @@ -35,6 +42,8 @@ additionalProperties: false examples: - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> soc { #address-cells = <2>; #size-cells = <1>; @@ -49,6 +58,9 @@ examples: #address-cells = <2>; #size-cells = <1>; ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>; + dma-coherent; + interrupt-parent = <&gic>; + interrupts = <GIC_PPI 2 IRQ_TYPE_EDGE_RISING>; }; }; }; diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml index e879bc0be8e2..9f8e6689cd94 100644 --- a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml @@ -83,6 +83,8 @@ properties: by SNVS ONOFF, the driver can report the status of POWER key and wakeup system if pressed after system suspend. + $ref: /schemas/input/input.yaml + properties: compatible: const: fsl,sec-v4.0-pwrkey @@ -111,6 +113,9 @@ properties: maxItems: 1 default: 116 + power-off-time-sec: + enum: [0, 5, 10, 15] + required: - compatible - interrupts diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml new file mode 100644 index 000000000000..bf028a8718f1 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/pmbus/adi,lt3074.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices LT3074 voltage regulator + +maintainers: + - Cedric Encarnacion <cedricjustine.encarnacion@analog.com> + +description: | + The LT3074 is a low voltage, ultra-low noise and ultra-fast transient + response linear regulator. It allows telemetry for input/output voltage, + output current and temperature through the PMBus serial interface. + + Datasheet: + https://www.analog.com/en/products/lt3074.html + +allOf: + - $ref: /schemas/regulator/regulator.yaml# + +properties: + compatible: + enum: + - adi,lt3074 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@6d { + compatible = "adi,lt3074"; + reg = <0x6d>; + regulator-name = "vout"; + regulator-max-microvolt = <1250000>; + regulator-min-microvolt = <1150000>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml new file mode 100644 index 000000000000..90970a0433e9 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/pmbus/mps,mpq8785.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Monolithic Power Systems Multiphase Voltage Regulators with PMBus + +maintainers: + - Charles Hsu <ythsu0511@gmail.com> + +description: + Monolithic Power Systems digital multiphase voltage regulators with PMBus. + +properties: + compatible: + enum: + - mps,mpm3695 + - mps,mpm3695-25 + - mps,mpm82504 + - mps,mpq8785 + + reg: + maxItems: 1 + + mps,vout-fb-divider-ratio-permille: + description: + The feedback resistor divider ratio, expressed in permille + (Vfb / Vout * 1000). This value is written to the PMBUS_VOUT_SCALE_LOOP + register and is required for correct output voltage presentation. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4095 + default: 706 + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + enum: + - mps,mpm3695 + - mps,mpm82504 + then: + properties: + mps,vout-fb-divider-ratio-permille: + maximum: 1023 + + - if: + properties: + compatible: + const: mps,mpq8785 + then: + properties: + mps,vout-fb-divider-ratio-permille: + maximum: 2047 + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@30 { + compatible = "mps,mpm82504"; + reg = <0x30>; + mps,vout-fb-divider-ratio-permille = <600>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml b/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml index f0667ac41d75..b76805d39427 100644 --- a/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml +++ b/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml @@ -11,7 +11,11 @@ maintainers: properties: compatible: - const: sophgo,sg2042-hwmon-mcu + oneOf: + - items: + - const: sophgo,sg2044-hwmon-mcu + - const: sophgo,sg2042-hwmon-mcu + - const: sophgo,sg2042-hwmon-mcu reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml b/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml index 5d33f1a23d03..9ca7356760a7 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml @@ -28,6 +28,17 @@ properties: i2c-mux: type: object + fan: + $ref: fan-common.yaml# + unevaluatedProperties: false + + "#pwm-cells": + const: 2 + description: | + Number of cells in a PWM specifier. + - cell 0: PWM period in nanoseconds + - cell 1: PWM polarity: 0 or PWM_POLARITY_INVERTED + required: - compatible - reg @@ -50,9 +61,14 @@ examples: #address-cells = <1>; #size-cells = <0>; - fan@18 { + fan_controller: fan@18 { compatible = "ti,amc6821"; reg = <0x18>; + #pwm-cells = <2>; + + fan { + pwms = <&fan_controller 40000 0>; + }; }; }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index bc03781342c0..d1fb7b9abda0 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -19,6 +19,7 @@ description: | properties: compatible: enum: + - silergy,sq52206 - silergy,sy24655 - ti,ina209 - ti,ina219 @@ -58,6 +59,9 @@ properties: shunt voltage, and a value of 4 maps to ADCRANGE=0 such that a wider voltage range is used. + For SQ52206,the shunt-gain value 1 mapps to ADCRANGE=10/11, the value 2 + mapps to ADCRANGE=01, and the value 4 mapps to ADCRANGE=00. + The default value is device dependent, and is defined by the reset value of PGA/ADCRANGE in the respective configuration registers. $ref: /schemas/types.yaml#/definitions/uint32 @@ -97,6 +101,7 @@ allOf: compatible: contains: enum: + - silergy,sq52206 - silergy,sy24655 - ti,ina209 - ti,ina219 diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml index 7e5b62a0215d..4c89448eba0d 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml @@ -23,6 +23,9 @@ properties: "#thermal-sensor-cells": const: 1 + vcc-supply: + description: Power supply for tmp102 + required: - compatible - reg @@ -42,6 +45,7 @@ examples: reg = <0x48>; interrupt-parent = <&gpio7>; interrupts = <16 IRQ_TYPE_LEVEL_LOW>; + vcc-supply = <&supply>; #thermal-sensor-cells = <1>; }; }; diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt b/Documentation/devicetree/bindings/input/dlg,da7280.txt deleted file mode 100644 index 96ee5d50e111..000000000000 --- a/Documentation/devicetree/bindings/input/dlg,da7280.txt +++ /dev/null @@ -1,108 +0,0 @@ -Dialog Semiconductor DA7280 Haptics bindings - -Required properties: -- compatible: Should be "dlg,da7280". -- reg: Specifies the I2C slave address. - -- interrupt-parent : Specifies the phandle of the interrupt controller to - which the IRQs from DA7280 are delivered to. - -- dlg,actuator-type: Set Actuator type. it should be one of: - "LRA" - Linear Resonance Actuator type. - "ERM-bar" - Bar type Eccentric Rotating Mass. - "ERM-coin" - Coin type Eccentric Rotating Mass. - -- dlg,const-op-mode: Haptic operation mode for FF_CONSTANT. - Possible values: - 1 - Direct register override(DRO) mode triggered by i2c(default), - 2 - PWM data source mode controlled by PWM duty, -- dlg,periodic-op-mode: Haptic operation mode for FF_PERIODIC. - Possible values: - 1 - Register triggered waveform memory(RTWM) mode, the pattern - assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP, - 2 - Edge triggered waveform memory(ETWM) mode, external GPI(N) - control are required to enable/disable and it needs to keep - device enabled by sending magnitude (X > 0), - the pattern is assigned to the GPI(N)_SEQUENCE_ID below. - The default value is 1 for both of the operation modes. - For more details, please see the datasheet. - -- dlg,nom-microvolt: Nominal actuator voltage rating. - Valid values: 0 - 6000000. -- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating. - Valid values: 0 - 6000000. -- dlg,imax-microamp: Actuator max current rating. - Valid values: 0 - 252000. - Default: 130000. -- dlg,impd-micro-ohms: the impedance of the actuator in micro ohms. - Valid values: 0 - 1500000000. - -Optional properties: -- pwms : phandle to the physical PWM(Pulse Width Modulation) device. - PWM properties should be named "pwms". And number of cell is different - for each pwm device. - (See Documentation/devicetree/bindings/pwm/pwm.txt - for further information relating to pwm properties) - -- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip) - to play back when RTWM-MODE is enabled. - Valid range: 0 - 15. -- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence - pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated. - Valid range: 0 - 15. -- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play - when gpi0 is triggered, 'N' must be 0 - 2. - Valid range: 0 - 15. -- dlg,gpiN-mode: the pattern mode which can select either - "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2. -- dlg,gpiN-polarity: gpiN polarity which can be chosen among - "Rising-edge", "Falling-edge" and "Both-edge", - 'N' must be 0 - 2 - Haptic will work by this edge option in case of ETWM mode. - -- dlg,resonant-freq-hz: use in case of LRA. - the frequency range: 50 - 300. - Default: 205. - -- dlg,bemf-sens-enable: Enable for internal loop computations. -- dlg,freq-track-enable: Enable for resonant frequency tracking. -- dlg,acc-enable: Enable for active acceleration. -- dlg,rapid-stop-enable: Enable for rapid stop. -- dlg,amp-pid-enable: Enable for the amplitude PID. -- dlg,mem-array: Customized waveform memory(patterns) data downloaded to - the device during initialization. This is an array of 100 values(u8). - -For further information, see device datasheet. - -====== - -Example: - - haptics: da7280-haptics@4a { - compatible = "dlg,da7280"; - reg = <0x4a>; - interrupt-parent = <&gpio6>; - interrupts = <11 IRQ_TYPE_LEVEL_LOW>; - dlg,actuator-type = "LRA"; - dlg,dlg,const-op-mode = <1>; - dlg,dlg,periodic-op-mode = <1>; - dlg,nom-microvolt = <2000000>; - dlg,abs-max-microvolt = <2000000>; - dlg,imax-microamp = <170000>; - dlg,resonant-freq-hz = <180>; - dlg,impd-micro-ohms = <10500000>; - dlg,freq-track-enable; - dlg,rapid-stop-enable; - dlg,mem-array = < - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - >; - }; diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.yaml b/Documentation/devicetree/bindings/input/dlg,da7280.yaml new file mode 100644 index 000000000000..0d06755aaaa8 --- /dev/null +++ b/Documentation/devicetree/bindings/input/dlg,da7280.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/dlg,da7280.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dialog Semiconductor DA7280 Low Power High-Definition Haptic Driver + +maintainers: + - Roy Im <roy.im.opensource@diasemi.com> + +properties: + compatible: + const: dlg,da7280 + + reg: + maxItems: 1 + description: I2C address of the device. + + interrupts: + maxItems: 1 + + dlg,actuator-type: + enum: + - LRA # Linear Resonance Actuator type + - ERM-bar # Bar type Eccentric Rotating Mass + - ERM-coin # Coin type Eccentric Rotating Mass + + dlg,const-op-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 # Direct register override (DRO) mode triggered by i2c (default) + - 2 # PWM data source mode controlled by PWM duty + description: + Haptic operation mode for FF_CONSTANT + + dlg,periodic-op-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 # Register triggered waveform memory(RTWM) mode, the pattern + # assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP + - 2 # Edge triggered waveform memory(ETWM) mode, external GPI(N) + # control are required to enable/disable and it needs to keep + # device enabled by sending magnitude (X > 0), + # the pattern is assigned to the GPI(N)_SEQUENCE_ID below + default: 1 + description: + Haptic operation mode for FF_PERIODIC. + The default value is 1 for both of the operation modes. + For more details, please see the datasheet + + dlg,nom-microvolt: + minimum: 0 + maximum: 6000000 + description: + Nominal actuator voltage rating + + dlg,abs-max-microvolt: + minimum: 0 + maximum: 6000000 + description: + Absolute actuator maximum voltage rating + + dlg,imax-microamp: + minimum: 0 + maximum: 252000 + default: 130000 + description: + Actuator max current rating + + dlg,impd-micro-ohms: + minimum: 0 + maximum: 1500000000 + description: + Impedance of the actuator + + pwms: + maxItems: 1 + + dlg,ps-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + The PS_SEQ_ID(pattern ID in waveform memory inside chip) + to play back when RTWM-MODE is enabled + + dlg,ps-seq-loop: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + The PS_SEQ_LOOP, Number of times the pre-stored sequence pointed to by + PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated + + dlg,gpi0-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + the GPI0_SEQUENCE_ID, pattern to play when gpi0 is triggered + + dlg,gpi1-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + the GPI1_SEQUENCE_ID, pattern to play when gpi1 is triggered + + dlg,gpi2-seq-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + the GPI2_SEQUENCE_ID, pattern to play when gpi2 is triggered + + dlg,gpi0-mode: + enum: + - Single-pattern + - Multi-pattern + description: + Pattern mode for gpi0 + + dlg,gpi1-mode: + enum: + - Single-pattern + - Multi-pattern + description: + Pattern mode for gpi1 + + dlg,gpi2-mode: + enum: + - Single-pattern + - Multi-pattern + description: + Pattern mode for gpi2 + + dlg,gpi0-polarity: + enum: + - Rising-edge + - Falling-edge + - Both-edge + description: + gpi0 polarity, Haptic will work by this edge option in case of ETWM mode + + dlg,gpi1-polarity: + enum: + - Rising-edge + - Falling-edge + - Both-edge + description: + gpi1 polarity, Haptic will work by this edge option in case of ETWM mode + + dlg,gpi2-polarity: + enum: + - Rising-edge + - Falling-edge + - Both-edge + description: + gpi2 polarity, Haptic will work by this edge option in case of ETWM mode + + dlg,resonant-freq-hz: + minimum: 50 + maximum: 300 + default: 205 + + dlg,bemf-sens-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for internal loop computations + + dlg,freq-track-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for resonant frequency tracking + + dlg,acc-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for active acceleration + + dlg,rapid-stop-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for rapid stop + + dlg,amp-pid-enable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable for the amplitude PID + + dlg,mem-array: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 100 + description: + Customized waveform memory (patterns) data downloaded to the device during initialization. + Each entry value must be included between 0 and 255. + +required: + - compatible + - reg + - interrupts + - dlg,actuator-type + - dlg,const-op-mode + - dlg,periodic-op-mode + - dlg,nom-microvolt + - dlg,abs-max-microvolt + - dlg,imax-microamp + - dlg,impd-micro-ohms + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + haptics@4a { + compatible = "dlg,da7280"; + reg = <0x4a>; + interrupt-parent = <&gpio6>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + dlg,actuator-type = "LRA"; + dlg,const-op-mode = <1>; + dlg,periodic-op-mode = <1>; + dlg,nom-microvolt = <2000000>; + dlg,abs-max-microvolt = <2000000>; + dlg,imax-microamp = <170000>; + dlg,resonant-freq-hz = <180>; + dlg,impd-micro-ohms = <10500000>; + dlg,freq-track-enable; + dlg,rapid-stop-enable; + dlg,mem-array = <0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index 70a922e213f2..ab821490284a 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -103,16 +103,9 @@ properties: minimum: 0 maximum: 255 - touchscreen-size-x: true - touchscreen-size-y: true - touchscreen-fuzz-x: true - touchscreen-fuzz-y: true - touchscreen-inverted-x: true - touchscreen-inverted-y: true - touchscreen-swapped-x-y: true interrupt-controller: true -additionalProperties: false +unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/leds/ti,tps61310.yaml b/Documentation/devicetree/bindings/leds/ti,tps61310.yaml new file mode 100644 index 000000000000..118f9c8bfdf7 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/ti,tps61310.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/ti,tps61310.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TPS6131X flash LED driver + +maintainers: + - Matthias Fend <matthias.fend@emfend.at> + +description: | + The TPS61310/TPS61311 is a flash LED driver with I2C interface. + Its power stage is capable of supplying a maximum total current of roughly 1500mA. + The TPS6131x provides three constant-current sinks, capable of sinking + up to 2 x 400mA (LED1 and LED3) and 800mA (LED2) in flash mode. + In torch mode, each sink (LED1, LED2, LED3) supports currents up to 175mA. + Since the three current sinks share most of the control components such as + flash timer, control logic, safety timer and the operating mode, they cannot + be used completely independently of each other. Therefore, only one LED is + supported, but the current sinks can be combined accordingly. + + The data sheet can be found at: + https://www.ti.com/lit/ds/symlink/tps61310.pdf + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,tps61311 + - const: ti,tps61310 + - items: + - const: ti,tps61310 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: GPIO connected to NRESET pin + + ti,valley-current-limit: + type: boolean + description: + Reduce the valley peak current limit from 1750mA to 1250mA (TPS61310) or + from 2480mA to 1800mA (TPS61311). + + led: + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + led-sources: + minItems: 1 + maxItems: 3 + items: + enum: [1, 2, 3] + + led-max-microamp: + oneOf: + - minimum: 50000 + maximum: 350000 + multipleOf: 50000 + - minimum: 25000 + maximum: 525000 + multipleOf: 25000 + + flash-max-microamp: + oneOf: + - minimum: 50000 + maximum: 800000 + multipleOf: 50000 + - minimum: 25000 + maximum: 1500000 + multipleOf: 25000 + + flash-max-timeout-us: + enum: [ 5300, 10700, 16000, 21300, 26600, 32000, 37300, 68200, 71500, + 102200, 136300, 170400, 204500, 340800, 579300, 852000 ] + + required: + - led-sources + - led-max-microamp + - flash-max-microamp + - flash-max-timeout-us + +required: + - compatible + - reg + - led + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@33 { + compatible = "ti,tps61311", "ti,tps61310"; + reg = <0x33>; + + reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; + + led { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + led-sources = <1>, <2>, <3>; + led-max-microamp = <525000>; + flash-max-microamp = <1500000>; + flash-max-timeout-us = <852000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index a58a018f3f7b..ac726136f7e5 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -49,6 +49,7 @@ properties: - qcom,qcs615-apss-shared - qcom,sc7180-apss-shared - qcom,sc8180x-apss-shared + - qcom,sm7150-apss-shared - qcom,sm8150-apss-shared - const: qcom,sdm845-apss-shared - items: @@ -72,6 +73,7 @@ properties: description: phandles to the parent clocks of the clock driver minItems: 2 maxItems: 3 + deprecated: true '#mbox-cells': const: 1 @@ -82,6 +84,23 @@ properties: clock-names: minItems: 2 maxItems: 3 + deprecated: true + + clock-controller: + type: object + additionalProperties: false + properties: + clocks: + description: phandles to the parent clocks of the clock driver + minItems: 2 + maxItems: 3 + + '#clock-cells': + enum: [0, 1] + + clock-names: + minItems: 2 + maxItems: 3 required: - compatible @@ -90,6 +109,76 @@ required: additionalProperties: false +# Clocks should be specified either on the parent node or on the child node +oneOf: + - required: + - clock-controller + properties: + clocks: false + clock-names: false + '#clock-cells': false + - properties: + clock-controller: false + +$defs: + msm8916-apcs-clock-controller: + properties: + clocks: + items: + - description: primary pll parent of the clock driver + - description: auxiliary parent + clock-names: + items: + - const: pll + - const: aux + '#clock-cells': + const: 0 + + msm8939-apcs-clock-controller: + properties: + clocks: + items: + - description: primary pll parent of the clock driver + - description: auxiliary parent + - description: reference clock + clock-names: + items: + - const: pll + - const: aux + - const: ref + '#clock-cells': + const: 0 + + sdx55-apcs-clock-controller: + properties: + clocks: + items: + - description: reference clock + - description: primary pll parent of the clock driver + - description: auxiliary parent + clock-names: + items: + - const: ref + - const: pll + - const: aux + '#clock-cells': + const: 0 + + ipq6018-apcs-clock-controller: + properties: + clocks: + items: + - description: primary pll parent of the clock driver + - description: XO clock + - description: GCC GPLL0 clock source + clock-names: + items: + - const: pll + - const: xo + - const: gpll0 + '#clock-cells': + const: 1 + allOf: - if: properties: @@ -98,15 +187,10 @@ allOf: enum: - qcom,msm8916-apcs-kpss-global then: + $ref: "#/$defs/msm8916-apcs-clock-controller" properties: - clocks: - items: - - description: primary pll parent of the clock driver - - description: auxiliary parent - clock-names: - items: - - const: pll - - const: aux + clock-controller: + $ref: "#/$defs/msm8916-apcs-clock-controller" - if: properties: @@ -115,17 +199,10 @@ allOf: enum: - qcom,msm8939-apcs-kpss-global then: + $ref: "#/$defs/msm8939-apcs-clock-controller" properties: - clocks: - items: - - description: primary pll parent of the clock driver - - description: auxiliary parent - - description: reference clock - clock-names: - items: - - const: pll - - const: aux - - const: ref + clock-controller: + $ref: "#/$defs/msm8939-apcs-clock-controller" - if: properties: @@ -134,17 +211,10 @@ allOf: enum: - qcom,sdx55-apcs-gcc then: + $ref: "#/$defs/sdx55-apcs-clock-controller" properties: - clocks: - items: - - description: reference clock - - description: primary pll parent of the clock driver - - description: auxiliary parent - clock-names: - items: - - const: ref - - const: pll - - const: aux + clock-controller: + $ref: "#/$defs/sdx55-apcs-clock-controller" - if: properties: @@ -153,17 +223,10 @@ allOf: enum: - qcom,ipq6018-apcs-apps-global then: + $ref: "#/$defs/ipq6018-apcs-clock-controller" properties: - clocks: - items: - - description: primary pll parent of the clock driver - - description: XO clock - - description: GCC GPLL0 clock source - clock-names: - items: - - const: pll - - const: xo - - const: gpll0 + clock-controller: + $ref: "#/$defs/ipq6018-apcs-clock-controller" - if: properties: @@ -179,19 +242,7 @@ allOf: properties: clocks: false clock-names: false - - - if: - properties: - compatible: - contains: - enum: - - qcom,ipq6018-apcs-apps-global - then: - properties: - '#clock-cells': - const: 1 - else: - properties: + clock-controller: false '#clock-cells': const: 0 @@ -219,6 +270,23 @@ examples: - | #define GCC_APSS_AHB_CLK_SRC 1 #define GCC_GPLL0_AO_OUT_MAIN 123 + mailbox@b011000 { + compatible = "qcom,qcs404-apcs-apps-global", + "qcom,msm8916-apcs-kpss-global", "syscon"; + reg = <0x0b011000 0x1000>; + #mbox-cells = <1>; + + apcs_clk: clock-controller { + clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>; + clock-names = "pll", "aux"; + #clock-cells = <0>; + }; + }; + + # Example apcs with qcs404 (deprecated: use clock-controller subnode) + - | + #define GCC_APSS_AHB_CLK_SRC 1 + #define GCC_GPLL0_AO_OUT_MAIN 123 apcs: mailbox@b011000 { compatible = "qcom,qcs404-apcs-apps-global", "qcom,msm8916-apcs-kpss-global", "syscon"; diff --git a/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml new file mode 100644 index 000000000000..24e126bd3a20 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/sophgo,cv1800b-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo CV1800/SG2000 mailbox controller + +maintainers: + - Yuntao Dai <d1581209858@live.com> + - Junhui Liu <junhui.liu@pigmoral.tech> + +description: + Mailboxes integrated in Sophgo CV1800/SG2000 SoCs have 8 channels, each + shipping an 8-byte FIFO. Any processor can write to an arbitrary channel + and raise interrupts to receivers. Sending messages to itself is also + supported. + +properties: + compatible: + const: sophgo,cv1800b-mailbox + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 2 + description: | + <&phandle channel target> + phandle : Label name of mailbox controller + channel : 0-7, Channel index + target : 0-3, Target processor ID + + Sophgo CV1800/SG2000 SoCs include the following processors, numbered as: + <0> Cortex-A53 (Only available on CV181X/SG200X) + <1> C906B + <2> C906L + <3> 8051 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + mailbox@1900000 { + compatible = "sophgo,cv1800b-mailbox"; + reg = <0x01900000 0x1000>; + interrupts = <101 IRQ_TYPE_LEVEL_HIGH>; + #mbox-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml index f805545aa62a..f6f47999c6c1 100644 --- a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml +++ b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml @@ -19,6 +19,7 @@ properties: - items: - enum: - atmel,at91sam9260-gpbr + - microchip,sama7d65-gpbr - const: syscon - items: - enum: diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt deleted file mode 100644 index be51a15e05f9..000000000000 --- a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt +++ /dev/null @@ -1,39 +0,0 @@ -------------------------------- -BCM590xx Power Management Units -------------------------------- - -Required properties: -- compatible: "brcm,bcm59056" -- reg: I2C slave address -- interrupts: interrupt for the PMU. Generic interrupt client node bindings - are described in interrupt-controller/interrupts.txt - ------------------- -Voltage Regulators ------------------- - -Optional child nodes: -- regulators: container node for regulators following the generic - regulator binding in regulator/regulator.txt - - The valid regulator node names for BCM59056 are: - rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo, - mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo, - csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr, - gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6, - vbus - -Example: - pmu: bcm59056@8 { - compatible = "brcm,bcm59056"; - reg = <0x08>; - interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; - regulators { - rfldo_reg: rfldo { - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3300000>; - }; - - ... - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml new file mode 100644 index 000000000000..b67d7a723fc2 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/brcm,bcm59056.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM590xx Power Management Units + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +properties: + compatible: + enum: + - brcm,bcm59054 + - brcm,bcm59056 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + regulators: + type: object + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: brcm,bcm59054 + then: + properties: + regulators: + $ref: /schemas/regulator/brcm,bcm59054.yaml# + + - if: + properties: + compatible: + contains: + const: brcm,bcm59056 + then: + properties: + regulators: + $ref: /schemas/regulator/brcm,bcm59056.yaml# + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@8 { + compatible = "brcm,bcm59056"; + reg = <0x08>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + + regulators { + rfldo { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/iqs62x.yaml b/Documentation/devicetree/bindings/mfd/iqs62x.yaml index e79ce447a800..f242dd0e18fd 100644 --- a/Documentation/devicetree/bindings/mfd/iqs62x.yaml +++ b/Documentation/devicetree/bindings/mfd/iqs62x.yaml @@ -60,43 +60,34 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - iqs620a@44 { - compatible = "azoteq,iqs620a"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - - keys { - compatible = "azoteq,iqs620a-keys"; - - linux,keycodes = <KEY_SELECT>, - <KEY_MENU>, - <KEY_OK>, - <KEY_MENU>; - - hall-switch-south { - linux,code = <SW_LID>; - azoteq,use-prox; - }; - }; - - iqs620a_pwm: pwm { - compatible = "azoteq,iqs620a-pwm"; - #pwm-cells = <2>; - }; + #address-cells = <1>; + #size-cells = <0>; + + iqs620a@44 { + compatible = "azoteq,iqs620a"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + keys { + compatible = "azoteq,iqs620a-keys"; + + linux,keycodes = <KEY_SELECT>, + <KEY_MENU>, + <KEY_OK>, + <KEY_MENU>; + + hall-switch-south { + linux,code = <SW_LID>; + azoteq,use-prox; + }; }; - }; - - pwmleds { - compatible = "pwm-leds"; - led-1 { - pwms = <&iqs620a_pwm 0 1000000>; - max-brightness = <255>; + iqs620a_pwm: pwm { + compatible = "azoteq,iqs620a-pwm"; + #pwm-cells = <2>; }; + }; }; - | @@ -105,37 +96,37 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - iqs620a@44 { - compatible = "azoteq,iqs620a"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - - firmware-name = "iqs620a_coil.bin"; - - keys { - compatible = "azoteq,iqs620a-keys"; - - linux,keycodes = <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <KEY_MUTE>; - - hall-switch-north { - linux,code = <SW_DOCK>; - }; - - hall-switch-south { - linux,code = <SW_TABLET_MODE>; - }; - }; + #address-cells = <1>; + #size-cells = <0>; + + iqs620a@44 { + compatible = "azoteq,iqs620a"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + firmware-name = "iqs620a_coil.bin"; + + keys { + compatible = "azoteq,iqs620a-keys"; + + linux,keycodes = <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <KEY_MUTE>; + + hall-switch-north { + linux,code = <SW_DOCK>; + }; + + hall-switch-south { + linux,code = <SW_TABLET_MODE>; + }; }; + }; }; - | @@ -144,36 +135,36 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - iqs624@44 { - compatible = "azoteq,iqs624"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - - keys { - compatible = "azoteq,iqs624-keys"; - - linux,keycodes = <BTN_0>, - <0>, - <BTN_1>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <0>, - <KEY_VOLUMEUP>, - <KEY_VOLUMEDOWN>; - }; + #address-cells = <1>; + #size-cells = <0>; + + iqs624@44 { + compatible = "azoteq,iqs624"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + keys { + compatible = "azoteq,iqs624-keys"; + + linux,keycodes = <BTN_0>, + <0>, + <BTN_1>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <0>, + <KEY_VOLUMEUP>, + <KEY_VOLUMEDOWN>; }; + }; }; ... diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml index 768390b92682..0e1d43c96fb9 100644 --- a/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml @@ -18,6 +18,7 @@ properties: compatible: items: - enum: + - mediatek,mt6893-scpsys - mediatek,mt8167-scpsys - mediatek,mt8173-scpsys - mediatek,mt8183-scpsys diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml index 8bd1abfc44d9..b613da83dca4 100644 --- a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml +++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml @@ -76,12 +76,6 @@ additionalProperties: false examples: - | - ocelot_clock: ocelot-clock { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <125000000>; - }; - spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml index 59a630025f52..37fbb953ea12 100644 --- a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml +++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml @@ -48,29 +48,18 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - ec: embedded-controller@43 { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ntxec>; - - compatible = "netronix,ntxec"; - reg = <0x43>; - system-power-controller; - interrupt-parent = <&gpio4>; - interrupts = <11 IRQ_TYPE_EDGE_FALLING>; - #pwm-cells = <2>; - }; - }; - - backlight { - compatible = "pwm-backlight"; - pwms = <&ec 0 50000>; - power-supply = <&backlight_regulator>; - }; - - backlight_regulator: regulator-dummy { - compatible = "regulator-fixed"; - regulator-name = "backlight"; + #address-cells = <1>; + #size-cells = <0>; + + ec: embedded-controller@43 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ntxec>; + + compatible = "netronix,ntxec"; + reg = <0x43>; + system-power-controller; + interrupt-parent = <&gpio4>; + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; + #pwm-cells = <2>; + }; }; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml index 534cf03f36bb..47611c2a982c 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml @@ -99,29 +99,29 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - - pmic: pmic@30 { - compatible = "rohm,bd9571mwv"; - reg = <0x30>; - interrupt-parent = <&gpio2>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - gpio-controller; - #gpio-cells = <2>; - rohm,ddr-backup-power = <0xf>; - rohm,rstbmode-pulse; - - regulators { - dvfs: dvfs { - regulator-name = "dvfs"; - regulator-min-microvolt = <750000>; - regulator-max-microvolt = <1030000>; - regulator-boot-on; - regulator-always-on; - }; - }; - }; + #address-cells = <1>; + #size-cells = <0>; + + pmic: pmic@30 { + compatible = "rohm,bd9571mwv"; + reg = <0x30>; + interrupt-parent = <&gpio2>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + rohm,ddr-backup-power = <0xf>; + rohm,rstbmode-pulse; + + regulators { + dvfs: dvfs { + regulator-name = "dvfs"; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <1030000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml index efee3de0d9ad..0e06570483ae 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml @@ -4,19 +4,21 @@ $id: http://devicetree.org/schemas/mfd/rohm,bd96801-pmic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ROHM BD96801 Scalable Power Management Integrated Circuit +title: ROHM BD96801/BD96805 Scalable Power Management Integrated Circuit maintainers: - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> description: - BD96801 is an automotive grade single-chip power management IC. - It integrates 4 buck converters and 3 LDOs with safety features like + BD96801 and BD96805 are automotive grade, single-chip power management ICs. + They both integrate 4 buck converters and 3 LDOs with safety features like over-/under voltage and over current detection and a watchdog. properties: compatible: - const: rohm,bd96801 + enum: + - rohm,bd96801 + - rohm,bd96805 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml new file mode 100644 index 000000000000..6cbea796d12f --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rohm,bd96802-pmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD96802 / BD96806 Scalable Power Management Integrated Circuit + +maintainers: + - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> + +description: | + BD96802Qxx-C and BD96806 are automotive grade configurable Power Management + Integrated Circuits supporting Functional Safety features for application + processors, SoCs and FPGAs + +properties: + compatible: + enum: + - rohm,bd96802 + - rohm,bd96806 + + reg: + maxItems: 1 + + interrupts: + description: + The PMIC provides intb and errb IRQ lines. The errb IRQ line is used + for fatal IRQs which will cause the PMIC to shut down power outputs. + In many systems this will shut down the SoC contolling the PMIC and + connecting/handling the errb can be omitted. However, there are cases + where the SoC is not powered by the PMIC or has a short time backup + energy to handle shutdown of critical hardware. In that case it may be + useful to connect the errb and handle errb events. + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - enum: [intb, errb] + - const: errb + + regulators: + $ref: ../regulator/rohm,bd96802-regulator.yaml + description: + List of child nodes that specify the regulators. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/leds/common.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + pmic: pmic@62 { + reg = <0x62>; + compatible = "rohm,bd96802"; + interrupt-parent = <&gpio1>; + interrupts = <29 IRQ_TYPE_LEVEL_LOW>, <6 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "intb", "errb"; + + regulators { + buck1 { + regulator-name = "buck1"; + regulator-ramp-delay = <1250>; + /* 0.5V min INITIAL - 150 mV tune */ + regulator-min-microvolt = <350000>; + /* 3.3V + 150mV tune */ + regulator-max-microvolt = <3450000>; + + /* These can be set only when PMIC is in STBY */ + rohm,initial-voltage-microvolt = <500000>; + regulator-ov-error-microvolt = <230000>; + regulator-uv-error-microvolt = <230000>; + regulator-temp-protection-kelvin = <1>; + regulator-temp-warn-kelvin = <0>; + }; + buck2 { + regulator-name = "buck2"; + regulator-min-microvolt = <350000>; + regulator-max-microvolt = <3450000>; + + rohm,initial-voltage-microvolt = <3000000>; + regulator-ov-error-microvolt = <18000>; + regulator-uv-error-microvolt = <18000>; + regulator-temp-protection-kelvin = <1>; + regulator-temp-warn-kelvin = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml index ac5d0c149796..d6b9e2914796 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - samsung,s2mpg10-pmic - samsung,s2mps11-pmic - samsung,s2mps13-pmic - samsung,s2mps14-pmic @@ -58,11 +59,12 @@ properties: reset (setting buck voltages to default values). type: boolean + system-power-controller: true + wakeup-source: true required: - compatible - - reg - regulators additionalProperties: false @@ -72,6 +74,28 @@ allOf: properties: compatible: contains: + const: samsung,s2mpg10-pmic + then: + properties: + reg: false + samsung,s2mps11-acokb-ground: false + samsung,s2mps11-wrstbi-ground: false + + oneOf: + - required: [interrupts] + - required: [interrupts-extended] + + else: + properties: + system-power-controller: false + + required: + - reg + + - if: + properties: + compatible: + contains: const: samsung,s2mps11-pmic then: properties: diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index d41308856408..4eabafb8079d 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml @@ -21,7 +21,12 @@ maintainers: properties: compatible: - const: st,stm32-lptimer + oneOf: + - items: + - const: st,stm32mp25-lptimer + - const: st,stm32-lptimer + - items: + - const: st,stm32-lptimer reg: maxItems: 1 @@ -48,13 +53,21 @@ properties: minItems: 1 maxItems: 2 + power-domains: + maxItems: 1 + pwm: type: object additionalProperties: false properties: compatible: - const: st,stm32-pwm-lp + oneOf: + - items: + - const: st,stm32mp25-pwm-lp + - const: st,stm32-pwm-lp + - items: + - const: st,stm32-pwm-lp "#pwm-cells": const: 3 @@ -69,7 +82,12 @@ properties: properties: compatible: - const: st,stm32-lptimer-counter + oneOf: + - items: + - const: st,stm32mp25-lptimer-counter + - const: st,stm32-lptimer-counter + - items: + - const: st,stm32-lptimer-counter required: - compatible @@ -80,7 +98,12 @@ properties: properties: compatible: - const: st,stm32-lptimer-timer + oneOf: + - items: + - const: st,stm32mp25-lptimer-timer + - const: st,stm32-lptimer-timer + - items: + - const: st,stm32-lptimer-timer required: - compatible @@ -92,13 +115,18 @@ patternProperties: properties: compatible: - const: st,stm32-lptimer-trigger + oneOf: + - items: + - const: st,stm32mp25-lptimer-trigger + - const: st,stm32-lptimer-trigger + - items: + - const: st,stm32-lptimer-trigger reg: description: Identify trigger hardware block. items: minimum: 0 - maximum: 2 + maximum: 4 required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index c6bbb19c3e3e..27672adeb1fe 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -84,6 +84,7 @@ select: - mediatek,mt2701-pctl-a-syscfg - mediatek,mt2712-pctl-a-syscfg - mediatek,mt6397-pctl-pmic-syscfg + - mediatek,mt7988-topmisc - mediatek,mt8135-pctl-a-syscfg - mediatek,mt8135-pctl-b-syscfg - mediatek,mt8173-pctl-a-syscfg @@ -98,6 +99,8 @@ select: - mstar,msc313-pmsleep - nuvoton,ma35d1-sys - nuvoton,wpcm450-shm + - qcom,apq8064-mmss-sfpb + - qcom,apq8064-sps-sic - rockchip,px30-qos - rockchip,rk3036-qos - rockchip,rk3066-qos @@ -187,9 +190,11 @@ properties: - mediatek,mt2701-pctl-a-syscfg - mediatek,mt2712-pctl-a-syscfg - mediatek,mt6397-pctl-pmic-syscfg + - mediatek,mt7988-topmisc - mediatek,mt8135-pctl-a-syscfg - mediatek,mt8135-pctl-b-syscfg - mediatek,mt8173-pctl-a-syscfg + - mediatek,mt8365-infracfg-nao - mediatek,mt8365-syscfg - microchip,lan966x-cpu-syscon - microchip,mpfs-sysreg-scb @@ -201,6 +206,8 @@ properties: - mstar,msc313-pmsleep - nuvoton,ma35d1-sys - nuvoton,wpcm450-shm + - qcom,apq8064-mmss-sfpb + - qcom,apq8064-sps-sic - rockchip,px30-qos - rockchip,rk3036-qos - rockchip,rk3066-qos diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml index 3f7661bdd202..45f015d63df1 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -316,106 +316,106 @@ additionalProperties: false examples: - | - i2c { - #address-cells = <1>; - #size-cells = <0>; - - pmic@30 { - compatible = "x-powers,axp152"; - reg = <0x30>; - interrupts = <0>; - interrupt-controller; - #interrupt-cells = <1>; - }; - }; + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@30 { + compatible = "x-powers,axp152"; + reg = <0x30>; + interrupts = <0>; + interrupt-controller; + #interrupt-cells = <1>; + }; + }; - | - #include <dt-bindings/interrupt-controller/irq.h> - - i2c { - #address-cells = <1>; - #size-cells = <0>; - - pmic@34 { - compatible = "x-powers,axp209"; - reg = <0x34>; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <1>; - - ac_power_supply: ac-power { - compatible = "x-powers,axp202-ac-power-supply"; - }; - - axp_adc: adc { - compatible = "x-powers,axp209-adc"; - #io-channel-cells = <1>; - }; - - axp_gpio: gpio { - compatible = "x-powers,axp209-gpio"; - gpio-controller; - #gpio-cells = <2>; - - gpio0-adc-pin { - pins = "GPIO0"; - function = "adc"; - }; - }; - - battery_power_supply: battery-power { - compatible = "x-powers,axp209-battery-power-supply"; - }; - - regulators { - /* Default work frequency for buck regulators */ - x-powers,dcdc-freq = <1500>; - - reg_dcdc2: dcdc2 { - regulator-always-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1450000>; - regulator-name = "vdd-cpu"; - }; - - reg_dcdc3: dcdc3 { - regulator-always-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1400000>; - regulator-name = "vdd-int-dll"; - }; - - reg_ldo1: ldo1 { - /* LDO1 is a fixed output regulator */ - regulator-always-on; - regulator-min-microvolt = <1300000>; - regulator-max-microvolt = <1300000>; - regulator-name = "vdd-rtc"; - }; - - reg_ldo2: ldo2 { - regulator-always-on; - regulator-min-microvolt = <3000000>; - regulator-max-microvolt = <3000000>; - regulator-name = "avcc"; - }; - - reg_ldo3: ldo3 { - regulator-name = "ldo3"; - }; - - reg_ldo4: ldo4 { - regulator-name = "ldo4"; - }; - - reg_ldo5: ldo5 { - regulator-name = "ldo5"; - }; - }; - - usb_power_supply: usb-power { - compatible = "x-powers,axp202-usb-power-supply"; - }; - }; - }; + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + ac_power_supply: ac-power { + compatible = "x-powers,axp202-ac-power-supply"; + }; + + axp_adc: adc { + compatible = "x-powers,axp209-adc"; + #io-channel-cells = <1>; + }; + + axp_gpio: gpio { + compatible = "x-powers,axp209-gpio"; + gpio-controller; + #gpio-cells = <2>; + + gpio0-adc-pin { + pins = "GPIO0"; + function = "adc"; + }; + }; + + battery_power_supply: battery-power { + compatible = "x-powers,axp209-battery-power-supply"; + }; + + regulators { + /* Default work frequency for buck regulators */ + x-powers,dcdc-freq = <1500>; + + reg_dcdc2: dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1450000>; + regulator-name = "vdd-cpu"; + }; + + reg_dcdc3: dcdc3 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-name = "vdd-int-dll"; + }; + + reg_ldo1: ldo1 { + /* LDO1 is a fixed output regulator */ + regulator-always-on; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-rtc"; + }; + + reg_ldo2: ldo2 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "avcc"; + }; + + reg_ldo3: ldo3 { + regulator-name = "ldo3"; + }; + + reg_ldo4: ldo4 { + regulator-name = "ldo4"; + }; + + reg_ldo5: ldo5 { + regulator-name = "ldo5"; + }; + }; + + usb_power_supply: usb-power { + compatible = "x-powers,axp202-usb-power-supply"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml b/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml new file mode 100644 index 000000000000..480a5c87859d --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/fsl,vf610-nfc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale's NAND flash controller (NFC) + +description: + This variant of the Freescale NAND flash controller (NFC) can be found on + Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70. + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +properties: + compatible: + enum: + - fsl,vf610-nfc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: nfc + +patternProperties: + "^nand@[a-f0-9]$": + type: object + $ref: raw-nand-chip.yaml + + properties: + compatible: + const: fsl,vf610-nfc-nandcs + + reg: + const: 0 + + nand-ecc-strength: + enum: [24, 32] + + nand-ecc-step-size: + const: 2048 + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: nand-controller.yaml + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/vf610-clock.h> + + nand-controller@400e0000 { + compatible = "fsl,vf610-nfc"; + reg = <0x400e0000 0x4000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks VF610_CLK_NFC>; + clock-names = "nfc"; + assigned-clocks = <&clks VF610_CLK_NFC>; + assigned-clock-rates = <33000000>; + + nand@0 { + compatible = "fsl,vf610-nfc-nandcs"; + reg = <0>; + nand-bus-width = <8>; + nand-ecc-mode = "hw"; + nand-ecc-strength = <32>; + nand-ecc-step-size = <2048>; + nand-on-flash-bbt; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml b/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml new file mode 100644 index 000000000000..a09e92e416c4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/loongson,ls1b-nand-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 NAND Controller + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +description: + The Loongson-1 NAND controller abstracts all supported operations, + meaning it does not support low-level access to raw NAND flash chips. + Moreover, the controller is paired with the DMA engine to perform + READ and PROGRAM functions. + +allOf: + - $ref: nand-controller.yaml + +properties: + compatible: + oneOf: + - enum: + - loongson,ls1b-nand-controller + - loongson,ls1c-nand-controller + - items: + - enum: + - loongson,ls1a-nand-controller + - const: loongson,ls1b-nand-controller + + reg: + maxItems: 2 + + reg-names: + items: + - const: nand + - const: nand-dma + + dmas: + maxItems: 1 + + dma-names: + const: rxtx + +required: + - compatible + - reg + - reg-names + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + nand-controller@1fe78000 { + compatible = "loongson,ls1b-nand-controller"; + reg = <0x1fe78000 0x24>, <0x1fe78040 0x4>; + reg-names = "nand", "nand-dma"; + dmas = <&dma 0>; + dma-names = "rxtx"; + #address-cells = <1>; + #size-cells = <0>; + + nand@0 { + reg = <0>; + label = "ls1x-nand"; + nand-use-soft-ecc-engine; + nand-ecc-algo = "hamming"; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml index 35b4206ea918..5511389960f0 100644 --- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml @@ -11,12 +11,18 @@ maintainers: properties: compatible: - enum: - - qcom,ipq806x-nand - - qcom,ipq4019-nand - - qcom,ipq6018-nand - - qcom,ipq8074-nand - - qcom,sdx55-nand + oneOf: + - items: + - enum: + - qcom,sdx75-nand + - const: qcom,sdx55-nand + - items: + - enum: + - qcom,ipq806x-nand + - qcom,ipq4019-nand + - qcom,ipq6018-nand + - qcom,ipq8074-nand + - qcom,sdx55-nand reg: maxItems: 1 @@ -100,6 +106,18 @@ allOf: compatible: contains: enum: + - qcom,sdx75-nand + + then: + properties: + iommus: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: - qcom,ipq4019-nand - qcom,ipq6018-nand - qcom,ipq8074-nand diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt deleted file mode 100644 index 7db5e6e609df..000000000000 --- a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt +++ /dev/null @@ -1,59 +0,0 @@ -Freescale's NAND flash controller (NFC) - -This variant of the Freescale NAND flash controller (NFC) can be found on -Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70. - -Required properties: -- compatible: Should be set to "fsl,vf610-nfc". -- reg: address range of the NFC. -- interrupts: interrupt of the NFC. -- #address-cells: shall be set to 1. Encode the nand CS. -- #size-cells : shall be set to 0. -- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>; -- assigned-clock-rates: The NAND bus timing is derived from this clock - rate and should not exceed maximum timing for any NAND memory chip - in a board stuffing. Typical NAND memory timings derived from this - clock are found in the SoC hardware reference manual. Furthermore, - there might be restrictions on maximum rates when using hardware ECC. - -- #address-cells, #size-cells : Must be present if the device has sub-nodes - representing partitions. - -Required children nodes: -Children nodes represent the available nand chips. Currently the driver can -only handle one NAND chip. - -Required properties: -- compatible: Should be set to "fsl,vf610-nfc-cs". -- nand-bus-width: see nand-controller.yaml -- nand-ecc-mode: see nand-controller.yaml - -Required properties for hardware ECC: -- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand-controller.yaml) -- nand-ecc-step-size: step size equals page size, currently only 2k pages are - supported -- nand-on-flash-bbt: see nand-controller.yaml - -Example: - - nfc: nand@400e0000 { - compatible = "fsl,vf610-nfc"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x400e0000 0x4000>; - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks VF610_CLK_NFC>; - clock-names = "nfc"; - assigned-clocks = <&clks VF610_CLK_NFC>; - assigned-clock-rates = <33000000>; - - nand@0 { - compatible = "fsl,vf610-nfc-nandcs"; - reg = <0>; - nand-bus-width = <8>; - nand-ecc-mode = "hw"; - nand-ecc-strength = <32>; - nand-ecc-step-size = <2048>; - nand-on-flash-bbt; - }; - }; diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml index c8775f9cb071..c0852be04f6d 100644 --- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml @@ -17,6 +17,10 @@ description: | implements its root ports. But the ATU found on most DesignWare PCIe host bridges is absent. + On systems derived from T602x, the PHY registers are in a region + separate from the port registers. In that case, there is one PHY + register range per port register range. + All root ports share a single ECAM space, but separate GPIOs are used to take the PCI devices on those ports out of reset. Therefore the standard "reset-gpios" and "max-link-speed" properties appear on @@ -30,16 +34,18 @@ description: | properties: compatible: - items: - - enum: - - apple,t8103-pcie - - apple,t8112-pcie - - apple,t6000-pcie - - const: apple,pcie + oneOf: + - items: + - enum: + - apple,t8103-pcie + - apple,t8112-pcie + - apple,t6000-pcie + - const: apple,pcie + - const: apple,t6020-pcie reg: minItems: 3 - maxItems: 6 + maxItems: 10 reg-names: minItems: 3 @@ -50,6 +56,10 @@ properties: - const: port1 - const: port2 - const: port3 + - const: phy0 + - const: phy1 + - const: phy2 + - const: phy3 ranges: minItems: 2 @@ -98,6 +108,15 @@ allOf: maxItems: 5 interrupts: maxItems: 3 + - if: + properties: + compatible: + contains: + const: apple,t6020-pcie + then: + properties: + reg-names: + minItems: 10 examples: - | diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index 29f0e1eb5096..c4f9674e8695 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -186,49 +186,48 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> scb { - #address-cells = <2>; - #size-cells = <1>; - pcie0: pcie@7d500000 { - compatible = "brcm,bcm2711-pcie"; - reg = <0x0 0x7d500000 0x9310>; - device_type = "pci"; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "pcie", "msi"; - interrupt-map-mask = <0x0 0x0 0x0 0x7>; - interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH - 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH - 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH - 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; - - msi-parent = <&pcie0>; - msi-controller; - ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>; - dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>, - <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>; - brcm,enable-ssc; - brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>; - - /* PCIe bridge, Root Port */ - pci@0,0 { - #address-cells = <3>; - #size-cells = <2>; - reg = <0x0 0x0 0x0 0x0 0x0>; - compatible = "pciclass,0604"; - device_type = "pci"; - vpcie3v3-supply = <&vreg7>; - ranges; - - /* PCIe endpoint */ - pci-ep@0,0 { - assigned-addresses = - <0x82010000 0x0 0xf8000000 0x6 0x00000000 0x0 0x2000>; - reg = <0x0 0x0 0x0 0x0 0x0>; - compatible = "pci14e4,1688"; - }; - }; + #address-cells = <2>; + #size-cells = <1>; + pcie0: pcie@7d500000 { + compatible = "brcm,bcm2711-pcie"; + reg = <0x0 0x7d500000 0x9310>; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie", "msi"; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH + 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH + 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH + 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; + + msi-parent = <&pcie0>; + msi-controller; + ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>; + dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>, + <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>; + brcm,enable-ssc; + brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>; + + /* PCIe bridge, Root Port */ + pci@0,0 { + #address-cells = <3>; + #size-cells = <2>; + reg = <0x0 0x0 0x0 0x0 0x0>; + compatible = "pciclass,0604"; + device_type = "pci"; + vpcie3v3-supply = <&vreg7>; + ranges; + + /* PCIe endpoint */ + pci-ep@0,0 { + assigned-addresses = <0x82010000 0x0 0xf8000000 0x6 0x00000000 0x0 0x2000>; + reg = <0x0 0x0 0x0 0x0 0x0>; + compatible = "pci14e4,1688"; + }; }; + }; }; diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml index 98651ab22103..8735293962ee 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml @@ -37,14 +37,14 @@ examples: #size-cells = <2>; pcie-ep@fc000000 { - compatible = "cdns,cdns-pcie-ep"; - reg = <0x0 0xfc000000 0x0 0x01000000>, - <0x0 0x80000000 0x0 0x40000000>; - reg-names = "reg", "mem"; - cdns,max-outbound-regions = <16>; - max-functions = /bits/ 8 <8>; - phys = <&pcie_phy0>; - phy-names = "pcie-phy"; + compatible = "cdns,cdns-pcie-ep"; + reg = <0x0 0xfc000000 0x0 0x01000000>, + <0x0 0x80000000 0x0 0x40000000>; + reg-names = "reg", "mem"; + cdns,max-outbound-regions = <16>; + max-functions = /bits/ 8 <8>; + phys = <&pcie_phy0>; + phy-names = "pcie-phy"; }; }; ... diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml index 730e63fd7669..b19f61ae72fb 100644 --- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml @@ -53,17 +53,17 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interrupt-controller/irq.h> pcie-ep@37000000 { - compatible = "intel,keembay-pcie-ep"; - reg = <0x37000000 0x00001000>, - <0x37100000 0x00001000>, - <0x37300000 0x00001000>, - <0x36000000 0x01000000>, - <0x37800000 0x00000200>; - reg-names = "dbi", "dbi2", "atu", "addr_space", "apb"; - interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 108 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "pcie", "pcie_ev", "pcie_err", "pcie_mem_access"; - num-lanes = <2>; + compatible = "intel,keembay-pcie-ep"; + reg = <0x37000000 0x00001000>, + <0x37100000 0x00001000>, + <0x37300000 0x00001000>, + <0x36000000 0x01000000>, + <0x37800000 0x00000200>; + reg-names = "dbi", "dbi2", "atu", "addr_space", "apb"; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 108 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie", "pcie_ev", "pcie_err", "pcie_mem_access"; + num-lanes = <2>; }; diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml index 1fd557504b10..dd71e3d6bf94 100644 --- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml @@ -75,23 +75,23 @@ examples: #define KEEM_BAY_A53_PCIE #define KEEM_BAY_A53_AUX_PCIE pcie@37000000 { - compatible = "intel,keembay-pcie"; - reg = <0x37000000 0x00001000>, - <0x37300000 0x00001000>, - <0x36e00000 0x00200000>, - <0x37800000 0x00000200>; - reg-names = "dbi", "atu", "config", "apb"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x02000000 0 0x36000000 0x36000000 0 0x00e00000>; - interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "pcie", "pcie_ev", "pcie_err"; - clocks = <&scmi_clk KEEM_BAY_A53_PCIE>, - <&scmi_clk KEEM_BAY_A53_AUX_PCIE>; - clock-names = "master", "aux"; - reset-gpios = <&pca2 9 GPIO_ACTIVE_LOW>; - num-lanes = <2>; + compatible = "intel,keembay-pcie"; + reg = <0x37000000 0x00001000>, + <0x37300000 0x00001000>, + <0x36e00000 0x00200000>, + <0x37800000 0x00000200>; + reg-names = "dbi", "atu", "config", "apb"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x02000000 0 0x36000000 0x36000000 0 0x00e00000>; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie", "pcie_ev", "pcie_err"; + clocks = <&scmi_clk KEEM_BAY_A53_PCIE>, + <&scmi_clk KEEM_BAY_A53_AUX_PCIE>; + clock-names = "master", "aux"; + reset-gpios = <&pca2 9 GPIO_ACTIVE_LOW>; + num-lanes = <2>; }; diff --git a/Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml b/Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml new file mode 100644 index 000000000000..f3ba9230ce2a --- /dev/null +++ b/Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/marvell,armada8k-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Armada 7K/8K PCIe interface + +maintainers: + - Thomas Petazzoni <thomas.petazzoni@bootlin.com> + +description: + This PCIe host controller is based on the Synopsys DesignWare PCIe IP. + +select: + properties: + compatible: + contains: + enum: + - marvell,armada8k-pcie + required: + - compatible + +allOf: + - $ref: snps,dw-pcie.yaml# + +properties: + compatible: + items: + - enum: + - marvell,armada8k-pcie + - const: snps,dw-pcie + + reg: + maxItems: 2 + + reg-names: + items: + - const: ctrl + - const: config + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + items: + - const: core + - const: reg + + interrupts: + maxItems: 1 + + msi-parent: + maxItems: 1 + + phys: + minItems: 1 + maxItems: 4 + + phy-names: + minItems: 1 + maxItems: 4 + + marvell,reset-gpio: + maxItems: 1 + deprecated: true + +required: + - interrupt-map + - clocks + - msi-parent + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + pcie@f2600000 { + compatible = "marvell,armada8k-pcie", "snps,dw-pcie"; + reg = <0xf2600000 0x10000>, <0xf6f00000 0x80000>; + reg-names = "ctrl", "config"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + dma-coherent; + msi-parent = <&gic_v2m0>; + + ranges = <0x81000000 0 0xf9000000 0xf9000000 0 0x10000>, /* downstream I/O */ + <0x82000000 0 0xf6000000 0xf6000000 0 0xf00000>; /* non-prefetchable memory */ + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + num-lanes = <1>; + clocks = <&cpm_syscon0 1 13>; + }; +... diff --git a/Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml b/Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml new file mode 100644 index 000000000000..7be695320ddf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml @@ -0,0 +1,277 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/marvell,kirkwood-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell EBU PCIe interfaces + +maintainers: + - Thomas Petazzoni <thomas.petazzoni@bootlin.com> + - Pali Rohár <pali@kernel.org> + +allOf: + - $ref: /schemas/pci/pci-host-bridge.yaml# + +properties: + compatible: + enum: + - marvell,armada-370-pcie + - marvell,armada-xp-pcie + - marvell,dove-pcie + - marvell,kirkwood-pcie + + ranges: + description: > + The ranges describing the MMIO registers have the following layout: + + 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s + + where: + + * r is a 32-bits value that gives the offset of the MMIO registers of + this PCIe interface, from the base of the internal registers. + + * s is a 32-bits value that give the size of this MMIO registers area. + This range entry translates the '0x82000000 0 r' PCI address into the + 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part of the internal + register window (as identified by MBUS_ID(0xf0, 0x01)). + + The ranges describing the MBus windows have the following layout: + + 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0 + + where: + + * t is the type of the MBus window (as defined by the standard PCI DT + bindings), 1 for I/O and 2 for memory. + + * s is the PCI slot that corresponds to this PCIe interface + + * w is the 'target ID' value for the MBus window + + * a the 'attribute' value for the MBus window. + + Since the location and size of the different MBus windows is not fixed in + hardware, and only determined in runtime, those ranges cover the full first + 4 GB of the physical address space, and do not translate into a valid CPU + address. + + msi-parent: + maxItems: 1 + +patternProperties: + '^pcie@': + type: object + allOf: + - $ref: /schemas/pci/pci-bus-common.yaml# + - $ref: /schemas/pci/pci-device.yaml# + unevaluatedProperties: false + + properties: + clocks: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: intx + - const: error + + reset-delay-us: + default: 100000 + description: todo + + marvell,pcie-port: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + description: todo + + marvell,pcie-lane: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + description: todo + + interrupt-controller: + type: object + additionalProperties: false + + properties: + interrupt-controller: true + + '#interrupt-cells': + const: 1 + + required: + - assigned-addresses + - clocks + - interrupt-map + - marvell,pcie-port + +unevaluatedProperties: false + +examples: + - | + #define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16)) + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie@f001000000000000 { + compatible = "marvell,armada-xp-pcie"; + device_type = "pci"; + + #address-cells = <3>; + #size-cells = <2>; + + bus-range = <0x00 0xff>; + msi-parent = <&mpic>; + + ranges = + <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ + 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ + 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ + 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ + 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ + 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */ + 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */ + 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */ + 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */ + 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */ + 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ + 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ + 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */ + 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */ + 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */ + 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */ + 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */ + 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */ + + 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ + 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */ + 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */ + 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */ + 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */ + 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */ + 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */ + 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */ + + 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */ + 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */ + + 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */ + 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>; + + pcie@1,0 { + device_type = "pci"; + assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; + reg = <0x0800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 + 0x81000000 0 0 0x81000000 0x1 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 58>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <0>; + num-lanes = <1>; + /* low-active PERST# reset on GPIO 25 */ + reset-gpios = <&gpio0 25 1>; + /* wait 20ms for device settle after reset deassertion */ + reset-delay-us = <20000>; + clocks = <&gateclk 5>; + }; + + pcie@2,0 { + device_type = "pci"; + assigned-addresses = <0x82001000 0 0x44000 0 0x2000>; + reg = <0x1000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 + 0x81000000 0 0 0x81000000 0x2 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 59>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <1>; + num-lanes = <1>; + clocks = <&gateclk 6>; + }; + + pcie@3,0 { + device_type = "pci"; + assigned-addresses = <0x82001800 0 0x48000 0 0x2000>; + reg = <0x1800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0 + 0x81000000 0 0 0x81000000 0x3 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 60>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <2>; + num-lanes = <1>; + clocks = <&gateclk 7>; + }; + + pcie@4,0 { + device_type = "pci"; + assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>; + reg = <0x2000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0 + 0x81000000 0 0 0x81000000 0x4 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 61>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <3>; + num-lanes = <1>; + clocks = <&gateclk 8>; + }; + + pcie@5,0 { + device_type = "pci"; + assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; + reg = <0x2800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0 + 0x81000000 0 0 0x81000000 0x5 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 62>; + marvell,pcie-port = <1>; + marvell,pcie-lane = <0>; + num-lanes = <1>; + clocks = <&gateclk 9>; + }; + + pcie@6,0 { + device_type = "pci"; + assigned-addresses = <0x82003000 0 0x84000 0 0x2000>; + reg = <0x3000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0 + 0x81000000 0 0 0x81000000 0x6 0 1 0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 63>; + marvell,pcie-port = <1>; + marvell,pcie-lane = <1>; + num-lanes = <1>; + clocks = <&gateclk 10>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index 103574d18dbc..47b0bad690d5 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -50,7 +50,7 @@ properties: items: pattern: '^fic[0-3]$' - dma-coherent: true + dma-noncoherent: true ranges: minItems: 1 @@ -65,33 +65,33 @@ unevaluatedProperties: false examples: - | soc { - #address-cells = <2>; + #address-cells = <2>; + #size-cells = <2>; + pcie0: pcie@2030000000 { + compatible = "microchip,pcie-host-1.0"; + reg = <0x0 0x70000000 0x0 0x08000000>, + <0x0 0x43008000 0x0 0x00002000>, + <0x0 0x4300a000 0x0 0x00002000>; + reg-names = "cfg", "bridge", "ctrl"; + device_type = "pci"; + #address-cells = <3>; #size-cells = <2>; - pcie0: pcie@2030000000 { - compatible = "microchip,pcie-host-1.0"; - reg = <0x0 0x70000000 0x0 0x08000000>, - <0x0 0x43008000 0x0 0x00002000>, - <0x0 0x4300a000 0x0 0x00002000>; - reg-names = "cfg", "bridge", "ctrl"; - device_type = "pci"; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - interrupts = <119>; - interrupt-map-mask = <0x0 0x0 0x0 0x7>; - interrupt-map = <0 0 0 1 &pcie_intc0 0>, - <0 0 0 2 &pcie_intc0 1>, - <0 0 0 3 &pcie_intc0 2>, - <0 0 0 4 &pcie_intc0 3>; - interrupt-parent = <&plic0>; - msi-parent = <&pcie0>; - msi-controller; - bus-range = <0x00 0x7f>; - ranges = <0x03000000 0x0 0x78000000 0x0 0x78000000 0x0 0x04000000>; - pcie_intc0: interrupt-controller { - #address-cells = <0>; - #interrupt-cells = <1>; - interrupt-controller; - }; + #interrupt-cells = <1>; + interrupts = <119>; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0 0 0 1 &pcie_intc0 0>, + <0 0 0 2 &pcie_intc0 1>, + <0 0 0 3 &pcie_intc0 2>, + <0 0 0 4 &pcie_intc0 3>; + interrupt-parent = <&plic0>; + msi-parent = <&pcie0>; + msi-controller; + bus-range = <0x00 0x7f>; + ranges = <0x03000000 0x0 0x78000000 0x0 0x78000000 0x0 0x04000000>; + pcie_intc0: interrupt-controller { + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; }; + }; }; diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt deleted file mode 100644 index 6d022a9d36ee..000000000000 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ /dev/null @@ -1,310 +0,0 @@ -* Marvell EBU PCIe interfaces - -Mandatory properties: - -- compatible: one of the following values: - marvell,armada-370-pcie - marvell,armada-xp-pcie - marvell,dove-pcie - marvell,kirkwood-pcie -- #address-cells, set to <3> -- #size-cells, set to <2> -- #interrupt-cells, set to <1> -- bus-range: PCI bus numbers covered -- device_type, set to "pci" -- ranges: ranges describing the MMIO registers to control the PCIe - interfaces, and ranges describing the MBus windows needed to access - the memory and I/O regions of each PCIe interface. -- msi-parent: Link to the hardware entity that serves as the Message - Signaled Interrupt controller for this PCI controller. - -The ranges describing the MMIO registers have the following layout: - - 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s - -where: - - * r is a 32-bits value that gives the offset of the MMIO - registers of this PCIe interface, from the base of the internal - registers. - - * s is a 32-bits value that give the size of this MMIO - registers area. This range entry translates the '0x82000000 0 r' PCI - address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part - of the internal register window (as identified by MBUS_ID(0xf0, - 0x01)). - -The ranges describing the MBus windows have the following layout: - - 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0 - -where: - - * t is the type of the MBus window (as defined by the standard PCI DT - bindings), 1 for I/O and 2 for memory. - - * s is the PCI slot that corresponds to this PCIe interface - - * w is the 'target ID' value for the MBus window - - * a the 'attribute' value for the MBus window. - -Since the location and size of the different MBus windows is not fixed in -hardware, and only determined in runtime, those ranges cover the full first -4 GB of the physical address space, and do not translate into a valid CPU -address. - -In addition, the device tree node must have sub-nodes describing each -PCIe interface, having the following mandatory properties: - -- reg: used only for interrupt mapping, so only the first four bytes - are used to refer to the correct bus number and device number. -- assigned-addresses: reference to the MMIO registers used to control - this PCIe interface. -- clocks: the clock associated to this PCIe interface -- marvell,pcie-port: the physical PCIe port number -- status: either "disabled" or "okay" -- device_type, set to "pci" -- #address-cells, set to <3> -- #size-cells, set to <2> -- #interrupt-cells, set to <1> -- ranges, translating the MBus windows ranges of the parent node into - standard PCI addresses. -- interrupt-map-mask and interrupt-map, standard PCI properties to - define the mapping of the PCIe interface to interrupt numbers. - -and the following optional properties: -- marvell,pcie-lane: the physical PCIe lane number, for ports having - multiple lanes. If this property is not found, we assume that the - value is 0. -- num-lanes: number of SerDes PCIe lanes for this link (1 or 4) -- reset-gpios: optional GPIO to PERST# -- reset-delay-us: delay in us to wait after reset de-assertion, if not - specified will default to 100ms, as required by the PCIe specification. -- interrupt-names: list of interrupt names, supported are: - - "intx" - interrupt line triggered by one of the legacy interrupt -- interrupts or interrupts-extended: List of the interrupt sources which - corresponding to the "interrupt-names". If non-empty then also additional - 'interrupt-controller' subnode must be defined. - -Example: - -pcie-controller { - compatible = "marvell,armada-xp-pcie"; - device_type = "pci"; - - #address-cells = <3>; - #size-cells = <2>; - - bus-range = <0x00 0xff>; - msi-parent = <&mpic>; - - ranges = - <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ - 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ - 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ - 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ - 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ - 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */ - 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */ - 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */ - 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */ - 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */ - 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ - 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ - 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */ - 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */ - 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */ - 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */ - 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */ - 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */ - - 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ - 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */ - 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */ - 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */ - 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */ - 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */ - 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */ - 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */ - - 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */ - 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */ - - 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */ - 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>; - - pcie@1,0 { - device_type = "pci"; - assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; - reg = <0x0800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 - 0x81000000 0 0 0x81000000 0x1 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 58>; - marvell,pcie-port = <0>; - marvell,pcie-lane = <0>; - num-lanes = <1>; - /* low-active PERST# reset on GPIO 25 */ - reset-gpios = <&gpio0 25 1>; - /* wait 20ms for device settle after reset deassertion */ - reset-delay-us = <20000>; - clocks = <&gateclk 5>; - }; - - pcie@2,0 { - device_type = "pci"; - assigned-addresses = <0x82001000 0 0x44000 0 0x2000>; - reg = <0x1000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 - 0x81000000 0 0 0x81000000 0x2 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 59>; - marvell,pcie-port = <0>; - marvell,pcie-lane = <1>; - num-lanes = <1>; - clocks = <&gateclk 6>; - }; - - pcie@3,0 { - device_type = "pci"; - assigned-addresses = <0x82001800 0 0x48000 0 0x2000>; - reg = <0x1800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0 - 0x81000000 0 0 0x81000000 0x3 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 60>; - marvell,pcie-port = <0>; - marvell,pcie-lane = <2>; - num-lanes = <1>; - clocks = <&gateclk 7>; - }; - - pcie@4,0 { - device_type = "pci"; - assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>; - reg = <0x2000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0 - 0x81000000 0 0 0x81000000 0x4 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 61>; - marvell,pcie-port = <0>; - marvell,pcie-lane = <3>; - num-lanes = <1>; - clocks = <&gateclk 8>; - }; - - pcie@5,0 { - device_type = "pci"; - assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; - reg = <0x2800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0 - 0x81000000 0 0 0x81000000 0x5 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 62>; - marvell,pcie-port = <1>; - marvell,pcie-lane = <0>; - num-lanes = <1>; - clocks = <&gateclk 9>; - }; - - pcie@6,0 { - device_type = "pci"; - assigned-addresses = <0x82003000 0 0x84000 0 0x2000>; - reg = <0x3000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0 - 0x81000000 0 0 0x81000000 0x6 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 63>; - marvell,pcie-port = <1>; - marvell,pcie-lane = <1>; - num-lanes = <1>; - clocks = <&gateclk 10>; - }; - - pcie@7,0 { - device_type = "pci"; - assigned-addresses = <0x82003800 0 0x88000 0 0x2000>; - reg = <0x3800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0 - 0x81000000 0 0 0x81000000 0x7 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 64>; - marvell,pcie-port = <1>; - marvell,pcie-lane = <2>; - num-lanes = <1>; - clocks = <&gateclk 11>; - }; - - pcie@8,0 { - device_type = "pci"; - assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>; - reg = <0x4000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0 - 0x81000000 0 0 0x81000000 0x8 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 65>; - marvell,pcie-port = <1>; - marvell,pcie-lane = <3>; - num-lanes = <1>; - clocks = <&gateclk 12>; - }; - - pcie@9,0 { - device_type = "pci"; - assigned-addresses = <0x82004800 0 0x42000 0 0x2000>; - reg = <0x4800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0 - 0x81000000 0 0 0x81000000 0x9 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 99>; - marvell,pcie-port = <2>; - marvell,pcie-lane = <0>; - num-lanes = <1>; - clocks = <&gateclk 26>; - }; - - pcie@a,0 { - device_type = "pci"; - assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; - reg = <0x5000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0 - 0x81000000 0 0 0x81000000 0xa 0 1 0>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &mpic 103>; - marvell,pcie-port = <3>; - marvell,pcie-lane = <0>; - num-lanes = <1>; - clocks = <&gateclk 27>; - }; -}; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml index a24fb8307d29..6d6052a2748f 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml @@ -74,7 +74,7 @@ properties: 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. + that is being used as PERST input signal. phys: minItems: 1 diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt deleted file mode 100644 index ff25a134befa..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt +++ /dev/null @@ -1,48 +0,0 @@ -* Marvell Armada 7K/8K PCIe interface - -This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in snps,dw-pcie.yaml. - -Required properties: -- compatible: "marvell,armada8k-pcie" -- reg: must contain two register regions - - the control register region - - the config space region -- reg-names: - - "ctrl" for the control register region - - "config" for the config space region -- interrupts: Interrupt specifier for the PCIe controller -- clocks: reference to the PCIe controller clocks -- clock-names: mandatory if there is a second clock, in this case the - name must be "core" for the first clock and "reg" for the second - one - -Optional properties: -- phys: phandle(s) to PHY node(s) following the generic PHY bindings. - Either 1, 2 or 4 PHYs might be needed depending on the number of - PCIe lanes. -- phy-names: names of the PHYs corresponding to the number of lanes. - Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for - 2 PHYs. - -Example: - - pcie@f2600000 { - compatible = "marvell,armada8k-pcie", "snps,dw-pcie"; - reg = <0 0xf2600000 0 0x10000>, <0 0xf6f00000 0 0x80000>; - reg-names = "ctrl", "config"; - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - device_type = "pci"; - dma-coherent; - - bus-range = <0 0xff>; - ranges = <0x81000000 0 0xf9000000 0 0xf9000000 0 0x10000 /* downstream I/O */ - 0x82000000 0 0xf6000000 0 0xf6000000 0 0xf00000>; /* non-prefetchable memory */ - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; - num-lanes = <1>; - clocks = <&cpm_syscon0 1 13>; - }; diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt deleted file mode 100644 index 0def586fdcdf..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt +++ /dev/null @@ -1,171 +0,0 @@ -This document describes the generic device tree binding for describing the -relationship between PCI(e) devices and IOMMU(s). - -Each PCI(e) device under a root complex is uniquely identified by its Requester -ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and -Function number. - -For the purpose of this document, when treated as a numeric value, a RID is -formatted such that: - -* Bits [15:8] are the Bus number. -* Bits [7:3] are the Device number. -* Bits [2:0] are the Function number. -* Any other bits required for padding must be zero. - -IOMMUs may distinguish PCI devices through sideband data derived from the -Requester ID. While a given PCI device can only master through one IOMMU, a -root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per -bus). - -The generic 'iommus' property is insufficient to describe this relationship, -and a mechanism is required to map from a PCI device to its IOMMU and sideband -data. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - - -PCI root complex -================ - -Optional properties -------------------- - -- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier - data. - - The property is an arbitrary number of tuples of - (rid-base,iommu,iommu-base,length). - - Any RID r in the interval [rid-base, rid-base + length) is associated with - the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base). - -- iommu-map-mask: A mask to be applied to each Requester ID prior to being - mapped to an IOMMU specifier per the iommu-map property. - - -Example (1) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - iommu: iommu@a { - reg = <0xa 0x1>; - compatible = "vendor,some-iommu"; - #iommu-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the IOMMU is the RID, - * identity-mapped. - */ - iommu-map = <0x0 &iommu 0x0 0x10000>; - }; -}; - - -Example (2) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - iommu: iommu@a { - reg = <0xa 0x1>; - compatible = "vendor,some-iommu"; - #iommu-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the IOMMU is the RID with the - * function bits masked out. - */ - iommu-map = <0x0 &iommu 0x0 0x10000>; - iommu-map-mask = <0xfff8>; - }; -}; - - -Example (3) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - iommu: iommu@a { - reg = <0xa 0x1>; - compatible = "vendor,some-iommu"; - #iommu-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the IOMMU is the RID, - * but the high bits of the bus number are flipped. - */ - iommu-map = <0x0000 &iommu 0x8000 0x8000>, - <0x8000 &iommu 0x0000 0x8000>; - }; -}; - - -Example (4) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - iommu_a: iommu@a { - reg = <0xa 0x1>; - compatible = "vendor,some-iommu"; - #iommu-cells = <1>; - }; - - iommu_b: iommu@b { - reg = <0xb 0x1>; - compatible = "vendor,some-iommu"; - #iommu-cells = <1>; - }; - - iommu_c: iommu@c { - reg = <0xc 0x1>; - compatible = "vendor,some-iommu"; - #iommu-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * Devices with bus number 0-127 are mastered via IOMMU - * a, with sideband data being RID[14:0]. - * Devices with bus number 128-255 are mastered via - * IOMMU b, with sideband data being RID[14:0]. - * No devices master via IOMMU c. - */ - iommu-map = <0x0000 &iommu_a 0x0000 0x8000>, - <0x8000 &iommu_b 0x0000 0x8000>; - }; -}; diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt deleted file mode 100644 index b73d839657b6..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-msi.txt +++ /dev/null @@ -1,220 +0,0 @@ -This document describes the generic device tree binding for describing the -relationship between PCI devices and MSI controllers. - -Each PCI device under a root complex is uniquely identified by its Requester ID -(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and -Function number. - -For the purpose of this document, when treated as a numeric value, a RID is -formatted such that: - -* Bits [15:8] are the Bus number. -* Bits [7:3] are the Device number. -* Bits [2:0] are the Function number. -* Any other bits required for padding must be zero. - -MSIs may be distinguished in part through the use of sideband data accompanying -writes. In the case of PCI devices, this sideband data may be derived from the -Requester ID. A mechanism is required to associate a device with both the MSI -controllers it can address, and the sideband data that will be associated with -its writes to those controllers. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - - -PCI root complex -================ - -Optional properties -------------------- - -- msi-map: Maps a Requester ID to an MSI controller and associated - msi-specifier data. The property is an arbitrary number of tuples of - (rid-base,msi-controller,msi-base,length), where: - - * rid-base is a single cell describing the first RID matched by the entry. - - * msi-controller is a single phandle to an MSI controller - - * msi-base is an msi-specifier describing the msi-specifier produced for the - first RID matched by the entry. - - * length is a single cell describing how many consecutive RIDs are matched - following the rid-base. - - Any RID r in the interval [rid-base, rid-base + length) is associated with - the listed msi-controller, with the msi-specifier (r - rid-base + msi-base). - -- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped - to an msi-specifier per the msi-map property. - -- msi-parent: Describes the MSI parent of the root complex itself. Where - the root complex and MSI controller do not pass sideband data with MSI - writes, this property may be used to describe the MSI controller(s) - used by PCI devices under the root complex, if defined as such in the - binding for the root complex. - - -Example (1) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - msi: msi-controller@a { - reg = <0xa 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the MSI controller is - * the RID, identity-mapped. - */ - msi-map = <0x0 &msi_a 0x0 0x10000>, - }; -}; - - -Example (2) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - msi: msi-controller@a { - reg = <0xa 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the MSI controller is - * the RID, masked to only the device and function bits. - */ - msi-map = <0x0 &msi_a 0x0 0x100>, - msi-map-mask = <0xff> - }; -}; - - -Example (3) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - msi: msi-controller@a { - reg = <0xa 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the MSI controller is - * the RID, but the high bit of the bus number is - * ignored. - */ - msi-map = <0x0000 &msi 0x0000 0x8000>, - <0x8000 &msi 0x0000 0x8000>; - }; -}; - - -Example (4) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - msi: msi-controller@a { - reg = <0xa 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to the MSI controller is - * the RID, but the high bit of the bus number is - * negated. - */ - msi-map = <0x0000 &msi 0x8000 0x8000>, - <0x8000 &msi 0x0000 0x8000>; - }; -}; - - -Example (5) -=========== - -/ { - #address-cells = <1>; - #size-cells = <1>; - - msi_a: msi-controller@a { - reg = <0xa 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - msi_b: msi-controller@b { - reg = <0xb 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - msi_c: msi-controller@c { - reg = <0xc 0x1>; - compatible = "vendor,some-controller"; - msi-controller; - #msi-cells = <1>; - }; - - pci: pci@f { - reg = <0xf 0x1>; - compatible = "vendor,pcie-root-complex"; - device_type = "pci"; - - /* - * The sideband data provided to MSI controller a is the - * RID, but the high bit of the bus number is negated. - * The sideband data provided to MSI controller b is the - * RID, identity-mapped. - * MSI controller c is not addressable. - */ - msi-map = <0x0000 &msi_a 0x8000 0x08000>, - <0x8000 &msi_a 0x0000 0x08000>, - <0x0000 &msi_b 0x0000 0x10000>; - }; -}; diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt deleted file mode 100644 index 6a8f2874a24d..000000000000 --- a/Documentation/devicetree/bindings/pci/pci.txt +++ /dev/null @@ -1,84 +0,0 @@ -PCI bus bridges have standardized Device Tree bindings: - -PCI Bus Binding to: IEEE Std 1275-1994 -https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf - -And for the interrupt mapping part: - -Open Firmware Recommended Practice: Interrupt Mapping -https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf - -Additionally to the properties specified in the above standards a host bridge -driver implementation may support the following properties: - -- linux,pci-domain: - If present this property assigns a fixed PCI domain number to a host bridge, - otherwise an unstable (across boots) unique number will be assigned. - It is required to either not set this property at all or set it for all - host bridges in the system, otherwise potentially conflicting domain numbers - may be assigned to root buses behind different host bridges. The domain - number for each host bridge in the system must be unique. -- max-link-speed: - If present this property specifies PCI gen for link capability. Host - drivers could add this as a strategy to avoid unnecessary operation for - unsupported link speed, for instance, trying to do training for - unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2' - for gen2, and '1' for gen1. Any other values are invalid. -- reset-gpios: - If present this property specifies PERST# GPIO. Host drivers can parse the - GPIO and apply fundamental reset to endpoints. -- supports-clkreq: - If present this property specifies that CLKREQ signal routing exists from - root port to downstream device and host bridge drivers can do programming - which depends on CLKREQ signal existence. For example, programming root port - not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal. - -PCI-PCI Bridge properties -------------------------- - -PCIe root ports and switch ports may be described explicitly in the device -tree, as children of the host bridge node. Even though those devices are -discoverable by probing, it might be necessary to describe properties that -aren't provided by standard PCIe capabilities. - -Required properties: - -- reg: - Identifies the PCI-PCI bridge. As defined in the IEEE Std 1275-1994 - document, it is a five-cell address encoded as (phys.hi phys.mid - phys.lo size.hi size.lo). phys.hi should contain the device's BDF as - 0b00000000 bbbbbbbb dddddfff 00000000. The other cells should be zero. - - The bus number is defined by firmware, through the standard bridge - configuration mechanism. If this port is a switch port, then firmware - allocates the bus number and writes it into the Secondary Bus Number - register of the bridge directly above this port. Otherwise, the bus - number of a root port is the first number in the bus-range property, - defaulting to zero. - - If firmware leaves the ARI Forwarding Enable bit set in the bridge - above this port, then phys.hi contains the 8-bit function number as - 0b00000000 bbbbbbbb ffffffff 00000000. Note that the PCIe specification - recommends that firmware only leaves ARI enabled when it knows that the - OS is ARI-aware. - -Optional properties: - -- external-facing: - When present, the port is external-facing. All bridges and endpoints - downstream of this port are external to the machine. The OS can, for - example, use this information to identify devices that cannot be - trusted with relaxed DMA protection, as users could easily attach - malicious devices to this port. - -Example: - -pcie@10000000 { - compatible = "pci-host-ecam-generic"; - ... - pcie@0008 { - /* Root port 00:01.0 is external-facing */ - reg = <0x00000800 0 0 0 0>; - external-facing; - }; -}; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml index efde49d1bef8..e3fa232da2ca 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml @@ -45,9 +45,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -57,6 +58,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: maxItems: 1 @@ -129,7 +131,8 @@ examples: <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", @@ -137,7 +140,8 @@ examples: "msi4", "msi5", "msi6", - "msi7"; + "msi7", + "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc GIC_SPI 434 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml index 76cb9fbfd476..ff508f592a1a 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml @@ -54,9 +54,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -66,6 +67,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: maxItems: 1 @@ -149,9 +151,10 @@ examples: <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", "msi3", - "msi4", "msi5", "msi6", "msi7"; + "msi4", "msi5", "msi6", "msi7", "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 0 0 434 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml index baf1813ec0ac..331fc25d7a17 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml @@ -49,9 +49,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -61,6 +62,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: maxItems: 1 @@ -136,7 +138,8 @@ examples: <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", @@ -144,7 +147,8 @@ examples: "msi4", "msi5", "msi6", - "msi7"; + "msi7", + "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml index 9d569644fda9..a604f2a79de3 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml @@ -49,9 +49,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -61,6 +62,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: maxItems: 1 @@ -128,9 +130,10 @@ examples: <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", "msi3", - "msi4", "msi5", "msi6", "msi7"; + "msi4", "msi5", "msi6", "msi7", "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml index 4d060bce6f9d..af4dae68d508 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml @@ -61,9 +61,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -73,6 +74,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: maxItems: 1 @@ -143,9 +145,10 @@ examples: <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", "msi3", - "msi4", "msi5", "msi6", "msi7"; + "msi4", "msi5", "msi6", "msi7", "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml index 2a4cc41fc710..dde3079adbb3 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml @@ -51,9 +51,10 @@ properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -63,6 +64,7 @@ properties: - const: msi5 - const: msi6 - const: msi7 + - const: global resets: maxItems: 1 @@ -132,9 +134,10 @@ examples: <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi0", "msi1", "msi2", "msi3", - "msi4", "msi5", "msi6", "msi7"; + "msi4", "msi5", "msi6", "msi7", "global"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index 8f628939209e..0e1808105a81 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -21,6 +21,7 @@ properties: - qcom,pcie-apq8064 - qcom,pcie-apq8084 - qcom,pcie-ipq4019 + - qcom,pcie-ipq5018 - qcom,pcie-ipq6018 - qcom,pcie-ipq8064 - qcom,pcie-ipq8064-v2 @@ -168,6 +169,7 @@ allOf: compatible: contains: enum: + - qcom,pcie-ipq5018 - qcom,pcie-ipq6018 - qcom,pcie-ipq8074-gen3 - qcom,pcie-ipq9574 @@ -175,14 +177,16 @@ allOf: properties: reg: minItems: 5 - maxItems: 5 + maxItems: 6 reg-names: + minItems: 5 items: - const: dbi # DesignWare PCIe registers - const: elbi # External local bus interface registers - const: atu # ATU address space - const: parf # Qualcomm specific registers - const: config # PCIe configuration space + - const: mhi # MHI registers - if: properties: @@ -327,6 +331,53 @@ allOf: compatible: contains: enum: + - qcom,pcie-ipq5018 + then: + properties: + clocks: + minItems: 6 + maxItems: 6 + clock-names: + items: + - const: iface # PCIe to SysNOC BIU clock + - const: axi_m # AXI Master clock + - const: axi_s # AXI Slave clock + - const: ahb # AHB clock + - const: aux # Auxiliary clock + - const: axi_bridge # AXI bridge clock + resets: + minItems: 8 + maxItems: 8 + reset-names: + items: + - const: pipe # PIPE reset + - const: sleep # Sleep reset + - const: sticky # Core sticky reset + - const: axi_m # AXI master reset + - const: axi_s # AXI slave reset + - const: ahb # AHB reset + - const: axi_m_sticky # AXI master sticky reset + - const: axi_s_sticky # AXI slave sticky reset + interrupts: + minItems: 9 + maxItems: 9 + interrupt-names: + items: + - const: msi0 + - const: msi1 + - const: msi2 + - const: msi3 + - const: msi4 + - const: msi5 + - const: msi6 + - const: msi7 + - const: global + + - if: + properties: + compatible: + contains: + enum: - qcom,pcie-msm8996 then: properties: @@ -562,6 +613,7 @@ allOf: enum: - qcom,pcie-apq8064 - qcom,pcie-ipq4019 + - qcom,pcie-ipq5018 - qcom,pcie-ipq8064 - qcom,pcie-ipq8064v2 - qcom,pcie-ipq8074 @@ -589,7 +641,11 @@ allOf: compatible: contains: enum: + - qcom,pcie-ipq6018 + - qcom,pcie-ipq8074 + - qcom,pcie-ipq8074-gen3 - qcom,pcie-msm8996 + - qcom,pcie-msm8998 - qcom,pcie-sdm845 then: oneOf: @@ -602,8 +658,9 @@ allOf: - properties: interrupts: minItems: 8 - maxItems: 8 + maxItems: 9 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -613,6 +670,7 @@ allOf: - const: msi5 - const: msi6 - const: msi7 + - const: global - if: properties: @@ -622,11 +680,8 @@ allOf: - qcom,pcie-apq8064 - qcom,pcie-apq8084 - qcom,pcie-ipq4019 - - qcom,pcie-ipq6018 - qcom,pcie-ipq8064 - qcom,pcie-ipq8064-v2 - - qcom,pcie-ipq8074 - - qcom,pcie-ipq8074-gen3 - qcom,pcie-qcs404 then: properties: diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml index 32a3b7665ff5..6b91581c30ae 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml @@ -73,21 +73,21 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/power/r8a774c0-sysc.h> - pcie0_ep: pcie-ep@fe000000 { - compatible = "renesas,r8a774c0-pcie-ep", - "renesas,rcar-gen3-pcie-ep"; - reg = <0xfe000000 0x80000>, - <0xfe100000 0x100000>, - <0xfe200000 0x200000>, - <0x30000000 0x8000000>, - <0x38000000 0x8000000>; - reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3"; - interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; - resets = <&cpg 319>; - power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>; - clocks = <&cpg CPG_MOD 319>; - clock-names = "pcie"; - max-functions = /bits/ 8 <1>; + pcie0_ep: pcie-ep@fe000000 { + compatible = "renesas,r8a774c0-pcie-ep", + "renesas,rcar-gen3-pcie-ep"; + reg = <0xfe000000 0x80000>, + <0xfe100000 0x100000>, + <0xfe200000 0x200000>, + <0x30000000 0x8000000>, + <0x38000000 0x8000000>; + reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3"; + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + resets = <&cpg 319>; + power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>; + clocks = <&cpg CPG_MOD 319>; + clock-names = "pcie"; + max-functions = /bits/ 8 <1>; }; diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml index 666f013e3af8..7896576920aa 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml @@ -113,27 +113,27 @@ examples: pcie: pcie@fe000000 { compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2"; reg = <0 0xfe000000 0 0x80000>; - #address-cells = <3>; - #size-cells = <2>; - bus-range = <0x00 0xff>; - device_type = "pci"; - ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000>, - <0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000>, - <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>, - <0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; - dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>, - <0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>; - interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>; - clock-names = "pcie", "pcie_bus"; - power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; - resets = <&cpg 319>; - vpcie3v3-supply = <&pcie_3v3>; - vpcie12v-supply = <&pcie_12v>; - }; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x00 0xff>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000>, + <0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000>, + <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>, + <0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>, + <0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>; + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 319>; + vpcie3v3-supply = <&pcie_3v3>; + vpcie12v-supply = <&pcie_12v>; + }; }; diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml index cc9adfc7611c..fde9b87508b3 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml @@ -65,7 +65,11 @@ properties: tx_cpl_timeout, cor_err_sent, nf_err_sent, f_err_sent, cor_err_rx, nf_err_rx, f_err_rx, radm_qoverflow - description: - eDMA write channel 0 interrupt + If the matching interrupt name is "msi", then this is the combined + MSI line interrupt, which is to support MSI interrupts output to GIC + controller via GIC SPI interrupt instead of GIC ITS interrupt. + If the matching interrupt name is "dma0", then this is the eDMA write + channel 0 interrupt. - description: eDMA write channel 1 interrupt - description: @@ -81,7 +85,9 @@ properties: - const: msg - const: legacy - const: err - - const: dma0 + - enum: + - msi + - dma0 - const: dma1 - const: dma2 - const: dma3 diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml index 550d8a684af3..6c6d828ce964 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml @@ -16,16 +16,14 @@ description: |+ PCIe IP and thus inherits all the common properties defined in snps,dw-pcie.yaml. -allOf: - - $ref: /schemas/pci/snps,dw-pcie.yaml# - - $ref: /schemas/pci/rockchip-dw-pcie-common.yaml# - properties: compatible: oneOf: - const: rockchip,rk3568-pcie - items: - enum: + - rockchip,rk3562-pcie + - rockchip,rk3576-pcie - rockchip,rk3588-pcie - const: rockchip,rk3568-pcie @@ -71,8 +69,58 @@ properties: vpcie3v3-supply: true -required: - - msi-map +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + - $ref: /schemas/pci/rockchip-dw-pcie-common.yaml# + - if: + not: + properties: + compatible: + contains: + enum: + - rockchip,rk3562-pcie + - rockchip,rk3576-pcie + then: + required: + - msi-map + + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3562-pcie + - rockchip,rk3576-pcie + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + interrupt-names: + items: + - const: sys + - const: pmc + - const: msg + - const: legacy + - const: err + - const: msi + else: + properties: + interrupts: + minItems: 5 + interrupt-names: + minItems: 5 + items: + - const: sys + - const: pmc + - const: msg + - const: legacy + - const: err + - const: dma0 + - const: dma1 + - const: dma2 + - const: dma3 + unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml index 844fc7142302..d35ff807936b 100644 --- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml @@ -81,10 +81,10 @@ unevaluatedProperties: false examples: - | + #include <dt-bindings/clock/sifive-fu740-prci.h> bus { #address-cells = <2>; #size-cells = <2>; - #include <dt-bindings/clock/sifive-fu740-prci.h> pcie@e00000000 { compatible = "sifive,fu740-pcie"; diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml index dc05761c5cf9..34594972d8db 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml @@ -115,7 +115,7 @@ properties: above for new bindings. oneOf: - description: See native 'dbi' clock for details - enum: [ pcie, pcie_apb_sys, aclk_dbi ] + enum: [ pcie, pcie_apb_sys, aclk_dbi, reg ] - description: See native 'mstr/slv' clock for details enum: [ pcie_bus, pcie_inbound_axi, pcie_aclk, aclk_mst, aclk_slv ] - description: See native 'pipe' clock for details @@ -201,6 +201,7 @@ properties: oneOf: - pattern: '^pcie(-?phy[0-9]*)?$' - pattern: '^p2u-[0-7]$' + - pattern: '^cp[01]-pcie[0-2]-x[124](-lane[0-3])?-phy$' # marvell,armada8k-pcie reset-gpio: deprecated: true diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index 1117a86fb6f7..69e82f438f58 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -105,6 +105,8 @@ properties: Vendor-specific CSR names. Consider using the generic names above for new bindings. oneOf: + - description: See native 'dbi' CSR region for details. + enum: [ ctrl ] - description: See native 'elbi/app' CSR region for details. enum: [ apb, mgmt, link, ulreg, appl ] - description: See native 'atu' CSR region for details. @@ -117,7 +119,7 @@ properties: const: slcr allOf: - contains: - const: dbi + enum: [ dbi, ctrl ] - contains: const: config diff --git a/Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml b/Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml new file mode 100644 index 000000000000..38cac88f17bf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/v3,v360epc-pci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: V3 Semiconductor V360 EPC PCI bridge + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: + This bridge is found in the ARM Integrator/AP (Application Platform) + +allOf: + - $ref: /schemas/pci/pci-host-bridge.yaml# + +properties: + compatible: + items: + - const: arm,integrator-ap-pci + - const: v3,v360epc-pci + + reg: + items: + - description: V3 host bridge controller + - description: Configuration space + + clocks: + maxItems: 1 + + dma-ranges: + maxItems: 2 + description: + The inbound ranges must be aligned to a 1MB boundary, and may be 1MB, 2MB, + 4MB, 8MB, 16MB, 32MB, 64MB, 128MB, 256MB, 512MB, 1GB or 2GB in size. The + memory should be marked as pre-fetchable. + + interrupts: + description: Bus Error IRQ + maxItems: 1 + + ranges: + description: + The non-prefetchable and prefetchable memory windows must each be exactly + 256MB (0x10000000) in size. The prefetchable memory window must be + immediately adjacent to the non-prefetchable memory window. + +required: + - compatible + - reg + - clocks + - dma-ranges + - "#interrupt-cells" + - interrupt-map + - interrupt-map-mask + +unevaluatedProperties: false + +examples: + - | + pci@62000000 { + compatible = "arm,integrator-ap-pci", "v3,v360epc-pci"; + #interrupt-cells = <1>; + #size-cells = <2>; + #address-cells = <3>; + reg = <0x62000000 0x10000>, <0x61000000 0x01000000>; + device_type = "pci"; + interrupt-parent = <&pic>; + interrupts = <17>; /* Bus error IRQ */ + clocks = <&pciclk>; + ranges = <0x01000000 0 0x00000000 0x60000000 0 0x01000000>, /* 16 MiB @ LB 60000000 */ + <0x02000000 0 0x40000000 0x40000000 0 0x10000000>, /* 256 MiB @ LB 40000000 1:1 */ + <0x42000000 0 0x50000000 0x50000000 0 0x10000000>; /* 256 MiB @ LB 50000000 1:1 */ + dma-ranges = <0x02000000 0 0x20000000 0x20000000 0 0x20000000>, /* EBI: 512 MB @ LB 20000000 1:1 */ + <0x02000000 0 0x80000000 0x80000000 0 0x40000000>; /* CM alias: 1GB @ LB 80000000 */ + interrupt-map-mask = <0xf800 0 0 0x7>; + interrupt-map = + /* IDSEL 9 */ + <0x4800 0 0 1 &pic 13>, /* INT A on slot 9 is irq 13 */ + <0x4800 0 0 2 &pic 14>, /* INT B on slot 9 is irq 14 */ + <0x4800 0 0 3 &pic 15>, /* INT C on slot 9 is irq 15 */ + <0x4800 0 0 4 &pic 16>, /* INT D on slot 9 is irq 16 */ + /* IDSEL 10 */ + <0x5000 0 0 1 &pic 14>, /* INT A on slot 10 is irq 14 */ + <0x5000 0 0 2 &pic 15>, /* INT B on slot 10 is irq 15 */ + <0x5000 0 0 3 &pic 16>, /* INT C on slot 10 is irq 16 */ + <0x5000 0 0 4 &pic 13>, /* INT D on slot 10 is irq 13 */ + /* IDSEL 11 */ + <0x5800 0 0 1 &pic 15>, /* INT A on slot 11 is irq 15 */ + <0x5800 0 0 2 &pic 16>, /* INT B on slot 11 is irq 16 */ + <0x5800 0 0 3 &pic 13>, /* INT C on slot 11 is irq 13 */ + <0x5800 0 0 4 &pic 14>, /* INT D on slot 11 is irq 14 */ + /* IDSEL 12 */ + <0x6000 0 0 1 &pic 16>, /* INT A on slot 12 is irq 16 */ + <0x6000 0 0 2 &pic 13>, /* INT B on slot 12 is irq 13 */ + <0x6000 0 0 3 &pic 14>, /* INT C on slot 12 is irq 14 */ + <0x6000 0 0 4 &pic 15>; /* INT D on slot 12 is irq 15 */ + }; +... diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt deleted file mode 100644 index 11063293f761..000000000000 --- a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt +++ /dev/null @@ -1,76 +0,0 @@ -V3 Semiconductor V360 EPC PCI bridge - -This bridge is found in the ARM Integrator/AP (Application Platform) - -Required properties: -- compatible: should be one of: - "v3,v360epc-pci" - "arm,integrator-ap-pci", "v3,v360epc-pci" -- reg: should contain two register areas: - first the base address of the V3 host bridge controller, 64KB - second the configuration area register space, 16MB -- interrupts: should contain a reference to the V3 error interrupt - as routed on the system. -- bus-range: see pci.txt -- ranges: this follows the standard PCI bindings in the IEEE Std - 1275-1994 (see pci.txt) with the following restriction: - - The non-prefetchable and prefetchable memory windows must - each be exactly 256MB (0x10000000) in size. - - The prefetchable memory window must be immediately adjacent - to the non-prefetcable memory window -- dma-ranges: three ranges for the inbound memory region. The ranges must - be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, - 64MB, 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked - as pre-fetchable. Two ranges are supported by the hardware. - -Integrator-specific required properties: -- syscon: should contain a link to the syscon device node, since - on the Integrator, some registers in the syscon are required to - operate the V3 host bridge. - -Example: - -pci: pciv3@62000000 { - compatible = "arm,integrator-ap-pci", "v3,v360epc-pci"; - #interrupt-cells = <1>; - #size-cells = <2>; - #address-cells = <3>; - reg = <0x62000000 0x10000>, <0x61000000 0x01000000>; - interrupt-parent = <&pic>; - interrupts = <17>; /* Bus error IRQ */ - clocks = <&pciclk>; - bus-range = <0x00 0xff>; - ranges = 0x01000000 0 0x00000000 /* I/O space @00000000 */ - 0x60000000 0 0x01000000 /* 16 MiB @ LB 60000000 */ - 0x02000000 0 0x40000000 /* non-prefectable memory @40000000 */ - 0x40000000 0 0x10000000 /* 256 MiB @ LB 40000000 1:1 */ - 0x42000000 0 0x50000000 /* prefetchable memory @50000000 */ - 0x50000000 0 0x10000000>; /* 256 MiB @ LB 50000000 1:1 */ - dma-ranges = <0x02000000 0 0x20000000 /* EBI memory space */ - 0x20000000 0 0x20000000 /* 512 MB @ LB 20000000 1:1 */ - 0x02000000 0 0x80000000 /* Core module alias memory */ - 0x80000000 0 0x40000000>; /* 1GB @ LB 80000000 */ - interrupt-map-mask = <0xf800 0 0 0x7>; - interrupt-map = < - /* IDSEL 9 */ - 0x4800 0 0 1 &pic 13 /* INT A on slot 9 is irq 13 */ - 0x4800 0 0 2 &pic 14 /* INT B on slot 9 is irq 14 */ - 0x4800 0 0 3 &pic 15 /* INT C on slot 9 is irq 15 */ - 0x4800 0 0 4 &pic 16 /* INT D on slot 9 is irq 16 */ - /* IDSEL 10 */ - 0x5000 0 0 1 &pic 14 /* INT A on slot 10 is irq 14 */ - 0x5000 0 0 2 &pic 15 /* INT B on slot 10 is irq 15 */ - 0x5000 0 0 3 &pic 16 /* INT C on slot 10 is irq 16 */ - 0x5000 0 0 4 &pic 13 /* INT D on slot 10 is irq 13 */ - /* IDSEL 11 */ - 0x5800 0 0 1 &pic 15 /* INT A on slot 11 is irq 15 */ - 0x5800 0 0 2 &pic 16 /* INT B on slot 11 is irq 16 */ - 0x5800 0 0 3 &pic 13 /* INT C on slot 11 is irq 13 */ - 0x5800 0 0 4 &pic 14 /* INT D on slot 11 is irq 14 */ - /* IDSEL 12 */ - 0x6000 0 0 1 &pic 16 /* INT A on slot 12 is irq 16 */ - 0x6000 0 0 2 &pic 13 /* INT B on slot 12 is irq 13 */ - 0x6000 0 0 3 &pic 14 /* INT C on slot 12 is irq 14 */ - 0x6000 0 0 4 &pic 15 /* INT D on slot 12 is irq 15 */ - >; -}; diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml index d674a24c8ccc..9823456addea 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -76,64 +76,62 @@ unevaluatedProperties: false examples: - | - versal { - #address-cells = <2>; - #size-cells = <2>; - cpm_pcie: pcie@fca10000 { - compatible = "xlnx,versal-cpm-host-1.00"; - 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_0 0>, - <0 0 0 2 &pcie_intc_0 1>, - <0 0 0 3 &pcie_intc_0 2>, - <0 0 0 4 &pcie_intc_0 3>; - bus-range = <0x00 0xff>; - ranges = <0x02000000 0x0 0xe0010000 0x0 0xe0010000 0x0 0x10000000>, - <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>; - msi-map = <0x0 &its_gic 0x0 0x10000>; - reg = <0x0 0xfca10000 0x0 0x1000>, - <0x6 0x00000000 0x0 0x10000000>; - reg-names = "cpm_slcr", "cfg"; - pcie_intc_0: interrupt-controller { - #address-cells = <0>; - #interrupt-cells = <1>; - 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; - }; - }; - + #address-cells = <2>; + #size-cells = <2>; + pcie@fca10000 { + compatible = "xlnx,versal-cpm-host-1.00"; + 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_0 0>, + <0 0 0 2 &pcie_intc_0 1>, + <0 0 0 3 &pcie_intc_0 2>, + <0 0 0 4 &pcie_intc_0 3>; + bus-range = <0x00 0xff>; + ranges = <0x02000000 0x0 0xe0010000 0x0 0xe0010000 0x0 0x10000000>, + <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>; + msi-map = <0x0 &its_gic 0x0 0x10000>; + reg = <0x0 0xfca10000 0x0 0x1000>, + <0x6 0x00000000 0x0 0x10000000>; + reg-names = "cpm_slcr", "cfg"; + pcie_intc_0: interrupt-controller { + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; + }; + }; + + 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/regulator/brcm,bcm59054.yaml b/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml new file mode 100644 index 000000000000..5b46d7fca05e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/brcm,bcm59054.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM59054 Power Management Unit regulators + +description: | + This is a part of device tree bindings for the BCM59054 power + management unit. + + See Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml for + additional information and example. + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +patternProperties: + "^(cam|sim|mmc)ldo[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(rf|sd|sdx|aud|mic|usb|vib|tcx)ldo$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(c|mm|v)sr$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(io|sd)sr[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^gpldo[1-3]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^lvldo[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +properties: + vbus: + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml b/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml new file mode 100644 index 000000000000..7a5e36394d21 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/brcm,bcm59056.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM59056 Power Management Unit regulators + +description: | + This is a part of device tree bindings for the BCM59056 power + management unit. + + See Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml for + additional information and example. + +maintainers: + - Artur Weber <aweber.kernel@gmail.com> + +patternProperties: + "^(cam|sim|mmc)ldo[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(rf|sd|sdx|aud|mic|usb|vib)ldo$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(c|m|v)sr$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^(io|sd)sr[1-2]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + "^gpldo[1-6]$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +properties: + vbus: + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml new file mode 100644 index 000000000000..671eaf1096d3 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/rohm,bd96802-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD96802 Power Management Integrated Circuit regulators + +maintainers: + - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> + +description: + This module is part of the ROHM BD96802 MFD device. For more details + see Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml. + + The regulator controller is represented as a sub-node of the PMIC node + on the device tree. + + Regulator nodes should be named to buck1 and buck2. + +patternProperties: + "^buck[1-2]$": + type: object + description: + Properties for single BUCK regulator. + $ref: regulator.yaml# + + properties: + rohm,initial-voltage-microvolt: + description: + Initial voltage for regulator. Voltage can be tuned +/-150 mV from + this value. NOTE, This can be modified via I2C only when PMIC is in + STBY state. + minimum: 500000 + maximum: 3300000 + + rohm,keep-on-stby: + description: + Keep the regulator powered when PMIC transitions to STBY state. + type: boolean + + unevaluatedProperties: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml index 56ff6386534d..5dcc2a32c080 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml @@ -16,6 +16,9 @@ description: properties: compatible: enum: + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-slpi-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8150-mpss-pas diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml index fd3423e6051b..6d09823153fc 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml @@ -15,16 +15,20 @@ description: properties: compatible: - enum: - - qcom,sar2130p-adsp-pas - - qcom,sm8350-adsp-pas - - qcom,sm8350-cdsp-pas - - qcom,sm8350-slpi-pas - - qcom,sm8350-mpss-pas - - qcom,sm8450-adsp-pas - - qcom,sm8450-cdsp-pas - - qcom,sm8450-mpss-pas - - qcom,sm8450-slpi-pas + oneOf: + - enum: + - qcom,sar2130p-adsp-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8350-mpss-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-mpss-pas + - qcom,sm8450-slpi-pas + - items: + - const: qcom,sc8280xp-slpi-pas + - const: qcom,sm8350-slpi-pas reg: maxItems: 1 @@ -61,14 +65,15 @@ allOf: - if: properties: compatible: - enum: - - qcom,sar2130p-adsp-pas - - qcom,sm8350-adsp-pas - - qcom,sm8350-cdsp-pas - - qcom,sm8350-slpi-pas - - qcom,sm8450-adsp-pas - - qcom,sm8450-cdsp-pas - - qcom,sm8450-slpi-pas + contains: + enum: + - qcom,sar2130p-adsp-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-slpi-pas then: properties: interrupts: @@ -102,12 +107,13 @@ allOf: - if: properties: compatible: - enum: - - qcom,sar2130p-adsp-pas - - qcom,sm8350-adsp-pas - - qcom,sm8350-slpi-pas - - qcom,sm8450-adsp-pas - - qcom,sm8450-slpi-pas + contains: + enum: + - qcom,sar2130p-adsp-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-slpi-pas then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 370af61d8f28..843679c557e7 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -139,6 +139,10 @@ properties: If defined, when remoteproc is probed, it loads the default firmware and starts the remote processor. + firmware-name: + maxItems: 1 + description: Default name of the remote processor firmware. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 6a49e8efc0f7..8dc81b1ca48e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -295,8 +295,6 @@ properties: - mps,mp5990 # Monolithic Power Systems Inc. digital step-down converter mp9941 - mps,mp9941 - # Monolithic Power Systems Inc. synchronous step-down converter mpq8785 - - mps,mpq8785 # Temperature sensor with integrated fan control - national,lm63 # Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor diff --git a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml index 8b7aa922249b..1d9f15ec6657 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml @@ -20,6 +20,7 @@ properties: items: - enum: - fsl,imx8dxl-sc-wdt + - fsl,imx8qm-sc-wdt - fsl,imx8qxp-sc-wdt - const: fsl,imx-sc-wdt diff --git a/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml b/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml new file mode 100644 index 000000000000..8f168a05b50c --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/nxp,s32g2-swt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Software Watchdog Timer (SWT) + +maintainers: + - Daniel Lezcano <daniel.lezcano@kernel.org> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + oneOf: + - const: nxp,s32g2-swt + - items: + - const: nxp,s32g3-swt + - const: nxp,s32g2-swt + + reg: + maxItems: 1 + + clocks: + items: + - description: Counter clock + - description: Module clock + - description: Register clock + + clock-names: + items: + - const: counter + - const: module + - const: register + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + watchdog@40100000 { + compatible = "nxp,s32g2-swt"; + reg = <0x40100000 0x1000>; + clocks = <&clks 0x3a>, <&clks 0x3b>, <&clks 0x3c>; + clock-names = "counter", "module", "register"; + timeout-sec = <10>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 3e0a8747a357..78874b90c88c 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -76,7 +76,9 @@ properties: - const: renesas,rcar-gen4-wdt # R-Car Gen4 - items: - - const: renesas,r9a09g047-wdt # RZ/G3E + - enum: + - renesas,r9a09g047-wdt # RZ/G3E + - renesas,r9a09g056-wdt # RZ/V2N - const: renesas,r9a09g057-wdt # RZ/V2H(P) - const: renesas,r9a09g057-wdt # RZ/V2H(P) diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml index d175ae968336..53fc64f5b56d 100644 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml @@ -25,6 +25,7 @@ properties: - samsung,exynos5420-wdt # for Exynos5420 - samsung,exynos7-wdt # for Exynos7 - samsung,exynos850-wdt # for Exynos850 + - samsung,exynos990-wdt # for Exynos990 - samsung,exynosautov9-wdt # for Exynosautov9 - samsung,exynosautov920-wdt # for Exynosautov920 - items: @@ -49,14 +50,14 @@ properties: samsung,cluster-index: $ref: /schemas/types.yaml#/definitions/uint32 description: - Index of CPU cluster on which watchdog is running (in case of Exynos850 - or Google gs101). + Index of CPU cluster on which watchdog is running (in case of Exynos850, + Exynos990 or Google gs101). samsung,syscon-phandle: $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to the PMU system controller node (in case of Exynos5250, - Exynos5420, Exynos7, Exynos850 and gs101). + Exynos5420, Exynos7, Exynos850, Exynos990 and gs101). required: - compatible @@ -77,6 +78,7 @@ allOf: - samsung,exynos5420-wdt - samsung,exynos7-wdt - samsung,exynos850-wdt + - samsung,exynos990-wdt - samsung,exynosautov9-wdt - samsung,exynosautov920-wdt then: @@ -89,6 +91,7 @@ allOf: enum: - google,gs101-wdt - samsung,exynos850-wdt + - samsung,exynos990-wdt - samsung,exynosautov9-wdt - samsung,exynosautov920-wdt then: @@ -102,7 +105,7 @@ allOf: - const: watchdog - const: watchdog_src samsung,cluster-index: - enum: [0, 1] + enum: [0, 1, 2] required: - samsung,cluster-index else: diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index 1efefd741c06..ef088e0f6917 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -28,6 +28,7 @@ properties: - rockchip,rk3328-wdt - rockchip,rk3368-wdt - rockchip,rk3399-wdt + - rockchip,rk3562-wdt - rockchip,rk3568-wdt - rockchip,rk3576-wdt - rockchip,rk3588-wdt diff --git a/Documentation/driver-api/cxl/access-coordinates.rst b/Documentation/driver-api/cxl/access-coordinates.rst deleted file mode 100644 index b07950ea30c9..000000000000 --- a/Documentation/driver-api/cxl/access-coordinates.rst +++ /dev/null @@ -1,91 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 -.. include:: <isonum.txt> - -================================== -CXL Access Coordinates Computation -================================== - -Shared Upstream Link Calculation -================================ -For certain CXL region construction with endpoints behind CXL switches (SW) or -Root Ports (RP), there is the possibility of the total bandwidth for all -the endpoints behind a switch being more than the switch upstream link. -A similar situation can occur within the host, upstream of the root ports. -The CXL driver performs an additional pass after all the targets have -arrived for a region in order to recalculate the bandwidths with possible -upstream link being a limiting factor in mind. - -The algorithm assumes the configuration is a symmetric topology as that -maximizes performance. When asymmetric topology is detected, the calculation -is aborted. An asymmetric topology is detected during topology walk where the -number of RPs detected as a grandparent is not equal to the number of devices -iterated in the same iteration loop. The assumption is made that subtle -asymmetry in properties does not happen and all paths to EPs are equal. - -There can be multiple switches under an RP. There can be multiple RPs under -a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory -Window Structure (CFMWS). - -An example hierarchy: - -> CFMWS 0 -> | -> _________|_________ -> | | -> ACPI0017-0 ACPI0017-1 -> GP0/HB0/ACPI0016-0 GP1/HB1/ACPI0016-1 -> | | | | -> RP0 RP1 RP2 RP3 -> | | | | -> SW 0 SW 1 SW 2 SW 3 -> | | | | | | | | -> EP0 EP1 EP2 EP3 EP4 EP5 EP6 EP7 - -Computation for the example hierarchy: - -Min (GP0 to CPU BW, - Min(SW 0 Upstream Link to RP0 BW, - Min(SW0SSLBIS for SW0DSP0 (EP0), EP0 DSLBIS, EP0 Upstream Link) + - Min(SW0SSLBIS for SW0DSP1 (EP1), EP1 DSLBIS, EP1 Upstream link)) + - Min(SW 1 Upstream Link to RP1 BW, - Min(SW1SSLBIS for SW1DSP0 (EP2), EP2 DSLBIS, EP2 Upstream Link) + - Min(SW1SSLBIS for SW1DSP1 (EP3), EP3 DSLBIS, EP3 Upstream link))) + -Min (GP1 to CPU BW, - Min(SW 2 Upstream Link to RP2 BW, - Min(SW2SSLBIS for SW2DSP0 (EP4), EP4 DSLBIS, EP4 Upstream Link) + - Min(SW2SSLBIS for SW2DSP1 (EP5), EP5 DSLBIS, EP5 Upstream link)) + - Min(SW 3 Upstream Link to RP3 BW, - Min(SW3SSLBIS for SW3DSP0 (EP6), EP6 DSLBIS, EP6 Upstream Link) + - Min(SW3SSLBIS for SW3DSP1 (EP7), EP7 DSLBIS, EP7 Upstream link)))) - -The calculation starts at cxl_region_shared_upstream_perf_update(). A xarray -is created to collect all the endpoint bandwidths via the -cxl_endpoint_gather_bandwidth() function. The min() of bandwidth from the -endpoint CDAT and the upstream link bandwidth is calculated. If the endpoint -has a CXL switch as a parent, then min() of calculated bandwidth and the -bandwidth from the SSLBIS for the switch downstream port that is associated -with the endpoint is calculated. The final bandwidth is stored in a -'struct cxl_perf_ctx' in the xarray indexed by a device pointer. If the -endpoint is direct attached to a root port (RP), the device pointer would be an -RP device. If the endpoint is behind a switch, the device pointer would be the -upstream device of the parent switch. - -At the next stage, the code walks through one or more switches if they exist -in the topology. For endpoints directly attached to RPs, this step is skipped. -If there is another switch upstream, the code takes the min() of the current -gathered bandwidth and the upstream link bandwidth. If there's a switch -upstream, then the SSLBIS of the upstream switch. - -Once the topology walk reaches the RP, whether it's direct attached endpoints -or walking through the switch(es), cxl_rp_gather_bandwidth() is called. At -this point all the bandwidths are aggregated per each host bridge, which is -also the index for the resulting xarray. - -The next step is to take the min() of the per host bridge bandwidth and the -bandwidth from the Generic Port (GP). The bandwidths for the GP is retrieved -via ACPI tables SRAT/HMAT. The min bandwidth are aggregated under the same -ACPI0017 device to form a new xarray. - -Finally, the cxl_region_update_bandwidth() is called and the aggregated -bandwidth from all the members of the last xarray is updated for the -access coordinates residing in the cxl region (cxlr) context. diff --git a/Documentation/driver-api/cxl/allocation/dax.rst b/Documentation/driver-api/cxl/allocation/dax.rst new file mode 100644 index 000000000000..c6f7a5da832f --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/dax.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========== +DAX Devices +=========== +CXL capacity exposed as a DAX device can be accessed directly via mmap. +Users may wish to use this interface mechanism to write their own userland +CXL allocator, or to managed shared or persistent memory regions across multiple +hosts. + +If the capacity is shared across hosts or persistent, appropriate flushing +mechanisms must be employed unless the region supports Snoop Back-Invalidate. + +Note that mappings must be aligned (size and base) to the dax device's base +alignment, which is typically 2MB - but maybe be configured larger. + +:: + + #include <stdio.h> + #include <stdlib.h> + #include <stdint.h> + #include <sys/mman.h> + #include <fcntl.h> + #include <unistd.h> + + #define DEVICE_PATH "/dev/dax0.0" // Replace DAX device path + #define DEVICE_SIZE (4ULL * 1024 * 1024 * 1024) // 4GB + + int main() { + int fd; + void* mapped_addr; + + /* Open the DAX device */ + fd = open(DEVICE_PATH, O_RDWR); + if (fd < 0) { + perror("open"); + return -1; + } + + /* Map the device into memory */ + mapped_addr = mmap(NULL, DEVICE_SIZE, PROT_READ | PROT_WRITE, + MAP_SHARED, fd, 0); + if (mapped_addr == MAP_FAILED) { + perror("mmap"); + close(fd); + return -1; + } + + printf("Mapped address: %p\n", mapped_addr); + + /* You can now access the device through the mapped address */ + uint64_t* ptr = (uint64_t*)mapped_addr; + *ptr = 0x1234567890abcdef; // Write a value to the device + printf("Value at address %p: 0x%016llx\n", ptr, *ptr); + + /* Clean up */ + munmap(mapped_addr, DEVICE_SIZE); + close(fd); + return 0; + } diff --git a/Documentation/driver-api/cxl/allocation/hugepages.rst b/Documentation/driver-api/cxl/allocation/hugepages.rst new file mode 100644 index 000000000000..1023c6922829 --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/hugepages.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +Huge Pages +========== + +Contiguous Memory Allocator +=========================== +CXL Memory onlined as SystemRAM during early boot is eligible for use by CMA, +as the NUMA node hosting that capacity will be `Online` at the time CMA +carves out contiguous capacity. + +CXL Memory deferred to the CXL Driver for configuration cannot have its +capacity allocated by CMA - as the NUMA node hosting the capacity is `Offline` +at :code:`__init` time - when CMA carves out contiguous capacity. + +HugeTLB +======= +Different huge page sizes allow different memory configurations. + +2MB Huge Pages +-------------- +All CXL capacity regardless of configuration time or memory zone is eligible +for use as 2MB huge pages. + +1GB Huge Pages +-------------- +CXL capacity onlined in :code:`ZONE_NORMAL` is eligible for 1GB Gigantic Page +allocation. + +CXL capacity onlined in :code:`ZONE_MOVABLE` is not eligible for 1GB Gigantic +Page allocation. diff --git a/Documentation/driver-api/cxl/allocation/page-allocator.rst b/Documentation/driver-api/cxl/allocation/page-allocator.rst new file mode 100644 index 000000000000..7b8fe1b8d5bb --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/page-allocator.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================== +The Page Allocator +================== + +The kernel page allocator services all general page allocation requests, such +as :code:`kmalloc`. CXL configuration steps affect the behavior of the page +allocator based on the selected `Memory Zone` and `NUMA node` the capacity is +placed in. + +This section mostly focuses on how these configurations affect the page +allocator (as of Linux v6.15) rather than the overall page allocator behavior. + +NUMA nodes and mempolicy +======================== +Unless a task explicitly registers a mempolicy, the default memory policy +of the linux kernel is to allocate memory from the `local NUMA node` first, +and fall back to other nodes only if the local node is pressured. + +Generally, we expect to see local DRAM and CXL memory on separate NUMA nodes, +with the CXL memory being non-local. Technically, however, it is possible +for a compute node to have no local DRAM, and for CXL memory to be the +`local` capacity for that compute node. + + +Memory Zones +============ +CXL capacity may be onlined in :code:`ZONE_NORMAL` or :code:`ZONE_MOVABLE`. + +As of v6.15, the page allocator attempts to allocate from the highest +available and compatible ZONE for an allocation from the local node first. + +An example of a `zone incompatibility` is attempting to service an allocation +marked :code:`GFP_KERNEL` from :code:`ZONE_MOVABLE`. Kernel allocations are +typically not migratable, and as a result can only be serviced from +:code:`ZONE_NORMAL` or lower. + +To simplify this, the page allocator will prefer :code:`ZONE_MOVABLE` over +:code:`ZONE_NORMAL` by default, but if :code:`ZONE_MOVABLE` is depleted, it +will fallback to allocate from :code:`ZONE_NORMAL`. + + +Zone and Node Quirks +==================== +Let's consider a configuration where the local DRAM capacity is largely onlined +into :code:`ZONE_NORMAL`, with no :code:`ZONE_MOVABLE` capacity present. The +CXL capacity has the opposite configuration - all onlined in +:code:`ZONE_MOVABLE`. + +Under the default allocation policy, the page allocator will completely skip +:code:`ZONE_MOVABLE` as a valid allocation target. This is because, as of +Linux v6.15, the page allocator does (approximately) the following: :: + + for (each zone in local_node): + + for (each node in fallback_order): + + attempt_allocation(gfp_flags); + +Because the local node does not have :code:`ZONE_MOVABLE`, the CXL node is +functionally unreachable for direct allocation. As a result, the only way +for CXL capacity to be used is via `demotion` in the reclaim path. + +This configuration also means that if the DRAM ndoe has :code:`ZONE_MOVABLE` +capacity - when that capacity is depleted, the page allocator will actually +prefer CXL :code:`ZONE_MOVABLE` pages over DRAM :code:`ZONE_NORMAL` pages. + +We may wish to invert this priority in future Linux versions. + +If `demotion` and `swap` are disabled, Linux will begin to cause OOM crashes +when the DRAM nodes are depleted. See the reclaim section for more details. + + +CGroups and CPUSets +=================== +Finally, assuming CXL memory is reachable via the page allocation (i.e. onlined +in :code:`ZONE_NORMAL`), the :code:`cpusets.mems_allowed` may be used by +containers to limit the accessibility of certain NUMA nodes for tasks in that +container. Users may wish to utilize this in multi-tenant systems where some +tasks prefer not to use slower memory. + +In the reclaim section we'll discuss some limitations of this interface to +prevent demotions of shared data to CXL memory (if demotions are enabled). + diff --git a/Documentation/driver-api/cxl/allocation/reclaim.rst b/Documentation/driver-api/cxl/allocation/reclaim.rst new file mode 100644 index 000000000000..f40f1cae391a --- /dev/null +++ b/Documentation/driver-api/cxl/allocation/reclaim.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======= +Reclaim +======= +Another way CXL memory can be utilized *indirectly* is via the reclaim system +in :code:`mm/vmscan.c`. Reclaim is engaged when memory capacity on the system +becomes pressured based on global and cgroup-local `watermark` settings. + +In this section we won't discuss the `watermark` configurations, just how CXL +memory can be consumed by various pieces of reclaim system. + +Demotion +======== +By default, the reclaim system will prefer swap (or zswap) when reclaiming +memory. Enabling :code:`kernel/mm/numa/demotion_enabled` will cause vmscan +to opportunistically prefer distant NUMA nodes to swap or zswap, if capacity +is available. + +Demotion engages the :code:`mm/memory_tier.c` component to determine the +next demotion node. The next demotion node is based on the :code:`HMAT` +or :code:`CDAT` performance data. + +cpusets.mems_allowed quirk +-------------------------- +In Linux v6.15 and below, demotion does not respect :code:`cpusets.mems_allowed` +when migrating pages. As a result, if demotion is enabled, vmscan cannot +guarantee isolation of a container's memory from nodes not set in mems_allowed. + +In Linux v6.XX and up, demotion does attempt to respect +:code:`cpusets.mems_allowed`; however, certain classes of shared memory +originally instantiated by another cgroup (such as common libraries - e.g. +libc) may still be demoted. As a result, the mems_allowed interface still +cannot provide perfect isolation from the remote nodes. + +ZSwap and Node Preference +========================= +In Linux v6.15 and below, ZSwap allocates memory from the local node of the +processor for the new pages being compressed. Since pages being compressed +are typically cold, the result is a cold page becomes promoted - only to +be later demoted as it ages off the LRU. + +In Linux v6.XX, ZSwap tries to prefer the node of the page being compressed +as the allocation target for the compression page. This helps prevent +thrashing. + +Demotion with ZSwap +=================== +When enabling both Demotion and ZSwap, you create a situation where ZSwap +will prefer the slowest form of CXL memory by default until that tier of +memory is exhausted. diff --git a/Documentation/driver-api/cxl/devices/device-types.rst b/Documentation/driver-api/cxl/devices/device-types.rst new file mode 100644 index 000000000000..f5e4330c1cfe --- /dev/null +++ b/Documentation/driver-api/cxl/devices/device-types.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Devices and Protocols +===================== + +The type of CXL device (Memory, Accelerator, etc) dictates many configuration steps. This section +covers some basic background on device types and on-device resources used by the platform and OS +which impact configuration. + +Protocols +========= + +There are three core protocols to CXL. For the purpose of this documentation, +we will only discuss very high level definitions as the specific hardware +details are largely abstracted away from Linux. See the CXL specification +for more details. + +CXL.io +------ +The basic interaction protocol, similar to PCIe configuration mechanisms. +Typically used for initialization, configuration, and I/O access for anything +other than memory (CXL.mem) or cache (CXL.cache) operations. + +The Linux CXL driver exposes access to .io functionalty via the various sysfs +interfaces and /dev/cxl/ devices (which exposes direct access to device +mailboxes). + +CXL.cache +--------- +The mechanism by which a device may coherently access and cache host memory. + +Largely transparent to Linux once configured. + +CXL.mem +--------- +The mechanism by which the CPU may coherently access and cache device memory. + +Largely transparent to Linux once configured. + + +Device Types +============ + +Type-1 +------ + +A Type-1 CXL device: + +* Supports cxl.io and cxl.cache protocols +* Implements a fully coherent cache +* Allows Device-to-Host coherence and Host-to-Device snoops. +* Does NOT have host-managed device memory (HDM) + +Typical examples of type-1 devices is a Smart NIC - which may want to +directly operate on host-memory (DMA) to store incoming packets. These +devices largely rely on CPU-attached memory. + +Type-2 +------ + +A Type-2 CXL Device: + +* Supports cxl.io, cxl.cache, and cxl.mem protocols +* Optionally implements coherent cache and Host-Managed Device Memory +* Is typically an accelerator device w/ high bandwidth memory. + +The primary difference between a type-1 and type-2 device is the presence +of host-managed device memory, which allows the device to operate on a +local memory bank - while the CPU sill has coherent DMA to the same memory. + +The allows things like GPUs to expose their memory via DAX devices or file +descriptors, allows drivers and programs direct access to device memory +rather than use block-transfer semantics. + +Type-3 +------ + +A Type-3 CXL Device + +* Supports cxl.io and cxl.mem +* Implements Host-Managed Device Memory +* May provide either Volatile or Persistent memory capacity (or both). + +A basic example of a type-3 device is a simple memory expander, whose +local memory capacity is exposed to the CPU for access directly via +basic coherent DMA. + +Switch +------ + +A CXL switch is a device capacity of routing any CXL (and by extension, PCIe) +protocol between an upstream, downstream, or peer devices. Many devices, such +as Multi-Logical Devices, imply the presence of switching in some manner. + +Logical Devices and Heads +------------------------- + +A CXL device may present one or more "Logical Devices" to one or more hosts +(via physical "Heads"). + +A Single-Logical Device (SLD) is a device which presents a single device to +one or more heads. + +A Multi-Logical Device (MLD) is a device which may present multiple devices +to one or more devices. + +A Single-Headed Device exposes only a single physical connection. + +A Multi-Headed Device exposes multiple physical connections. + +MHSLD +~~~~~ +A Multi-Headed Single-Logical Device (MHSLD) exposes a single logical +device to multiple heads which may be connected to one or more discrete +hosts. An example of this would be a simple memory-pool which may be +statically configured (prior to boot) to expose portions of its memory +to Linux via :doc:`CEDT <../platform/acpi/cedt>`. + +MHMLD +~~~~~ +A Multi-Headed Multi-Logical Device (MHMLD) exposes multiple logical +devices to multiple heads which may be connected to one or more discrete +hosts. An example of this would be a Dynamic Capacity Device or which +may be configured at runtime to expose portions of its memory to Linux. + +Example Devices +=============== + +Memory Expander +--------------- +The simplest form of Type-3 device is a memory expander. A memory expander +exposes Host-Managed Device Memory (HDM) to Linux. This memory may be +Volatile or Non-Volatile (Persistent). + +Memory Expanders will typically be considered a form of Single-Headed, +Single-Logical Device - as its form factor will typically be an add-in-card +(AIC) or some other similar form-factor. + +The Linux CXL driver provides support for static or dynamic configuration of +basic memory expanders. The platform may program decoders prior to OS init +(e.g. auto-decoders), or the user may program the fabric if the platform +defers these operations to the OS. + +Multiple Memory Expanders may be added to an external chassis and exposed to +a host via a head attached to a CXL switch. This is a "memory pool", and +would be considered an MHSLD or MHMLD depending on the management capabilities +provided by the switch platform. + +As of v6.14, Linux does not provide a formalized interface to manage non-DCD +MHSLD or MHMLD devices. + +Dynamic Capacity Device (DCD) +----------------------------- + +A Dynamic Capacity Device is a Type-3 device which provides dynamic management +of memory capacity. The basic premise of a DCD to provide an allocator-like +interface for physical memory capacity to a "Fabric Manager" (an external, +privileged host with privileges to change configurations for other hosts). + +A DCD manages "Memory Extents", which may be volatile or persistent. Extents +may also be exclusive to a single host or shared across multiple hosts. + +As of v6.14, Linux does not provide a formalized interface to manage DCD +devices, however there is active work on LKML targeting future release. diff --git a/Documentation/driver-api/cxl/index.rst b/Documentation/driver-api/cxl/index.rst index 965ba90e8fb7..9e1414ad3357 100644 --- a/Documentation/driver-api/cxl/index.rst +++ b/Documentation/driver-api/cxl/index.rst @@ -4,12 +4,50 @@ Compute Express Link ==================== -.. toctree:: - :maxdepth: 1 +CXL device configuration has a complex handoff between platform (Hardware, +BIOS, EFI), OS (early boot, core kernel, driver), and user policy decisions +that have impacts on each other. The docs here break up configurations steps. - memory-devices - access-coordinates +.. toctree:: + :maxdepth: 2 + :caption: Overview + theory-of-operation maturity-map +.. toctree:: + :maxdepth: 2 + :caption: Device Reference + + devices/device-types + +.. toctree:: + :maxdepth: 2 + :caption: Platform Configuration + + platform/bios-and-efi + platform/acpi + platform/cdat + platform/example-configs + +.. toctree:: + :maxdepth: 2 + :caption: Linux Kernel Configuration + + linux/overview + linux/early-boot + linux/cxl-driver + linux/dax-driver + linux/memory-hotplug + linux/access-coordinates + +.. toctree:: + :maxdepth: 2 + :caption: Memory Allocation + + allocation/dax + allocation/page-allocator + allocation/reclaim + allocation/hugepages.rst + .. only:: subproject and html diff --git a/Documentation/driver-api/cxl/linux/access-coordinates.rst b/Documentation/driver-api/cxl/linux/access-coordinates.rst new file mode 100644 index 000000000000..341a7c682043 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/access-coordinates.rst @@ -0,0 +1,178 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +================================== +CXL Access Coordinates Computation +================================== + +Latency and Bandwidth Calculation +================================= +A memory region performance coordinates (latency and bandwidth) are typically +provided via ACPI tables :doc:`SRAT <../platform/acpi/srat>` and +:doc:`HMAT <../platform/acpi/hmat>`. However, the platform firmware (BIOS) is +not able to annotate those for CXL devices that are hot-plugged since they do +not exist during platform firmware initialization. The CXL driver can compute +the performance coordinates by retrieving data from several components. + +The :doc:`SRAT <../platform/acpi/srat>` provides a Generic Port Affinity +subtable that ties a proximity domain to a device handle, which in this case +would be the CXL hostbridge. Using this association, the performance +coordinates for the Generic Port can be retrieved from the +:doc:`HMAT <../platform/acpi/hmat>` subtable. This piece represents the +performance coordinates between a CPU and a Generic Port (CXL hostbridge). + +The :doc:`CDAT <../platform/cdat>` provides the performance coordinates for +the CXL device itself. That is the bandwidth and latency to access that device's +memory region. The DSMAS subtable provides a DSMADHandle that is tied to a +Device Physical Address (DPA) range. The DSLBIS subtable provides the +performance coordinates that's tied to a DSMADhandle and this ties the two +table entries together to provide the performance coordinates for each DPA +region. For example, if a device exports a DRAM region and a PMEM region, +then there would be different performance characteristsics for each of those +regions. + +If there's a CXL switch in the topology, then the performance coordinates for the +switch is provided by SSLBIS subtable. This provides the bandwidth and latency +for traversing the switch between the switch upstream port and the switch +downstream port that points to the endpoint device. + +Simple topology example:: + + GP0/HB0/ACPI0016-0 + RP0 + | + | L0 + | + SW 0 / USP0 + SW 0 / DSP0 + | + | L1 + | + EP0 + +In this example, there is a CXL switch between an endpoint and a root port. +Latency in this example is calculated as such: +L(EP0) - Latency from EP0 CDAT DSMAS+DSLBIS +L(L1) - Link latency between EP0 and SW0DSP0 +L(SW0) - Latency for the switch from SW0 CDAT SSLBIS. +L(L0) - Link latency between SW0 and RP0 +L(RP0) - Latency from root port to CPU via SRAT and HMAT (Generic Port). +Total read and write latencies are the sum of all these parts. + +Bandwidth in this example is calculated as such: +B(EP0) - Bandwidth from EP0 CDAT DSMAS+DSLBIS +B(L1) - Link bandwidth between EP0 and SW0DSP0 +B(SW0) - Bandwidth for the switch from SW0 CDAT SSLBIS. +B(L0) - Link bandwidth between SW0 and RP0 +B(RP0) - Bandwidth from root port to CPU via SRAT and HMAT (Generic Port). +The total read and write bandwidth is the min() of all these parts. + +To calculate the link bandwidth: +LinkOperatingFrequency (GT/s) is the current negotiated link speed. +DataRatePerLink (MB/s) = LinkOperatingFrequency / 8 +Bandwidth (MB/s) = PCIeCurrentLinkWidth * DataRatePerLink +Where PCIeCurrentLinkWidth is the number of lanes in the link. + +To calculate the link latency: +LinkLatency (picoseconds) = FlitSize / LinkBandwidth (MB/s) + +See `CXL Memory Device SW Guide r1.0 <https://www.intel.com/content/www/us/en/content-details/643805/cxl-memory-device-software-guide.html>`_, +section 2.11.3 and 2.11.4 for details. + +In the end, the access coordinates for a constructed memory region is calculated from one +or more memory partitions from each of the CXL device(s). + +Shared Upstream Link Calculation +================================ +For certain CXL region construction with endpoints behind CXL switches (SW) or +Root Ports (RP), there is the possibility of the total bandwidth for all +the endpoints behind a switch being more than the switch upstream link. +A similar situation can occur within the host, upstream of the root ports. +The CXL driver performs an additional pass after all the targets have +arrived for a region in order to recalculate the bandwidths with possible +upstream link being a limiting factor in mind. + +The algorithm assumes the configuration is a symmetric topology as that +maximizes performance. When asymmetric topology is detected, the calculation +is aborted. An asymmetric topology is detected during topology walk where the +number of RPs detected as a grandparent is not equal to the number of devices +iterated in the same iteration loop. The assumption is made that subtle +asymmetry in properties does not happen and all paths to EPs are equal. + +There can be multiple switches under an RP. There can be multiple RPs under +a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory +Window Structure (CFMWS) in the :doc:`CEDT <../platform/acpi/cedt>`. + +An example hierarchy:: + + CFMWS 0 + | + _________|_________ + | | + ACPI0017-0 ACPI0017-1 + GP0/HB0/ACPI0016-0 GP1/HB1/ACPI0016-1 + | | | | + RP0 RP1 RP2 RP3 + | | | | + SW 0 SW 1 SW 2 SW 3 + | | | | | | | | + EP0 EP1 EP2 EP3 EP4 EP5 EP6 EP7 + +Computation for the example hierarchy: + +Min (GP0 to CPU BW, + Min(SW 0 Upstream Link to RP0 BW, + Min(SW0SSLBIS for SW0DSP0 (EP0), EP0 DSLBIS, EP0 Upstream Link) + + Min(SW0SSLBIS for SW0DSP1 (EP1), EP1 DSLBIS, EP1 Upstream link)) + + Min(SW 1 Upstream Link to RP1 BW, + Min(SW1SSLBIS for SW1DSP0 (EP2), EP2 DSLBIS, EP2 Upstream Link) + + Min(SW1SSLBIS for SW1DSP1 (EP3), EP3 DSLBIS, EP3 Upstream link))) + +Min (GP1 to CPU BW, + Min(SW 2 Upstream Link to RP2 BW, + Min(SW2SSLBIS for SW2DSP0 (EP4), EP4 DSLBIS, EP4 Upstream Link) + + Min(SW2SSLBIS for SW2DSP1 (EP5), EP5 DSLBIS, EP5 Upstream link)) + + Min(SW 3 Upstream Link to RP3 BW, + Min(SW3SSLBIS for SW3DSP0 (EP6), EP6 DSLBIS, EP6 Upstream Link) + + Min(SW3SSLBIS for SW3DSP1 (EP7), EP7 DSLBIS, EP7 Upstream link)))) + +The calculation starts at cxl_region_shared_upstream_perf_update(). A xarray +is created to collect all the endpoint bandwidths via the +cxl_endpoint_gather_bandwidth() function. The min() of bandwidth from the +endpoint CDAT and the upstream link bandwidth is calculated. If the endpoint +has a CXL switch as a parent, then min() of calculated bandwidth and the +bandwidth from the SSLBIS for the switch downstream port that is associated +with the endpoint is calculated. The final bandwidth is stored in a +'struct cxl_perf_ctx' in the xarray indexed by a device pointer. If the +endpoint is direct attached to a root port (RP), the device pointer would be an +RP device. If the endpoint is behind a switch, the device pointer would be the +upstream device of the parent switch. + +At the next stage, the code walks through one or more switches if they exist +in the topology. For endpoints directly attached to RPs, this step is skipped. +If there is another switch upstream, the code takes the min() of the current +gathered bandwidth and the upstream link bandwidth. If there's a switch +upstream, then the SSLBIS of the upstream switch. + +Once the topology walk reaches the RP, whether it's direct attached endpoints +or walking through the switch(es), cxl_rp_gather_bandwidth() is called. At +this point all the bandwidths are aggregated per each host bridge, which is +also the index for the resulting xarray. + +The next step is to take the min() of the per host bridge bandwidth and the +bandwidth from the Generic Port (GP). The bandwidths for the GP are retrieved +via ACPI tables (:doc:`SRAT <../platform/acpi/srat>` and +:doc:`HMAT <../platform/acpi/hmat>`). The minimum bandwidth are aggregated +under the same ACPI0017 device to form a new xarray. + +Finally, the cxl_region_update_bandwidth() is called and the aggregated +bandwidth from all the members of the last xarray is updated for the +access coordinates residing in the cxl region (cxlr) context. + +QTG ID +====== +Each :doc:`CEDT <../platform/acpi/cedt>` has a QTG ID field. This field provides +the ID that associates with a QoS Throttling Group (QTG) for the CFMWS window. +Once the access coordinates are calculated, an ACPI Device Specific Method can +be issued to the ACPI0016 device to retrieve the QTG ID depends on the access +coordinates provided. The QTG ID for the device can be used as guidance to match +to the CFMWS to setup the best Linux root decoder for the device performance. diff --git a/Documentation/driver-api/cxl/linux/cxl-driver.rst b/Documentation/driver-api/cxl/linux/cxl-driver.rst new file mode 100644 index 000000000000..9759e90c3cf1 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/cxl-driver.rst @@ -0,0 +1,630 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +CXL Driver Operation +==================== + +The devices described in this section are present in :: + + /sys/bus/cxl/devices/ + /dev/cxl/ + +The :code:`cxl-cli` library, maintained as part of the NDTCL project, may +be used to script interactions with these devices. + +Drivers +======= +The CXL driver is split into a number of drivers. + +* cxl_core - fundamental init interface and core object creation +* cxl_port - initializes root and provides port enumeration interface. +* cxl_acpi - initializes root decoders and interacts with ACPI data. +* cxl_p/mem - initializes memory devices +* cxl_pci - uses cxl_port to enumates the actual fabric hierarchy. + +Driver Devices +============== +Here is an example from a single-socket system with 4 host bridges. Two host +bridges have a single memory device attached, and the devices are interleaved +into a single memory region. The memory region has been converted to dax. :: + + # ls /sys/bus/cxl/devices/ + dax_region0 decoder3.0 decoder6.0 mem0 port3 + decoder0.0 decoder4.0 decoder6.1 mem1 port4 + decoder1.0 decoder5.0 endpoint5 port1 region0 + decoder2.0 decoder5.1 endpoint6 port2 root0 + + +.. kernel-render:: DOT + :alt: Digraph of CXL fabric describing host-bridge interleaving + :caption: Diagraph of CXL fabric with a host-bridge interleave memory region + + digraph foo { + "root0" -> "port1"; + "root0" -> "port3"; + "root0" -> "decoder0.0"; + "port1" -> "endpoint5"; + "port3" -> "endpoint6"; + "port1" -> "decoder1.0"; + "port3" -> "decoder3.0"; + "endpoint5" -> "decoder5.0"; + "endpoint6" -> "decoder6.0"; + "decoder0.0" -> "region0"; + "decoder0.0" -> "decoder1.0"; + "decoder0.0" -> "decoder3.0"; + "decoder1.0" -> "decoder5.0"; + "decoder3.0" -> "decoder6.0"; + "decoder5.0" -> "region0"; + "decoder6.0" -> "region0"; + "region0" -> "dax_region0"; + "dax_region0" -> "dax0.0"; + } + +For this section we'll explore the devices present in this configuration, but +we'll explore more configurations in-depth in example configurations below. + +Base Devices +------------ +Most devices in a CXL fabric are a `port` of some kind (because each +device mostly routes request from one device to the next, rather than +provide a direct service). + +Root +~~~~ +The `CXL Root` is logical object created by the `cxl_acpi` driver during +:code:`cxl_acpi_probe` - if the :code:`ACPI0017` `Compute Express Link +Root Object` Device Class is found. + +The Root contains links to: + +* `Host Bridge Ports` defined by CHBS in the :doc:`CEDT<../platform/acpi/cedt>` + +* `Downstream Ports` typically connected to `Host Bridge Ports`. + +* `Root Decoders` defined by CFMWS the :doc:`CEDT<../platform/acpi/cedt>` + +:: + + # ls /sys/bus/cxl/devices/root0 + decoder0.0 dport0 dport5 port2 subsystem + decoders_committed dport1 modalias port3 uevent + devtype dport4 port1 port4 uport + + # cat /sys/bus/cxl/devices/root0/devtype + cxl_port + + # cat port1/devtype + cxl_port + + # cat decoder0.0/devtype + cxl_decoder_root + +The root is first `logical port` in the CXL fabric, as presented by the Linux +CXL driver. The `CXL root` is a special type of `switch port`, in that it +only has downstream port connections. + +Port +~~~~ +A `port` object is better described as a `switch port`. It may represent a +host bridge to the root or an actual switch port on a switch. A `switch port` +contains one or more decoders used to route memory requests downstream ports, +which may be connected to another `switch port` or an `endpoint port`. + +:: + + # ls /sys/bus/cxl/devices/port1 + decoder1.0 dport0 driver parent_dport uport + decoders_committed dport113 endpoint5 subsystem + devtype dport2 modalias uevent + + # cat devtype + cxl_port + + # cat decoder1.0/devtype + cxl_decoder_switch + + # cat endpoint5/devtype + cxl_port + +CXL `Host Bridges` in the fabric are probed during :code:`cxl_acpi_probe` at +the time the `CXL Root` is probed. The allows for the immediate logical +connection to between the root and host bridge. + +* The root has a downstream port connection to a host bridge + +* The host bridge has an upstream port connection to the root. + +* The host bridge has one or more downstream port connections to switch + or endpoint ports. + +A `Host Bridge` is a special type of CXL `switch port`. It is explicitly +defined in the ACPI specification via `ACPI0016` ID. `Host Bridge` ports +will be probed at `acpi_probe` time, while similar ports on an actual switch +will be probed later. Otherwise, switch and host bridge ports look very +similar - the both contain switch decoders which route accesses between +upstream and downstream ports. + +Endpoint +~~~~~~~~ +An `endpoint` is a terminal port in the fabric. This is a `logical device`, +and may be one of many `logical devices` presented by a memory device. It +is still considered a type of `port` in the fabric. + +An `endpoint` contains `endpoint decoders` and the device's Coherent Device +Attribute Table (which describes the device's capabilities). :: + + # ls /sys/bus/cxl/devices/endpoint5 + CDAT decoders_committed modalias uevent + decoder5.0 devtype parent_dport uport + decoder5.1 driver subsystem + + # cat /sys/bus/cxl/devices/endpoint5/devtype + cxl_port + + # cat /sys/bus/cxl/devices/endpoint5/decoder5.0/devtype + cxl_decoder_endpoint + + +Memory Device (memdev) +~~~~~~~~~~~~~~~~~~~~~~ +A `memdev` is probed and added by the `cxl_pci` driver in :code:`cxl_pci_probe` +and is managed by the `cxl_mem` driver. It primarily provides the `IOCTL` +interface to a memory device, via :code:`/dev/cxl/memN`, and exposes various +device configuration data. :: + + # ls /sys/bus/cxl/devices/mem0 + dev firmware_version payload_max security uevent + driver label_storage_size pmem serial + firmware numa_node ram subsystem + +A Memory Device is a discrete base object that is not a port. While the +physical device it belongs to may also host an `endpoint`, the relationship +between an `endpoint` and a `memdev` is not captured in sysfs. + +Port Relationships +~~~~~~~~~~~~~~~~~~ +In our example described above, there are four host bridges attached to the +root, and two of the host bridges have one endpoint attached. + +.. kernel-render:: DOT + :alt: Digraph of CXL fabric describing host-bridge interleaving + :caption: Diagraph of CXL fabric with a host-bridge interleave memory region + + digraph foo { + "root0" -> "port1"; + "root0" -> "port2"; + "root0" -> "port3"; + "root0" -> "port4"; + "port1" -> "endpoint5"; + "port3" -> "endpoint6"; + } + +Decoders +-------- +A `Decoder` is short for a CXL Host-Managed Device Memory (HDM) Decoder. It is +a device that routes accesses through the CXL fabric to an endpoint, and at +the endpoint translates a `Host Physical` to `Device Physical` Addressing. + +The CXL 3.1 specification heavily implies that only endpoint decoders should +engage in translation of `Host Physical Address` to `Device Physical Address`. +:: + + 8.2.4.20 CXL HDM Decoder Capability Structure + + IMPLEMENTATION NOTE + CXL Host Bridge and Upstream Switch Port Decode Flow + + IMPLEMENTATION NOTE + Device Decode Logic + +These notes imply that there are two logical groups of decoders. + +* Routing Decoder - a decoder which routes accesses but does not translate + addresses from HPA to DPA. + +* Translating Decoder - a decoder which translates accesses from HPA to DPA + for an endpoint to service. + +The CXL drivers distinguish 3 decoder types: root, switch, and endpoint. Only +endpoint decoders are Translating Decoders, all others are Routing Decoders. + +.. note:: PLATFORM VENDORS BE AWARE + + Linux makes a strong assumption that endpoint decoders are the only decoder + in the fabric that actively translates HPA to DPA. Linux assumes routing + decoders pass the HPA unchanged to the next decoder in the fabric. + + It is therefore assumed that any given decoder in the fabric will have an + address range that is a subset of its upstream port decoder. Any deviation + from this scheme undefined per the specification. Linux prioritizes + spec-defined / architectural behavior. + +Decoders may have one or more `Downstream Targets` if configured to interleave +memory accesses. This will be presented in sysfs via the :code:`target_list` +parameter. + +Root Decoder +~~~~~~~~~~~~ +A `Root Decoder` is logical construct of the physical address and interleave +configurations present in the CFMWS field of the :doc:`CEDT +<../platform/acpi/cedt>`. +Linux presents this information as a decoder present in the `CXL Root`. We +consider this a `Root Decoder`, though technically it exists on the boundary +of the CXL specification and platform-specific CXL root implementations. + +Linux considers these logical decoders a type of `Routing Decoder`, and is the +first decoder in the CXL fabric to receive a memory access from the platform's +memory controllers. + +`Root Decoders` are created during :code:`cxl_acpi_probe`. One root decoder +is created per CFMWS entry in the :doc:`CEDT <../platform/acpi/cedt>`. + +The :code:`target_list` parameter is filled by the CFMWS target fields. Targets +of a root decoder are `Host Bridges`, which means interleave done at the root +decoder level is an `Inter-Host-Bridge Interleave`. + +Only root decoders are capable of `Inter-Host-Bridge Interleave`. + +Such interleaves must be configured by the platform and described in the ACPI +CEDT CFMWS, as the target CXL host bridge UIDs in the CFMWS must match the CXL +host bridge UIDs in the CHBS field of the :doc:`CEDT +<../platform/acpi/cedt>` and the UID field of CXL Host Bridges defined in +the :doc:`DSDT <../platform/acpi/dsdt>`. + +Interleave settings in a root decoder describe how to interleave accesses among +the *immediate downstream targets*, not the entire interleave set. + +The memory range described in the root decoder is used to + +1) Create a memory region (:code:`region0` in this example), and + +2) Associate the region with an IO Memory Resource (:code:`kernel/resource.c`) + +:: + + # ls /sys/bus/cxl/devices/decoder0.0/ + cap_pmem devtype region0 + cap_ram interleave_granularity size + cap_type2 interleave_ways start + cap_type3 locked subsystem + create_ram_region modalias target_list + delete_region qos_class uevent + + # cat /sys/bus/cxl/devices/decoder0.0/region0/resource + 0xc050000000 + +The IO Memory Resource is created during early boot when the CFMWS region is +identified in the EFI Memory Map or E820 table (on x86). + +Root decoders are defined as a separate devtype, but are also a type +of `Switch Decoder` due to having downstream targets. :: + + # cat /sys/bus/cxl/devices/decoder0.0/devtype + cxl_decoder_root + +Switch Decoder +~~~~~~~~~~~~~~ +Any non-root, translating decoder is considered a `Switch Decoder`, and will +present with the type :code:`cxl_decoder_switch`. Both `Host Bridge` and `CXL +Switch` (device) decoders are of type :code:`cxl_decoder_switch`. :: + + # ls /sys/bus/cxl/devices/decoder1.0/ + devtype locked size target_list + interleave_granularity modalias start target_type + interleave_ways region subsystem uevent + + # cat /sys/bus/cxl/devices/decoder1.0/devtype + cxl_decoder_switch + + # cat /sys/bus/cxl/devices/decoder1.0/region + region0 + +A `Switch Decoder` has associations between a region defined by a root +decoder and downstream target ports. Interleaving done within a switch decoder +is a multi-downstream-port interleave (or `Intra-Host-Bridge Interleave` for +host bridges). + +Interleave settings in a switch decoder describe how to interleave accesses +among the *immediate downstream targets*, not the entire interleave set. + +Switch decoders are created during :code:`cxl_switch_port_probe` in the +:code:`cxl_port` driver, and is created based on a PCI device's DVSEC +registers. + +Switch decoder programming is validated during probe if the platform programs +them during boot (See `Auto Decoders` below), or on commit if programmed at +runtime (See `Runtime Programming` below). + + +Endpoint Decoder +~~~~~~~~~~~~~~~~ +Any decoder attached to a *terminal* point in the CXL fabric (`An Endpoint`) is +considered an `Endpoint Decoder`. Endpoint decoders are of type +:code:`cxl_decoder_endpoint`. :: + + # ls /sys/bus/cxl/devices/decoder5.0 + devtype locked start + dpa_resource modalias subsystem + dpa_size mode target_type + interleave_granularity region uevent + interleave_ways size + + # cat /sys/bus/cxl/devices/decoder5.0/devtype + cxl_decoder_endpoint + + # cat /sys/bus/cxl/devices/decoder5.0/region + region0 + +An `Endpoint Decoder` has an association with a region defined by a root +decoder and describes the device-local resource associated with this region. + +Unlike root and switch decoders, endpoint decoders translate `Host Physical` to +`Device Physical` address ranges. The interleave settings on an endpoint +therefore describe the entire *interleave set*. + +`Device Physical Address` regions must be committed in-order. For example, the +DPA region starting at 0x80000000 cannot be committed before the DPA region +starting at 0x0. + +As of Linux v6.15, Linux does not support *imbalanced* interleave setups, all +endpoints in an interleave set are expected to have the same interleave +settings (granularity and ways must be the same). + +Endpoint decoders are created during :code:`cxl_endpoint_port_probe` in the +:code:`cxl_port` driver, and is created based on a PCI device's DVSEC registers. + +Decoder Relationships +~~~~~~~~~~~~~~~~~~~~~ +In our example described above, there is one root decoder which routes memory +accesses over two host bridges. Each host bridge has a decoder which routes +access to their singular endpoint targets. Each endpoint has a decoder which +translates HPA to DPA and services the memory request. + +The driver validates relationships between ports by decoder programming, so +we can think of decoders being related in a similarly hierarchical fashion to +ports. + +.. kernel-render:: DOT + :alt: Digraph of hierarchical relationship between root, switch, and endpoint decoders. + :caption: Diagraph of CXL root, switch, and endpoint decoders. + + digraph foo { + "root0" -> "decoder0.0"; + "decoder0.0" -> "decoder1.0"; + "decoder0.0" -> "decoder3.0"; + "decoder1.0" -> "decoder5.0"; + "decoder3.0" -> "decoder6.0"; + } + +Regions +------- + +Memory Region +~~~~~~~~~~~~~ +A `Memory Region` is a logical construct that connects a set of CXL ports in +the fabric to an IO Memory Resource. It is ultimately used to expose the memory +on these devices to the DAX subsystem via a `DAX Region`. + +An example RAM region: :: + + # ls /sys/bus/cxl/devices/region0/ + access0 devtype modalias subsystem uuid + access1 driver mode target0 + commit interleave_granularity resource target1 + dax_region0 interleave_ways size uevent + +A memory region can be constructed during endpoint probe, if decoders were +programmed by BIOS/EFI (see `Auto Decoders`), or by creating a region manually +via a `Root Decoder`'s :code:`create_ram_region` or :code:`create_pmem_region` +interfaces. + +The interleave settings in a `Memory Region` describe the configuration of the +`Interleave Set` - and are what can be expected to be seen in the endpoint +interleave settings. + +.. kernel-render:: DOT + :alt: Digraph of CXL memory region relationships between root and endpoint decoders. + :caption: Regions are created based on root decoder configurations. Endpoint decoders + must be programmed with the same interleave settings as the region. + + digraph foo { + "root0" -> "decoder0.0"; + "decoder0.0" -> "region0"; + "region0" -> "decoder5.0"; + "region0" -> "decoder6.0"; + } + +DAX Region +~~~~~~~~~~ +A `DAX Region` is used to convert a CXL `Memory Region` to a DAX device. A +DAX device may then be accessed directly via a file descriptor interface, or +converted to System RAM via the DAX kmem driver. See the DAX driver section +for more details. :: + + # ls /sys/bus/cxl/devices/dax_region0/ + dax0.0 devtype modalias uevent + dax_region driver subsystem + +Mailbox Interfaces +------------------ +A mailbox command interface for each device is exposed in :: + + /dev/cxl/mem0 + /dev/cxl/mem1 + +These mailboxes may receive any specification-defined command. Raw commands +(custom commands) can only be sent to these interfaces if the build config +:code:`CXL_MEM_RAW_COMMANDS` is set. This is considered a debug and/or +development interface, not an officially supported mechanism for creation +of vendor-specific commands (see the `fwctl` subsystem for that). + +Decoder Programming +=================== + +Runtime Programming +------------------- +During probe, the only decoders *required* to be programmed are `Root Decoders`. +In reality, `Root Decoders` are a logical construct to describe the memory +region and interleave configuration at the host bridge level - as described +in the ACPI CEDT CFMWS. + +All other `Switch` and `Endpoint` decoders may be programmed by the user +at runtime - if the platform supports such configurations. + +This interaction is what creates a `Software Defined Memory` environment. + +See the :code:`cxl-cli` documentation for more information about how to +configure CXL decoders at runtime. + +Auto Decoders +------------- +Auto Decoders are decoders programmed by BIOS/EFI at boot time, and are +almost always locked (cannot be changed). This is done by a platform +which may have a static configuration - or certain quirks which may prevent +dynamic runtime changes to the decoders (such as requiring additional +controller programming within the CPU complex outside the scope of CXL). + +Auto Decoders are probed automatically as long as the devices and memory +regions they are associated with probe without issue. When probing Auto +Decoders, the driver's primary responsibility is to ensure the fabric is +sane - as-if validating runtime programmed regions and decoders. + +If Linux cannot validate auto-decoder configuration, the memory will not +be surfaced as a DAX device - and therefore not be exposed to the page +allocator - effectively stranding it. + +Interleave +---------- + +The Linux CXL driver supports `Cross-Link First` interleave. This dictates +how interleave is programmed at each decoder step, as the driver validates +the relationships between a decoder and it's parent. + +For example, in a `Cross-Link First` interleave setup with 16 endpoints +attached to 4 host bridges, linux expects the following ways/granularity +across the root, host bridge, and endpoints respectively. + +.. flat-table:: 4x4 cross-link first interleave settings + + * - decoder + - ways + - granularity + + * - root + - 4 + - 256 + + * - host bridge + - 4 + - 1024 + + * - endpoint + - 16 + - 256 + +At the root, every a given access will be routed to the +:code:`((HPA / 256) % 4)th` target host bridge. Within a host bridge, every +:code:`((HPA / 1024) % 4)th` target endpoint. Each endpoint translates based +on the entire 16 device interleave set. + +Unbalanced interleave sets are not supported - decoders at a similar point +in the hierarchy (e.g. all host bridge decoders) must have the same ways and +granularity configuration. + +At Root +~~~~~~~ +Root decoder interleave is defined by CFMWS field of the :doc:`CEDT +<../platform/acpi/cedt>`. The CEDT may actually define multiple CFMWS +configurations to describe the same physical capacity, with the intent to allow +users to decide at runtime whether to online memory as interleaved or +non-interleaved. :: + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Window base address : 0000000100000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Window base address : 0000000200000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + First Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Window base address : 0000000300000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 01 + Interleave Arithmetic : 00 + First Target : 00000007 + Next Target : 00000006 + +In this example, the CFMWS defines two discrete non-interleaved 4GB regions +for each host bridge, and one interleaved 8GB region that targets both. This +would result in 3 root decoders presenting in the root. :: + + # ls /sys/bus/cxl/devices/root0/decoder* + decoder0.0 decoder0.1 decoder0.2 + + # cat /sys/bus/cxl/devices/decoder0.0/target_list start size + 7 + 0x100000000 + 0x100000000 + + # cat /sys/bus/cxl/devices/decoder0.1/target_list start size + 6 + 0x200000000 + 0x100000000 + + # cat /sys/bus/cxl/devices/decoder0.2/target_list start size + 7,6 + 0x300000000 + 0x200000000 + +These decoders are not runtime programmable. They are used to generate a +`Memory Region` to bring this memory online with runtime programmed settings +at the `Switch` and `Endpoint` decoders. + +At Host Bridge or Switch +~~~~~~~~~~~~~~~~~~~~~~~~ +`Host Bridge` and `Switch` decoders are programmable via the following fields: + +- :code:`start` - the HPA region associated with the memory region +- :code:`size` - the size of the region +- :code:`target_list` - the list of downstream ports +- :code:`interleave_ways` - the number downstream ports to interleave across +- :code:`interleave_granularity` - the granularity to interleave at. + +Linux expects the :code:`interleave_granularity` of switch decoders to be +derived from their upstream port connections. In `Cross-Link First` interleave +configurations, the :code:`interleave_granularity` of a decoder is equal to +:code:`parent_interleave_granularity * parent_interleave_ways`. + +At Endpoint +~~~~~~~~~~~ +`Endpoint Decoders` are programmed similar to Host Bridge and Switch decoders, +with the exception that the ways and granularity are defined by the interleave +set (e.g. the interleave settings defined by the associated `Memory Region`). + +- :code:`start` - the HPA region associated with the memory region +- :code:`size` - the size of the region +- :code:`interleave_ways` - the number endpoints in the interleave set +- :code:`interleave_granularity` - the granularity to interleave at. + +These settings are used by endpoint decoders to *Translate* memory requests +from HPA to DPA. This is why they must be aware of the entire interleave set. + +Linux does not support unbalanced interleave configurations. As a result, all +endpoints in an interleave set must have the same ways and granularity. + +Example Configurations +====================== +.. toctree:: + :maxdepth: 1 + + example-configurations/single-device.rst + example-configurations/hb-interleave.rst + example-configurations/intra-hb-interleave.rst + example-configurations/multi-interleave.rst diff --git a/Documentation/driver-api/cxl/linux/dax-driver.rst b/Documentation/driver-api/cxl/linux/dax-driver.rst new file mode 100644 index 000000000000..10d953a2167b --- /dev/null +++ b/Documentation/driver-api/cxl/linux/dax-driver.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +DAX Driver Operation +==================== +The `Direct Access Device` driver was originally designed to provide a +memory-like access mechanism to memory-like block-devices. It was +extended to support CXL Memory Devices, which provide user-configured +memory devices. + +The CXL subsystem depends on the DAX subsystem to either: + +- Generate a file-like interface to userland via :code:`/dev/daxN.Y`, or +- Engage the memory-hotplug interface to add CXL memory to page allocator. + +The DAX subsystem exposes this ability through the `cxl_dax_region` driver. +A `dax_region` provides the translation between a CXL `memory_region` and +a `DAX Device`. + +DAX Device +========== +A `DAX Device` is a file-like interface exposed in :code:`/dev/daxN.Y`. A +memory region exposed via dax device can be accessed via userland software +via the :code:`mmap()` system-call. The result is direct mappings to the +CXL capacity in the task's page tables. + +Users wishing to manually handle allocation of CXL memory should use this +interface. + +kmem conversion +=============== +The :code:`dax_kmem` driver converts a `DAX Device` into a series of `hotplug +memory blocks` managed by :code:`kernel/memory-hotplug.c`. This capacity +will be exposed to the kernel page allocator in the user-selected memory +zone. + +The :code:`memmap_on_memory` setting (both global and DAX device local) +dictates where the kernell will allocate the :code:`struct folio` descriptors +for this memory will come from. If :code:`memmap_on_memory` is set, memory +hotplug will set aside a portion of the memory block capacity to allocate +folios. If unset, the memory is allocated via a normal :code:`GFP_KERNEL` +allocation - and as a result will most likely land on the local NUM node of the +CPU executing the hotplug operation. diff --git a/Documentation/driver-api/cxl/linux/early-boot.rst b/Documentation/driver-api/cxl/linux/early-boot.rst new file mode 100644 index 000000000000..a7fc6fc85fbe --- /dev/null +++ b/Documentation/driver-api/cxl/linux/early-boot.rst @@ -0,0 +1,137 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +Linux Init (Early Boot) +======================= + +Linux configuration is split into two major steps: Early-Boot and everything else. + +During early boot, Linux sets up immutable resources (such as numa nodes), while +later operations include things like driver probe and memory hotplug. Linux may +read EFI and ACPI information throughout this process to configure logical +representations of the devices. + +During Linux Early Boot stage (functions in the kernel that have the __init +decorator), the system takes the resources created by EFI/BIOS +(:doc:`ACPI tables <../platform/acpi>`) and turns them into resources that the +kernel can consume. + + +BIOS, Build and Boot Options +============================ + +There are 4 pre-boot options that need to be considered during kernel build +which dictate how memory will be managed by Linux during early boot. + +* EFI_MEMORY_SP + + * BIOS/EFI Option that dictates whether memory is SystemRAM or + Specific Purpose. Specific Purpose memory will be deferred to + drivers to manage - and not immediately exposed as system RAM. + +* CONFIG_EFI_SOFT_RESERVE + + * Linux Build config option that dictates whether the kernel supports + Specific Purpose memory. + +* CONFIG_MHP_DEFAULT_ONLINE_TYPE + + * Linux Build config that dictates whether and how Specific Purpose memory + converted to a dax device should be managed (left as DAX or onlined as + SystemRAM in ZONE_NORMAL or ZONE_MOVABLE). + +* nosoftreserve + + * Linux kernel boot option that dictates whether Soft Reserve should be + supported. Similar to CONFIG_EFI_SOFT_RESERVE. + +Memory Map Creation +=================== + +While the kernel parses the EFI memory map, if :code:`Specific Purpose` memory +is supported and detected, it will set this region aside as +:code:`SOFT_RESERVED`. + +If :code:`EFI_MEMORY_SP=0`, :code:`CONFIG_EFI_SOFT_RESERVE=n`, or +:code:`nosoftreserve=y` - Linux will default a CXL device memory region to +SystemRAM. This will expose the memory to the kernel page allocator in +:code:`ZONE_NORMAL`, making it available for use for most allocations (including +:code:`struct page` and page tables). + +If `Specific Purpose` is set and supported, :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE_*` +dictates whether the memory is onlined by default (:code:`_OFFLINE` or +:code:`_ONLINE_*`), and if online which zone to online this memory to by default +(:code:`_NORMAL` or :code:`_MOVABLE`). + +If placed in :code:`ZONE_MOVABLE`, the memory will not be available for most +kernel allocations (such as :code:`struct page` or page tables). This may +significant impact performance depending on the memory capacity of the system. + + +NUMA Node Reservation +===================== + +Linux refers to the proximity domains (:code:`PXM`) defined in the :doc:`SRAT +<../platform/acpi/srat>` to create NUMA nodes in :code:`acpi_numa_init`. +Typically, there is a 1:1 relation between :code:`PXM` and NUMA node IDs. + +The SRAT is the only ACPI defined way of defining Proximity Domains. Linux +chooses to, at most, map those 1:1 with NUMA nodes. +:doc:`CEDT <../platform/acpi/cedt>` adds a description of SPA ranges which +Linux may map to one or more NUMA nodes. + +If there are CXL ranges in the CFMWS but not in SRAT, then a fake :code:`PXM` +is created (as of v6.15). In the future, Linux may reject CFMWS not described +by SRAT due to the ambiguity of proximity domain association. + +It is important to note that NUMA node creation cannot be done at runtime. All +possible NUMA nodes are identified at :code:`__init` time, more specifically +during :code:`mm_init`. The CEDT and SRAT must contain sufficient :code:`PXM` +data for Linux to identify NUMA nodes their associated memory regions. + +The relevant code exists in: :code:`linux/drivers/acpi/numa/srat.c`. + +See :doc:`Example Platform Configurations <../platform/example-configs>` +for more info. + +Memory Tiers Creation +===================== +Memory tiers are a collection of NUMA nodes grouped by performance characteristics. +During :code:`__init`, Linux initializes the system with a default memory tier that +contains all nodes marked :code:`N_MEMORY`. + +:code:`memory_tier_init` is called at boot for all nodes with memory online by +default. :code:`memory_tier_late_init` is called during late-init for nodes setup +during driver configuration. + +Nodes are only marked :code:`N_MEMORY` if they have *online* memory. + +Tier membership can be inspected in :: + + /sys/devices/virtual/memory_tiering/memory_tierN/nodelist + 0-1 + +If nodes are grouped which have clear difference in performance, check the +:doc:`HMAT <../platform/acpi/hmat>` and CDAT information for the CXL nodes. All +nodes default to the DRAM tier, unless HMAT/CDAT information is reported to the +memory_tier component via `access_coordinates`. + +For more, see :doc:`CXL access coordinates documentation +<../linux/access-coordinates>`. + +Contiguous Memory Allocation +============================ +The contiguous memory allocator (CMA) enables reservation of contiguous memory +regions on NUMA nodes during early boot. However, CMA cannot reserve memory +on NUMA nodes that are not online during early boot. :: + + void __init hugetlb_cma_reserve(int order) { + if (!node_online(nid)) + /* do not allow reservations */ + } + +This means if users intend to defer management of CXL memory to the driver, CMA +cannot be used to guarantee huge page allocations. If enabling CXL memory as +SystemRAM in `ZONE_NORMAL` during early boot, CMA reservations per-node can be +made with the :code:`cma_pernuma` or :code:`numa_cma` kernel command line +parameters. diff --git a/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst new file mode 100644 index 000000000000..f071490763a2 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst @@ -0,0 +1,314 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Inter-Host-Bridge Interleave +============================ +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* Two CXL Host Bridges have a single CXL Memory Expander Attached +* The CXL root is configured to interleave across the two host bridges. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0 and 1), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`.. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +Next we have the decodesr belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":1, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose only +target is :code:`dport1` - which is attached to :code:`endpoint5`. + +The following chunk shows a similar configuration for Host Bridge :code:`port3`, +the second host bridge with a memory device attached. + +:: + + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + } + ], + "endpoints:port3":[ + { + "endpoint":"endpoint6", + "host":"mem1", + "parent_dport":"0000:a8:01.1", + "depth":2, + "memdev":{ + "memdev":"mem1", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint6":[ + { + "decoder":"decoder6.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + "decoders:port3":[ + { + "decoder":"decoder3.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":1, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:a8:01.1", + "alias":"device:c3", + "position":0, + "id":0 + } + ] + } + ] + }, + + +The next chunk shows the two CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +applies the interleave across the downstream ports :code:`port1` and +:code:`port3` - with a granularity of 256 bytes. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":2, + "targets":[ + { + "target":"pci0000:a8", + "alias":"ACPI0016:02", + "position":1, + "id":4 + }, + { + "target":"pci0000:d2", + "alias":"ACPI0016:00", + "position":0, + "id":5 + } + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the overall interleave configuration +of the interleave set. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":274877906944, + "type":"ram", + "interleave_ways":2, + "interleave_granularity":256, + "decode_state":"commit", + "mappings":[ + { + "position":1, + "memdev":"mem1", + "decoder":"decoder6.0" + }, + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst new file mode 100644 index 000000000000..077dfaf8458d --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst @@ -0,0 +1,291 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Intra-Host-Bridge Interleave +============================ +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* One (1) CXL Host Bridges has two CXL Memory Expanders Attached +* The Host bridge decoder is programmed to interleave across the expanders. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0 and 1), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`.. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + }, + { + "endpoint":"endpoint6", + "host":"mem1", + "parent_dport":"0000:d2:01.3, + "depth":2, + "memdev":{ + "memdev":"mem1", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint6":[ + { + "decoder":"decoder6.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration memory region they belong to +(show later). + +Next we have the decoders belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":2, + "interleave_granularity":256, + "region":"region0", + "nr_targets":2, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + }, + { + "target":"0000:d2:01.3", + "alias":"device:05", + "position":1, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`) with two +targets: :code:`dport1` and :code:`dport3` - which are attached to +:code:`endpoint5` and :code:`endpoint6` respectively. + +The host bridge decoder interleaves these devices at a 256 byte granularity. + +The next chunk shows the three CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + } + ], + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +applies the interleave across the downstream ports :code:`port1` and +:code:`port3` - with a granularity of 256 bytes. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":274877906944, + "interleave_ways":1, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":2, + "targets":[ + { + "target":"pci0000:a8", + "alias":"ACPI0016:02", + "position":1, + "id":4 + }, + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the overall interleave configuration +of the interleave set. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":274877906944, + "type":"ram", + "interleave_ways":2, + "interleave_granularity":256, + "decode_state":"commit", + "mappings":[ + { + "position":1, + "memdev":"mem1", + "decoder":"decoder6.0" + }, + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst new file mode 100644 index 000000000000..008f9053c630 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst @@ -0,0 +1,401 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +Multi-Level Interleave +====================== +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* Two CXL Host Bridges have a two CXL Memory Expanders Attached each. +* The CXL root is configured to interleave across the two host bridges. +* Each host bridge with expanders interleaves across two endpoints. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0 and 1), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport0`, :code:`dport2`, and :code:`dport113`. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + }, + { + "endpoint":"endpoint6", + "host":"mem1", + "parent_dport":"0000:d2:01.3", + "depth":2, + "memdev":{ + "memdev":"mem1", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint6":[ + { + "decoder":"decoder6.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +:code:`endpoint6` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +Next we have the decoders belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":2, + "interleave_granularity":512, + "region":"region0", + "nr_targets":2, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + }, + { + "target":"0000:d2:01.3", + "alias":"device:05", + "position":2, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose +targets are :code:`dport0` and :code:`dport2` - which are attached to +:code:`endpoint5` and :code:`endpoint6` respectively. + +The following chunk shows a similar configuration for Host Bridge :code:`port3`, +the second host bridge with a memory device attached. + +:: + + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + }, + { + "dport":"0000:a8:01.3", + "alias":"device:c5", + "id":0 + } + ], + "endpoints:port3":[ + { + "endpoint":"endpoint7", + "host":"mem2", + "parent_dport":"0000:a8:01.1", + "depth":2, + "memdev":{ + "memdev":"mem2", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint7":[ + { + "decoder":"decoder7.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + }, + { + "endpoint":"endpoint8", + "host":"mem3", + "parent_dport":"0000:a8:01.3", + "depth":2, + "memdev":{ + "memdev":"mem3", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:a9:00.0" + }, + "decoders:endpoint8":[ + { + "decoder":"decoder8.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":4, + "interleave_granularity":256, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + "decoders:port3":[ + { + "decoder":"decoder3.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":2, + "interleave_granularity":512, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:a8:01.1", + "alias":"device:c3", + "position":1, + "id":0 + }, + { + "target":"0000:a8:01.3", + "alias":"device:c5", + "position":3, + "id":0 + } + ] + } + ] + }, + + +The next chunk shows the two CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +applies the interleave across the downstream ports :code:`port1` and +:code:`port3` - with a granularity of 256 bytes. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":549755813888, + "interleave_ways":2, + "interleave_granularity":256, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":2, + "targets":[ + { + "target":"pci0000:a8", + "alias":"ACPI0016:02", + "position":1, + "id":4 + }, + { + "target":"pci0000:d2", + "alias":"ACPI0016:00", + "position":0, + "id":5 + } + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the overall interleave configuration +of the interleave set. So we see there are a total of :code:`4` interleave +targets across 4 endpoint decoders. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":549755813888, + "type":"ram", + "interleave_ways":4, + "interleave_granularity":256, + "decode_state":"commit", + "mappings":[ + { + "position":3, + "memdev":"mem3", + "decoder":"decoder8.0" + }, + { + "position":2, + "memdev":"mem1", + "decoder":"decoder6.0" + } + { + "position":1, + "memdev":"mem2", + "decoder":"decoder7.0" + }, + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst b/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst new file mode 100644 index 000000000000..5fd38eb0aaf4 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst @@ -0,0 +1,246 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +Single Device +============= +This cxl-cli configuration dump shows the following host configuration: + +* A single socket system with one CXL root +* CXL Root has Four (4) CXL Host Bridges +* One CXL Host Bridges has a single CXL Memory Expander Attached +* No interleave is present. + +This output is generated by :code:`cxl list -v` and describes the relationships +between objects exposed in :code:`/sys/bus/cxl/devices/`. + +:: + + [ + { + "bus":"root0", + "provider":"ACPI.CXL", + "nr_dports":4, + "dports":[ + { + "dport":"pci0000:00", + "alias":"ACPI0016:01", + "id":0 + }, + { + "dport":"pci0000:a8", + "alias":"ACPI0016:02", + "id":4 + }, + { + "dport":"pci0000:2a", + "alias":"ACPI0016:03", + "id":1 + }, + { + "dport":"pci0000:d2", + "alias":"ACPI0016:00", + "id":5 + } + ], + +This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL +Host Bridges. The `Root` can be considered the singular upstream port attached +to the platform's memory controller - which routes memory requests to it. + +The `ports:root0` section lays out how each of these downstream ports are +configured. If a port is not configured (id's 0, 1, and 4), they are omitted. + +:: + + "ports:root0":[ + { + "port":"port1", + "host":"pci0000:d2", + "depth":1, + "nr_dports":3, + "dports":[ + { + "dport":"0000:d2:01.1", + "alias":"device:02", + "id":0 + }, + { + "dport":"0000:d2:01.3", + "alias":"device:05", + "id":2 + }, + { + "dport":"0000:d2:07.1", + "alias":"device:0d", + "id":113 + } + ], + +This chunk shows the available downstream ports associated with the CXL Host +Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream +ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`.. + +:: + + "endpoints:port1":[ + { + "endpoint":"endpoint5", + "host":"mem0", + "parent_dport":"0000:d2:01.1", + "depth":2, + "memdev":{ + "memdev":"mem0", + "ram_size":137438953472, + "serial":0, + "numa_node":0, + "host":"0000:d3:00.0" + }, + "decoders:endpoint5":[ + { + "decoder":"decoder5.0", + "resource":825975898112, + "size":137438953472, + "interleave_ways":1, + "region":"region0", + "dpa_resource":0, + "dpa_size":137438953472, + "mode":"ram" + } + ] + } + ], + +This chunk shows the endpoints attached to the host bridge :code:`port1`. + +:code:`endpoint5` contains a single configured decoder :code:`decoder5.0` +which has the same interleave configuration as :code:`region0` (shown later). + +Next we have the decoders belonging to the host bridge: + +:: + + "decoders:port1":[ + { + "decoder":"decoder1.0", + "resource":825975898112, + "size":137438953472, + "interleave_ways":1, + "region":"region0", + "nr_targets":1, + "targets":[ + { + "target":"0000:d2:01.1", + "alias":"device:02", + "position":0, + "id":0 + } + ] + } + ] + }, + +Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose only +target is :code:`dport1` - which is attached to :code:`endpoint5`. + +The next chunk shows the three CXL host bridges without attached endpoints. + +:: + + { + "port":"port2", + "host":"pci0000:00", + "depth":1, + "nr_dports":2, + "dports":[ + { + "dport":"0000:00:01.3", + "alias":"device:55", + "id":2 + }, + { + "dport":"0000:00:07.1", + "alias":"device:5d", + "id":113 + } + ] + }, + { + "port":"port3", + "host":"pci0000:a8", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:a8:01.1", + "alias":"device:c3", + "id":0 + } + ] + }, + { + "port":"port4", + "host":"pci0000:2a", + "depth":1, + "nr_dports":1, + "dports":[ + { + "dport":"0000:2a:01.1", + "alias":"device:d0", + "id":0 + } + ] + } + ], + +Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder +is a pass-through decoder because :code:`interleave_ways` is set to :code:`1`. + +This information is generated by the CXL driver reading the ACPI CEDT CMFWS. + +:: + + "decoders:root0":[ + { + "decoder":"decoder0.0", + "resource":825975898112, + "size":137438953472, + "interleave_ways":1, + "max_available_extent":0, + "volatile_capable":true, + "nr_targets":1, + "targets":[ + { + "target":"pci0000:d2", + "alias":"ACPI0016:00", + "position":0, + "id":5 + } + ], + +Finally we have the `Memory Region` associated with the `Root Decoder` +:code:`decoder0.0`. This region describes the discrete region associated +with the lone device. + +:: + + "regions:decoder0.0":[ + { + "region":"region0", + "resource":825975898112, + "size":137438953472, + "type":"ram", + "interleave_ways":1, + "decode_state":"commit", + "mappings":[ + { + "position":0, + "memdev":"mem0", + "decoder":"decoder5.0" + } + ] + } + ] + } + ] + } + ] diff --git a/Documentation/driver-api/cxl/linux/memory-hotplug.rst b/Documentation/driver-api/cxl/linux/memory-hotplug.rst new file mode 100644 index 000000000000..af368c2bc9cf --- /dev/null +++ b/Documentation/driver-api/cxl/linux/memory-hotplug.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +Memory Hotplug +============== +The final phase of surfacing CXL memory to the kernel page allocator is for +the `DAX` driver to surface a `Driver Managed` memory region via the +memory-hotplug component. + +There are four major configurations to consider: + +1) Default Online Behavior (on/off and zone) +2) Hotplug Memory Block size +3) Memory Map Resource location +4) Driver-Managed Memory Designation + +Default Online Behavior +======================= +The default-online behavior of hotplug memory is dictated by the following, +in order of precedence: + +- :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE` Build Configuration +- :code:`memhp_default_state` Boot parameter +- :code:`/sys/devices/system/memory/auto_online_blocks` value + +These dictate whether hotplugged memory blocks arrive in one of three states: + +1) Offline +2) Online in :code:`ZONE_NORMAL` +3) Online in :code:`ZONE_MOVABLE` + +:code:`ZONE_NORMAL` implies this capacity may be used for almost any allocation, +while :code:`ZONE_MOVABLE` implies this capacity should only be used for +migratable allocations. + +:code:`ZONE_MOVABLE` attempts to retain the hotplug-ability of a memory block +so that it the entire region may be hot-unplugged at a later time. Any capacity +onlined into :code:`ZONE_NORMAL` should be considered permanently attached to +the page allocator. + +Hotplug Memory Block Size +========================= +By default, on most architectures, the Hotplug Memory Block Size is either +128MB or 256MB. On x86, the block size increases up to 2GB as total memory +capacity exceeds 64GB. As of v6.15, Linux does not take into account the +size and alignment of the ACPI CEDT CFMWS regions (see Early Boot docs) when +deciding the Hotplug Memory Block Size. + +Memory Map +========== +The location of :code:`struct folio` allocations to represent the hotplugged +memory capacity are dictated by the following system settings: + +- :code:`/sys_module/memory_hotplug/parameters/memmap_on_memory` +- :code:`/sys/bus/dax/devices/daxN.Y/memmap_on_memory` + +If both of these parameters are set to true, :code:`struct folio` for this +capacity will be carved out of the memory block being onlined. This has +performance implications if the memory is particularly high-latency and +its :code:`struct folio` becomes hotly contended. + +If either parameter is set to false, :code:`struct folio` for this capacity +will be allocated from the local node of the processor running the hotplug +procedure. This capacity will be allocated from :code:`ZONE_NORMAL` on +that node, as it is a :code:`GFP_KERNEL` allocation. + +Systems with extremely large amounts of :code:`ZONE_MOVABLE` memory (e.g. +CXL memory pools) must ensure that there is sufficient local +:code:`ZONE_NORMAL` capacity to host the memory map for the hotplugged capacity. + +Driver Managed Memory +===================== +The DAX driver surfaces this memory to memory-hotplug as "Driver Managed". This +is not a configurable setting, but it's important to note that driver managed +memory is explicitly excluded from use during kexec. This is required to ensure +any reset or out-of-band operations that the CXL device may be subject to during +a functional system-reboot (such as a reset-on-probe) will not cause portions of +the kexec kernel to be overwritten. diff --git a/Documentation/driver-api/cxl/linux/overview.rst b/Documentation/driver-api/cxl/linux/overview.rst new file mode 100644 index 000000000000..648beb2c8c83 --- /dev/null +++ b/Documentation/driver-api/cxl/linux/overview.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======== +Overview +======== + +This section presents the configuration process of a CXL Type-3 memory device, +and how it is ultimately exposed to users as either a :code:`DAX` device or +normal memory pages via the kernel's page allocator. + +Portions marked with a bullet are points at which certain kernel objects +are generated. + +1) Early Boot + + a) BIOS, Build, and Boot Parameters + + i) EFI_MEMORY_SP + ii) CONFIG_EFI_SOFT_RESERVE + iii) CONFIG_MHP_DEFAULT_ONLINE_TYPE + iv) nosoftreserve + + b) Memory Map Creation + + i) EFI Memory Map / E820 Consulted for Soft-Reserved + + * CXL Memory is set aside to be handled by the CXL driver + + * Soft-Reserved IO Resource created for CFMWS entry + + c) NUMA Node Creation + + * Nodes created from ACPI CEDT CFMWS and SRAT Proximity domains (PXM) + + d) Memory Tier Creation + + * A default memory_tier is created with all nodes. + + e) Contiguous Memory Allocation + + * Any requested CMA is allocated from Online nodes + + f) Init Finishes, Drivers start probing + +2) ACPI and PCI Drivers + + a) Detects PCI device is CXL, marking it for probe by CXL driver + +3) CXL Driver Operation + + a) Base device creation + + * root, port, and memdev devices created + * CEDT CFMWS IO Resource creation + + b) Decoder creation + + * root, switch, and endpoint decoders created + + c) Logical device creation + + * memory_region and endpoint devices created + + d) Devices are associated with each other + + * If auto-decoder (BIOS-programmed decoders), driver validates + configurations, builds associations, and locks configs at probe time. + + * If user-configured, validation and associations are built at + decoder-commit time. + + e) Regions surfaced as DAX region + + * dax_region created + + * DAX device created via DAX driver + +4) DAX Driver Operation + + a) DAX driver surfaces DAX region as one of two dax device modes + + * kmem - dax device is converted to hotplug memory blocks + + * DAX kmem IO Resource creation + + * hmem - dax device is left as daxdev to be accessed as a file. + + * If hmem, journey ends here. + + b) DAX kmem surfaces memory region to Memory Hotplug to add to page + allocator as "driver managed memory" + +5) Memory Hotplug + + a) mhp component surfaces a dax device memory region as multiple memory + blocks to the page allocator + + * blocks appear in :code:`/sys/bus/memory/devices` and linked to a NUMA node + + b) blocks are onlined into the requested zone (NORMAL or MOVABLE) + + * Memory is marked "Driver Managed" to avoid kexec from using it as region + for kernel updates diff --git a/Documentation/driver-api/cxl/maturity-map.rst b/Documentation/driver-api/cxl/maturity-map.rst index a2288f9df658..1330f3f52129 100644 --- a/Documentation/driver-api/cxl/maturity-map.rst +++ b/Documentation/driver-api/cxl/maturity-map.rst @@ -51,9 +51,9 @@ in place, but there are several corner cases that are pending closure. * [2] CXL Window Enumeration - * [0] :ref:`Extended-linear memory-side cache <extended-linear>` + * [2] :ref:`Extended-linear memory-side cache <extended-linear>` * [0] Low Memory-hole - * [0] Hetero-interleave + * [X] Hetero-interleave * [2] Switch Enumeration @@ -173,7 +173,7 @@ Accelerator User Flow Support ----------------- -* [0] HPA->DPA Address translation (need xormaps export solution) +* [0] Inject & clear poison by HPA Details ======= diff --git a/Documentation/driver-api/cxl/platform/acpi.rst b/Documentation/driver-api/cxl/platform/acpi.rst new file mode 100644 index 000000000000..ee7e6bd4c43d --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========== +ACPI Tables +=========== + +ACPI is the "Advanced Configuration and Power Interface", which is a standard +that defines how platforms and OS manage power and configure computer hardware. +For the purpose of this theory of operation, when referring to "ACPI" we will +usually refer to "ACPI Tables" - which are the way a platform (BIOS/EFI) +communicates static configuration information to the operation system. + +The Following ACPI tables contain *static* configuration and performance data +about CXL devices. + +.. toctree:: + :maxdepth: 1 + + acpi/cedt.rst + acpi/srat.rst + acpi/hmat.rst + acpi/slit.rst + acpi/dsdt.rst + +The SRAT table may also contain generic port/initiator content that is intended +to describe the generic port, but not information about the rest of the path to +the endpoint. + +Linux uses these tables to configure kernel resources for statically configured +(by BIOS/EFI) CXL devices, such as: + +- NUMA nodes +- Memory Tiers +- NUMA Abstract Distances +- SystemRAM Memory Regions +- Weighted Interleave Node Weights + +ACPI Debugging +============== + +The :code:`acpidump -b` command dumps the ACPI tables into binary format. + +The :code:`iasl -d` command disassembles the files into human readable format. + +Example :code:`acpidump -b && iasl -d cedt.dat` :: + + [000h 0000 4] Signature : "CEDT" [CXL Early Discovery Table] + +Common Issues +------------- +Most failures described here result in a failure of the driver to surface +memory as a DAX device and/or kmem. + +* CEDT CFMWS targets list UIDs do not match CEDT CHBS UIDs. +* CEDT CFMWS targets list UIDs do not match DSDT CXL Host Bridge UIDs. +* CEDT CFMWS Restriction Bits are not correct. +* CEDT CFMWS Memory regions are poorly aligned. +* CEDT CFMWS Memory regions spans a platform memory hole. +* CEDT CHBS UIDs do not match DSDT CXL Host Bridge UIDs. +* CEDT CHBS Specification version is incorrect. +* SRAT is missing regions described in CEDT CFMWS. + + * Result: failure to create a NUMA node for the region, or + region is placed in wrong node. + +* HMAT is missing data for regions described in CEDT CFMWS. + + * Result: NUMA node being placed in the wrong memory tier. + +* SLIT has bad data. + + * Result: Lots of performance mechanisms in the kernel will be very unhappy. + +All of these issues will appear to users as if the driver is failing to +support CXL - when in reality they are all the failure of a platform to +configure the ACPI tables correctly. diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst b/Documentation/driver-api/cxl/platform/acpi/cedt.rst new file mode 100644 index 000000000000..1d9c9d3592dc --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst @@ -0,0 +1,62 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +CEDT - CXL Early Discovery Table +================================ + +The CXL Early Discovery Table is generated by BIOS to describe the CXL memory +regions configured at boot by the BIOS. + +CHBS +==== +The CXL Host Bridge Structure describes CXL host bridges. Other than describing +device register information, it reports the specific host bridge UID for this +host bridge. These host bridge ID's will be referenced in other tables. + +Example :: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 <- Host bridge _UID + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + +CFMWS +===== +The CXL Fixed Memory Window structure describes a memory region associated +with one or more CXL host bridges (as described by the CHBS). It additionally +describes any inter-host-bridge interleave configuration that may have been +programmed by BIOS. + +Example :: + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 000000C050000000 <- Memory Region + Window size : 0000003CA0000000 + Interleave Members (2^n) : 01 <- Interleave configuration + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 <- Host Bridge _UID + Next Target : 00000006 <- Host Bridge _UID + +The restriction field dictates what this SPA range may be used for (memory type, +voltile vs persistent, etc). One or more bits may be set. :: + + Bit[0]: CXL Type 2 Memory + Bit[1]: CXL Type 3 Memory + Bit[2]: Volatile Memory + Bit[3]: Persistent Memory + Bit[4]: Fixed Config (HPA cannot be re-used) + +INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT +reported in this structure, and is solely defined via CXL device decoder +programming (host bridge and endpoint decoders). diff --git a/Documentation/driver-api/cxl/platform/acpi/dsdt.rst b/Documentation/driver-api/cxl/platform/acpi/dsdt.rst new file mode 100644 index 000000000000..b4583b01d67d --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/dsdt.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================== +DSDT - Differentiated system Description Table +============================================== + +This table describes what peripherals a machine has. + +This table's UIDs for CXL devices - specifically host bridges, must be +consistent with the contents of the CEDT, otherwise the CXL driver will +fail to probe correctly. + +Example Compute Express Link Host Bridge :: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + Name (_CID, Package (0x02) // _CID: Compatible ID + { + EisaId ("PNP0A08") /* PCI Express Bus */, + EisaId ("PNP0A03") /* PCI Bus */ + }) + ... + Name (_UID, 0x05) // _UID: Unique ID + ... + } diff --git a/Documentation/driver-api/cxl/platform/acpi/hmat.rst b/Documentation/driver-api/cxl/platform/acpi/hmat.rst new file mode 100644 index 000000000000..095a26f02a37 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/hmat.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================== +HMAT - Heterogeneous Memory Attribute Table +=========================================== + +The Heterogeneous Memory Attributes Table contains information such as cache +attributes and bandwidth and latency details for memory proximity domains. +For the purpose of this document, we will only discuss the SSLIB entry. + +SLLBI +===== +The System Locality Latency and Bandwidth Information records latency and +bandwidth information for proximity domains. + +This table is used by Linux to configure interleave weights and memory tiers. + +Example (Heavily truncated for brevity) :: + + Structure Type : 0001 [SLLBI] + Data Type : 00 <- Latency + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 0080 <- DRAM LTC + Entry : 0100 <- CXL LTC + + Structure Type : 0001 [SLLBI] + Data Type : 03 <- Bandwidth + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 1200 <- DRAM BW + Entry : 0200 <- CXL BW diff --git a/Documentation/driver-api/cxl/platform/acpi/slit.rst b/Documentation/driver-api/cxl/platform/acpi/slit.rst new file mode 100644 index 000000000000..a56768e8fe41 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/slit.rst @@ -0,0 +1,21 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +SLIT - System Locality Information Table +======================================== + +The system locality information table provides "abstract distances" between +accessor and memory nodes. Node without initiators (cpus) are infinitely (FF) +distance away from all other nodes. + +The abstract distance described in this table does not describe any real +latency of bandwidth information. + +Example :: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000004 + Locality 0 : 10 20 20 30 + Locality 1 : 20 10 30 20 + Locality 2 : FF FF 0A FF + Locality 3 : FF FF FF 0A diff --git a/Documentation/driver-api/cxl/platform/acpi/srat.rst b/Documentation/driver-api/cxl/platform/acpi/srat.rst new file mode 100644 index 000000000000..cc98ca0e508e --- /dev/null +++ b/Documentation/driver-api/cxl/platform/acpi/srat.rst @@ -0,0 +1,71 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +SRAT - Static Resource Affinity Table +===================================== + +The System/Static Resource Affinity Table describes resource (CPU, Memory) +affinity to "Proximity Domains". This table is technically optional, but for +performance information (see "HMAT") to be enumerated by linux it must be +present. + +There is a careful dance between the CEDT and SRAT tables and how NUMA nodes are +created. If things don't look quite the way you expect - check the SRAT Memory +Affinity entries and CEDT CFMWS to determine what your platform actually +supports in terms of flexible topologies. + +The SRAT may statically assign portions of a CFMWS SPA range to a specific +proximity domains. See linux numa creation for more information about how +this presents in the NUMA topology. + +Proximity Domain +================ +A proximity domain is ROUGHLY equivalent to "NUMA Node" - though a 1-to-1 +mapping is not guaranteed. There are scenarios where "Proximity Domain 4" may +map to "NUMA Node 3", for example. (See "NUMA Node Creation") + +Memory Affinity +=============== +Generally speaking, if a host does any amount of CXL fabric (decoder) +programming in BIOS - an SRAT entry for that memory needs to be present. + +Example :: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 <- NUMA Node 1 + Reserved1 : 0000 + Base Address : 000000C050000000 <- Physical Memory Region + Address Length : 0000003CA0000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + +Generic Port Affinity +===================== +The Generic Port Affinity subtable provides an association between a proximity +domain and a device handle representing a Generic Port such as a CXL host +bridge. With the association, latency and bandwidth numbers can be retrieved +from the SRAT for the path between CPU(s) (initiator) and the Generic Port. +This is used to construct performance coordinates for hotplugged CXL DEVICES, +which cannot be enumerated at boot by platform firmware. + +Example :: + + Subtable Type : 06 [Generic Port Affinity] + Length : 20 <- 32d, length of table + Reserved : 00 + Device Handle Type : 00 <- 0 - ACPI, 1 - PCI + Proximity Domain : 00000001 + Device Handle : ACPI0016:01 + Flags : 00000001 <- Bit 0 (Enabled) + Reserved : 00000000 + +The Proximity Domain is matched up to the :doc:`HMAT <hmat>` SSLBI Target +Proximity Domain List for the related latency or bandwidth numbers. Those +performance numbers are tied to a CXL host bridge via the Device Handle. +The driver uses the association to retrieve the Generic Port performance +numbers for the whole CXL path access coordinates calculation. diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst b/Documentation/driver-api/cxl/platform/bios-and-efi.rst new file mode 100644 index 000000000000..645322632cc9 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst @@ -0,0 +1,262 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== +BIOS/EFI Configuration +====================== + +BIOS and EFI are largely responsible for configuring static information about +devices (or potential future devices) such that Linux can build the appropriate +logical representations of these devices. + +At a high level, this is what occurs during this phase of configuration. + +* The bootloader starts the BIOS/EFI. + +* BIOS/EFI do early device probe to determine static configuration + +* BIOS/EFI creates ACPI Tables that describe static config for the OS + +* BIOS/EFI create the system memory map (EFI Memory Map, E820, etc) + +* BIOS/EFI calls :code:`start_kernel` and begins the Linux Early Boot process. + +Much of what this section is concerned with is ACPI Table production and +static memory map configuration. More detail on these tables can be found +at :doc:`ACPI Tables <acpi>`. + +.. note:: + Platform Vendors should read carefully, as this sections has recommendations + on physical memory region size and alignment, memory holes, HDM interleave, + and what linux expects of HDM decoders trying to work with these features. + +UEFI Settings +============= +If your platform supports it, the :code:`uefisettings` command can be used to +read/write EFI settings. Changes will be reflected on the next reboot. Kexec +is not a sufficient reboot. + +One notable configuration here is the EFI_MEMORY_SP (Specific Purpose) bit. +When this is enabled, this bit tells linux to defer management of a memory +region to a driver (in this case, the CXL driver). Otherwise, the memory is +treated as "normal memory", and is exposed to the page allocator during +:code:`__init`. + +uefisettings examples +--------------------- + +:code:`uefisettings identify` :: + + uefisettings identify + + bios_vendor: xxx + bios_version: xxx + bios_release: xxx + bios_date: xxx + product_name: xxx + product_family: xxx + product_version: xxx + +On some AMD platforms, the :code:`EFI_MEMORY_SP` bit is set via the :code:`CXL +Memory Attribute` field. This may be called something else on your platform. + +:code:`uefisettings get "CXL Memory Attribute"` :: + + selector: xxx + ... + question: Question { + name: "CXL Memory Attribute", + answer: "Enabled", + ... + } + +Physical Memory Map +=================== + +Physical Address Region Alignment +--------------------------------- + +As of Linux v6.14, the hotplug memory system requires memory regions to be +uniform in size and alignment. While the CXL specification allows for memory +regions as small as 256MB, the supported memory block size and alignment for +hotplugged memory is architecture-defined. + +A Linux memory blocks may be as small as 128MB and increase in powers of two. + +* On ARM, the default block size and alignment is either 128MB or 256MB. + +* On x86, the default block size is 256MB, and increases to 2GB as the + capacity of the system increases up to 64GB. + +For best support across versions, platform vendors should place CXL memory at +a 2GB aligned base address, and regions should be 2GB aligned. This also helps +prevent the creating thousands of memory devices (one per block). + +Memory Holes +------------ + +Holes in the memory map are tricky. Consider a 4GB device located at base +address 0x100000000, but with the following memory map :: + + --------------------- + | 0x100000000 | + | CXL | + | 0x1BFFFFFFF | + --------------------- + | 0x1C0000000 | + | MEMORY HOLE | + | 0x1FFFFFFFF | + --------------------- + | 0x200000000 | + | CXL CONT. | + | 0x23FFFFFFF | + --------------------- + +There are two issues to consider: + +* decoder programming, and +* memory block alignment. + +If your architecture requires 2GB uniform size and aligned memory blocks, the +only capacity Linux is capable of mapping (as of v6.14) would be the capacity +from `0x100000000-0x180000000`. The remaining capacity will be stranded, as +they are not of 2GB aligned length. + +Assuming your architecture and memory configuration allows 1GB memory blocks, +this memory map is supported and this should be presented as multiple CFMWS +in the CEDT that describe each side of the memory hole separately - along with +matching decoders. + +Multiple decoders can (and should) be used to manage such a memory hole (see +below), but each chunk of a memory hole should be aligned to a reasonable block +size (larger alignment is always better). If you intend to have memory holes +in the memory map, expect to use one decoder per contiguous chunk of host +physical memory. + +As of v6.14, Linux does provide support for memory hotplug of multiple +physical memory regions separated by a memory hole described by a single +HDM decoder. + + +Decoder Programming +=================== +If BIOS/EFI intends to program the decoders to be statically configured, +there are a few things to consider to avoid major pitfalls that will +prevent Linux compatibility. Some of these recommendations are not +required "per the specification", but Linux makes no guarantees of support +otherwise. + + +Translation Point +----------------- +Per the specification, the only decoders which **TRANSLATE** Host Physical +Address (HPA) to Device Physical Address (DPA) are the **Endpoint Decoders**. +All other decoders in the fabric are intended to route accesses without +translating the addresses. + +This is heavily implied by the specification, see: :: + + CXL Specification 3.1 + 8.2.4.20: CXL HDM Decoder Capability Structure + - Implementation Note: CXL Host Bridge and Upstream Switch Port Decoder Flow + - Implementation Note: Device Decoder Logic + +Given this, Linux makes a strong assumption that decoders between CPU and +endpoint will all be programmed with addresses ranges that are subsets of +their parent decoder. + +Due to some ambiguity in how Architecture, ACPI, PCI, and CXL specifications +"hand off" responsibility between domains, some early adopting platforms +attempted to do translation at the originating memory controller or host +bridge. This configuration requires a platform specific extension to the +driver and is not officially endorsed - despite being supported. + +It is *highly recommended* **NOT** to do this; otherwise, you are on your own +to implement driver support for your platform. + +Interleave and Configuration Flexibility +---------------------------------------- +If providing cross-host-bridge interleave, a CFMWS entry in the :doc:`CEDT +<acpi/cedt>` must be presented with target host-bridges for the interleaved +device sets (there may be multiple behind each host bridge). + +If providing intra-host-bridge interleaving, only 1 CFMWS entry in the CEDT is +required for that host bridge - if it covers the entire capacity of the devices +behind the host bridge. + +If intending to provide users flexibility in programming decoders beyond the +root, you may want to provide multiple CFMWS entries in the CEDT intended for +different purposes. For example, you may want to consider adding: + +1) A CFMWS entry to cover all interleavable host bridges. +2) A CFMWS entry to cover all devices on a single host bridge. +3) A CFMWS entry to cover each device. + +A platform may choose to add all of these, or change the mode based on a BIOS +setting. For each CFMWS entry, Linux expects descriptions of the described +memory regions in the :doc:`SRAT <acpi/srat>` to determine the number of +NUMA nodes it should reserve during early boot / init. + +As of v6.14, Linux will create a NUMA node for each CEDT CFMWS entry, even if +a matching SRAT entry does not exist; however, this is not guaranteed in the +future and such a configuration should be avoided. + +Memory Holes +------------ +If your platform includes memory holes intersparsed between your CXL memory, it +is recommended to utilize multiple decoders to cover these regions of memory, +rather than try to program the decoders to accept the entire range and expect +Linux to manage the overlap. + +For example, consider the Memory Hole described above :: + + --------------------- + | 0x100000000 | + | CXL | + | 0x1BFFFFFFF | + --------------------- + | 0x1C0000000 | + | MEMORY HOLE | + | 0x1FFFFFFFF | + --------------------- + | 0x200000000 | + | CXL CONT. | + | 0x23FFFFFFF | + --------------------- + +Assuming this is provided by a single device attached directly to a host bridge, +Linux would expect the following decoder programming :: + + ----------------------- ----------------------- + | root-decoder-0 | | root-decoder-1 | + | base: 0x100000000 | | base: 0x200000000 | + | size: 0xC0000000 | | size: 0x40000000 | + ----------------------- ----------------------- + | | + ----------------------- ----------------------- + | HB-decoder-0 | | HB-decoder-1 | + | base: 0x100000000 | | base: 0x200000000 | + | size: 0xC0000000 | | size: 0x40000000 | + ----------------------- ----------------------- + | | + ----------------------- ----------------------- + | ep-decoder-0 | | ep-decoder-1 | + | base: 0x100000000 | | base: 0x200000000 | + | size: 0xC0000000 | | size: 0x40000000 | + ----------------------- ----------------------- + +With a CEDT configuration with two CFMWS describing the above root decoders. + +Linux makes no guarantee of support for strange memory hole situations. + +Multi-Media Devices +------------------- +The CFMWS field of the CEDT has special restriction bits which describe whether +the described memory region allows volatile or persistent memory (or both). If +the platform intends to support either: + +1) A device with multiple medias, or +2) Using a persistent memory device as normal memory + +A platform may wish to create multiple CEDT CFMWS entries to describe the same +memory, with the intent of allowing the end user flexibility in how that memory +is configured. Linux does not presently have strong requirements in this area. diff --git a/Documentation/driver-api/cxl/platform/cdat.rst b/Documentation/driver-api/cxl/platform/cdat.rst new file mode 100644 index 000000000000..34bbe7264d71 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/cdat.rst @@ -0,0 +1,118 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Coherent Device Attribute Table (CDAT) +====================================== + +The CDAT provides functional and performance attributes of devices such +as CXL accelerators, switches, or endpoints. The table formatting is +similar to ACPI tables. CDAT data may be parsed by BIOS at boot or may +be enumerated at runtime (after device hotplug, for example). + +Terminology: +DPA - Device Physical Address, used by the CXL device to denote the address +it supports for that device. + +DSMADHandle - A device unique handle that is associated with a DPA range +defined by the DSMAS table. + + +=============================================== +Device Scoped Memory Affinity Structure (DSMAS) +=============================================== + +The DSMAS contains information such as DSMADHandle, the DPA Base, and DPA +Length. + +This table is used by Linux in conjunction with the Device Scoped Latency and +Bandwidth Information Structure (DSLBIS) to determine the performance +attributes of the CXL device itself. + +Example :: + + Structure Type : 00 [DSMAS] + Reserved : 00 + Length : 0018 <- 24d, size of structure + DSMADHandle : 01 + Flags : 00 + Reserved : 0000 + DPA Base : 0000000040000000 <- 1GiB base + DPA Length : 0000000080000000 <- 2GiB size + + +================================================================== +Device Scoped Latency and Bandwidth Information Structure (DSLBIS) +================================================================== + +This table is used by Linux in conjunction with DSMAS to determine the +performance attributes of a CXL device. The DSLBIS contains latency +and bandwidth information based on DSMADHandle matching. + +Example :: + + Structure Type : 01 [DSLBIS] + Reserved : 00 + Length : 18 <- 24d, size of structure + Handle : 0001 <- DSMAS handle + Flags : 00 <- Matches flag field for HMAT SLLBIS + Data Type : 00 <- Latency + Entry Basee Unit : 0000000000001000 <- Entry Base Unit field in HMAT SSLBIS + Entry : 010000000000 <- First byte used here, CXL LTC + Reserved : 0000 + + Structure Type : 01 [DSLBIS] + Reserved : 00 + Length : 18 <- 24d, size of structure + Handle : 0001 <- DSMAS handle + Flags : 00 <- Matches flag field for HMAT SLLBIS + Data Type : 03 <- Bandwidth + Entry Basee Unit : 0000000000001000 <- Entry Base Unit field in HMAT SSLBIS + Entry : 020000000000 <- First byte used here, CXL BW + Reserved : 0000 + + +================================================================== +Switch Scoped Latency and Bandwidth Information Structure (SSLBIS) +================================================================== + +The SSLBIS contains information about the latency and bandwidth of a switch. + +The table is used by Linux to compute the performance coordinates of a CXL path +from the device to the root port where a switch is part of the path. + +Example :: + + Structure Type : 05 [SSLBIS] + Reserved : 00 + Length : 20 <- 32d, length of record, including SSLB entries + Data Type : 00 <- Latency + Reserved : 000000 + Entry Base Unit : 00000000000000001000 <- Matches Entry Base Unit in HMAT SSLBIS + + <- SSLB Entry 0 + Port X ID : 0100 <- First port, 0100h represents an upstream port + Port Y ID : 0000 <- Second port, downstream port 0 + Latency : 0100 <- Port latency + Reserved : 0000 + <- SSLB Entry 1 + Port X ID : 0100 + Port Y ID : 0001 + Latency : 0100 + Reserved : 0000 + + + Structure Type : 05 [SSLBIS] + Reserved : 00 + Length : 18 <- 24d, length of record, including SSLB entry + Data Type : 03 <- Bandwidth + Reserved : 000000 + Entry Base Unit : 00000000000000001000 <- Matches Entry Base Unit in HMAT SSLBIS + + <- SSLB Entry 0 + Port X ID : 0100 <- First port, 0100h represents an upstream port + Port Y ID : FFFF <- Second port, FFFFh indicates any port + Bandwidth : 1200 <- Port bandwidth + Reserved : 0000 + +The CXL driver uses a combination of CDAT, HMAT, SRAT, and other data to +generate "whole path performance" data for a CXL device. diff --git a/Documentation/driver-api/cxl/platform/example-configs.rst b/Documentation/driver-api/cxl/platform/example-configs.rst new file mode 100644 index 000000000000..90a10d7473c6 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configs.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Example Platform Configurations +############################### + +.. toctree:: + :maxdepth: 1 + :caption: Contents + + example-configurations/one-dev-per-hb.rst + example-configurations/multi-dev-per-hb.rst + example-configurations/hb-interleave.rst + example-configurations/flexible.rst diff --git a/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst b/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst new file mode 100644 index 000000000000..dab704b6fcc2 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst @@ -0,0 +1,296 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Flexible Presentation +===================== +This system has a single socket with two CXL host bridges. Each host bridge +has two CXL memory expanders with a 4GB of memory (32GB total). + +On this system, the platform designer wanted to provide the user flexibility +to configure the memory devices in various interleave or NUMA node +configurations. So they provided every combination. + +Things to note: + +* Cross-Bridge interleave is described in one CFMWS that covers all capacity. +* One CFMWS is also described per-host bridge. +* One CFMWS is also described per-device. +* This SRAT describes one node for each of the above CFMWS. +* The HMAT describes performance for each node in the SRAT. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000006 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010380800000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000400000000 + Interleave Members (2^n) : 01 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + Second Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000002000000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000002200000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003000000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003100000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003200000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000003300000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000400000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000002 + Reserved1 : 0000 + Base Address : 0000002000000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000003 + Reserved1 : 0000 + Base Address : 0000002200000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000004 + Reserved1 : 0000 + Base Address : 0000003000000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000005 + Reserved1 : 0000 + Base Address : 0000003100000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000006 + Reserved1 : 0000 + Base Address : 0000003200000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000007 + Reserved1 : 0000 + Base Address : 0000003300000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Target Proximity Domain List : 00000003 + Target Proximity Domain List : 00000004 + Target Proximity Domain List : 00000005 + Target Proximity Domain List : 00000006 + Target Proximity Domain List : 00000007 + Entry : 0080 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Target Proximity Domain List : 00000003 + Target Proximity Domain List : 00000004 + Target Proximity Domain List : 00000005 + Target Proximity Domain List : 00000006 + Target Proximity Domain List : 00000007 + Entry : 1200 + Entry : 0400 + Entry : 0200 + Entry : 0200 + Entry : 0100 + Entry : 0100 + Entry : 0100 + Entry : 0100 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 20 20 20 20 20 20 + Locality 1 : FF 0A FF FF FF FF FF FF + Locality 2 : FF FF 0A FF FF FF FF FF + Locality 3 : FF FF FF 0A FF FF FF FF + Locality 4 : FF FF FF FF 0A FF FF FF + Locality 5 : FF FF FF FF FF 0A FF FF + Locality 6 : FF FF FF FF FF FF 0A FF + Locality 7 : FF FF FF FF FF FF FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + Device (S0D5) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x06) // _UID: Unique ID + } + } diff --git a/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst b/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst new file mode 100644 index 000000000000..c474dcf09fb0 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst @@ -0,0 +1,107 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Cross-Host-Bridge Interleave +============================ +This system has a single socket with two CXL host bridges. Each host bridge +has a single CXL memory expander with a 4GB of memory. + +Things to note: + +* Cross-Bridge interleave is described. +* The expanders are described by a single CFMWS. +* This SRAT describes one node for both host bridges. +* The HMAT describes a single node's performance. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000006 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010380800000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 01 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + Second Target : 00000006 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 0080 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 1200 + Entry : 0400 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 + Locality 1 : FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + Device (S0D5) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x06) // _UID: Unique ID + } + } diff --git a/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst b/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst new file mode 100644 index 000000000000..a7854a79dbbd --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +Multiple Devices per Host Bridge +================================ + +In this example system we will have a single socket and one CXL host bridge. +There are two CXL memory expanders with 4GB attached to the host bridge. + +Things to note: + +* Intra-Bridge interleave is not described here. +* The expanders are described by a single CEDT/CFMWS. +* This CEDT/SRAT describes one node for both devices. +* There is only one proximity domain the HMAT for both devices. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000200000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000200000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 0080 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Entry : 1200 + Entry : 0200 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 + Locality 1 : FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + } diff --git a/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst b/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst new file mode 100644 index 000000000000..aebda0eb3e17 --- /dev/null +++ b/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst @@ -0,0 +1,136 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +One Device per Host Bridge +========================== + +This system has a single socket with two CXL host bridges. Each host bridge +has a single CXL memory expander with a 4GB of memory. + +Things to note: + +* Cross-Bridge interleave is not being used. +* The expanders are in two separate but adjascent memory regions. +* This CEDT/SRAT describes one node per device +* The expanders have the same performance and will be in the same memory tier. + +:doc:`CEDT <../acpi/cedt>`:: + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000007 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010370400000 + Register length : 0000000000010000 + + Subtable Type : 00 [CXL Host Bridge Structure] + Reserved : 00 + Length : 0020 + Associated host bridge : 00000006 + Specification version : 00000001 + Reserved : 00000000 + Register base : 0000010380800000 + Register length : 0000000000010000 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001000000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000007 + + Subtable Type : 01 [CXL Fixed Memory Window Structure] + Reserved : 00 + Length : 002C + Reserved : 00000000 + Window base address : 0000001100000000 + Window size : 0000000100000000 + Interleave Members (2^n) : 00 + Interleave Arithmetic : 00 + Reserved : 0000 + Granularity : 00000000 + Restrictions : 0006 + QtgId : 0001 + First Target : 00000006 + +:doc:`SRAT <../acpi/srat>`:: + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000001 + Reserved1 : 0000 + Base Address : 0000001000000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + + Subtable Type : 01 [Memory Affinity] + Length : 28 + Proximity Domain : 00000002 + Reserved1 : 0000 + Base Address : 0000001100000000 + Address Length : 0000000100000000 + Reserved2 : 00000000 + Flags (decoded below) : 0000000B + Enabled : 1 + Hot Pluggable : 1 + Non-Volatile : 0 + +:doc:`HMAT <../acpi/hmat>`:: + + Structure Type : 0001 [SLLBI] + Data Type : 00 [Latency] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 0080 + Entry : 0100 + Entry : 0100 + + Structure Type : 0001 [SLLBI] + Data Type : 03 [Bandwidth] + Target Proximity Domain List : 00000000 + Target Proximity Domain List : 00000001 + Target Proximity Domain List : 00000002 + Entry : 1200 + Entry : 0200 + Entry : 0200 + +:doc:`SLIT <../acpi/slit>`:: + + Signature : "SLIT" [System Locality Information Table] + Localities : 0000000000000003 + Locality 0 : 10 20 20 + Locality 1 : FF 0A FF + Locality 2 : FF FF 0A + +:doc:`DSDT <../acpi/dsdt>`:: + + Scope (_SB) + { + Device (S0D0) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x07) // _UID: Unique ID + } + ... + Device (S0D5) + { + Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID + ... + Name (_UID, 0x06) // _UID: Unique ID + } + } diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/theory-of-operation.rst index d732c42526df..40793dad3630 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/theory-of-operation.rst @@ -1,9 +1,9 @@ .. SPDX-License-Identifier: GPL-2.0 .. include:: <isonum.txt> -=================================== -Compute Express Link Memory Devices -=================================== +=============================================== +Compute Express Link Driver Theory of Operation +=============================================== A Compute Express Link Memory Device is a CXL component that implements the CXL.mem protocol. It contains some amount of volatile memory, persistent memory, @@ -14,8 +14,8 @@ that optionally define a device's contribution to an interleaved address range across multiple devices underneath a host-bridge or interleaved across host-bridges. -CXL Bus: Theory of Operation -============================ +The CXL Bus +=========== Similar to how a RAID driver takes disk objects and assembles them into a new logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and assemble them into a CXL.mem decode topology. The need for runtime configuration @@ -347,6 +347,9 @@ CXL Core .. kernel-doc:: drivers/cxl/cxl.h :internal: +.. kernel-doc:: drivers/cxl/acpi.c + :identifiers: add_cxl_resources + .. kernel-doc:: drivers/cxl/core/hdm.c :doc: cxl core hdm @@ -371,12 +374,26 @@ CXL Core .. kernel-doc:: drivers/cxl/core/pmem.c :doc: cxl pmem +.. kernel-doc:: drivers/cxl/core/pmem.c + :identifiers: + .. kernel-doc:: drivers/cxl/core/regs.c :doc: cxl registers +.. kernel-doc:: drivers/cxl/core/regs.c + :identifiers: + .. kernel-doc:: drivers/cxl/core/mbox.c :doc: cxl mbox +.. kernel-doc:: drivers/cxl/core/mbox.c + :identifiers: + +.. kernel-doc:: drivers/cxl/core/features.c + :doc: cxl features + +See :c:func:`devm_cxl_setup_features` for API details. + CXL Regions ----------- .. kernel-doc:: drivers/cxl/core/region.c diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index d75728eb05f8..3d56f94ac2ee 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -391,12 +391,11 @@ PCI devm_pci_remap_cfgspace() : ioremap PCI configuration space devm_pci_remap_cfg_resource() : ioremap PCI configuration space resource - pcim_enable_device() : after success, some PCI ops become managed + pcim_enable_device() : after success, the PCI device gets disabled automatically on driver detach pcim_iomap() : do iomap() on a single BAR pcim_iomap_regions() : do request_region() and iomap() on multiple BARs pcim_iomap_table() : array of mapped addresses indexed by BAR pcim_iounmap() : do iounmap() on a single BAR - pcim_iounmap_regions() : do iounmap() and release_region() on multiple BARs pcim_pin_device() : keep PCI device enabled after release pcim_set_mwi() : enable Memory-Write-Invalidate PCI transaction diff --git a/Documentation/edac/memory_repair.rst b/Documentation/edac/memory_repair.rst index 52162a422864..5f8da7c9b186 100644 --- a/Documentation/edac/memory_repair.rst +++ b/Documentation/edac/memory_repair.rst @@ -119,3 +119,34 @@ sysfs Sysfs files are documented in `Documentation/ABI/testing/sysfs-edac-memory-repair`. + +Examples +-------- + +The memory repair usage takes the form shown in this example: + +1. CXL memory sparing + +Memory sparing is defined as a repair function that replaces a portion of +memory with a portion of functional memory at that same DPA. The subclass +for this operation, cacheline/row/bank/rank sparing, vary in terms of the +scope of the sparing being performed. + +Memory sparing maintenance operations may be supported by CXL devices that +implement CXL.mem protocol. A sparing maintenance operation requests the +CXL device to perform a repair operation on its media. For example, a CXL +device with DRAM components that support memory sparing features may +implement sparing maintenance operations. + +2. CXL memory Soft Post Package Repair (sPPR) + +Post Package Repair (PPR) maintenance operations may be supported by CXL +devices that implement CXL.mem protocol. A PPR maintenance operation +requests the CXL device to perform a repair operation on its media. +For example, a CXL device with DRAM components that support PPR features +may implement PPR Maintenance operations. Soft PPR (sPPR) is a temporary +row repair. Soft PPR may be faster, but the repair is lost with a power +cycle. + +Sysfs files for memory repair are documented in +`Documentation/ABI/testing/sysfs-edac-memory-repair` diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst index daab929cdba1..2cfa74fa1ffd 100644 --- a/Documentation/edac/scrub.rst +++ b/Documentation/edac/scrub.rst @@ -264,3 +264,79 @@ Sysfs files are documented in `Documentation/ABI/testing/sysfs-edac-scrub` `Documentation/ABI/testing/sysfs-edac-ecs` + +Examples +-------- + +The usage takes the form shown in these examples: + +1. CXL memory Patrol Scrub + +The following are the use cases identified why we might increase the scrub rate. + +- Scrubbing is needed at device granularity because a device is showing + unexpectedly high errors. + +- Scrubbing may apply to memory that isn't online at all yet. Likely this + is a system wide default setting on boot. + +- Scrubbing at a higher rate because the monitor software has determined that + more reliability is necessary for a particular data set. This is called + Differentiated Reliability. + +1.1. Device based scrubbing + +CXL memory is exposed to memory management subsystem and ultimately userspace +via CXL devices. Device-based scrubbing is used for the first use case +described in "Section 1 CXL Memory Patrol Scrub". + +When combining control via the device interfaces and region interfaces, +"see Section 1.2 Region based scrubbing". + +Sysfs files for scrubbing are documented in +`Documentation/ABI/testing/sysfs-edac-scrub` + +1.2. Region based scrubbing + +CXL memory is exposed to memory management subsystem and ultimately userspace +via CXL regions. CXL Regions represent mapped memory capacity in system +physical address space. These can incorporate one or more parts of multiple CXL +memory devices with traffic interleaved across them. The user may want to control +the scrub rate via this more abstract region instead of having to figure out the +constituent devices and program them separately. The scrub rate for each device +covers the whole device. Thus if multiple regions use parts of that device then +requests for scrubbing of other regions may result in a higher scrub rate than +requested for this specific region. + +Region-based scrubbing is used for the third use case described in +"Section 1 CXL Memory Patrol Scrub". + +Userspace must follow below set of rules on how to set the scrub rates for any +mixture of requirements. + +1. Taking each region in turn from lowest desired scrub rate to highest and set + their scrub rates. Later regions may override the scrub rate on individual + devices (and hence potentially whole regions). + +2. Take each device for which enhanced scrubbing is required (higher rate) and + set those scrub rates. This will override the scrub rates of individual devices, + setting them to the maximum rate required for any of the regions they help back, + unless a specific rate is already defined. + +Sysfs files for scrubbing are documented in +`Documentation/ABI/testing/sysfs-edac-scrub` + +2. CXL memory Error Check Scrub (ECS) + +The Error Check Scrub (ECS) feature enables a memory device to perform error +checking and correction (ECC) and count single-bit errors. The associated +memory controller sets the ECS mode with a trigger sent to the memory +device. CXL ECS control allows the host, thus the userspace, to change the +attributes for error count mode, threshold number of errors per segment +(indicating how many segments have at least that number of errors) for +reporting errors, and reset the ECS counter. Thus the responsibility for +initiating Error Check Scrub on a memory device may lie with the memory +controller or platform when unexpectedly high error rates are detected. + +Sysfs files for scrubbing are documented in +`Documentation/ABI/testing/sysfs-edac-ecs` diff --git a/Documentation/filesystems/fuse-passthrough.rst b/Documentation/filesystems/fuse-passthrough.rst new file mode 100644 index 000000000000..2b0e7c2da54a --- /dev/null +++ b/Documentation/filesystems/fuse-passthrough.rst @@ -0,0 +1,133 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +FUSE Passthrough +================ + +Introduction +============ + +FUSE (Filesystem in Userspace) passthrough is a feature designed to improve the +performance of FUSE filesystems for I/O operations. Typically, FUSE operations +involve communication between the kernel and a userspace FUSE daemon, which can +incur overhead. Passthrough allows certain operations on a FUSE file to bypass +the userspace daemon and be executed directly by the kernel on an underlying +"backing file". + +This is achieved by the FUSE daemon registering a file descriptor (pointing to +the backing file on a lower filesystem) with the FUSE kernel module. The kernel +then receives an identifier (``backing_id``) for this registered backing file. +When a FUSE file is subsequently opened, the FUSE daemon can, in its response to +the ``OPEN`` request, include this ``backing_id`` and set the +``FOPEN_PASSTHROUGH`` flag. This establishes a direct link for specific +operations. + +Currently, passthrough is supported for operations like ``read(2)``/``write(2)`` +(via ``read_iter``/``write_iter``), ``splice(2)``, and ``mmap(2)``. + +Enabling Passthrough +==================== + +To use FUSE passthrough: + + 1. The FUSE filesystem must be compiled with ``CONFIG_FUSE_PASSTHROUGH`` + enabled. + 2. The FUSE daemon, during the ``FUSE_INIT`` handshake, must negotiate the + ``FUSE_PASSTHROUGH`` capability and specify its desired + ``max_stack_depth``. + 3. The (privileged) FUSE daemon uses the ``FUSE_DEV_IOC_BACKING_OPEN`` ioctl + on its connection file descriptor (e.g., ``/dev/fuse``) to register a + backing file descriptor and obtain a ``backing_id``. + 4. When handling an ``OPEN`` or ``CREATE`` request for a FUSE file, the daemon + replies with the ``FOPEN_PASSTHROUGH`` flag set in + ``fuse_open_out::open_flags`` and provides the corresponding ``backing_id`` + in ``fuse_open_out::backing_id``. + 5. The FUSE daemon should eventually call ``FUSE_DEV_IOC_BACKING_CLOSE`` with + the ``backing_id`` to release the kernel's reference to the backing file + when it's no longer needed for passthrough setups. + +Privilege Requirements +====================== + +Setting up passthrough functionality currently requires the FUSE daemon to +possess the ``CAP_SYS_ADMIN`` capability. This requirement stems from several +security and resource management considerations that are actively being +discussed and worked on. The primary reasons for this restriction are detailed +below. + +Resource Accounting and Visibility +---------------------------------- + +The core mechanism for passthrough involves the FUSE daemon opening a file +descriptor to a backing file and registering it with the FUSE kernel module via +the ``FUSE_DEV_IOC_BACKING_OPEN`` ioctl. This ioctl returns a ``backing_id`` +associated with a kernel-internal ``struct fuse_backing`` object, which holds a +reference to the backing ``struct file``. + +A significant concern arises because the FUSE daemon can close its own file +descriptor to the backing file after registration. The kernel, however, will +still hold a reference to the ``struct file`` via the ``struct fuse_backing`` +object as long as it's associated with a ``backing_id`` (or subsequently, with +an open FUSE file in passthrough mode). + +This behavior leads to two main issues for unprivileged FUSE daemons: + + 1. **Invisibility to lsof and other inspection tools**: Once the FUSE + daemon closes its file descriptor, the open backing file held by the kernel + becomes "hidden." Standard tools like ``lsof``, which typically inspect + process file descriptor tables, would not be able to identify that this + file is still open by the system on behalf of the FUSE filesystem. This + makes it difficult for system administrators to track resource usage or + debug issues related to open files (e.g., preventing unmounts). + + 2. **Bypassing RLIMIT_NOFILE**: The FUSE daemon process is subject to + resource limits, including the maximum number of open file descriptors + (``RLIMIT_NOFILE``). If an unprivileged daemon could register backing files + and then close its own FDs, it could potentially cause the kernel to hold + an unlimited number of open ``struct file`` references without these being + accounted against the daemon's ``RLIMIT_NOFILE``. This could lead to a + denial-of-service (DoS) by exhausting system-wide file resources. + +The ``CAP_SYS_ADMIN`` requirement acts as a safeguard against these issues, +restricting this powerful capability to trusted processes. + +**NOTE**: ``io_uring`` solves this similar issue by exposing its "fixed files", +which are visible via ``fdinfo`` and accounted under the registering user's +``RLIMIT_NOFILE``. + +Filesystem Stacking and Shutdown Loops +-------------------------------------- + +Another concern relates to the potential for creating complex and problematic +filesystem stacking scenarios if unprivileged users could set up passthrough. +A FUSE passthrough filesystem might use a backing file that resides: + + * On the *same* FUSE filesystem. + * On another filesystem (like OverlayFS) which itself might have an upper or + lower layer that is a FUSE filesystem. + +These configurations could create dependency loops, particularly during +filesystem shutdown or unmount sequences, leading to deadlocks or system +instability. This is conceptually similar to the risks associated with the +``LOOP_SET_FD`` ioctl, which also requires ``CAP_SYS_ADMIN``. + +To mitigate this, FUSE passthrough already incorporates checks based on +filesystem stacking depth (``sb->s_stack_depth`` and ``fc->max_stack_depth``). +For example, during the ``FUSE_INIT`` handshake, the FUSE daemon can negotiate +the ``max_stack_depth`` it supports. When a backing file is registered via +``FUSE_DEV_IOC_BACKING_OPEN``, the kernel checks if the backing file's +filesystem stack depth is within the allowed limit. + +The ``CAP_SYS_ADMIN`` requirement provides an additional layer of security, +ensuring that only privileged users can create these potentially complex +stacking arrangements. + +General Security Posture +------------------------ + +As a general principle for new kernel features that allow userspace to instruct +the kernel to perform direct operations on its behalf based on user-provided +file descriptors, starting with a higher privilege requirement (like +``CAP_SYS_ADMIN``) is a conservative and common security practice. This allows +the feature to be used and tested while further security implications are +evaluated and addressed. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 32618512a965..11a599387266 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -99,6 +99,7 @@ Documentation for filesystem implementations. fuse fuse-io fuse-io-uring + fuse-passthrough inotify isofs nilfs2 diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 939b4b624fad..ddd799df6ce3 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -712,11 +712,6 @@ handle falling back from one source type to another. The members are: at a boundary with the filesystem structure (e.g. at the end of a Ceph object). It tells netfslib not to retile subrequests across it. - * ``NETFS_SREQ_SEEK_DATA_READ`` - - This is a hint from netfslib to the cache that it might want to try - skipping ahead to the next data (ie. using SEEK_DATA). - * ``error`` This is for the filesystem to store result of the subrequest. It should be diff --git a/Documentation/hwmon/acpi_power_meter.rst b/Documentation/hwmon/acpi_power_meter.rst index 8628c1161015..a91403a2a26f 100644 --- a/Documentation/hwmon/acpi_power_meter.rst +++ b/Documentation/hwmon/acpi_power_meter.rst @@ -37,9 +37,16 @@ arbitrary strings that ACPI provides with the meter. The measures/ directory contains symlinks to the devices that this meter measures. Some computers have the ability to enforce a power cap in hardware. If this is -the case, the `power[1-*]_cap` and related sysfs files will appear. When the -average power consumption exceeds the cap, an ACPI event will be broadcast on -the netlink event socket and a poll notification will be sent to the +the case, the `power[1-*]_cap` and related sysfs files will appear. +For information on enabling the power cap feature, refer to the description +of the "force_on_cap" option in the "Module Parameters" chapter. +To use the power cap feature properly, you need to set appropriate value +(in microWatts) to the `power[1-*]_cap` sysfs files. +The value must be within the range between the minimum value at `power[1-]_cap_min` +and the maximum value at `power[1-]_cap_max (both in microWatts)`. + +When the average power consumption exceeds the cap, an ACPI event will be +broadcast on the netlink event socket and a poll notification will be sent to the appropriate `power[1-*]_alarm` file to indicate that capping has begun, and the hardware has taken action to reduce power consumption. Most likely this will result in reduced performance. @@ -52,3 +59,19 @@ follows: `power[1-*]_cap` will be notified if the firmware changes the power cap. `power[1-*]_interval` will be notified if the firmware changes the averaging interval. + +Module Parameters +----------------- + +* force_cap_on: bool + Forcefully enable the power capping feature to specify + the upper limit of the system's power consumption. + + By default, the driver's power capping feature is only + enabled on IBM products. + Therefore, on other systems that support power capping, + you will need to use the option to enable it. + + Note: power capping is potentially unsafe feature. + Please check the platform specifications to make sure + that capping is supported before using this option. diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index d2be9db29614..816d1f9947ea 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -4,6 +4,7 @@ Kernel driver asus_ec_sensors ================================= Supported boards: + * MAXIMUS VI HERO * PRIME X470-PRO * PRIME X570-PRO * PRIME X670E-PRO WIFI @@ -20,6 +21,7 @@ Supported boards: * ROG CROSSHAIR X670E GENE * ROG MAXIMUS XI HERO * ROG MAXIMUS XI HERO (WI-FI) + * ROG MAXIMUS Z690 FORMULA * ROG STRIX B550-E GAMING * ROG STRIX B550-I GAMING * ROG STRIX X570-E GAMING diff --git a/Documentation/hwmon/ina238.rst b/Documentation/hwmon/ina238.rst index d9f479984420..d1b93cf8627f 100644 --- a/Documentation/hwmon/ina238.rst +++ b/Documentation/hwmon/ina238.rst @@ -14,6 +14,12 @@ Supported chips: Datasheet: https://www.ti.com/lit/gpn/ina238 + * Silergy SQ52206 + + Prefix: 'SQ52206' + + Addresses: I2C 0x40 - 0x4f + Author: Nathan Rossi <nathan.rossi@digi.com> Description @@ -54,3 +60,12 @@ temp1_input Die temperature measurement (mC) temp1_max Maximum die temperature threshold (mC) temp1_max_alarm Maximum die temperature alarm ======================= ======================================================= + +Additional sysfs entries for sq52206 +------------------------------------ + +======================= ======================================================= +energy1_input Energy measurement (mJ) + +power1_input_highest Peak Power (uW) +======================= ======================================================= diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index ffe1a756a4f9..b45bfb4ebf30 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -106,6 +106,8 @@ Hardware Monitoring Kernel Drivers jc42 k10temp k8temp + kbatt + kfan lan966x lineage-pem lm25066 @@ -125,6 +127,7 @@ Hardware Monitoring Kernel Drivers lm95234 lm95245 lochnagar + lt3074 lt7182s ltc2992 ltc2945 @@ -161,6 +164,7 @@ Hardware Monitoring Kernel Drivers max6639 max6650 max6697 + max77705 max8688 mc13783-adc mc34vr500 diff --git a/Documentation/hwmon/kbatt.rst b/Documentation/hwmon/kbatt.rst new file mode 100644 index 000000000000..b72718c5ede3 --- /dev/null +++ b/Documentation/hwmon/kbatt.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver kbatt +=================== + +Supported chips: + + * KEBA battery monitoring controller (IP core in FPGA) + + Prefix: 'kbatt' + +Authors: + + Gerhard Engleder <eg@keba.com> + Petar Bojanic <boja@keba.com> + +Description +----------- + +The KEBA battery monitoring controller is an IP core for FPGAs, which +monitors the health of a coin cell battery. The coin cell battery is +typically used to supply the RTC during power off to keep the current +time. E.g., the CP500 FPGA includes this IP core to monitor the coin cell +battery of PLCs and the corresponding cp500 driver creates an auxiliary +device for the kbatt driver. + +This driver provides information about the coin cell battery health to +user space. Actually the user space shall be informed that the coin cell +battery is nearly empty and needs to be replaced. + +The coin cell battery must be tested actively to get to know if its nearly +empty or not. Therefore, a load is put on the coin cell battery and the +resulting voltage is evaluated. This evaluation is done by some hard wired +analog logic, which compares the voltage to a defined limit. If the +voltage is above the limit, then the coin cell battery is assumed to be +ok. If the voltage is below the limit, then the coin cell battery is +nearly empty (or broken, removed, ...) and shall be replaced by a new one. +The KEBA battery monitoring controller allows to start the test of the +coin cell battery and to get the result if the voltage is above or below +the limit. The actual voltage is not available. Only the information if +the voltage is below a limit is available. + +The test load, which is put on the coin cell battery for the health check, +is similar to the load during power off. Therefore, the lifetime of the +coin cell battery is reduced directly by the duration of each test. To +limit the negative impact to the lifetime the test is limited to at most +once every 10 seconds. The test load is put on the coin cell battery for +100ms. Thus, in worst case the coin cell battery lifetime is reduced by +1% of the uptime or 3.65 days per year. As the coin cell battery lasts +multiple years, this lifetime reduction negligible. + +This driver only provides a single alarm attribute, which is raised when +the coin cell battery is nearly empty. + +====================== ==== =================================================== +Attribute R/W Contents +====================== ==== =================================================== +in0_min_alarm R voltage of coin cell battery under load is below + limit +====================== ==== =================================================== diff --git a/Documentation/hwmon/kfan.rst b/Documentation/hwmon/kfan.rst new file mode 100644 index 000000000000..ce02dddfb4b8 --- /dev/null +++ b/Documentation/hwmon/kfan.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver kfan +================== + +Supported chips: + + * KEBA fan controller (IP core in FPGA) + + Prefix: 'kfan' + +Authors: + + Gerhard Engleder <eg@keba.com> + Petar Bojanic <boja@keba.com> + +Description +----------- + +The KEBA fan controller is an IP core for FPGAs, which monitors the health +and controls the speed of a fan. The fan is typically used to cool the CPU +and the whole device. E.g., the CP500 FPGA includes this IP core to monitor +and control the fan of PLCs and the corresponding cp500 driver creates an +auxiliary device for the kfan driver. + +This driver provides information about the fan health to user space. +The user space shall be informed if the fan is removed or blocked. +Additionally, the speed in RPM is reported for fans with tacho signal. + +For fan control PWM is supported. For PWM 255 equals 100%. None-regulable +fans can be turned on with PWM 255 and turned off with PWM 0. + +====================== ==== =================================================== +Attribute R/W Contents +====================== ==== =================================================== +fan1_fault R Fan fault +fan1_input R Fan tachometer input (in RPM) +pwm1 RW Fan target duty cycle (0..255) +====================== ==== =================================================== diff --git a/Documentation/hwmon/lt3074.rst b/Documentation/hwmon/lt3074.rst new file mode 100644 index 000000000000..234f369153cf --- /dev/null +++ b/Documentation/hwmon/lt3074.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver lt3074 +==================== + +Supported chips: + + * Analog Devices LT3074 + + Prefix: 'lt3074' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt3074.html + +Authors: Cedric Encarnacion <cedricjustine.encarnacion@analog.com> + + +Description +----------- + +This driver supports hardware monitoring for Analog Devices LT3074 Linear +Regulator with PMBus interface. + +The LT3074 is a low voltage, ultra-low noise and ultra-fast transient +response linear regulator with PMBus serial interface. PMBus telemetry +feature provides information regarding the output voltage and current, +input voltage, bias voltage and die temperature. + +The driver is a client driver to the core PMBus driver. Please see +Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate +the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst +for details. + +Platform data support +--------------------- + +The driver supports standard PMBus driver platform data. + +Sysfs entries +------------- + +======================= ======================================================= +in1_label "vin" +in1_input Measured input voltage +in1_max Input overvoltage warning limit +in1_max_alarm Input overvoltage warning status +in1_min Input undervoltage warning limit +in1_min_alarm Input undervoltage warning status +in2_label "vmon" +in2_input Measured bias voltage +in2_max Bias overvoltage warning limit +in2_min Bias undervoltage warning limit +in3_label "vout1" +in3_input Measured output voltage +in3_max Output overvoltage warning limit +in3_max_alarm Output overvoltage warning status +in3_min Output undervoltage warning limit +in3_min_alarm Output undervoltage warning status +curr1_label "iout1" +curr1_input Measured output current. +curr1_crit Output overcurrent fault limit +curr1_crit_alarm Output overcurrent fault status +temp1_input Measured temperature +temp1_max Maximum temperature limit +temp1_max_alarm Overtemperature warning status +======================= ======================================================= diff --git a/Documentation/hwmon/max34440.rst b/Documentation/hwmon/max34440.rst index 162d289f0814..8591a7152ce5 100644 --- a/Documentation/hwmon/max34440.rst +++ b/Documentation/hwmon/max34440.rst @@ -3,6 +3,14 @@ Kernel driver max34440 Supported chips: + * ADI ADPM12160 + + Prefixes: 'adpm12160' + + Addresses scanned: - + + Datasheet: - + * Maxim MAX34440 Prefixes: 'max34440' @@ -67,13 +75,14 @@ Author: Guenter Roeck <linux@roeck-us.net> Description ----------- -This driver supports hardware monitoring for Maxim MAX34440 PMBus 6-Channel -Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager -and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger. -It also supports the MAX34451, MAX34460, and MAX34461 PMBus Voltage Monitor & -Sequencers. The MAX34451 supports monitoring voltage or current of 12 channels -based on GIN pins. The MAX34460 supports 12 voltage channels, and the MAX34461 -supports 16 voltage channels. +This driver supports multiple devices: hardware monitoring for Maxim MAX34440 +PMBus 6-Channel Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply +Manager and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data +Logger; PMBus Voltage Monitor and Sequencers for MAX34451, MAX34460, and +MAX34461; PMBus DC/DC Power Module ADPM12160. The MAX34451 supports monitoring +voltage or current of 12 channels based on GIN pins. The MAX34460 supports 12 +voltage channels, and the MAX34461 supports 16 voltage channels. The ADPM1260 +also monitors both input and output of voltage and current. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers. @@ -128,7 +137,10 @@ in[1-6]_highest Historical maximum voltage. in[1-6]_reset_history Write any value to reset history. ======================= ======================================================= -.. note:: MAX34446 only supports in[1-4]. +.. note:: + + - MAX34446 only supports in[1-4]. + - ADPM12160 only supports in[1-2]. Label is "vin1" and "vout1" respectively. Curr ~~~~ @@ -150,6 +162,7 @@ curr[1-6]_reset_history Write any value to reset history. - in6 and curr6 attributes only exist for MAX34440. - MAX34446 only supports curr[1-4]. + - For ADPM12160, curr[1] is "iin1" and curr[2-6] are "iout[1-5]. Power ~~~~~ @@ -185,6 +198,7 @@ temp[1-8]_reset_history Write any value to reset history. .. note:: - temp7 and temp8 attributes only exist for MAX34440. - MAX34446 only supports temp[1-3]. + - ADPM12160 only supports temp[1]. .. note:: diff --git a/Documentation/hwmon/max77705.rst b/Documentation/hwmon/max77705.rst new file mode 100644 index 000000000000..4a7680a340e1 --- /dev/null +++ b/Documentation/hwmon/max77705.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver max77705 +====================== + +Supported chips: + + * Maxim Integrated MAX77705 + + Prefix: 'max77705' + + Addresses scanned: none + + Datasheet: Not available + +Authors: + - Dzmitry Sankouski <dsankouski@gmail.com> + +Description +----------- + +The MAX77705 PMIC provides current and voltage measurements besides fuelgauge: +- chip input current +- system bus current and voltage +- VBYP voltage + +Sysfs Attributes +---------------- + +================= ======================================== +in1_label "vbyp" +in1_input Measured chip vbyp voltage +in2_label "vsys" +in2_input Measured chip system bus voltage +curr1_label "iin" +curr1_input Measured chip input current. +curr2_label "isys" +curr2_input Measured chip system bus current. +================= ======================================== diff --git a/Documentation/hwmon/mpq8785.rst b/Documentation/hwmon/mpq8785.rst index bf8176b87086..198d5dfd7c30 100644 --- a/Documentation/hwmon/mpq8785.rst +++ b/Documentation/hwmon/mpq8785.rst @@ -5,6 +5,8 @@ Kernel driver mpq8785 Supported chips: + * MPS MPM3695 family + * MPS MPM82504 * MPS MPQ8785 Prefix: 'mpq8785' @@ -14,6 +16,22 @@ Author: Charles Hsu <ythsu0511@gmail.com> Description ----------- +The MPM3695 family is a scalable, ultra-thin, fully integrated power module with +a PMBus interface. It offers a complete power solution that achieves up to +10A (-10 variant), 20A (-25 variant), 25A (-20 variant), 100A (-100 variant) +of output current with excellent load and line regulation across a wide input +voltage range. It operates at high efficiency over a wide load range, and can +be parallled to deliver higher current. Variants -10,-20 and -100 have different +voltage scale configuration register range (10 bits) than -25 version (11 bits). + +The MPM82504 is a quad 25A, scalable, fully integrated power module with a PMBus +interface. The device offers a complete power solution that achieves up to 25A +per output channel. The MPM82504 has four output channels that can be paralleled +to provide 50A, 75A, or 100A of output current for flexible configurations. +The device can also operate in parallel with the MPM3695-100 and additional +MPM82504 devices to provide a higher output current. The MPM82504 operates +at high efficiency across a wide load range. + The MPQ8785 is a fully integrated, PMBus-compatible, high-frequency, synchronous buck converter. The MPQ8785 offers a very compact solution that achieves up to 40A output current per phase, with excellent load and line regulation over a @@ -23,19 +41,16 @@ output current load range. The PMBus interface provides converter configurations and key parameters monitoring. -The MPQ8785 adopts MPS's proprietary multi-phase digital constant-on-time (MCOT) +The devices adopts MPS's proprietary multi-phase digital constant-on-time (MCOT) control, which provides fast transient response and eases loop stabilization. -The MCOT scheme also allows multiple MPQ8785 devices to be connected in parallel -with excellent current sharing and phase interleaving for high-current +The MCOT scheme also allows multiple devices or channels to be connected in +parallel with excellent current sharing and phase interleaving for high-current applications. Fully integrated protection features include over-current protection (OCP), over-voltage protection (OVP), under-voltage protection (UVP), and over-temperature protection (OTP). -The MPQ8785 requires a minimal number of readily available, standard external -components, and is available in a TLGA (5mmx6mm) package. - Device compliant with: - PMBus rev 1.3 interface. diff --git a/Documentation/input/devices/amijoy.rst b/Documentation/input/devices/amijoy.rst index 8df7b11cd98d..a81e9de481c7 100644 --- a/Documentation/input/devices/amijoy.rst +++ b/Documentation/input/devices/amijoy.rst @@ -1,14 +1,15 @@ -~~~~~~~~~~~~~~~~~~~~~~~~~ -Amiga joystick extensions -~~~~~~~~~~~~~~~~~~~~~~~~~ +=============== +Amiga joysticks +=============== +Pinouts +======= -Amiga 4-joystick parport extension -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Amiga 4-joystick parallel port extension +---------------------------------------- Parallel port pins: - ===== ======== ==== ========== Pin Meaning Pin Meaning ===== ======== ==== ========== @@ -17,11 +18,11 @@ Pin Meaning Pin Meaning 4 Left1 8 Left2 5 Right1 9 Right2 13 Fire1 11 Fire2 -18 Gnd1 18 Gnd2 +19 Gnd1 18 Gnd2 ===== ======== ==== ========== -Amiga digital joystick pinout -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Amiga digital joystick +---------------------- === ============ Pin Meaning @@ -37,8 +38,8 @@ Pin Meaning 9 Thumb button === ============ -Amiga mouse pinout -~~~~~~~~~~~~~~~~~~ +Amiga mouse +----------- === ============ Pin Meaning @@ -54,8 +55,8 @@ Pin Meaning 9 Right button === ============ -Amiga analog joystick pinout -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Amiga analog joystick +--------------------- === ============== Pin Meaning @@ -71,8 +72,8 @@ Pin Meaning 9 Analog Y === ============== -Amiga lightpen pinout -~~~~~~~~~~~~~~~~~~~~~ +Amiga lightpen +-------------- === ============= Pin Meaning @@ -88,19 +89,23 @@ Pin Meaning 9 Stylus button === ============= -------------------------------------------------------------------------------- +Register addresses +================== + +JOY0DAT/JOY1DAT +--------------- -======== === ==== ==== ====== ======================================== +======== === ==== ==== ====== =========================================== NAME rev ADDR type chip Description -======== === ==== ==== ====== ======================================== -JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert, horiz) -JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz) -======== === ==== ==== ====== ======================================== +======== === ==== ==== ====== =========================================== +JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert., horiz.) +JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert., horiz.) +======== === ==== ==== ====== =========================================== These addresses each read a 16 bit register. These in turn are loaded from the MDAT serial stream and are clocked in on the rising edge of SCLK. MLD output is used to parallel load - the external parallel-to-serial converter.This in turn is + the external parallel-to-serial converter. This in turn is loaded with the 4 quadrature inputs from each of two game controller ports (8 total) plus 8 miscellaneous control bits which are new for LISA and can be read in upper 8 bits of @@ -108,7 +113,7 @@ JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz) Register bits are as follows: - - Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock) + - Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock) ======== === === === === === === === === ====== === === === === === === === BIT# 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 @@ -123,7 +128,7 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 clocked by 2 of the signals input from the mouse serial stream. Starting with first bit received: - +-------------------+-----------------------------------------+ + +--------+----------+-----------------------------------------+ | Serial | Bit Name | Description | +========+==========+=========================================+ | 0 | M0H | JOY0DAT Horizontal Clock | @@ -160,7 +165,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 | Right | 4 | X1 | +------------+------+---------------------------------+ -------------------------------------------------------------------------------- +JOYTEST +------- ======== === ==== ==== ====== ================================================= NAME rev ADDR type chip Description @@ -177,14 +183,15 @@ JOYTEST 036 W Denise Write to all 4 joystick-mouse counters at once. JOYxDAT Y7 Y6 Y5 Y4 Y3 Y2 xx xx X7 X6 X5 X4 X3 X2 xx xx ========= === === === === === === === === ====== === === === === === === === -------------------------------------------------------------------------------- +POT0DAT/POT1DAT +--------------- -======= === ==== ==== ====== ======================================== +======= === ==== ==== ====== =========================================== NAME rev ADDR type chip Description -======= === ==== ==== ====== ======================================== -POT0DAT h 012 R Paula Pot counter data left pair (vert, horiz) -POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz) -======= === ==== ==== ====== ======================================== +======= === ==== ==== ====== =========================================== +POT0DAT h 012 R Paula Pot counter data left pair (vert., horiz.) +POT1DAT h 014 R Paula Pot counter data right pair (vert., horiz.) +======= === ==== ==== ====== =========================================== These addresses each read a pair of 8 bit pot counters. (4 counters total). The bit assignment for both @@ -213,12 +220,13 @@ POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz) +-------+------+-----+-----+-------+ With normal (NTSC or PAL) horiz. line rate, the pots will - give a full scale (FF) reading with about 500kohms in one - frame time. With proportionally faster horiz line times, + give a full scale (FF) reading with about 500k ohm in one + frame time. With proportionally faster horiz. line times, the counters will count proportionally faster. This should be noted when doing variable beam displays. -------------------------------------------------------------------------------- +POTGO +----- ====== === ==== ==== ====== ================================================ NAME rev ADDR type chip Description @@ -227,7 +235,8 @@ POTGO 034 W Paula Pot port (4 bit) bi-direction and data, and pot counter start. ====== === ==== ==== ====== ================================================ -------------------------------------------------------------------------------- +POTINP +------ ====== === ==== ==== ====== ================================================ NAME rev ADDR type chip Description @@ -238,26 +247,26 @@ POTINP 016 R Paula Pot pin data read This register controls a 4 bit bi-direction I/O port that shares the same 4 pins as the 4 pot counters above. - +-------+----------+---------------------------------------------+ - | BIT# | FUNCTION | DESCRIPTION | - +=======+==========+=============================================+ - | 15 | OUTRY | Output enable for Paula pin 33 | - +-------+----------+---------------------------------------------+ - | 14 | DATRY | I/O data Paula pin 33 | - +-------+----------+---------------------------------------------+ - | 13 | OUTRX | Output enable for Paula pin 32 | - +-------+----------+---------------------------------------------+ - | 12 | DATRX | I/O data Paula pin 32 | - +-------+----------+---------------------------------------------+ - | 11 | OUTLY | Out put enable for Paula pin 36 | - +-------+----------+---------------------------------------------+ - | 10 | DATLY | I/O data Paula pin 36 | - +-------+----------+---------------------------------------------+ - | 09 | OUTLX | Output enable for Paula pin 35 | - +-------+----------+---------------------------------------------+ - | 08 | DATLX | I/O data Paula pin 35 | - +-------+----------+---------------------------------------------+ - | 07-01 | X | Not used | - +-------+----------+---------------------------------------------+ - | 00 | START | Start pots (dump capacitors,start counters) | - +-------+----------+---------------------------------------------+ + +-------+----------+----------------------------------------------+ + | BIT# | FUNCTION | DESCRIPTION | + +=======+==========+==============================================+ + | 15 | OUTRY | Output enable for Paula pin 33 | + +-------+----------+----------------------------------------------+ + | 14 | DATRY | I/O data Paula pin 33 | + +-------+----------+----------------------------------------------+ + | 13 | OUTRX | Output enable for Paula pin 32 | + +-------+----------+----------------------------------------------+ + | 12 | DATRX | I/O data Paula pin 32 | + +-------+----------+----------------------------------------------+ + | 11 | OUTLY | Out put enable for Paula pin 36 | + +-------+----------+----------------------------------------------+ + | 10 | DATLY | I/O data Paula pin 36 | + +-------+----------+----------------------------------------------+ + | 09 | OUTLX | Output enable for Paula pin 35 | + +-------+----------+----------------------------------------------+ + | 08 | DATLX | I/O data Paula pin 35 | + +-------+----------+----------------------------------------------+ + | 07-01 | X | Not used | + +-------+----------+----------------------------------------------+ + | 00 | START | Start pots (dump capacitors, start counters) | + +-------+----------+----------------------------------------------+ diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index 0ab0a2128a11..76fae171039c 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -28,5 +28,5 @@ LEDs leds-mlxcpld leds-mt6370-rgb leds-sc27xx - leds-st1202.rst + leds-st1202 leds-qcom-lpg diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst index 3713adaa1608..40282cca86ca 100644 --- a/Documentation/staging/rpmsg.rst +++ b/Documentation/staging/rpmsg.rst @@ -112,31 +112,6 @@ Returns 0 on success and an appropriate error value on failure. :: - int rpmsg_send_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, - void *data, int len); - - -sends a message across to the remote processor, using the src and dst -addresses provided by the user. - -The caller should specify the endpoint, the data it wants to send, -its length (in bytes), and explicit source and destination addresses. -The message will then be sent to the remote processor to which the -endpoint's channel belongs, but the endpoint's src and channel dst -addresses will be ignored (and the user-provided addresses will -be used instead). - -In case there are no TX buffers available, the function will block until -one becomes available (i.e. until the remote processor consumes -a tx buffer and puts it back on virtio's used descriptor ring), -or a timeout of 15 seconds elapses. When the latter happens, --ERESTARTSYS is returned. - -The function can only be called from a process context (for now). -Returns 0 on success and an appropriate error value on failure. - -:: - int rpmsg_trysend(struct rpmsg_endpoint *ept, void *data, int len); sends a message across to the remote processor from a given endpoint. @@ -175,27 +150,6 @@ Returns 0 on success and an appropriate error value on failure. :: - int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, - void *data, int len); - - -sends a message across to the remote processor, using source and -destination addresses provided by the user. - -The user should specify the channel, the data it wants to send, -its length (in bytes), and explicit source and destination addresses. -The message will then be sent to the remote processor to which the -channel belongs, but the channel's src and dst addresses will be -ignored (and the user-provided addresses will be used instead). - -In case there are no TX buffers available, the function will immediately -return -ENOMEM without waiting until one becomes available. - -The function can only be called from a process context (for now). -Returns 0 on success and an appropriate error value on failure. - -:: - struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev, rpmsg_rx_cb_t cb, void *priv, struct rpmsg_channel_info chinfo); diff --git a/Documentation/virt/hyperv/vmbus.rst b/Documentation/virt/hyperv/vmbus.rst index 1dcef6a7fda3..654bb4849972 100644 --- a/Documentation/virt/hyperv/vmbus.rst +++ b/Documentation/virt/hyperv/vmbus.rst @@ -250,10 +250,18 @@ interrupts are not Linux IRQs, there are no entries in /proc/interrupts or /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. +VMBus channel interrupts assigned to it. Starting in kernel v6.15, +any such interrupts are automatically reassigned to some other CPU +at the time of offlining. The "other" CPU is chosen by the +implementation and is not load balanced or otherwise intelligently +determined. If the CPU is onlined again, channel interrupts previously +assigned to it are not moved back. As a result, after multiple CPUs +have been offlined, and perhaps onlined again, the interrupt-to-CPU +mapping may be scrambled and non-optimal. In such a case, optimal +assignments must be re-established manually. For kernels v6.14 and +earlier, any conflicting channel interrupts must first be manually +reassigned to another CPU as described above. Then when no channel +interrupts are assigned to the CPU, it can be taken offline. The VMBus channel interrupt handling code is designed to work correctly even if an interrupt is received on a CPU other than the @@ -324,3 +332,15 @@ 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(). + +For some devices, such as the KVP device, Hyper-V automatically +sends a rescind message when the primary channel is closed, +likely as a result of unbinding the device from its driver. +The rescind causes Linux to remove the device. But then Hyper-V +immediately reoffers the device to the guest, causing a new +instance of the device to be created in Linux. For other +devices, such as the synthetic SCSI and NIC devices, closing the +primary channel does *not* result in Hyper-V sending a rescind +message. The device continues to exist in Linux on the VMBus, +but with no driver bound to it. The same driver or a new driver +can subsequently be bound to the existing instance of the device. diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 6fb1870f0999..1bd2d42e6424 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8001,6 +8001,11 @@ apply some other policy-based mitigation. When exiting to userspace, KVM sets KVM_RUN_X86_BUS_LOCK in vcpu-run->flags, and conditionally sets the exit_reason to KVM_EXIT_X86_BUS_LOCK. +Due to differences in the underlying hardware implementation, the vCPU's RIP at +the time of exit diverges between Intel and AMD. On Intel hosts, RIP points at +the next instruction, i.e. the exit is trap-like. On AMD hosts, RIP points at +the offending instruction, i.e. the exit is fault-like. + Note! Detected bus locks may be coincident with other exits to userspace, i.e. KVM_RUN_X86_BUS_LOCK should be checked regardless of the primary exit reason if userspace wants to take action on all detected bus locks. |