linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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