From: Mark Kettenis <hidden> Date: 2021-08-27 17:15:49
From: Mark Kettenis <redacted>
This small series adds bindings for the PCIe controller found on the
Apple M1 SoC.
At this point, the primary consumer for these bindings is U-Boot.
With these bindings U-Boot can bring up the links for the root ports
of the PCIe root complex. A simple OS driver can then provide
standard ECAM access and manage MSI interrupts to provide access
to the built-in Ethernet and XHCI controllers of the Mac mini.
The Apple controller incorporates Synopsys Designware PCIe logic
to implement its root port. But unlike other hardware currently
supported by U-Boot and the Linux kernel the Apple hardware
integrates multiple root ports. As such the existing bindings
for the DWC PCIe interface can't be used. There is a single ECAM
space for all root space, but separate GPIOs to take the PCI devices
on those ports out of reset. Therefore the standard "reset-gpio" and
"max-link-speed" properties appear on the child nodes representing
the PCI devices 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 port registers.
This now adds an MSI controller binding schema and uses the generic
msi-ranges property to specify how the MSIs are mapped to interrupts
on the AIC. I copied some of the description text in the MSI
controller binding schema from msi.txt but it may need some further
tweaks to make sense.
Patch 2/2 of this series depends on the pinctrl series I sent earlier
and will probably go through Hector Martin's Apple M1 SoC tree.
Changelog:
v4: - Convert MSI controller binding to YAML
- Add generic msi-ranges property to MSI controller binding
- Fix typos/formatting in apple,pcie binding
- Use generic MSI controller binding in apple,pcie
v3: - Remove unneeded include in example
v2: - Adjust name for ECAM in "reg-names"
- Drop "phy" registers
- Expand description
- Add description for "interrupts"
- Fix incorrect minItems for "interrupts"
- Fix incorrect MaxItems for "reg-names"
- Document the use of "msi-controller", "msi-parent", "iommu-map" and
"iommu-map-mask"
- Fix "bus-range" and "iommu-map" properties in the example
Mark Kettenis (4):
dt-bindings: interrupt-controller: Convert MSI controller to
json-schema
dt-bindings: interrupt-controller: msi: Add msi-ranges property
dt-bindings: pci: Add DT bindings for apple,pcie
arm64: apple: Add PCIe node
.../interrupt-controller/msi-controller.yaml | 42 +++++
.../devicetree/bindings/pci/apple,pcie.yaml | 165 ++++++++++++++++++
.../bindings/pci/brcm,stb-pcie.yaml | 1 +
.../bindings/pci/microchip,pcie-host.yaml | 1 +
MAINTAINERS | 1 +
arch/arm64/boot/dts/apple/t8103.dtsi | 63 +++++++
6 files changed, 273 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/msi-controller.yaml
create mode 100644 Documentation/devicetree/bindings/pci/apple,pcie.yaml
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -0,0 +1,34 @@+# SPDX-License-Identifier: BSD-2-Clause+%YAML1.2+---+$id:http://devicetree.org/schemas/interrupt-controller/msi-controller.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:MSI controller++maintainers:+-Marc Zyngier <marc.zyngier@arm.com>++description:|+An MSI controller signals interrupts to a CPU when a write is made+to an MMIO address by some master. An MSI controller may feature a+number of doorbells.++properties:+"#msi-cells":+description:|+The number of cells in an msi-specifier, required if not zero.++Typically this will encode information related to sideband data,+and will not encode doorbells or payloads as these can be+configured dynamically.++The meaning of the msi-specifier is defined by the device tree+binding of the specific MSI controller.++msi-controller:+description:+Identifies the node as an MSI controller.+$ref:/schemas/types.yaml#/definitions/flag++additionalProperties:true
From: Mark Kettenis <hidden> Date: 2021-08-27 17:15:59
From: Mark Kettenis <redacted>
Update the MSI controller binding to add an msi-ranges property
that specifies how MSIs map onto regular interrupts on some other
interrupt controller.
Signed-off-by: Mark Kettenis <redacted>
---
.../bindings/interrupt-controller/msi-controller.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
@@ -31,4 +31,12 @@ properties:Identifies the node as an MSI controller.$ref:/schemas/types.yaml#/definitions/flag+msi-ranges:+description:+A list of pairs <intid span>, where "intid" is the specification+of the first interrupt (including the phandle for the interrupt+controller) that can be used as an MSI, and "span" the size of+that range. Multiple ranges can be provided.+$ref:/schemas/types.yaml#/definitions/phandle-array+additionalProperties:true
--
2.32.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Kettenis <hidden> Date: 2021-08-27 17:16:04
From: Mark Kettenis <redacted>
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 <redacted>
---
.../devicetree/bindings/pci/apple,pcie.yaml | 165 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/apple,pcie.yaml
@@ -0,0 +1,165 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.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.++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++# 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/phandle-array++iommu-map:true+iommu-map-mask:true++required:+-compatible+-reg+-reg-names+-bus-range+-interrupts+-msi-controller+-msi-parent+-msi-ranges++unevaluatedProperties:false++examples:+-|+#include <dt-bindings/interrupt-controller/apple-aic.h>++soc {+#address-cells = <2>;+#size-cells = <2>;++pcie0:pcie@690000000 {+compatible = "apple,t8103-pcie", "apple,pcie";+device_type = "pci";++reg = <0x6 0x90000000 0x0 0x1000000>,+<0x6 0x80000000 0x0 0x4000>,+<0x6 0x81000000 0x0 0x8000>,+<0x6 0x82000000 0x0 0x8000>,+<0x6 0x83000000 0x0 0x8000>;+reg-names = "config", "rc", "port0", "port1", "port2";++interrupt-parent = <&aic>;+interrupts = <AIC_IRQ 695 IRQ_TYPE_LEVEL_HIGH>,+<AIC_IRQ 698 IRQ_TYPE_LEVEL_HIGH>,+<AIC_IRQ 701 IRQ_TYPE_LEVEL_HIGH>;++msi-controller;+msi-parent = <&pcie0>;+msi-ranges = <&aic AIC_IRQ 704 IRQ_TYPE_EDGE_RISING 32>;++iommu-map = <0x100 &dart0 1 1>,+<0x200 &dart1 1 1>,+<0x300 &dart2 1 1>;+iommu-map-mask = <0xff00>;++bus-range = <0 3>;+#address-cells = <3>;+#size-cells = <2>;+ranges = <0x43000000 0x6 0xa0000000 0x6 0xa0000000 0x0 0x20000000>,+<0x02000000 0x0 0xc0000000 0x6 0xc0000000 0x0 0x40000000>;++clocks = <&pcie_core_clk>, <&pcie_aux_clk>, <&pcie_ref_clk>;+pinctrl-0 = <&pcie_pins>;+pinctrl-names = "default";++pci@0,0 {+device_type = "pci";+reg = <0x0 0x0 0x0 0x0 0x0>;+reset-gpios = <&pinctrl_ap 152 0>;+max-link-speed = <2>;++#address-cells = <3>;+#size-cells = <2>;+ranges;+};++pci@1,0 {+device_type = "pci";+reg = <0x800 0x0 0x0 0x0 0x0>;+reset-gpios = <&pinctrl_ap 153 0>;+max-link-speed = <2>;++#address-cells = <3>;+#size-cells = <2>;+ranges;+};++pci@2,0 {+device_type = "pci";+reg = <0x1000 0x0 0x0 0x0 0x0>;+reset-gpios = <&pinctrl_ap 33 0>;+max-link-speed = <1>;++#address-cells = <3>;+#size-cells = <2>;+ranges;+};+};+};
From: Mark Kettenis <hidden> Date: 2021-08-27 17:16:22
From: Mark Kettenis <redacted>
Add node corresponding to the apcie,t8103 node in the
Apple device tree for the Mac mini (M1, 2020).
Clock references and DART (IOMMU) references are left out at the
moment and will be added once the appropriate bindings have been
settled upon.
Signed-off-by: Mark Kettenis <redacted>
---
arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
+# 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/phandle-array
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-30 11:37:37
Hi Mark,
On Fri, 27 Aug 2021 18:15:29 +0100,
Mark Kettenis [off-list ref] wrote:
quoted hunk
From: Mark Kettenis <redacted>
Add node corresponding to the apcie,t8103 node in the
Apple device tree for the Mac mini (M1, 2020).
Clock references and DART (IOMMU) references are left out at the
moment and will be added once the appropriate bindings have been
settled upon.
Signed-off-by: Mark Kettenis <redacted>
---
arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
I have now implemented the MSI change on the Linux driver side, and it
works nicely. So thumbs up from me on this front.
I am now looking at the interrupts provided by each port:
(1) a bunch of port-private interrupts (link up/down...)
(2) INTx interrupts
Given that the programming is per-port, I've implemented this as a
per-port interrupt controller.
(1) is dead easy to implement, and doesn't require any DT description.
(2) is unfortunately exposing the limits of my DT knowledge, and I'm
not clear how to model it. I came up with the following:
port00: pci@0,0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
reset-gpios = <&pinctrl_ap 152 0>;
max-link-speed = <2>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&port00>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &port00 0>,
<0 0 0 2 &port00 1>,
<0 0 0 3 &port00 2>,
<0 0 0 4 &port00 3>;
};
which vaguely seem to do the right thing for the devices behind root
ports, but doesn't seem to work for INTx generated by the root ports
themselves. Any clue? Alternatively, I could move it to something
global to the whole PCIe controller, but that doesn't seem completely
right.
It also begs the question whether the per-port interrupt to the AIC
should be moved into each root port, should my per-port approach hold
any water.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh+dt@kernel.org> Date: 2021-08-30 15:58:23
On Mon, Aug 30, 2021 at 6:37 AM Marc Zyngier [off-list ref] wrote:
Hi Mark,
On Fri, 27 Aug 2021 18:15:29 +0100,
Mark Kettenis [off-list ref] wrote:
quoted
From: Mark Kettenis <redacted>
Add node corresponding to the apcie,t8103 node in the
Apple device tree for the Mac mini (M1, 2020).
Clock references and DART (IOMMU) references are left out at the
moment and will be added once the appropriate bindings have been
settled upon.
Signed-off-by: Mark Kettenis <redacted>
---
arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
I have now implemented the MSI change on the Linux driver side, and it
works nicely. So thumbs up from me on this front.
I am now looking at the interrupts provided by each port:
(1) a bunch of port-private interrupts (link up/down...)
(2) INTx interrupts
So each port has an independent INTx space? Is that even something PCI
defines or comprehends?
Given that the programming is per-port, I've implemented this as a
per-port interrupt controller.
(1) is dead easy to implement, and doesn't require any DT description.
(2) is unfortunately exposing the limits of my DT knowledge, and I'm
not clear how to model it. I came up with the following:
port00: pci@0,0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
reset-gpios = <&pinctrl_ap 152 0>;
max-link-speed = <2>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&port00>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &port00 0>,
<0 0 0 2 &port00 1>,
<0 0 0 3 &port00 2>,
<0 0 0 4 &port00 3>;
IIRC, I don't think the DT IRQ code handles a node having both
'interrupt-controller' and 'interrupt-map' properties. I think that's
why some PCI host bridge nodes have child interrupt-controller nodes.
I don't really like that work-around, so if the above can be made to
work, I'd be happy to see it. But the DT IRQ code is some ancient code
for ancient platforms (PowerMacs being one of them).
};
which vaguely seem to do the right thing for the devices behind root
ports, but doesn't seem to work for INTx generated by the root ports
themselves. Any clue? Alternatively, I could move it to something
global to the whole PCIe controller, but that doesn't seem completely
right.
It also begs the question whether the per-port interrupt to the AIC
should be moved into each root port, should my per-port approach hold
any water.
I tend to think per-port is the right thing to do. However, the child
nodes are PCI devices, so that creates some restrictions. Such as the
per port registers are in the host address space, not the PCI address
space, so we can't move the registers into the child nodes. The
interrupts may be okay. Certainly, being an 'interrupt-controller'
without having an 'interrupts' property for an non root interrupt
controller is odd.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-08-30 20:20:25
On Mon, 30 Aug 2021 16:57:59 +0100,
Rob Herring [off-list ref] wrote:
On Mon, Aug 30, 2021 at 6:37 AM Marc Zyngier [off-list ref] wrote:
quoted
I have now implemented the MSI change on the Linux driver side, and it
works nicely. So thumbs up from me on this front.
I am now looking at the interrupts provided by each port:
(1) a bunch of port-private interrupts (link up/down...)
(2) INTx interrupts
So each port has an independent INTx space?
Yes.
Is that even something PCI defines or comprehends?
Can't see why not. That's no different from having several PCI busses.
I don't think anything enforces that INTx interrupts have to be
unique across the system. As long as they are unique across a PCI
hierarchy, we should be OK.
quoted
Given that the programming is per-port, I've implemented this as a
per-port interrupt controller.
(1) is dead easy to implement, and doesn't require any DT description.
(2) is unfortunately exposing the limits of my DT knowledge, and I'm
not clear how to model it. I came up with the following:
port00: pci@0,0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
reset-gpios = <&pinctrl_ap 152 0>;
max-link-speed = <2>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&port00>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &port00 0>,
<0 0 0 2 &port00 1>,
<0 0 0 3 &port00 2>,
<0 0 0 4 &port00 3>;
IIRC, I don't think the DT IRQ code handles a node having both
'interrupt-controller' and 'interrupt-map' properties.
Indeed, and that actually explains why the damned INTx interrupts
insist on being 1-based instead of 0-based as the above mapping
attempts to describe it. Turns out I can rip the interrupt-map out and
it isn't worse.
I think that's why some PCI host bridge nodes have child
interrupt-controller nodes. I don't really like that work-around,
so if the above can be made to work, I'd be happy to see it. But the
DT IRQ code is some ancient code for ancient platforms (PowerMacs
being one of them).
That'd probably need some massaging. I'll have a look. I checked that
if I add something like:
interrupts-extended = <&port02 2>;
to each port, I get the PME interrupt correctly assigned should I pass
pcie_pme=nomsi. Given that this IP is pretty limited in terms of MSIs,
every bit that can free a MSI is welcome.
I guess that it would make sense to expand this support to also match
for an interrupt-map.
quoted
};
which vaguely seem to do the right thing for the devices behind root
ports, but doesn't seem to work for INTx generated by the root ports
themselves. Any clue? Alternatively, I could move it to something
global to the whole PCIe controller, but that doesn't seem completely
right.
I've investigated this one further, and it looks like the DT IRQ code
insists on trying to find the interrupt in the main pcie node instead
of in the root port itself. But of course it doesn't want to parse an
interrupt-map at that level either.
I guess that's related to the above.
quoted
It also begs the question whether the per-port interrupt to the AIC
should be moved into each root port, should my per-port approach hold
any water.
I tend to think per-port is the right thing to do. However, the child
nodes are PCI devices, so that creates some restrictions. Such as the
per port registers are in the host address space, not the PCI address
space, so we can't move the registers into the child nodes. The
interrupts may be okay. Certainly, being an 'interrupt-controller'
without having an 'interrupts' property for an non root interrupt
controller is odd.
That was my own impression as well.
I guess there is no real canonical way to handle this particular
system and to fully support it, we'll have to amend the current
infrastructure. The question is: what is the least ugly way to express
this that will work reasonably across implementations (OpenBSD, Linux,
u-boot)?
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -0,0 +1,34 @@+# SPDX-License-Identifier: BSD-2-Clause+%YAML1.2+---+$id:http://devicetree.org/schemas/interrupt-controller/msi-controller.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:MSI controller++maintainers:+-Marc Zyngier <marc.zyngier@arm.com>++description:|+An MSI controller signals interrupts to a CPU when a write is made+to an MMIO address by some master. An MSI controller may feature a+number of doorbells.++properties:+"#msi-cells":+description:|+The number of cells in an msi-specifier, required if not zero.++Typically this will encode information related to sideband data,+and will not encode doorbells or payloads as these can be+configured dynamically.++The meaning of the msi-specifier is defined by the device tree+binding of the specific MSI controller.
I'd prefer we limit this to the maximum range. I'd like to know when
someone needs 2 cells (or 3000).
enum: [ 0, 1 ]
Though no one seems to use 0 (making it optional was probably a
mistake...)
+
+ msi-controller:
+ description:
+ Identifies the node as an MSI controller.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+description: |
+ An MSI controller signals interrupts to a CPU when a write is made
+ to an MMIO address by some master. An MSI controller may feature a
+ number of doorbells.
+
+properties:
+ "#msi-cells":
+ description: |
+ The number of cells in an msi-specifier, required if not zero.
+
+ Typically this will encode information related to sideband data,
+ and will not encode doorbells or payloads as these can be
+ configured dynamically.
+
+ The meaning of the msi-specifier is defined by the device tree
+ binding of the specific MSI controller.
+
+ msi-controller:
+ description:
+ Identifies the node as an MSI controller.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+additionalProperties: true
From: Rob Herring <robh@kernel.org> Date: 2021-08-31 21:16:08
On Fri, Aug 27, 2021 at 07:15:27PM +0200, Mark Kettenis wrote:
quoted hunk
From: Mark Kettenis <redacted>
Update the MSI controller binding to add an msi-ranges property
that specifies how MSIs map onto regular interrupts on some other
interrupt controller.
Signed-off-by: Mark Kettenis <redacted>
---
.../bindings/interrupt-controller/msi-controller.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
@@ -31,4 +31,12 @@ properties:Identifies the node as an MSI controller.$ref:/schemas/types.yaml#/definitions/flag+msi-ranges:+description:+A list of pairs <intid span>, where "intid" is the specification
It's not really 'pairs' and 'interrupt specifier' is the terminology the
spec uses. How about:
A list of <phandle intspec span>, where "phandle" is parent interrupt
controller, "intspec" is the starting/base interrupt specifier, and
"span" is the size of that range (typically multiples of 32).
The 'multiples of 32' part is what Marc told me.
+ of the first interrupt (including the phandle for the interrupt
+ controller) that can be used as an MSI, and "span" the size of
+ that range. Multiple ranges can be provided.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
additionalProperties: true
--
2.32.0
From: Rob Herring <robh@kernel.org> Date: 2021-08-31 21:21:33
On Fri, Aug 27, 2021 at 07:15:28PM +0200, Mark Kettenis wrote:
quoted hunk
From: Mark Kettenis <redacted>
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 <redacted>
---
.../devicetree/bindings/pci/apple,pcie.yaml | 165 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/apple,pcie.yaml
@@ -0,0 +1,165 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.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.++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.
+
+# 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/phandle-array
Here, you'll want just 'maxItems: 1' as there's only 1 entry.
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-12 21:30:57
On Fri, 27 Aug 2021 18:15:29 +0100,
Mark Kettenis [off-list ref] wrote:
quoted hunk
From: Mark Kettenis <redacted>
Add node corresponding to the apcie,t8103 node in the
Apple device tree for the Mac mini (M1, 2020).
Clock references and DART (IOMMU) references are left out at the
moment and will be added once the appropriate bindings have been
settled upon.
Signed-off-by: Mark Kettenis <redacted>
---
arch/arm64/boot/dts/apple/t8103.dtsi | 63 ++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
Only exposing 16kB for the 'rc' crashes the Linux driver as it tries
to configure the port ref-clock configurations, which live much
higher:
#define CORE_LANE_CFG(port) (0x84000 + 0x4000 * (port))
Previous versions of the binding had this region as 1MB, which made
things work.
These used to be 16kB, and are now twice as much. Didn't cause any
issue with the Linux driver, but I wonder what trigger either change.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2021-09-21 11:01:43
On Fri, 27 Aug 2021 18:15:25 +0100,
Mark Kettenis [off-list ref] wrote:
From: Mark Kettenis <redacted>
This small series adds bindings for the PCIe controller found on the
Apple M1 SoC.
At this point, the primary consumer for these bindings is U-Boot.
With these bindings U-Boot can bring up the links for the root ports
of the PCIe root complex. A simple OS driver can then provide
standard ECAM access and manage MSI interrupts to provide access
to the built-in Ethernet and XHCI controllers of the Mac mini.
The Apple controller incorporates Synopsys Designware PCIe logic
to implement its root port. But unlike other hardware currently
supported by U-Boot and the Linux kernel the Apple hardware
integrates multiple root ports. As such the existing bindings
for the DWC PCIe interface can't be used. There is a single ECAM
space for all root space, but separate GPIOs to take the PCI devices
on those ports out of reset. Therefore the standard "reset-gpio" and
"max-link-speed" properties appear on the child nodes representing
the PCI devices 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 port registers.
This now adds an MSI controller binding schema and uses the generic
msi-ranges property to specify how the MSIs are mapped to interrupts
on the AIC. I copied some of the description text in the MSI
controller binding schema from msi.txt but it may need some further
tweaks to make sense.
Patch 2/2 of this series depends on the pinctrl series I sent earlier
and will probably go through Hector Martin's Apple M1 SoC tree.
Changelog:
v4: - Convert MSI controller binding to YAML
- Add generic msi-ranges property to MSI controller binding
- Fix typos/formatting in apple,pcie binding
- Use generic MSI controller binding in apple,pcie
v3: - Remove unneeded include in example
v2: - Adjust name for ECAM in "reg-names"
- Drop "phy" registers
- Expand description
- Add description for "interrupts"
- Fix incorrect minItems for "interrupts"
- Fix incorrect MaxItems for "reg-names"
- Document the use of "msi-controller", "msi-parent", "iommu-map" and
"iommu-map-mask"
- Fix "bus-range" and "iommu-map" properties in the example
Mark Kettenis (4):
dt-bindings: interrupt-controller: Convert MSI controller to
json-schema
dt-bindings: interrupt-controller: msi: Add msi-ranges property
dt-bindings: pci: Add DT bindings for apple,pcie
arm64: apple: Add PCIe node
.../interrupt-controller/msi-controller.yaml | 42 +++++
.../devicetree/bindings/pci/apple,pcie.yaml | 165 ++++++++++++++++++
.../bindings/pci/brcm,stb-pcie.yaml | 1 +
.../bindings/pci/microchip,pcie-host.yaml | 1 +
MAINTAINERS | 1 +
arch/arm64/boot/dts/apple/t8103.dtsi | 63 +++++++
6 files changed, 273 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/msi-controller.yaml
create mode 100644 Documentation/devicetree/bindings/pci/apple,pcie.yaml
With Rob's comments addressed, and the fix on the M1 RC MMIO region,
for the whole series:
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel