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>, "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>, "Johan Hovold" <johan+linaro@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 v7 10/12] PCI: qcom: Add SM8550 PCIe support Date: Wed, 8 Feb 2023 19:10:17 +0200 [thread overview] Message-ID: <Y+PXeYrBBL3QaznM@linaro.org> (raw) In-Reply-To: <Y+PQYxh4t/ytOe3+@hovoldconsulting.com> On 23-02-08 17:40:03, Johan Hovold wrote: > On Mon, Feb 06, 2023 at 05:11:01PM +0200, Abel Vesa wrote: > > On 23-02-03 10:49:24, Johan Hovold wrote: > > > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > > > Add compatible for both PCIe found on SM8550. > > > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > > > > > nit: You're now also adding 'noc_aggr' > > > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > > --- > > > > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > > > > > /* 6 clocks typically, 7 for sm8250 */ > > > > struct qcom_pcie_resources_2_7_0 { > > > > - struct clk_bulk_data clks[12]; > > > > + struct clk_bulk_data clks[14]; > > > > int num_clks; > > > > struct regulator_bulk_data supplies[2]; > > > > - struct reset_control *pci_reset; > > > > + struct reset_control *rst; > > > > > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > > > things like res->rst below). > > > > Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use > > rst. > > Yeah, I saw that. Fortunately these resources are completely > independent, but whatever. Will do it in the next version then. > > > > > }; > > > > > > > > struct qcom_pcie_resources_2_9_0 { > > > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > > > unsigned int idx; > > > > int ret; > > > > > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > > > - if (IS_ERR(res->pci_reset)) > > > > - return PTR_ERR(res->pci_reset); > > > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > > > + if (IS_ERR(res->rst)) > > > > + return PTR_ERR(res->rst); > > > > > > So the reset array implementation apparently both asserts and deasserts > > > the resets in the order specified in DT (i.e. does not deassert in > > > reverse order). > > > > > > Is that ok also for the new "pci" and "link_down" resets? > > > > According to the HPG, yes, this is perfectly fine. It specifically says > > to assert the pcie reset and then continues saying to assert the > > link_down reset. > > Ok, but that doesn't really say anything about whether it's ok to > *deassert* them in the same order, which was what I asked about. Actually, what I wanted to say is that the HPG says something like this: "assert pcie reset, then assert link_down" and then at the end it literaly repeats the same phrase. > > Johan
WARNING: multiple messages have this Message-ID (diff)
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>, "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>, "Johan Hovold" <johan+linaro@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 v7 10/12] PCI: qcom: Add SM8550 PCIe support Date: Wed, 8 Feb 2023 19:10:17 +0200 [thread overview] Message-ID: <Y+PXeYrBBL3QaznM@linaro.org> (raw) In-Reply-To: <Y+PQYxh4t/ytOe3+@hovoldconsulting.com> On 23-02-08 17:40:03, Johan Hovold wrote: > On Mon, Feb 06, 2023 at 05:11:01PM +0200, Abel Vesa wrote: > > On 23-02-03 10:49:24, Johan Hovold wrote: > > > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > > > Add compatible for both PCIe found on SM8550. > > > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > > > > > nit: You're now also adding 'noc_aggr' > > > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > > --- > > > > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > > > > > /* 6 clocks typically, 7 for sm8250 */ > > > > struct qcom_pcie_resources_2_7_0 { > > > > - struct clk_bulk_data clks[12]; > > > > + struct clk_bulk_data clks[14]; > > > > int num_clks; > > > > struct regulator_bulk_data supplies[2]; > > > > - struct reset_control *pci_reset; > > > > + struct reset_control *rst; > > > > > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > > > things like res->rst below). > > > > Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use > > rst. > > Yeah, I saw that. Fortunately these resources are completely > independent, but whatever. Will do it in the next version then. > > > > > }; > > > > > > > > struct qcom_pcie_resources_2_9_0 { > > > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > > > unsigned int idx; > > > > int ret; > > > > > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > > > - if (IS_ERR(res->pci_reset)) > > > > - return PTR_ERR(res->pci_reset); > > > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > > > + if (IS_ERR(res->rst)) > > > > + return PTR_ERR(res->rst); > > > > > > So the reset array implementation apparently both asserts and deasserts > > > the resets in the order specified in DT (i.e. does not deassert in > > > reverse order). > > > > > > Is that ok also for the new "pci" and "link_down" resets? > > > > According to the HPG, yes, this is perfectly fine. It specifically says > > to assert the pcie reset and then continues saying to assert the > > link_down reset. > > Ok, but that doesn't really say anything about whether it's ok to > *deassert* them in the same order, which was what I asked about. Actually, what I wanted to say is that the HPG says something like this: "assert pcie reset, then assert link_down" and then at the end it literaly repeats the same phrase. > > Johan -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2023-02-08 17:10 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-03 8:17 [PATCH v7 00/12] sm8550: Add PCIe HC and PHY support Abel Vesa 2023-02-03 8:17 ` Abel Vesa 2023-02-03 8:17 ` [PATCH v7 01/12] dt-bindings: phy: Add QMP PCIe PHY comptible for SM8550 Abel Vesa 2023-02-03 8:17 ` Abel Vesa 2023-02-03 8:33 ` Johan Hovold 2023-02-03 8:33 ` Johan Hovold 2023-02-03 8:17 ` [PATCH v7 02/12] phy: qcom-qmp: pcs: Add v6 register offsets Abel Vesa 2023-02-03 8:17 ` Abel Vesa 2023-02-03 8:17 ` [PATCH v7 03/12] phy: qcom-qmp: pcs: Add v6.20 " Abel Vesa 2023-02-03 8:17 ` Abel Vesa 2023-02-03 8:17 ` [PATCH v7 04/12] phy: qcom-qmp: pcs-pcie: Add v6 " Abel Vesa 2023-02-03 8:17 ` Abel Vesa 2023-02-03 8:18 ` [PATCH v7 05/12] phy: qcom-qmp: pcs-pcie: Add v6.20 " Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 8:18 ` [PATCH v7 06/12] phy: qcom-qmp: qserdes-txrx: " Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 8:18 ` [PATCH v7 07/12] phy: qcom-qmp: qserdes-lane-shared: Add v6 " Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 8:18 ` [PATCH v7 08/12] phy: qcom-qmp-pcie: Add support for SM8550 g3x2 and g4x2 PCIEs Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 9:33 ` Johan Hovold 2023-02-03 9:33 ` Johan Hovold 2023-02-06 14:05 ` Abel Vesa 2023-02-06 14:05 ` Abel Vesa 2023-02-08 16:35 ` Johan Hovold 2023-02-08 16:35 ` Johan Hovold 2023-02-03 8:18 ` [PATCH v7 09/12] dt-bindings: PCI: qcom: Add SM8550 compatible Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 9:35 ` Johan Hovold 2023-02-03 9:35 ` Johan Hovold 2023-02-03 10:03 ` Johan Hovold 2023-02-03 10:03 ` Johan Hovold 2023-02-03 10:35 ` Abel Vesa 2023-02-03 10:35 ` Abel Vesa 2023-02-03 8:18 ` [PATCH v7 10/12] PCI: qcom: Add SM8550 PCIe support Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 9:49 ` Johan Hovold 2023-02-03 9:49 ` Johan Hovold 2023-02-06 15:11 ` Abel Vesa 2023-02-06 15:11 ` Abel Vesa 2023-02-08 16:40 ` Johan Hovold 2023-02-08 16:40 ` Johan Hovold 2023-02-08 17:10 ` Abel Vesa [this message] 2023-02-08 17:10 ` Abel Vesa 2023-02-08 17:11 ` Abel Vesa 2023-02-08 17:11 ` Abel Vesa 2023-02-08 17:14 ` Johan Hovold 2023-02-08 17:14 ` Johan Hovold 2023-02-03 8:18 ` [PATCH v7 11/12] arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 9:50 ` Johan Hovold 2023-02-03 9:50 ` Johan Hovold 2023-02-03 8:18 ` [PATCH v7 12/12] arm64: dts: qcom: sm8550-mtp: " Abel Vesa 2023-02-03 8:18 ` Abel Vesa 2023-02-03 9:56 ` Johan Hovold 2023-02-03 9:56 ` Johan Hovold 2023-02-03 10:36 ` Abel Vesa 2023-02-03 10:36 ` 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=Y+PXeYrBBL3QaznM@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+linaro@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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.