[PATCH v4 3/4] dt-bindings: pci: Add DT bindings for apple,pcie
Marc Zyngier
maz at kernel.org
Sun Sep 12 13:13:17 PDT 2021
On Wed, 01 Sep 2021 12:29:22 +0100,
Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > Date: Tue, 31 Aug 2021 16:21:28 -0500
> > From: Rob Herring <robh at kernel.org>
> >
> > On Fri, Aug 27, 2021 at 07:15:28PM +0200, Mark Kettenis wrote:
> > > From: Mark Kettenis <kettenis at 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 at openbsd.org>
> > > ---
> > > .../devicetree/bindings/pci/apple,pcie.yaml | 165 ++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 2 files changed, 166 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..97a126db935a
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> > > @@ -0,0 +1,165 @@
> > > +# 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 at 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.
> > > +
> > > + 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
> > > + the child nodes that represent the PCI bridges that correspond to
> > > + the individual root ports.
> > > +
> > > + 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#
> > > + - $ref: ../interrupt-controller/msi-controller.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-parent: true
> >
> > I still think this should be dropped as it is meaningless with
> > 'msi-controller' present.
>
> Hmm. As far as I can tell all current arm64 device trees that
> describe hardware with an MSI controller integrated on the PCI host
> bridge have both the 'msi-controller' and 'msi-parent' properties.
> See arch/arm64/boot/dts/marvell/aramada-37xx.dtsi and
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi.
>
> The current OpenBSD code will fail to map the MSIs if 'msi-parent'
> isn't there, although Linux seems to fall back on an MSI domain that's
> directly attached to the host bridge if the 'msi-parent' property is
> missing. I think it makes sense to be explicit here, but if both you
> and Marc think it shouldn't be there, I probably can change the
> OpenBSD to do a similar fallback.
I think this matches the behaviour we have for interrupt-controller vs
interrupt-parent. I fail to see why msi-controller/msi-parent should
behave differently. And since there is an established OS that actually
requires this, I don't see how we can today make it illegal.
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list