Loading...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 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>; }; }; ... |