* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform
@ 2021-01-30 8:04 Yassine Oudjana
2021-01-30 16:12 ` Dmitry Baryshkov
0 siblings, 1 reply; 15+ messages in thread
From: Yassine Oudjana @ 2021-01-30 8:04 UTC (permalink / raw)
To: dmitry.baryshkov
Cc: agross, bhelgaas, arnd, bjorn.andersson, devicetree, gregkh,
linux-arm-msm, linux-kernel, linux-pci, lorenzo.pieralisi,
manivannan.sadhasivam, mchehab, svarbanov, robh+dt
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.
I'm lead to believe that this is also needed for QCA6174. I tried taking
the driver you wrote and changing regulators to match the ones used by QCA6174,
but I found that it gets probed after PCIe, which makes it get -EPROBE_DEFER
when it tries to attach to the power domain, which it doesn't handle it and
just proceeds to scan the bus and not find the chip as usual.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 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 0 siblings, 0 replies; 15+ messages in thread From: Dmitry Baryshkov @ 2021-01-30 16:12 UTC (permalink / raw) To: Yassine Oudjana Cc: agross, bhelgaas, arnd, bjorn.andersson, devicetree, gregkh, linux-arm-msm, linux-kernel, linux-pci, lorenzo.pieralisi, manivannan.sadhasivam, mchehab, svarbanov, robh+dt On Sat, 30 Jan 2021 at 11:04, Yassine Oudjana <y.oudjana@protonmail.com> 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. > > I'm lead to believe that this is also needed for QCA6174. I tried taking > the driver you wrote and changing regulators to match the ones used by QCA6174, > but I found that it gets probed after PCIe, which makes it get -EPROBE_DEFER > when it tries to attach to the power domain, which it doesn't handle it and > just proceeds to scan the bus and not find the chip as usual. As a quick hack, you can try using this power domain for the pci_phy (see my v1). Rob declined this approach, but it is useful to check if QCA6174 wakes up properly and deferring PCIe probing till the chip is powered up. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 0/5] Add support for Qualcomm QCA639x chips family @ 2021-01-28 17:52 Dmitry Baryshkov 2021-01-28 17:52 ` [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform Dmitry Baryshkov 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Baryshkov @ 2021-01-28 17:52 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Rob Herring, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas Cc: linux-arm-msm, Manivannan Sadhasivam, devicetree, linux-kernel, linux-pci Qualcomm QCA639x is a family of WiFi + Bluetooth chips, with BT part being controlled through the UART and WiFi being present on PCIe bus. Both blocks share common power sources wich should be turned on before either of devices can be probed. Declare common 'qca639x' driver providing a power domain to be used by both BT and WiFi parts. Changes since v1: - Stopped using wildcard in the dts binding, stick to qcom,qca6390. - Stopped using pcie0_phy for qca639x power domain. - Describe root PCIe bridge in the dts and bind power domain to the bridge. - Add pci quirk to power up power domains connected to this bridge. ---------------------------------------------------------------- Dmitry Baryshkov (4): misc: qca639x: add support for QCA639x powerup sequence arm64: qcom: dts: qrb5165-rb5: add qca6391 power device pcie-qcom: provide a way to power up qca6390 chip on RB5 platform arm64: dtb: qcom: qrb5165-rb5: add bridge@0,0 to power up qca6391 chip Manivannan Sadhasivam (1): arm64: dts: qcom: Add Bluetooth support on RB5 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/misc/Kconfig | 12 ++++++++++++ drivers/misc/Makefile | 1 + drivers/misc/qcom-qca639x.c | 164 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/pci/controller/dwc/pcie-qcom.c | 21 ++++++++++++++++++++ 5 files changed, 300 insertions(+) create mode 100644 drivers/misc/qcom-qca639x.c ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-28 17:52 [PATCH v2 0/5] Add support for Qualcomm QCA639x chips family Dmitry Baryshkov @ 2021-01-28 17:52 ` Dmitry Baryshkov [not found] ` <CAL_JsqLRn40h0K-Fze5m1LS2+raLp94LariMkUh7XtekTBT5+Q@mail.gmail.com> 2021-06-13 18:40 ` Konrad Dybcio 0 siblings, 2 replies; 15+ messages in thread From: Dmitry Baryshkov @ 2021-01-28 17:52 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Rob Herring, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas Cc: linux-arm-msm, Manivannan Sadhasivam, devicetree, linux-kernel, linux-pci 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. 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 ^ permalink raw reply related [flat|nested] 15+ messages in thread
[parent not found: <CAL_JsqLRn40h0K-Fze5m1LS2+raLp94LariMkUh7XtekTBT5+Q@mail.gmail.com>]
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform [not found] ` <CAL_JsqLRn40h0K-Fze5m1LS2+raLp94LariMkUh7XtekTBT5+Q@mail.gmail.com> @ 2021-01-29 3:45 ` Dmitry Baryshkov 2021-01-29 21:50 ` Bjorn Helgaas 2021-01-29 23:39 ` Rob Herring 0 siblings, 2 replies; 15+ messages in thread From: Dmitry Baryshkov @ 2021-01-29 3:45 UTC (permalink / raw) To: Rob Herring Cc: Andy Gross, Bjorn Andersson, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, devicetree, linux-kernel, PCI 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? > >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-29 3:45 ` Dmitry Baryshkov @ 2021-01-29 21:50 ` Bjorn Helgaas 2021-01-29 22:19 ` Dmitry Baryshkov 2021-01-29 23:39 ` Rob Herring 1 sibling, 1 reply; 15+ messages in thread From: Bjorn Helgaas @ 2021-01-29 21:50 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Rob Herring, Andy Gross, Bjorn Andersson, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, devicetree, linux-kernel, PCI 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-29 21:50 ` Bjorn Helgaas @ 2021-01-29 22:19 ` Dmitry Baryshkov 2021-01-29 22:39 ` Bjorn Helgaas 2021-01-30 3:53 ` Bjorn Andersson 0 siblings, 2 replies; 15+ messages in thread From: Dmitry Baryshkov @ 2021-01-29 22:19 UTC (permalink / raw) To: Bjorn Helgaas Cc: Rob Herring, Andy Gross, Bjorn Andersson, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > 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? Not quite. QCA6390 is a multifunction device, with PCIe and serial parts. It has internal power regulators which once enabled will powerup the PCIe, serial and radio parts. There is no need to manage regulators. Once enabled they will automatically handle device suspend/resume, etc. I'm not sure about link-up interrupt. I've just lightly tested using PCIe HP on this port, getting no interrupts from it. If I manually rescan the bus after enabling the qca6390 device (e.g. via sysfs), it gets enabled, but then I see PCIe link errors (most probably because the PCIe link was not retrained after the device comes up). > 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: Ack. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-29 22:19 ` Dmitry Baryshkov @ 2021-01-29 22:39 ` Bjorn Helgaas 2021-01-30 3:53 ` Bjorn Andersson 1 sibling, 0 replies; 15+ messages in thread From: Bjorn Helgaas @ 2021-01-29 22:39 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Rob Herring, Andy Gross, Bjorn Andersson, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Sat, Jan 30, 2021 at 01:19:10AM +0300, Dmitry Baryshkov wrote: > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > 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? > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > parts. It has internal power regulators which once enabled will > powerup the PCIe, serial and radio parts. There is no need to manage > regulators. Once enabled they will automatically handle device > suspend/resume, etc. OK, just elaborate on this a bit in the commit log so the topology makes sense to someone with no prior knowledge of QCA6390. Bjorn ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 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 1 sibling, 1 reply; 15+ messages in thread From: Bjorn Andersson @ 2021-01-30 3:53 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Bjorn Helgaas, Rob Herring, Andy Gross, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > 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? > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > parts. It has internal power regulators which once enabled will > powerup the PCIe, serial and radio parts. There is no need to manage > regulators. Once enabled they will automatically handle device > suspend/resume, etc. > So what you're saying is that if either the PCI controller or bluetooth driver probes these regulators will be turned on, indefinitely? If so, why do we need a driver to turn them on, rather than just mark them as always-on? What's the timing requirement wrt regulators vs WL_EN/BT_EN? Regards, Bjorn A > I'm not sure about link-up interrupt. I've just lightly tested using > PCIe HP on this port, getting no interrupts from it. > If I manually rescan the bus after enabling the qca6390 device (e.g. > via sysfs), it gets enabled, but then I see PCIe link errors (most > probably because the PCIe link was not retrained after the device > comes up). > > > 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: > > Ack. > > > -- > With best wishes > Dmitry ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-30 3:53 ` Bjorn Andersson @ 2021-01-30 16:14 ` Dmitry Baryshkov 2021-02-02 19:48 ` Bjorn Andersson 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Baryshkov @ 2021-01-30 16:14 UTC (permalink / raw) To: Bjorn Andersson Cc: Bjorn Helgaas, Rob Herring, Andy Gross, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > > > 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? > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > parts. It has internal power regulators which once enabled will > > powerup the PCIe, serial and radio parts. There is no need to manage > > regulators. Once enabled they will automatically handle device > > suspend/resume, etc. > > > > So what you're saying is that if either the PCI controller or bluetooth > driver probes these regulators will be turned on, indefinitely? > > If so, why do we need a driver to turn them on, rather than just mark > them as always-on? > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? According to the documentation I have, they must be enabled right after enabling powering the chip and they must stay enabled all the time. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-30 16:14 ` Dmitry Baryshkov @ 2021-02-02 19:48 ` Bjorn Andersson 2021-02-02 21:37 ` Rob Herring 0 siblings, 1 reply; 15+ messages in thread From: Bjorn Andersson @ 2021-02-02 19:48 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Bjorn Helgaas, Rob Herring, Andy Gross, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Sat 30 Jan 10:14 CST 2021, Dmitry Baryshkov wrote: > On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > > > > > 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? > > > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > > parts. It has internal power regulators which once enabled will > > > powerup the PCIe, serial and radio parts. There is no need to manage > > > regulators. Once enabled they will automatically handle device > > > suspend/resume, etc. > > > > > > > So what you're saying is that if either the PCI controller or bluetooth > > driver probes these regulators will be turned on, indefinitely? > > > > If so, why do we need a driver to turn them on, rather than just mark > > them as always-on? > > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? > > According to the documentation I have, they must be enabled right > after enabling powering the chip and they must stay enabled all the > time. > So presumably just marking these things always-on and flipping the GPIO statically won't be good enough due to the lack of control over the timing. This really do look like a simplified case of what we see with the PCIe attached modems, where similar requirements are provided, but also the ability to perform a device specific reset sequence in case the hardware has locked up. I'm slightly worried about the ability of extending your power-domain model to handle the restart operation though. Regards, Bjorn ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 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 0 siblings, 2 replies; 15+ messages in thread From: Rob Herring @ 2021-02-02 21:37 UTC (permalink / raw) To: Bjorn Andersson Cc: Dmitry Baryshkov, Bjorn Helgaas, Andy Gross, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Tue, Feb 2, 2021 at 1:48 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Sat 30 Jan 10:14 CST 2021, Dmitry Baryshkov wrote: > > > On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson > > <bjorn.andersson@linaro.org> wrote: > > > > > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > > > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > > > > > > > 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? > > > > > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > > > parts. It has internal power regulators which once enabled will > > > > powerup the PCIe, serial and radio parts. There is no need to manage > > > > regulators. Once enabled they will automatically handle device > > > > suspend/resume, etc. > > > > > > > > > > So what you're saying is that if either the PCI controller or bluetooth > > > driver probes these regulators will be turned on, indefinitely? > > > > > > If so, why do we need a driver to turn them on, rather than just mark > > > them as always-on? > > > > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? > > > > According to the documentation I have, they must be enabled right > > after enabling powering the chip and they must stay enabled all the > > time. > > > > So presumably just marking these things always-on and flipping the GPIO > statically won't be good enough due to the lack of control over the > timing. > > This really do look like a simplified case of what we see with the > PCIe attached modems, where similar requirements are provided, but also > the ability to perform a device specific reset sequence in case the > hardware has locked up. I'm slightly worried about the ability of > extending your power-domain model to handle the restart operation > though. I think this is an abuse of 'power-domains'. Just define the regulators in both WiFi and BT nodes and have each driver enable them. They're refcounted. If that's still not enough control over the power sequencing, then create a 3rd entity to do it, but that doesn't need to leak into DT. You already have all the information you need. Rob ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-02-02 21:37 ` Rob Herring @ 2021-02-02 21:50 ` Bjorn Andersson 2021-02-03 4:14 ` Dmitry Baryshkov 1 sibling, 0 replies; 15+ messages in thread From: Bjorn Andersson @ 2021-02-02 21:50 UTC (permalink / raw) To: Rob Herring Cc: Dmitry Baryshkov, Bjorn Helgaas, Andy Gross, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI On Tue 02 Feb 15:37 CST 2021, Rob Herring wrote: > On Tue, Feb 2, 2021 at 1:48 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > > > On Sat 30 Jan 10:14 CST 2021, Dmitry Baryshkov wrote: > > > > > On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > > > > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > > > > > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > > > > > > > > > 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? > > > > > > > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > > > > parts. It has internal power regulators which once enabled will > > > > > powerup the PCIe, serial and radio parts. There is no need to manage > > > > > regulators. Once enabled they will automatically handle device > > > > > suspend/resume, etc. > > > > > > > > > > > > > So what you're saying is that if either the PCI controller or bluetooth > > > > driver probes these regulators will be turned on, indefinitely? > > > > > > > > If so, why do we need a driver to turn them on, rather than just mark > > > > them as always-on? > > > > > > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? > > > > > > According to the documentation I have, they must be enabled right > > > after enabling powering the chip and they must stay enabled all the > > > time. > > > > > > > So presumably just marking these things always-on and flipping the GPIO > > statically won't be good enough due to the lack of control over the > > timing. > > > > This really do look like a simplified case of what we see with the > > PCIe attached modems, where similar requirements are provided, but also > > the ability to perform a device specific reset sequence in case the > > hardware has locked up. I'm slightly worried about the ability of > > extending your power-domain model to handle the restart operation > > though. > > I think this is an abuse of 'power-domains'. Just define the > regulators in both WiFi and BT nodes and have each driver enable them. > They're refcounted. If that's still not enough control over the power > sequencing, then create a 3rd entity to do it, but that doesn't need > to leak into DT. You already have all the information you need. > As Dmitry explained he still need to pull the two GPIOs high after enabling the regulators, but before scanning the PCI or serdev buses. I was thinking something along the lines you suggest, but I've not been able to come up with something that will guarantee the ordering of the events. Regards, Bjorn ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-02-02 21:37 ` Rob Herring 2021-02-02 21:50 ` Bjorn Andersson @ 2021-02-03 4:14 ` Dmitry Baryshkov 1 sibling, 0 replies; 15+ messages in thread From: Dmitry Baryshkov @ 2021-02-03 4:14 UTC (permalink / raw) To: Rob Herring Cc: Bjorn Andersson, Bjorn Helgaas, Andy Gross, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, linux-kernel, PCI, Kalle Valo On Wed, 3 Feb 2021 at 00:37, Rob Herring <robh+dt@kernel.org> wrote: > > On Tue, Feb 2, 2021 at 1:48 PM Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > > > On Sat 30 Jan 10:14 CST 2021, Dmitry Baryshkov wrote: > > > > > On Sat, 30 Jan 2021 at 06:53, Bjorn Andersson > > > <bjorn.andersson@linaro.org> wrote: > > > > > > > > On Fri 29 Jan 16:19 CST 2021, Dmitry Baryshkov wrote: > > > > > > > > > On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > > > > > > > > > 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? > > > > > > > > > > Not quite. QCA6390 is a multifunction device, with PCIe and serial > > > > > parts. It has internal power regulators which once enabled will > > > > > powerup the PCIe, serial and radio parts. There is no need to manage > > > > > regulators. Once enabled they will automatically handle device > > > > > suspend/resume, etc. > > > > > > > > > > > > > So what you're saying is that if either the PCI controller or bluetooth > > > > driver probes these regulators will be turned on, indefinitely? > > > > > > > > If so, why do we need a driver to turn them on, rather than just mark > > > > them as always-on? > > > > > > > > What's the timing requirement wrt regulators vs WL_EN/BT_EN? > > > > > > According to the documentation I have, they must be enabled right > > > after enabling powering the chip and they must stay enabled all the > > > time. > > > > > > > So presumably just marking these things always-on and flipping the GPIO > > statically won't be good enough due to the lack of control over the > > timing. > > > > This really do look like a simplified case of what we see with the > > PCIe attached modems, where similar requirements are provided, but also > > the ability to perform a device specific reset sequence in case the > > hardware has locked up. I'm slightly worried about the ability of > > extending your power-domain model to handle the restart operation > > though. > > I think this is an abuse of 'power-domains'. Just define the > regulators in both WiFi and BT nodes and have each driver enable them. I think it is too late to enable regulators in the WiFi driver. Even if I modify the/pci code to register devices basing on the OF nodes (like we do for PPC and Sparc), necessary link training/hotplug handling should happen outside of the WiFi driver. > They're refcounted. If that's still not enough control over the power > sequencing, then create a 3rd entity to do it, but that doesn't need > to leak into DT. You already have all the information you need. From my point of view the proposed design (with three nodes) exactly represents the hardware: the power-handling part, the WiFi part and the BT part. If you don't like the power domains, would regulators be better from your point of view? The "power" device providing a regulator to be used by the child nodes. For the BT part the regulator is fine, while for the WiFi... The major problem with regulators in this case is that they are typically enabled by the device driver itself, rather than by parent device/bus code. And in the WiFi driver case the WiFi chip should be already up and running before probing the ath11k driver. Maybe it would still be better to take a step back and just introduce 'vcc-child-supply' entry to the pcie-qcom device tree node or to the PCIe bridge node? This would also cover cases of PCIe mezzanine boards when the on-mezzanine devices are visible through the PCIe bus, but the mezzanine is powered by a separate voltage regulator. It would not be possible to describe child devices in the device tree node, but rather it would be possible to describe that there might be devices behind the PCIe bridge, they must be powered on using a referenced regulator. This starts to sound like a kind of PCI hotplug. This would result in the following nodes: pcie0: pci@1c0000 { compatible = "qcom,pcie-sm8250"; [....] bridge@0,0 { compatible = "pci17cb,010b", "linux,regulator-hotplug"; [....] vcc-children-supply = <&qca6390>; /* known WiFi card */ }; }; pce1: pci@1c08000 { compatible = "qcom,pcie-sm8250"; [....] bridge@1,0 { compatible = "pci17cb,010b", "linux,regulator-hotplug"; [....] vcc-children-supply = <&vdc_gpio13>; /* unpredictable devices on the mezzanine card */ }; }; -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 2021-01-29 3:45 ` Dmitry Baryshkov 2021-01-29 21:50 ` Bjorn Helgaas @ 2021-01-29 23:39 ` Rob Herring 1 sibling, 0 replies; 15+ messages in thread From: Rob Herring @ 2021-01-29 23:39 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Andy Gross, Bjorn Andersson, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas, linux-arm-msm, Manivannan Sadhasivam, devicetree, linux-kernel, PCI, Mauro Carvalho Chehab On Thu, Jan 28, 2021 at 9:45 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> 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? Oh good, something exists. :) FYI, there's another similar case needing this that just popped up[1]. Rob [1] https://lore.kernel.org/linux-pci/20210129173057.30288c9d@coco.lan/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v2 3/5] pcie-qcom: provide a way to power up qca6390 chip on RB5 platform 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-06-13 18:40 ` Konrad Dybcio 1 sibling, 0 replies; 15+ messages in thread From: Konrad Dybcio @ 2021-06-13 18:40 UTC (permalink / raw) To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring, Arnd Bergmann, Greg Kroah-Hartman, Stanimir Varbanov, Lorenzo Pieralisi, Bjorn Helgaas Cc: linux-arm-msm, Manivannan Sadhasivam, devicetree, linux-kernel, linux-pci Hi, bumping the discussion as solving this is crucial for Wi-Fi and Bluetooth to work on a good number (which will probably increase with time) of Qualcomm devices, including newer phones. Konrad ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-06-13 18:40 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 -- strict thread matches above, loose matches on Subject: below -- 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 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 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
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).