linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Stanimir Varbanov <svarbanov@mm-sol.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	PCI <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
Date: Fri, 29 Jan 2021 15:50:24 -0600	[thread overview]
Message-ID: <20210129215024.GA113900@bjorn-Precision-5520> (raw)
In-Reply-To: <da0ac373-4edb-0230-b264-49697fa3d86a@linaro.org>

On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote:
> On 28/01/2021 22:26, Rob Herring wrote:
> > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> > > 
> > > Some Qualcomm platforms require to power up an external device before
> > > probing the PCI bus. E.g. on RB5 platform the QCA6390 WiFi/BT chip needs
> > > to be powered up before PCIe0 bus is probed. Add a quirk to the
> > > respective PCIe root bridge to attach to the power domain if one is
> > > required, so that the QCA chip is started before scanning the PCIe bus.
> > 
> > This is solving a generic problem in a specific driver. It needs to be
> > solved for any PCI host and any device.
> 
> Ack. I see your point here.
> 
> As this would require porting code from powerpc/spark of-pci code and
> changing pcie port driver to apply power supply before bus probing happens,
> I'd also ask for the comments from PCI maintainers. Will that solution be
> acceptable to you?

I can't say without seeing the code.  I don't know enough about this
scenario to envision how it might look.

I guess the QCA6390 is a PCIe device?  Why does it need to be powered
up before probing?  Shouldn't we get a link-up interrupt when it is
powered up so we could probe it then?

Nit: when changing any file, please take a look at the commit history
and make yours match, e.g.,

  pcie-qcom: provide a way to power up qca6390 chip on RB5 platform

does not look like:

  PCI: qcom: Add support for configuring BDF to SID mapping for SM8250
  PCI: qcom: Add SM8250 SoC support
  PCI: qcom: Make sure PCIe is reset before init for rev 2.1.0
  PCI: qcom: Replace define with standard value
  PCI: qcom: Support pci speed set for ipq806x
  PCI: qcom: Add ipq8064 rev2 variant

Also, if you capitalize it as "QCA6390" in the commit log, do it the
same in the subject.

> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > ---
> > >   drivers/pci/controller/dwc/pcie-qcom.c | 21 +++++++++++++++++++++
> > >   1 file changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index ab21aa01c95d..eb73c8540d4d 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > > @@ -20,6 +20,7 @@
> > >   #include <linux/of_device.h>
> > >   #include <linux/of_gpio.h>
> > >   #include <linux/pci.h>
> > > +#include <linux/pm_domain.h>
> > >   #include <linux/pm_runtime.h>
> > >   #include <linux/platform_device.h>
> > >   #include <linux/phy/phy.h>
> > > @@ -1568,6 +1569,26 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0302, qcom_fixup_class);
> > >   DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x1000, qcom_fixup_class);
> > >   DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x1001, qcom_fixup_class);
> > > 
> > > +static void qcom_fixup_power(struct pci_dev *dev)
> > > +{
> > > +       int ret;
> > > +       struct pcie_port *pp = dev->bus->sysdata;
> > > +       struct dw_pcie *pci;
> > > +
> > > +       if (!pci_is_root_bus(dev->bus))
> > > +               return;
> > > +
> > > +       ret = dev_pm_domain_attach(&dev->dev, true);
> > > +       if (ret < 0 || !dev->dev.pm_domain)
> > > +               return;
> > > +
> > > +       pci = to_dw_pcie_from_pp(pp);
> > > +       dev_info(&dev->dev, "Bus powered up, waiting for link to come up\n");
> > > +
> > > +       dw_pcie_wait_for_link(pci);
> > > +}
> > > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x010b, qcom_fixup_power);
> > > +
> > >   static struct platform_driver qcom_pcie_driver = {
> > >          .probe = qcom_pcie_probe,
> > >          .driver = {
> > > --
> > > 2.29.2
> > > 
> 
> 
> -- 
> With best wishes
> Dmitry

  reply	other threads:[~2021-01-29 21:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 17:52 [PATCH v2 0/5] Add support for Qualcomm QCA639x chips family Dmitry Baryshkov
2021-01-28 17:52 ` [PATCH v2 1/5] misc: qca639x: add support for QCA639x powerup sequence Dmitry Baryshkov
2021-01-31 14:18   ` Kalle Valo
2021-01-28 17:52 ` [PATCH v2 2/5] arm64: qcom: dts: qrb5165-rb5: add qca6391 power device Dmitry Baryshkov
2021-01-30  3:47   ` Bjorn Andersson
2021-01-30  3:59     ` Manivannan Sadhasivam
2021-01-28 17:52 ` [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform Dmitry Baryshkov
     [not found]   ` <CAL_JsqLRn40h0K-Fze5m1LS2+raLp94LariMkUh7XtekTBT5+Q@mail.gmail.com>
2021-01-29  3:45     ` Dmitry Baryshkov
2021-01-29 21:50       ` Bjorn Helgaas [this message]
2021-01-29 22:19         ` Dmitry Baryshkov
2021-01-29 22:39           ` Bjorn Helgaas
2021-01-30  3:53           ` Bjorn Andersson
2021-01-30 16:14             ` Dmitry Baryshkov
2021-02-02 19:48               ` Bjorn Andersson
2021-02-02 21:37                 ` Rob Herring
2021-02-02 21:50                   ` Bjorn Andersson
2021-02-03  4:14                   ` Dmitry Baryshkov
2021-01-29 23:39       ` Rob Herring
2021-06-13 18:40   ` Konrad Dybcio
2021-01-28 17:52 ` [PATCH v2 4/5] arm64: dtb: qcom: qrb5165-rb5: add bridge@0,0 to power up qca6391 chip Dmitry Baryshkov
     [not found]   ` <CAL_Jsq+uim_0fDsCqSjgbz-xzUEu4GAf+KOgxSd1KdrFWjhd3Q@mail.gmail.com>
2021-01-29  3:48     ` Dmitry Baryshkov
2021-01-28 17:52 ` [PATCH v2 5/5] arm64: dts: qcom: Add Bluetooth support on RB5 Dmitry Baryshkov
     [not found]   ` <CAL_Jsq+nNRv3KceHthgktHR1oRMs+eKWC4O7n0k78izs1aTPfA@mail.gmail.com>
2021-01-29  3:49     ` Dmitry Baryshkov
2021-02-02  6:16     ` Manivannan Sadhasivam
2021-01-30  8:04 [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform Yassine Oudjana
2021-01-30 16:12 ` Dmitry Baryshkov

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=20210129215024.GA113900@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=agross@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=gregkh@linuxfoundation.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=manivannan.sadhasivam@linaro.org \
    --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).