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@xxxxxxxxxx>
> > > ---
> > > + 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
