Re: [PATCH v5 4/5] arm64: dts: qcom: ipq5332: Add PCIe related nodes

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Jan 15, 2025 at 01:28:22PM +0530, Varadarajan Narayanan wrote:
> On Wed, Jan 08, 2025 at 12:32:35PM -0600, Bjorn Helgaas wrote:
> > On Thu, Jan 02, 2025 at 05:00:18PM +0530, Varadarajan Narayanan wrote:
> > > From: Praveenkumar I <quic_ipkumar@quicinc.com>
> > >
> > > Add phy and controller nodes for pcie0_x1 and pcie1_x2.

> > > +		pcie1: pcie@18000000 {
> > > +			compatible = "qcom,pcie-ipq5332", "qcom,pcie-ipq9574";
> > > +			reg = <0x00088000 0x3000>,
> > > +			      <0x18000000 0xf1d>,
> > > +			      <0x18000f20 0xa8>,
> > > +			      <0x18001000 0x1000>,
> > > +			      <0x18100000 0x1000>,
> > > +			      <0x0008b000 0x1000>;
> > > +			reg-names = "parf",
> > > +				    "dbi",
> > > +				    "elbi",
> > > +				    "atu",
> > > +				    "config",
> > > +				    "mhi";
> > > +			device_type = "pci";
> > > +			linux,pci-domain = <1>;
> > > +			bus-range = <0x00 0xff>;

> > > +			num-lanes = <2>;
> > > +			phys = <&pcie1_phy>;
> > > +			phy-names = "pciephy";
> >
> > I think num-lanes and PHY info are per-Root Port properties, not a
> > host controller properties, aren't they?  Some of the clock and reset
> > properties might also be per-Root Port.
> >
> > Ideally, I think per-Root Port properties should be in a child device
> > as they are here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/mvebu-pci.txt?id=v6.12#n137
> > but it looks like the num-lanes parsing is done in
> > dw_pcie_get_resources(), which can only handle a single num-lanes per
> > DWC controller, so maybe it's impractical to add a child device here.
> >
> > But I wonder if it would be useful to at least group the per-Root Port
> > things together in the binding to help us start thinking about the
> > difference between the controller and the Root Port(s).
> 
> This looks like a big change and might impact the existing
> SoCs/platforms. To minimize the impact, should we continue
> supporting the legacy method in addition to the new per-Root port
> approach. Should we take this up separately? Kindly advice.

I just meant to change the order they're listed in the binding, not
add any new device stanzas.

E.g., maybe it could be arranged like this, where things that apply to
the Root Complex as a whole (bus-range, #address-cells, #size-cells,
ranges, etc) are listed first, and the Root Port-related things
(num-lanes, phys, etc) are listed later:

+               pcie1: pcie@18000000 {
+                       compatible = "qcom,pcie-ipq5332", "qcom,pcie-ipq9574";
+                       device_type = "pci";
+                       linux,pci-domain = <1>;
+                       bus-range = <0x00 0xff>;
+                       #address-cells = <3>;
+                       #size-cells = <2>;
+
+                       ranges = <0x01000000 0 0x18200000 0x18200000 0 0x00100000>,
+                                <0x02000000 0 0x18300000 0x18300000 0 0x07d00000>;
+                       interrupts = <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>, ...
+                       clocks = <&gcc GCC_PCIE3X2_AXI_M_CLK>, ...
+                       resets = <&gcc GCC_PCIE3X2_PIPE_ARES>, ...
+                       interconnects = <&gcc MASTER_SNOC_PCIE3_2_M ...

Everything above is potentially shared; everything below applies to a
single (the only one in this case) Root Port.

+                       num-lanes = <2>;
+                       phys = <&pcie1_phy>;
+
+                       status = "disabled";
+               };

I want people to think about which things belong to the Root Port and
which are shared for the whole Root Complex.

For new drivers, I think we should actually add "pcie@1,0" stanzas for
each Root Port, even if there is only one.

But for existing drivers that would have to be modified to comprehend
new stanzas, collecting the Root Port things so they are together in
the PCI controller stanza would be a good start (unless the order of
properties in the DT makes a functional difference, of course).

Bjorn