From: Bjorn Andersson <email@example.com> To: Rob Herring <firstname.lastname@example.org> Cc: Dmitry Baryshkov <email@example.com>, Ulf Hansson <firstname.lastname@example.org>, Peter Chen <email@example.com>, Mark Brown <firstname.lastname@example.org>, Andy Gross <email@example.com>, Liam Girdwood <firstname.lastname@example.org>, Marcel Holtmann <email@example.com>, Johan Hedberg <firstname.lastname@example.org>, Luiz Augusto von Dentz <email@example.com>, linux-arm-msm <firstname.lastname@example.org>, Manivannan Sadhasivam <email@example.com>, DTML <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH v3 2/7] regulator: qca6390: add support for QCA639x powerup sequence Date: Wed, 14 Jul 2021 12:10:10 -0500 [thread overview] Message-ID: <YO8ackdFtbGhAqtM@yoga> (raw) In-Reply-To: <20210714164710.GC2719790@robh.at.kernel.org> On Wed 14 Jul 11:47 CDT 2021, Rob Herring 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 <email@example.com> wrote: > > > > > > - Peter (the email was bouncing) > > > > + Peter's kernel.org address > > > > > > > > On Tue, 6 Jul 2021 at 13:55, Mark Brown <firstname.lastname@example.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  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. > But what do you want to see? We have a single piece of hardware that needs a specific power sequence, which is interacted with using both UART and PCIe. > If pwrseq works as a kernel library/api, then I have no issue with that. > > > > > > Therefore, I think it would be worth having a common solution for > > > this, rather than a solution per subsystem or even worse, per device. > > Power sequencing requirements are inheritently per device unless we're > talking about standard connectors. > Do you mean "device" as in the IC or device as in struct device? Because we do have one physical IC, that has a need for a specific power on sequence, but we have two struct device, on two different busses in Linux interacting with this thing. > This is a solved problem on MDIO. It's quite simple. If there's a DT > node for a device you haven't discovered, then probe it anyways. > Okay, so DT tells us that there's actually a WiFi thing on the PCIe bus, even though we can't find it, so we probe something...then what? Regards, Bjorn
next prev parent reply other threads:[~2021-07-14 17:10 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-21 22:31 [PATCH v3 0/7] Add support for Qualcomm QCA639x chips family Dmitry Baryshkov 2021-06-21 22:31 ` [PATCH v3 1/7] dt-bindings: regulator: qcom,qca6390: add binding for QCA6390 device Dmitry Baryshkov 2021-06-21 23:11 ` Add support for Qualcomm QCA639x chips family bluez.test.bot 2021-06-21 22:31 ` [PATCH v3 2/7] regulator: qca6390: add support for QCA639x powerup sequence Dmitry Baryshkov 2021-06-22 11:28 ` Mark Brown 2021-06-22 14:17 ` Dmitry Baryshkov 2021-06-22 14:38 ` Mark Brown 2021-06-22 16:46 ` Dmitry Baryshkov 2021-06-22 17:08 ` Mark Brown 2021-07-06 7:54 ` Ulf Hansson 2021-07-06 11:55 ` Mark Brown 2021-07-08 10:09 ` Ulf Hansson 2021-07-08 11:37 ` Dmitry Baryshkov 2021-07-14 16:47 ` Rob Herring 2021-07-14 17:10 ` Bjorn Andersson [this message] 2021-08-10 11:55 ` Ulf Hansson 2021-08-10 16:03 ` Bjorn Andersson 2021-08-12 9:48 ` Ulf Hansson 2021-08-12 11:51 ` Dmitry Baryshkov 2021-07-14 17:23 ` Bjorn Andersson 2021-06-21 22:31 ` [PATCH v3 3/7] Bluetooth: hci_qca: provide default device data Dmitry Baryshkov 2021-07-14 17:27 ` Bjorn Andersson 2021-06-21 22:31 ` [PATCH v3 4/7] Bluetooth: hci_qca: merge qca_power into qca_serdev Dmitry Baryshkov 2021-07-14 17:25 ` Bjorn Andersson 2021-06-21 22:31 ` [PATCH v3 5/7] Bluetooth: hci_qca: merge wcn & non-wcn code paths Dmitry Baryshkov 2021-06-21 22:31 ` [PATCH v3 6/7] Bluetooth: hci_qca: add power sequencer support to qca6390 Dmitry Baryshkov 2021-06-21 22:31 ` [PATCH v3 7/7] arm64: dts: qcom: qrb5165-rb5: add QCA6391 WiFi+BT SoC 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=YO8ackdFtbGhAqtM@yoga \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v3 2/7] regulator: qca6390: add support for QCA639x powerup sequence' \ /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
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).