Re: [PATCH 4/4] arm64: dts: uniphier: Add NX1 SoC and boards support

On 2022/10/27 20:28, Arnd Bergmann wrote:

On Thu, Oct 27, 2022, at 13:19, Kunihiko Hayashi wrote:

quoted

On 2022/10/27 19:01, Arnd Bergmann wrote:

quoted

On Thu, Oct 27, 2022, at 06:51, Kunihiko Hayashi wrote:

quoted

quoted

quoted

+			#interrupt-cells = <1>;
+			interrupt-names = "dma", "msi";
+			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0 0 0 1 &pcie_intc 0>,	/* INTA */
+					<0 0 0 2 &pcie_intc 1>,	/* INTB */
+					<0 0 0 3 &pcie_intc 2>,	/* INTC */
+					<0 0 0 4 &pcie_intc 3>;	/* INTD */
+			phy-names = "pcie-phy";
+			phys = <&pcie_phy>;
+
+			pcie_intc: legacy-interrupt-controller {
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 86

IRQ_TYPE_LEVEL_HIGH>;

quoted

+			};
+		};

Shouldn't there be an "msi-map" or "msi-parent" property pointing at
the GIC?

Since Designware PCIe receives an interrupt from GIC with interrupt-name

"msi"

quoted

and passes the interrupt to the linear irq domain corresponding to MSI,
I think there is neither "msi-map" nor "msi-parent" properties.

Usually, you have the choice to use either the built-in
MSI logic of the PCIe controller, or the one built into the
GIC itself, assuming you have a modern enough GIC implemetation.

I recognize ITS built into GICv3 can perform the parent of MSI.

Using the GIC is preferred here, because otherwise you lose
all the benefits that MSIs offer, regarding latency and CPU
affinity.

I understand, however, unfortunately GIC-ITS (or something alternative)
isn't supported in this SoC, so I think it is difficult to use the GIC
itself as msi-parent.

Thank you,

---
Best Regards
Kunihiko Hayashi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel