linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Abel Vesa <abel.vesa@linaro.org>
To: Johan Hovold <johan@kernel.org>
Cc: "Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 11/12] arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes
Date: Mon, 23 Jan 2023 14:39:55 +0200	[thread overview]
Message-ID: <Y86AG7ev++wYiza4@linaro.org> (raw)
In-Reply-To: <Y85KiKD+iQamchB5@hovoldconsulting.com>

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>
> > ---
> > 
> > This patch does not have a v3, but since it is now part of the same
> > patchset with the controller and the phy drivers patches, I had to
> > bump the version to 4.
> > 
> > Latest version was here (v2):
> > https://lore.kernel.org/all/20230118230526.1499328-2-abel.vesa@linaro.org/
> > 
> > Changes since latest version (v2):
> >  * renamed the pcie_1_link_down_reset to simply link_down
> >  * dropped the pipe from clock-names
> >  * renamed aggre clock-names to noc_aggr_4
> >  * dropped the _pcie infix from cnoc_pcie_sf_axi
> >  * dropped the aux_phy clock from the pcie1
> > 
> > Changes since v1:
> >  * ordered pcie related nodes alphabetically in MTP dts
> >  * dropped the pipe_mux, phy_pipe and ref clocks from the pcie nodes
> >  * dropped the child node from the phy nodes, like Johan suggested,
> >    and updated to use the sc8280xp binding scheme
> >  * changed "pcie_1_nocsr_com_phy_reset" 2nd reset name of pcie1_phy
> >    to "nocsr"
> >  * reordered all pcie nodes properties to look similar to the ones
> >    from sc8280xp
> > 
> > 
> >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 207 ++++++++++++++++++++++++++-
> >  1 file changed, 204 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 3d47281a276b..8df226530d76 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -646,9 +646,9 @@ gcc: clock-controller@100000 {
> >  			#reset-cells = <1>;
> >  			#power-domain-cells = <1>;
> >  			clocks = <&bi_tcxo_div2>, <&sleep_clk>,
> > -				 <0>,
> > -				 <0>,
> > -				 <0>,
> > +				 <&pcie0_phy>,
> > +				 <&pcie1_phy>,
> > +				 <&pcie_1_phy_aux_clk>,
> >  				 <&ufs_mem_phy 0>,
> >  				 <&ufs_mem_phy 1>,
> >  				 <&ufs_mem_phy 2>,
> > @@ -1547,6 +1547,207 @@ mmss_noc: interconnect@1780000 {
> >  			qcom,bcm-voters = <&apps_bcm_voter>;
> >  		};
> >  
> > +		pcie0: pci@1c00000 {
> > +			device_type = "pci";
> > +			compatible = "qcom,pcie-sm8550";
> > +			reg = <0 0x01c00000 0 0x3000>,
> > +			      <0 0x60000000 0 0xf1d>,
> > +			      <0 0x60000f20 0 0xa8>,
> > +			      <0 0x60001000 0 0x1000>,
> > +			      <0 0x60100000 0 0x100000>;
> > +			reg-names = "parf", "dbi", "elbi", "atu", "config";
> > +			#address-cells = <3>;
> > +			#size-cells = <2>;
> > +			ranges = <0x01000000 0x0 0x60200000 0 0x60200000 0x0 0x100000>,
> > +				 <0x02000000 0x0 0x60300000 0 0x60300000 0x0 0x3d00000>;
> > +			bus-range = <0x00 0xff>;
> > +
> > +			dma-coherent;
> > +
> > +			linux,pci-domain = <0>;
> > +			num-lanes = <2>;
> > +
> > +			interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
> > +			interrupt-names = "msi";
> > +
> > +			#interrupt-cells = <1>;
> > +			interrupt-map-mask = <0 0 0 0x7>;
> > +			interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
> > +					<0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
> > +					<0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
> > +					<0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
> > +
> > +			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?

> > +
> > +			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.

> > +
> > +			status = "disabled";
> > +		};
> > +
> > +		pcie0_phy: phy@1c06000 {
> > +			compatible = "qcom,sm8550-qmp-gen3x2-pcie-phy";
> > +			reg = <0 0x01c06000 0 0x2000>;
> > +
> > +			clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> > +				 <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> > +				 <&tcsr TCSR_PCIE_0_CLKREF_EN>,
> > +				 <&gcc GCC_PCIE_0_PHY_RCHNG_CLK>,
> > +				 <&gcc GCC_PCIE_0_PIPE_CLK>;
> > +			clock-names = "aux", "cfg_ahb", "ref", "rchng",
> > +				      "pipe";
> > +
> > +			resets = <&gcc GCC_PCIE_0_PHY_BCR>;
> > +			reset-names = "phy";
> > +
> > +			assigned-clocks = <&gcc GCC_PCIE_0_PHY_RCHNG_CLK>;
> > +			assigned-clock-rates = <100000000>;
> > +
> > +			power-domains = <&gcc PCIE_0_PHY_GDSC>;
> > +
> > +			#clock-cells = <0>;
> > +			clock-output-names = "pcie0_pipe_clk";
> > +
> > +			#phy-cells = <0>;
> > +
> > +			status = "disabled";
> > +		};
> 
> > +		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).

