From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Rob Herring <robh@kernel.org> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Ulf Hansson <ulf.hansson@linaro.org>, Marcel Holtmann <marcel@holtmann.org>, Johan Hedberg <johan.hedberg@gmail.com>, Luiz Augusto von Dentz <luiz.dentz@gmail.com>, Kalle Valo <kvalo@codeaurora.org>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Stanimir Varbanov <svarbanov@mm-sol.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, linux-mmc <linux-mmc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>, ath10k@lists.infradead.org, linux-wireless <linux-wireless@vger.kernel.org>, netdev <netdev@vger.kernel.org>, Abel Vesa <abel.vesa@linaro.org> Subject: Re: [PATCH v1 01/15] dt-bindings: add pwrseq device tree bindings Date: Fri, 10 Mar 2023 07:56:49 +0000 [thread overview] Message-ID: <6108c68b-e38b-3060-f6fa-53be79a795d7@linaro.org> (raw) In-Reply-To: <31792ef1-20b0-b801-23b7-29f303b91def@linaro.org> On 02/11/2021 15:26, Dmitry Baryshkov wrote: > On 28/10/2021 00:53, Rob Herring wrote: >> On Tue, Oct 26, 2021 at 9:42 AM Dmitry Baryshkov >> <dmitry.baryshkov@linaro.org> wrote: >>> >>> On 26/10/2021 15:53, Rob Herring wrote: >>>> On Wed, Oct 06, 2021 at 06:53:53AM +0300, Dmitry Baryshkov wrote: >>>>> Add device tree bindings for the new power sequencer subsystem. >>>>> Consumers would reference pwrseq nodes using "foo-pwrseq" properties. >>>>> Providers would use '#pwrseq-cells' property to declare the amount of >>>>> cells in the pwrseq specifier. >>>> >>>> Please use get_maintainers.pl. >>>> >>>> This is not a pattern I want to encourage, so NAK on a common binding. >>> >>> >>> Could you please spend a few more words, describing what is not >>> encouraged? The whole foo-subsys/#subsys-cells structure? >> >> No, that's generally how common provider/consumer style bindings work. >> >>> Or just specifying the common binding? >> >> If we could do it again, I would not have mmc pwrseq binding. The >> properties belong in the device's node. So don't generalize the mmc >> pwrseq binding. >> >> It's a kernel problem if the firmware says there's a device on a >> 'discoverable' bus and the kernel can't discover it. I know you have >> the added complication of a device with 2 interfaces, but please, >> let's solve one problem at a time. Just to keep this topic updated with some pointers [1] to changes done to solve same problem in USB Hub. These patches (drivers/usb/misc/onboard_usb_hub*) have been merged since last year July. It looks like we can take some inspiration from this to address PCIE Bus issue aswell. Thanks to Neil to point this. [1] https://lore.kernel.org/lkml/20220630193530.2608178-1-mka@chromium.org/T/ --srini > > The PCI bus handling is a separate topic for now (as you have seen from > the clearly WIP patches targeting just testing of qca6390's wifi part). > > For me there are three parts of the device: > - power regulator / device embedded power domain. > - WiFi > - Bluetooth > > With the power regulator being a complex and a bit nasty beast. It has > several regulators beneath, which have to be powered up in a proper way. > Next platforms might bring additional requirements common to both WiFi > and BT parts (like having additional clocks, etc). It is externally > controlled (after providing power to it you have to tell, which part of > the chip is required by pulling up the WiFi and/or BT enable GPIOs. > > Having to duplicate this information in BT and WiFi cases results in > non-aligned bindings (with WiFi and BT parts using different set of > properties and different property names) and non-algined drivers (so the > result of the powerup would depend on the order of drivers probing). > > So far I still suppose that having a single separate entity controlling > the powerup of such chips is the right thing to do. > > I'd prefer to use the power-domain bindings (as the idea seems to be > aligned here), but as the power-domain is used for the in-chip power > domains, we had to invent the pwrseq name. >
WARNING: multiple messages have this Message-ID (diff)
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Rob Herring <robh@kernel.org> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Ulf Hansson <ulf.hansson@linaro.org>, Marcel Holtmann <marcel@holtmann.org>, Johan Hedberg <johan.hedberg@gmail.com>, Luiz Augusto von Dentz <luiz.dentz@gmail.com>, Kalle Valo <kvalo@codeaurora.org>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Stanimir Varbanov <svarbanov@mm-sol.com>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, linux-mmc <linux-mmc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>, ath10k@lists.infradead.org, linux-wireless <linux-wireless@vger.kernel.org>, netdev <netdev@vger.kernel.org>, Abel Vesa <abel.vesa@linaro.org> Subject: Re: [PATCH v1 01/15] dt-bindings: add pwrseq device tree bindings Date: Fri, 10 Mar 2023 07:56:49 +0000 [thread overview] Message-ID: <6108c68b-e38b-3060-f6fa-53be79a795d7@linaro.org> (raw) In-Reply-To: <31792ef1-20b0-b801-23b7-29f303b91def@linaro.org> On 02/11/2021 15:26, Dmitry Baryshkov wrote: > On 28/10/2021 00:53, Rob Herring wrote: >> On Tue, Oct 26, 2021 at 9:42 AM Dmitry Baryshkov >> <dmitry.baryshkov@linaro.org> wrote: >>> >>> On 26/10/2021 15:53, Rob Herring wrote: >>>> On Wed, Oct 06, 2021 at 06:53:53AM +0300, Dmitry Baryshkov wrote: >>>>> Add device tree bindings for the new power sequencer subsystem. >>>>> Consumers would reference pwrseq nodes using "foo-pwrseq" properties. >>>>> Providers would use '#pwrseq-cells' property to declare the amount of >>>>> cells in the pwrseq specifier. >>>> >>>> Please use get_maintainers.pl. >>>> >>>> This is not a pattern I want to encourage, so NAK on a common binding. >>> >>> >>> Could you please spend a few more words, describing what is not >>> encouraged? The whole foo-subsys/#subsys-cells structure? >> >> No, that's generally how common provider/consumer style bindings work. >> >>> Or just specifying the common binding? >> >> If we could do it again, I would not have mmc pwrseq binding. The >> properties belong in the device's node. So don't generalize the mmc >> pwrseq binding. >> >> It's a kernel problem if the firmware says there's a device on a >> 'discoverable' bus and the kernel can't discover it. I know you have >> the added complication of a device with 2 interfaces, but please, >> let's solve one problem at a time. Just to keep this topic updated with some pointers [1] to changes done to solve same problem in USB Hub. These patches (drivers/usb/misc/onboard_usb_hub*) have been merged since last year July. It looks like we can take some inspiration from this to address PCIE Bus issue aswell. Thanks to Neil to point this. [1] https://lore.kernel.org/lkml/20220630193530.2608178-1-mka@chromium.org/T/ --srini > > The PCI bus handling is a separate topic for now (as you have seen from > the clearly WIP patches targeting just testing of qca6390's wifi part). > > For me there are three parts of the device: > - power regulator / device embedded power domain. > - WiFi > - Bluetooth > > With the power regulator being a complex and a bit nasty beast. It has > several regulators beneath, which have to be powered up in a proper way. > Next platforms might bring additional requirements common to both WiFi > and BT parts (like having additional clocks, etc). It is externally > controlled (after providing power to it you have to tell, which part of > the chip is required by pulling up the WiFi and/or BT enable GPIOs. > > Having to duplicate this information in BT and WiFi cases results in > non-aligned bindings (with WiFi and BT parts using different set of > properties and different property names) and non-algined drivers (so the > result of the powerup would depend on the order of drivers probing). > > So far I still suppose that having a single separate entity controlling > the powerup of such chips is the right thing to do. > > I'd prefer to use the power-domain bindings (as the idea seems to be > aligned here), but as the power-domain is used for the in-chip power > domains, we had to invent the pwrseq name. > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2023-03-10 7:57 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <2h9GS3myO9uyX8sDYwU_43cDbBCW_SE1h5qolKQLKT9ZVvz0-K6z6cix50eVsgMsYLtgTLsW37DxF0lf78vxCA==@protonmail.internalid> 2021-10-06 3:53 ` [PATCH v1 00/15] create power sequencing subsystem Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:53 ` [PATCH v1 01/15] dt-bindings: add pwrseq device tree bindings Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-26 12:53 ` Rob Herring 2021-10-26 12:53 ` Rob Herring 2021-10-26 14:42 ` Dmitry Baryshkov 2021-10-26 14:42 ` Dmitry Baryshkov 2021-10-27 21:53 ` Rob Herring 2021-10-27 21:53 ` Rob Herring 2021-11-02 15:26 ` Dmitry Baryshkov 2021-11-02 15:26 ` Dmitry Baryshkov 2023-03-10 7:56 ` Srinivas Kandagatla [this message] 2023-03-10 7:56 ` Srinivas Kandagatla 2021-10-06 3:53 ` [PATCH v1 02/15] power: add power sequencer subsystem Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:53 ` [PATCH v1 03/15] pwrseq: port MMC's pwrseq drivers to new pwrseq subsystem Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:53 ` [PATCH v1 04/15] mmc: core: switch " Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:53 ` [PATCH v1 05/15] pwrseq: implement onecell helper Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:53 ` [PATCH v1 06/15] pwrseq: add support for QCA BT+WiFi power sequencer Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:53 ` [PATCH v1 07/15] pwrseq: add fallback support Dmitry Baryshkov 2021-10-06 3:53 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 08/15] pwrseq: pwrseq_qca: implement " Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 09/15] Bluetooth: hci_qca: switch to using pwrseq Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 10/15] ath10k: add support for pwrseq sequencing Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-07 5:31 ` Kalle Valo 2021-10-07 5:31 ` Kalle Valo 2021-10-06 3:54 ` [PATCH v1 11/15] arm64: dts: qcom: sdm845-db845c: switch bt+wifi to qca power sequencer Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 12/15] arm64: dts: qcom: qrb5165-rb5: add bluetooth support Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 13/15] arm64: dts: qcom: sdm845-db845c: add second channel to qca power sequencer Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 14/15] WIP: PCI: qcom: use pwrseq to power up bus devices Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-06 3:54 ` [PATCH v1 15/15] WIP: arm64: dts: qcom: qrb5165-rb5: add bus-pwrseq property to pcie0 Dmitry Baryshkov 2021-10-06 3:54 ` Dmitry Baryshkov 2021-10-07 5:27 ` [PATCH v1 00/15] create power sequencing subsystem Kalle Valo 2021-10-07 5:27 ` Kalle Valo 2021-11-02 14:05 ` Caleb Connolly 2021-11-02 14:05 ` Caleb Connolly 2022-09-23 14:39 ` Luca Weiss 2022-09-23 14:39 ` Luca Weiss 2022-10-13 19:50 ` Matthias Kaehlcke 2022-10-13 19:50 ` Matthias Kaehlcke 2022-10-19 6:03 ` Dmitry Baryshkov 2022-10-19 6:03 ` Dmitry Baryshkov 2023-03-01 8:17 ` Alexander Stein 2023-03-01 8:17 ` Alexander Stein 2023-03-01 9:02 ` Ulf Hansson 2023-03-01 9:02 ` Ulf Hansson
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=6108c68b-e38b-3060-f6fa-53be79a795d7@linaro.org \ --to=srinivas.kandagatla@linaro.org \ --cc=abel.vesa@linaro.org \ --cc=agross@kernel.org \ --cc=ath10k@lists.infradead.org \ --cc=bjorn.andersson@linaro.org \ --cc=davem@davemloft.net \ --cc=dmitry.baryshkov@linaro.org \ --cc=johan.hedberg@gmail.com \ --cc=kuba@kernel.org \ --cc=kvalo@codeaurora.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-bluetooth@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=luiz.dentz@gmail.com \ --cc=marcel@holtmann.org \ --cc=netdev@vger.kernel.org \ --cc=robh@kernel.org \ --cc=svarbanov@mm-sol.com \ --cc=ulf.hansson@linaro.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.