dt-bindings: PCI: Convert generic host binding to DT schema

* ARM Juno R1 PCIe interface

This PCIe host controller is based on PLDA XpressRICH3-AXI IP

and thus inherits all the common properties defined in plda,xpressrich3-axi.txt

as well as the base properties defined in host-generic-pci.txt.

Required properties:

 - compatible: "arm,juno-r1-pcie"

 - dma-coherent: The host controller bridges the AXI transactions into PCIe bus

   in a manner that makes the DMA operations to appear coherent to the CPUs.

* Synopsys DesignWare PCIe root complex in ECAM shift mode

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.

Required properties:

- compatible: "marvell,armada8k-pcie-ecam" or

              "socionext,synquacer-pcie-ecam" or

              "snps,dw-pcie-ecam" (must be preceded by a more specific match)

Please refer to the binding document of "pci-host-ecam-generic" in the

file host-generic-pci.txt for a description of the remaining required

and optional properties.

Example:

    pcie1: pcie@7f000000 {

        compatible = "socionext,synquacer-pcie-ecam", "snps,dw-pcie-ecam";

        device_type = "pci";

        reg = <0x0 0x7f000000 0x0 0xf00000>;

        bus-range = <0x0 0xe>;

        #address-cells = <3>;

        #size-cells = <2>;

        ranges = <0x1000000 0x00 0x00010000 0x00 0x7ff00000 0x0 0x00010000>,

                 <0x2000000 0x00 0x70000000 0x00 0x70000000 0x0 0x0f000000>,

                 <0x3000000 0x3f 0x00000000 0x3f 0x00000000 0x1 0x00000000>;

        #interrupt-cells = <0x1>;

        interrupt-map-mask = <0x0 0x0 0x0 0x0>;

        interrupt-map = <0x0 0x0 0x0 0x0 &gic 0x0 0x0 0x0 182 0x4>;

        msi-map = <0x0 &its 0x0 0x10000>;

        dma-coherent;

    };

				 0x0 0 0 3 &mbigen_pcie 3 12

				 0x0 0 0 4 &mbigen_pcie 4 13>;

	};

HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description.

Some BIOSes place the host controller in a mode where it is ECAM

compliant for all devices other than the root complex. In such cases,

the host controller should be described as below.

The properties and their meanings are identical to those described in

host-generic-pci.txt except as listed below.

Properties of the host controller node that differ from

host-generic-pci.txt:

- compatible     : Must be "hisilicon,hip06-pcie-ecam", or

		   "hisilicon,hip07-pcie-ecam"

- reg            : Two entries: First the ECAM configuration space for any

		   other bus underneath the root bus. Second, the base

		   and size of the HiSilicon host bridge registers include

		   the RC's own config space.

Example:

	pcie0: pcie@a0090000 {

		compatible = "hisilicon,hip06-pcie-ecam";

		reg = <0 0xb0000000 0 0x2000000>,  /*  ECAM configuration space */

		      <0 0xa0090000 0 0x10000>; /* host bridge registers */

		bus-range = <0  31>;

		msi-map = <0x0000 &its_dsa 0x0000 0x2000>;

		msi-map-mask = <0xffff>;

		#address-cells = <3>;

		#size-cells = <2>;

		device_type = "pci";

		dma-coherent;

		ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000

			  0x01000000 0 0 0 0xb7ff0000 0 0x10000>;

		#interrupt-cells = <1>;

		interrupt-map-mask = <0xf800 0 0 7>;

		interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4

				 0x0 0 0 2 &mbigen_pcie0 650 4

				 0x0 0 0 3 &mbigen_pcie0 650 4

				 0x0 0 0 4 &mbigen_pcie0 650 4>;

	};

* Generic PCI host controller

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.

Such a controller can be described purely in terms of the standardized device

tree bindings communicated in pci.txt:

Properties of the host controller node:

- compatible     : Must be "pci-host-cam-generic" or "pci-host-ecam-generic"

                   depending on the layout of configuration space (CAM vs

                   ECAM respectively).

- device_type    : Must be "pci".

- ranges         : 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.

- bus-range      : Optional property (also described in IEEE Std 1275-1994)

                   to indicate the range of bus numbers for this controller.

                   If absent, defaults to <0 255> (i.e. all buses).

- #address-cells : Must be 3.

- #size-cells    : Must be 2.

- reg            : 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).

Properties of the /chosen node:

- linux,pci-probe-only

                 : Optional property which takes a single-cell argument.

                   If '0', then Linux will assign devices in its usual manner,

                   otherwise it will not try to assign devices and instead use

                   them as they are configured already.

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

Interrupt mapping is exactly as described in `Open Firmware Recommended

Practice: Interrupt Mapping' and requires the following properties:

- #interrupt-cells   : Must be 1

- interrupt-map      : <see aforementioned specification>

- interrupt-map-mask : <see aforementioned specification>

Example:

pci {

    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>;

}

# 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

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

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>;

        };

    };

...