> 
> 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.

> 
> 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.

> 
> > +
> > +			assigned-clocks = <&gcc GCC_PCIE_1_PHY_RCHNG_CLK>;
> > +			assigned-clock-rates = <100000000>;
> > +
> > +			power-domains = <&gcc PCIE_1_PHY_GDSC>;
> > +
> > +			#clock-cells = <0>;
> > +			clock-output-names = "pcie1_pipe_clk";
> > +
> > +			#phy-cells = <0>;
> > +
> > +			status = "disabled";
> > +		};
> > +
> >  		cryptobam: dma-controller@1dc4000 {
> >  			compatible = "qcom,bam-v1.7.0";
> >  			reg = <0x0 0x01dc4000 0x0 0x28000>;
> 
> Johan

  reply	other threads:[~2023-01-23 12:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 14:04 [PATCH v4 00/12] sm8550: Add PCIe HC and PHY support Abel Vesa
2023-01-19 14:04 ` [PATCH v4 01/12] dt-bindings: phy: Add QMP PCIe PHY comptible for SM8550 Abel Vesa
2023-01-22 14:09   ` Krzysztof Kozlowski
2023-01-19 14:04 ` [PATCH v4 02/12] phy: qcom-qmp: pcs: Add v6 register offsets Abel Vesa
2023-01-19 14:04 ` [PATCH v4 03/12] phy: qcom-qmp: pcs: Add v6.20 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 04/12] phy: qcom-qmp: pcs-pcie: Add v6 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 05/12] phy: qcom-qmp: pcs-pcie: Add v6.20 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 06/12] phy: qcom-qmp: qserdes-txrx: " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 07/12] phy: qcom-qmp: qserdes-lane-shared: Add v6 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 08/12] phy: qcom-qmp-pcie: Add support for SM8550 g3x2 and g4x2 PCIEs Abel Vesa
2023-01-23 15:03   ` Johan Hovold
2023-01-23 19:42     ` Abel Vesa
2023-01-19 14:04 ` [PATCH v4 09/12] dt-bindings: PCI: qcom: Add SM8550 compatible Abel Vesa
2023-01-22 14:10   ` Krzysztof Kozlowski
2023-01-23 10:44     ` Abel Vesa
2023-01-23 11:03       ` Krzysztof Kozlowski
2023-01-19 14:04 ` [PATCH v4 10/12] PCI: qcom: Add SM8550 PCIe support Abel Vesa
2023-01-19 14:21   ` Manivannan Sadhasivam
2023-01-19 15:35     ` Abel Vesa
2023-01-23  8:27       ` Johan Hovold
2023-01-19 14:04 ` [PATCH v4 11/12] arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes Abel Vesa
2023-01-23  8:51   ` Johan Hovold
2023-01-23 12:39     ` Abel Vesa [this message]
2023-01-23 13:11       ` Abel Vesa
2023-01-23 14:17         ` Johan Hovold
2023-01-23 14:16       ` Johan Hovold
2023-01-23 14:24         ` Johan Hovold
2023-01-19 14:04 ` [PATCH v4 12/12] arm64: dts: qcom: sm8550-mtp: " Abel Vesa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y86AG7ev++wYiza4@linaro.org \
    --to=abel.vesa@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=johan@kernel.org \
    --cc=kishon@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).