[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y86WqGW6pj5re3FU@hovoldconsulting.com>
Date: Mon, 23 Jan 2023 15:16:08 +0100
From: Johan Hovold <johan@...nel.org>
To: Abel Vesa <abel.vesa@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Rob Herring <robh@...nel.org>,
Krzysztof WilczyĆski <kw@...ux.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
"vkoul@...nel.org" <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Manivannan Sadhasivam <mani@...nel.org>,
linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 11/12] arm64: dts: qcom: sm8550: Add PCIe PHYs and
controllers nodes
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@...aro.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@...e000 {
> > > + 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
Powered by blists - more mailing lists