Re: [PATCH v3 1/2] dt-bindings: pci: Add DT bindings for apple,pcie

Rob Herring
2021-07-26T23:19:03Z

On Mon, Jul 26, 2021 at 10:32:00AM +0200, Mark Kettenis wrote:
> From: Mark Kettenis <kettenis@openbsd.org>
>
> The Apple PCIe host controller is a PCIe host controller with
> multiple root ports present in Apple ARM SoC platforms, including
> various iPhone and iPad devices and the "Apple Silicon" Macs.
>
> Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> ---
> .../devicetree/bindings/pci/apple,pcie.yaml | 166 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 167 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/apple,pcie.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> new file mode 100644
> index 000000000000..bfcbdee79c64
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> @@ -0,0 +1,166 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/apple,pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple PCIe host controller
> +
> +maintainers:
> + - Mark Kettenis <kettenis@openbsd.org>
> +
> +description: |
> + The Apple PCIe host controller is a PCIe host controller with
> + multiple root ports present in Apple ARM SoC platforms, including
> + various iPhone and iPad devices and the "Apple Silicon" Macs.
> + The controller incorporates Synopsys DesigWare PCIe logic to
> + implements its root ports. But the ATU found on most DesignWare
> + PCIe host bridges is absent.

blank line

> + 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-gpio" and "max-link-speed" properties appear on

reset-gpios

> + the child nodes that represent the PCI bridges that correspond to
> + the individual root ports.

blank line

> + MSIs are handled by the PCIe controller and translated into regular
> + interrupts. A range of 32 MSIs is provided. These 32 MSIs can be
> + distributed over the root ports as the OS sees fit by programming
> + the PCIe controller's port registers.
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> +
> +properties:
> + compatible:
> + items:
> + - const: apple,t8103-pcie
> + - const: apple,pcie
> +
> + reg:
> + minItems: 3
> + maxItems: 5
> +
> + reg-names:
> + minItems: 3
> + maxItems: 5
> + items:
> + - const: config
> + - const: rc
> + - const: port0
> + - const: port1
> + - const: port2
> +
> + ranges:
> + minItems: 2
> + maxItems: 2
> +
> + interrupts:
> + description:
> + Interrupt specifiers, one for each root port.
> + minItems: 1
> + maxItems: 3
> +
> + msi-controller: true
> + msi-parent: true
> +
> + msi-ranges:
> + description:
> + A list of pairs <intid span>, where "intid" is the first
> + interrupt number that can be used as an MSI, and "span" the size
> + of that range.
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + items:
> + minItems: 2
> + maxItems: 2

I still have issues I raised on v1 with this property. It's genericish
looking, but not generic. 'intid' as a single cell can't specify any
parent interrupt such as a GIC which uses 3 cells. You could put in all
the cells, but you'd still be assuming which cell you can increment.

I think you should just list all these under 'interrupts' using
interrupt-names to make your life easier:

interrupt-names:
items:
- const: port0
- const: port1
- const: port2
- const: msi0
- const: msi1
- const: msi2
- const: msi3
...

Yeah, it's kind of verbose, but if the h/w block handles N interrupts,
you should list N interrupts. The worst case for the above is N entries
too if not contiguous.

Rob