Messages in this thread | | | Subject | Re: [PATCH v3 2/7] regulator: qca6390: add support for QCA639x powerup sequence | From | Dmitry Baryshkov <> | Date | Thu, 12 Aug 2021 14:51:39 +0300 |
| |
On 12/08/2021 12:48, Ulf Hansson wrote: > On Tue, 10 Aug 2021 at 18:03, Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: >> >> On Tue 10 Aug 06:55 CDT 2021, Ulf Hansson wrote: >> >>> On Wed, 14 Jul 2021 at 18:47, Rob Herring <robh@kernel.org> wrote: >>>> >>>> On Thu, Jul 08, 2021 at 02:37:44PM +0300, Dmitry Baryshkov wrote: >>>>> Hi, >>>>> >>>>> On Thu, 8 Jul 2021 at 13:10, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>>>> >>>>>> - Peter (the email was bouncing) >>>>> >>>>> + Peter's kernel.org address >>>>> >>>>>> >>>>>> On Tue, 6 Jul 2021 at 13:55, Mark Brown <broonie@kernel.org> wrote: >>>>>>> >>>>>>> On Tue, Jul 06, 2021 at 09:54:03AM +0200, Ulf Hansson wrote: >>>>>>>> On Tue, 22 Jun 2021 at 00:32, Dmitry Baryshkov >>>>>>> >>>>>>>>> Qualcomm QCA6390/1 is a family of WiFi + Bluetooth SoCs, with BT part >>>>>>>>> being controlled through the UART and WiFi being present on PCIe >>>>>>>>> bus. Both blocks share common power sources. Add device driver handling >>>>>>>>> power sequencing of QCA6390/1. >>>>>>> >>>>>>>> Power sequencing of discoverable buses have been discussed several >>>>>>>> times before at LKML. The last attempt [1] I am aware of, was in 2017 >>>>>>>> from Peter Chen. I don't think there is a common solution, yet. >>>>>>> >>>>>>> This feels a bit different to the power sequencing problem - it's not >>>>>>> exposing the individual inputs to the device but rather is a block that >>>>>>> manages everything but needs a bit of a kick to get things going (I'd >>>>>>> guess that with ACPI it'd be triggered via AML). It's in the same space >>>>>>> but it's not quite the same issue I think, something that can handle >>>>>>> control of the individual resources might still struggle with this. >>>>>> >>>>>> Well, to me it looks very similar to those resouses we could manage >>>>>> with the mmc pwrseq, for SDIO. It's also typically the same kind of >>>>>> combo-chips that moved from supporting SDIO to PCIe, for improved >>>>>> performance I guess. More importantly, the same constraint to >>>>>> pre-power on the device is needed to allow it to be discovered/probed. >>>>> >>>>> In our case we'd definitely use pwrseq for PCIe bus and we can also >>>>> benefit from using pwrseq for serdev and for platform busses also (for >>>>> the same story of WiFi+BT chips). >>>>> >>>>> I can take a look at rewriting pwrseq code to also handle the PCIe >>>>> bus. Rewriting it to be a generic lib seems like an easy task, >>>>> plugging it into PCIe code would be more fun. >>>>> >>>>> Platform and serdev... Definitely even more fun. >>>> >>>> I don't want to see pwrseq (the binding) expanded to other buses. If >>>> that was the answer, we wouldn't be having this discussion. It was a >>>> mistake for MMC IMO. >>> >>> Let's make sure we get your point correctly. I think we have discussed >>> this in the past, but let's refresh our memories. >>> >>> If I recall correctly, you are against the mmc pwrseq DT bindings >>> because we are using a separate pwrseq OF node, that we point to via a >>> "mmc-pwrseq" property that contains a phandle from the mmc controller >>> device node. Is that correct? >>> >>> If we would have encoded the power sequence specific properties, from >>> within a child node for the mmc controller node, that would have been >>> okay for you, right? >>> >> >> In Dmitry's case, we have an external chip with that needs to be powered >> on per a specific sequence, at which point the WiFi driver on PCIe and >> BT driver on serdev will be able to communicate with the device. > > Thanks for sharing more details. > > So, not only do we have a discoverable device that needs to be powered > on in a device specific way before probing, but in fact we have two > consumers of that "combo chip", one (PCIe) for Wifi and one (serdev) > for Bluetooth. > >> >> The extended case of this is where we have an SDX55 modem soldered onto >> the pcb next to the SoC, in which case the power sequencing is even more >> complex and additionally there are incoming gpios used to detect things >> such as the firmware of the modem has crashed and Linux needs to toggle >> power and rescan the PCIe bus. > > That sounds very similar to what we manage for the SDIO bus already. > > We have a mmc pwrseq node to describe what resources that are needed > to power on/off the external chip. The driver for the functional > device (Wifi chip for example) may then call SDIO APIs provided by the > mmc core to power on/off the device, in case some kind of reset would > be needed. > > Additionally, we have a child node below the mmc controller node, > allowing us to describe device specific things for the SDIO functional > device, like an out-of-band IRQ line for example. > > Overall, this seems to work fine, even if the DT bindings may be questionable. > >> >> In both of these cases it seems quite reasonable to represent that >> external chip (and it's power needs) as a separate DT node. But we need >> a way to link the functional devices to that thing. > > Don't get me wrong, I am not suggesting we should re-use the > mmc-pwrseq DT bindings - but just trying to share our experience > around them. > > In the cases you describe, it certainly sounds like we need some kind > of minimal description in DT for these functional external devices. > For GPIO pins, for example. > > How to describe this in DT is one thing, let's see if Rob can help to > point us in some direction of what could make sense. > > When it comes to implementing a library/interface to manage these > functional devices, I guess we just have to continue to explore > various options. Perhaps just start simple with another subsystem, > like PCIe and see where this brings us.
Thank you for your opinion and suggestions. In fact I'm probably going to start working on non-discoverable busses first (by chaning support for few other BT+WiFi Qualcomm chips), later shifting the attention to the PCIe part. While this may seem like a longer path, I'd like to narrow pwrseq subsystem first, before going into PCIe details.
-- With best wishes Dmitry
| |