diff options
Diffstat (limited to 'Documentation/devicetree/bindings/pci/host-generic-pci.yaml')
| -rw-r--r-- | Documentation/devicetree/bindings/pci/host-generic-pci.yaml | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml new file mode 100644 index 000000000..d25423aa7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml @@ -0,0 +1,177 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/host-generic-pci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic PCI host controller + +maintainers: + - Will Deacon <will@kernel.org> + +description: | + Firmware-initialised PCI host controllers and PCI emulations, such as the + virtio-pci implementations found in kvmtool and other para-virtualised + systems, do not require driver support for complexities such as regulator + and clock management. In fact, the controller may not even require the + configuration of a control interface by the operating system, instead + presenting a set of fixed windows describing a subset of IO, Memory and + Configuration Spaces. + + Configuration Space is assumed to be memory-mapped (as opposed to being + accessed via an ioport) and laid out with a direct correspondence to the + geography of a PCI bus address by concatenating the various components to + form an offset. + + For CAM, this 24-bit offset is: + + cfg_offset(bus, device, function, register) = + bus << 16 | device << 11 | function << 8 | register + + While ECAM extends this by 4 bits to accommodate 4k of function space: + + cfg_offset(bus, device, function, register) = + bus << 20 | device << 15 | function << 12 | register + +properties: + compatible: + description: Depends on the layout of configuration space (CAM vs ECAM + respectively). May also have more specific compatibles. + oneOf: + - description: + PCIe host controller in Arm Juno based on PLDA XpressRICH3-AXI IP + items: + - const: arm,juno-r1-pcie + - const: plda,xpressrich3-axi + - const: pci-host-ecam-generic + - description: | + ThunderX PCI host controller for pass-1.x silicon + + Firmware-initialized PCI host controller to on-chip devices found on + some Cavium ThunderX processors. These devices have ECAM-based config + access, but the BARs are all at fixed addresses. We handle the fixed + addresses by synthesizing Enhanced Allocation (EA) capabilities for + these devices. + const: cavium,pci-host-thunder-ecam + - description: + Cavium ThunderX PEM firmware-initialized PCIe host controller + const: cavium,pci-host-thunder-pem + - description: + HiSilicon Hip06/Hip07 PCIe host bridge in almost-ECAM mode. Some + firmware places the host controller in a mode where it is ECAM + compliant for all devices other than the root complex. + enum: + - hisilicon,hip06-pcie-ecam + - hisilicon,hip07-pcie-ecam + - description: | + In some cases, firmware may already have configured the Synopsys + DesignWare PCIe controller in RC mode with static ATU window mappings + that cover all config, MMIO and I/O spaces in a [mostly] ECAM + compatible fashion. In this case, there is no need for the OS to + perform any low level setup of clocks, PHYs or device registers, nor + is there any reason for the driver to reconfigure ATU windows for + config and/or IO space accesses at runtime. + + In cases where the IP was synthesized with a minimum ATU window size + of 64 KB, it cannot be supported by the generic ECAM driver, because + it requires special config space accessors that filter accesses to + device #1 and beyond on the first bus. + items: + - enum: + - marvell,armada8k-pcie-ecam + - socionext,synquacer-pcie-ecam + - const: snps,dw-pcie-ecam + - description: + CAM or ECAM compliant PCI host controllers without any quirks + enum: + - pci-host-cam-generic + - pci-host-ecam-generic + + reg: + description: + The Configuration Space base address and size, as accessed from the parent + bus. The base address corresponds to the first bus in the "bus-range" + property. If no "bus-range" is specified, this will be bus 0 (the + default). Some host controllers have a 2nd non-compliant address range, + so 2 entries are allowed. + minItems: 1 + maxItems: 2 + + ranges: + description: + As described in IEEE Std 1275-1994, but must provide at least a + definition of non-prefetchable memory. One or both of prefetchable Memory + and IO Space may also be provided. + minItems: 1 + maxItems: 3 + + dma-coherent: true + iommu-map: true + iommu-map-mask: true + msi-parent: true + +required: + - compatible + - reg + - ranges + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + - if: + properties: + compatible: + contains: + const: arm,juno-r1-pcie + then: + required: + - dma-coherent + + - if: + properties: + compatible: + not: + contains: + enum: + - cavium,pci-host-thunder-pem + - hisilicon,hip06-pcie-ecam + - hisilicon,hip07-pcie-ecam + then: + properties: + reg: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + + bus { + #address-cells = <2>; + #size-cells = <2>; + pcie@40000000 { + compatible = "pci-host-cam-generic"; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x0 0x1>; + + // CPU_PHYSICAL(2) SIZE(2) + reg = <0x0 0x40000000 0x0 0x1000000>; + + // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2) + ranges = <0x01000000 0x0 0x01000000 0x0 0x01000000 0x0 0x00010000>, + <0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>; + + #interrupt-cells = <0x1>; + + // PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3) + interrupt-map = < 0x0 0x0 0x0 0x1 &gic 0x0 0x4 0x1>, + < 0x800 0x0 0x0 0x1 &gic 0x0 0x5 0x1>, + <0x1000 0x0 0x0 0x1 &gic 0x0 0x6 0x1>, + <0x1800 0x0 0x0 0x1 &gic 0x0 0x7 0x1>; + + // PCI_DEVICE(3) INT#(1) + interrupt-map-mask = <0xf800 0x0 0x0 0x7>; + }; + }; +... |