From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Stanimir Varbanov <svarbanov@mm-sol.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Andrew Murray <andrew.murray@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: qcom: Add support for SDM845 PCIe controller
Date: Wed, 6 Nov 2019 12:56:08 -0800 [thread overview]
Message-ID: <20191106205608.GF36595@minitux> (raw)
In-Reply-To: <776ec4265217cc83e9e847ff3c80a52a86390b1b.camel@pengutronix.de>
On Mon 04 Nov 01:41 PST 2019, Philipp Zabel wrote:
> Hi Bjorn,
>
> On Fri, 2019-11-01 at 17:27 -0700, Bjorn Andersson wrote:
> > The SDM845 has one Gen2 and one Gen3 controller, add support for these.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v1:
> > - Style changes requested by Stan
> > - Tested with second PCIe controller as well
> >
> > drivers/pci/controller/dwc/pcie-qcom.c | 152 +++++++++++++++++++++++++
> > 1 file changed, 152 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > index 7e581748ee9f..35f4980480bb 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -54,6 +54,7 @@
> [...]
> > +static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie)
> > +{
> > + struct qcom_pcie_resources_2_7_0 *res = &pcie->res.v2_7_0;
> > + struct dw_pcie *pci = pcie->pci;
> > + struct device *dev = pci->dev;
> > + u32 val;
> > + int ret;
> > +
> > + ret = regulator_bulk_enable(ARRAY_SIZE(res->supplies), res->supplies);
> > + if (ret < 0) {
> > + dev_err(dev, "cannot enable regulators\n");
> > + return ret;
> > + }
> > +
> > + ret = clk_bulk_prepare_enable(ARRAY_SIZE(res->clks), res->clks);
> > + if (ret < 0)
> > + goto err_disable_regulators;
> > +
> > + ret = reset_control_assert(res->pci_reset);
> > + if (ret < 0) {
> > + dev_err(dev, "cannot deassert pci reset\n");
> > + goto err_disable_clocks;
> > + }
>
> If for any of the above fails, the reset line is left in its default
> state, presumably unasserted. Is there a reason to assert and keep it
> asserted if enabling the clocks fails below?
>
No, I don't think there's any reason for doing this and looking at the
downstream driver, they don't even propagate this error.
> > + msleep(20);
And I see now that downstream has this as 1ms, will update and retest
again.
> > +
> > + ret = reset_control_deassert(res->pci_reset);
> > + if (ret < 0) {
> > + dev_err(dev, "cannot deassert pci reset\n");
> > + goto err_assert_resets;
>
> Nitpick: this seems superfluous since the reset line was just asserted
> 20 ms before. Maybe just:
>
> goto err_disable_clocks;
Yes, this seems reasonable.
>
> > + }
> > +
> > + ret = clk_prepare_enable(res->pipe_clk);
> > + if (ret) {
> > + dev_err(dev, "cannot prepare/enable pipe clock\n");
> > + goto err_assert_resets;
> > + }
> > +
> > + /* configure PCIe to RC mode */
> > + writel(DEVICE_TYPE_RC, pcie->parf + PCIE20_PARF_DEVICE_TYPE);
> > +
> > + /* enable PCIe clocks and resets */
> > + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> > + val &= ~BIT(0);
> > + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> > +
> > + /* change DBI base address */
> > + writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
> > +
> > + /* MAC PHY_POWERDOWN MUX DISABLE */
> > + val = readl(pcie->parf + PCIE20_PARF_SYS_CTRL);
> > + val &= ~BIT(29);
> > + writel(val, pcie->parf + PCIE20_PARF_SYS_CTRL);
> > +
> > + val = readl(pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
> > + val |= BIT(4);
> > + writel(val, pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
> > +
> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > + val = readl(pcie->parf + PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
> > + val |= BIT(31);
> > + writel(val, pcie->parf + PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
> > + }
> > +
> > + return 0;
> > +err_assert_resets:
> > + reset_control_assert(res->pci_reset);
>
> So maybe this can just be removed. The reset isn't asserted in deinit
> either.
>
Sounds good.
Thanks for your review, Philipp!
Regards,
Bjorn
next prev parent reply other threads:[~2019-11-06 20:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-02 0:27 [PATCH v2 0/2] PCI: qcom: Add support for SDM845 PCIe Bjorn Andersson
2019-11-02 0:27 ` [PATCH v2 1/2] dt-bindings: " Bjorn Andersson
2019-11-05 22:42 ` Rob Herring
2019-11-02 0:27 ` [PATCH v2 2/2] PCI: qcom: Add support for SDM845 PCIe controller Bjorn Andersson
2019-11-04 9:41 ` Philipp Zabel
2019-11-06 20:56 ` Bjorn Andersson [this message]
2019-11-03 8:24 ` [PATCH v2 0/2] PCI: qcom: Add support for SDM845 PCIe Vinod Koul
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=20191106205608.GF36595@minitux \
--to=bjorn.andersson@linaro.org \
--cc=andrew.murray@arm.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=svarbanov@mm-sol.com \
/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).