Re: [PATCH v4 11/12] arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes

[Johan Hovold <johan@kernel.org>]

On Mon, Jan 23, 2023 at 02:39:55PM +0200, Abel Vesa wrote:
> On 23-01-23 09:51:20, Johan Hovold wrote:
> > On Thu, Jan 19, 2023 at 04:04:52PM +0200, Abel Vesa wrote:
> > > Add PCIe controllers and PHY nodes.
> > > 
> > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > > ---

> > > +			clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> > > +				 <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> > > +				 <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> > > +				 <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> > > +				 <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> > > +				 <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> > > +				 <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>;
> > > +			clock-names = "aux",
> > > +				      "cfg",
> > > +				      "bus_master",
> > > +				      "bus_slave",
> > > +				      "slave_q2a",
> > > +				      "ddrss_sf_tbu",
> > 
> > You're reusing a clock name which doesn't seem to match this SoC. I
> > don't know what "QTB" refers to here and if it's just some Qualcomm
> > alternate name for "TBU" which could make this ok.
> 
> I'll come back later with an answer here, once I know exactly what QTB
> means.
> 
> > 
> > > +				      "noc_aggr_4";
> > 
> > The 4 here comes from the fact that the clock was named this way on
> > sc8280xp. Perhaps 'noc_aggr' would have been a better generic name for
> > the interconnect clock.
> > 
> 
> So should I rename it to noc_aggr as part of this patchset then?

Yes, or rather add that as the name this (and possible coming) SoCs use.

> > > +
> > > +			interconnects = <&pcie_noc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>;
> > > +			interconnect-names = "pcie-mem";
> > > +
> > > +			iommus = <&apps_smmu 0x1400 0x7f>;
> > > +			iommu-map = <0x0   &apps_smmu 0x1400 0x1>,
> > > +				    <0x100 &apps_smmu 0x1401 0x1>;
> > > +
> > > +			resets = <&gcc GCC_PCIE_0_BCR>;
> > > +			reset-names = "pci";
> > > +
> > > +			power-domains = <&gcc PCIE_0_GDSC>;
> > > +
> > > +			phys = <&pcie0_phy>;
> > > +			phy-names = "pciephy";
> > > +
> > > +			perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> > > +			wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > > +
> > > +			pinctrl-names = "default";
> > > +			pinctrl-0 = <&pcie0_default_state>;
> > 
> > For sc8280xp we decided to keep all pin configuration (and the gpios
> > properties above) in the dts file. I believe this should be done also
> > for any new SoCs.
> 
> Right, I'll move the pinctrl properties to the dts node instead.
> 
> > 
> > Either way, the pin nodes should be added along with the consumer.
> > 
> 
> The pin nodes have been added already, back when the initial dtsi was sent.

Ok.
 
> > > +		pcie1_phy: phy@1c0e000 {
> > > +			compatible = "qcom,sm8550-qmp-gen4x2-pcie-phy";
> > > +			reg = <0x0 0x01c0e000 0x0 0x2000>;
> > > +
> > > +			clocks = <&gcc GCC_PCIE_1_PHY_AUX_CLK>,
> > > +				 <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> > > +				 <&tcsr TCSR_PCIE_1_CLKREF_EN>,
> > > +				 <&gcc GCC_PCIE_1_PHY_RCHNG_CLK>,
> > > +				 <&gcc GCC_PCIE_1_PIPE_CLK>;
> > > +			clock-names = "aux", "cfg_ahb", "ref", "rchng",
> > > +				      "pipe";
> > > +
> > > +			resets = <&gcc GCC_PCIE_1_PHY_BCR>,
> > > +				 <&gcc GCC_PCIE_1_NOCSR_COM_PHY_BCR>;
> > > +			reset-names = "phy", "nocsr";
> > 
> > Do you know why only the second PHY uses two resets here? Did you intend
> > to add it also for the first PHY?
> 
> Please notice that this is a g4x2 phy. The documentation specifically
> says that both the pciephy_reset and pciephy_nocsr_reset should be
> asserted on power-up. Now, even the g3x2 has the nocsr reset (at least
> in GCC) but its documentation doesn't seem to say anything about
> nocsr needed to be asserted (ever).

Ok. Thanks for confirming. I did not notice the difference in generation
at first.

> > Both of these resets exists also on sc8280xp, and I believe downstream
> > used the NOCSR_COM variant, which does not reset all registers in the
> > PHY so you could unknowingly be relying on firmware to setup things up
> > for you.
> 
> That is also the case for the g3x2 phy on sm8550.
> 
> > 
> > I did a fair bit of reverse engineering to determine the init sequences
> > and opted to use the full reset for the PHYs here in the end.
> > 
> > I don't think you should be using both, but someone with access to
> > documentation may provide more insight.
> 
> Again, the documentation I have access to, seems to suggest otherwise.

If that's what the documentation says then let's go with that.

> > Have you tested both pci0 and 1 by the way?
> 
> Only the pcie0 can be tested with the MTP I have access to. So only
> pcie0 was tested.

Ok.

Johan