From: Ulf Hansson <email@example.com> To: Rob Herring <firstname.lastname@example.org> Cc: Dmitry Baryshkov <email@example.com>, Peter Chen <firstname.lastname@example.org>, Mark Brown <email@example.com>, Andy Gross <firstname.lastname@example.org>, Bjorn Andersson <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: Tue, 10 Aug 2021 13:55:09 +0200 [thread overview] Message-ID: <CAPDyKFokvTFSpbnhhKeCmZzAjqvSpUiwz7QjjQNdcd3Sd3T0rQ@mail.gmail.com> (raw) In-Reply-To: <20210714164710.GC2719790@robh.at.kernel.org> On Wed, 14 Jul 2021 at 18:47, Rob Herring <email@example.com> 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 <firstname.lastname@example.org> wrote: > > > > > > - Peter (the email was bouncing) > > > > + Peter's kernel.org address > > > > > > > > On Tue, 6 Jul 2021 at 13:55, Mark Brown <email@example.com> 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. 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? > > If pwrseq works as a kernel library/api, then I have no issue with that. That's what Peter Chen was trying to do. A generic interface, flexible enough so it can be used for many similar configurations (but not exactly the same). Perhaps it was too generic though. > > > > > > 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. The requirements are certainly per device, but the way to manage them doesn't have to be. As you said above, a generic library that subsystems/drivers can call to power on/off a discoverable device, before trying to probe it would be a good start. > > 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. A child OF node? Then what do you think about some common power sequence properties that we can use in such node? > > Rob Kind regards Uffe
next prev parent reply other threads:[~2021-08-10 11:55 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 2021-08-10 11:55 ` Ulf Hansson [this message] 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=CAPDyKFokvTFSpbnhhKeCmZzAjqvSpUiwz7QjjQNdcd3Sd3T0rQ@mail.gmail.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 \ --email@example.com \ --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).