From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: Marcel Holtmann <marcel@holtmann.org> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Ulf Hansson <ulf.hansson@linaro.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>, MSM <linux-arm-msm@vger.kernel.org>, linux-mmc@vger.kernel.org, open list <linux-kernel@vger.kernel.org>, "open list:BLUETOOTH SUBSYSTEM" <linux-bluetooth@vger.kernel.org>, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH 00/15] create power sequencing subsystem Date: Fri, 20 Aug 2021 16:08:21 +0300 [thread overview] Message-ID: <CAA8EJpoOxerwmwQozL3gp1nX-+oxLMFUFjVPvRy-MoVfPuvqrw@mail.gmail.com> (raw) In-Reply-To: <1CA665D1-86F0-45A1-862D-17DAB3ABA974@holtmann.org> Hi, On Thu, 19 Aug 2021 at 18:23, Marcel Holtmann <marcel@holtmann.org> wrote: > > This is an RFC of the proposed power sequencer subsystem. This is a > > generification of the MMC pwrseq code. The subsystem tries to abstract > > the idea of complex power-up/power-down/reset of the devices. > > > > The primary set of devices that promted me to create this patchset is > > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > > interfaces (older generations) or on serial+PCIe (newer generations). > > They require a set of external voltage regulators to be powered on and > > (some of them) have separate WiFi and Bluetooth enable GPIOs. > > > > This patchset being an RFC tries to demonstrate the approach, design and > > usage of the pwrseq subsystem. Following issues are present in the RFC > > at this moment but will be fixed later if the overall approach would be > > viewed as acceptable: > > > > - No documentation > > While the code tries to be self-documenting proper documentation > > would be required. > > > > - Minimal device tree bindings changes > > There are no proper updates for the DT bindings (thus neither Rob > > Herring nor devicetree are included in the To/Cc lists). The dt > > schema changes would be a part of v1. > > > > - Lack of proper PCIe integration > > At this moment support for PCIe is hacked up to be able to test the > > PCIe part of qca6390. Proper PCIe support would require automatically > > powering up the devices before the scan basing on the proper device > > structure in the device tree. > > > > ---------------------------------------------------------------- > > Dmitry Baryshkov (15): > > power: add power sequencer subsystem > > pwrseq: port MMC's pwrseq drivers to new pwrseq subsystem > > mmc: core: switch to new pwrseq subsystem > > ath10k: add support for pwrseq sequencing > > Bluetooth: hci_qca: merge qca_power into qca_serdev > > Bluetooth: hci_qca: merge init paths > > Bluetooth: hci_qca: merge qca_power_on with qca_regulators_init > > Bluetooth: hci_qca: futher rework of power on/off handling > > Bluetooth: hci_qca: add support for pwrseq > > any chance you can try to abandon patching hci_qca. The serdev support in hci_uart is rather hacking into old line discipline code and it is not aging well. It is really becoming a mess. I wanted to stay away from rewriting the BT code. But... New driver would have a bonus point that I don't have to be compatible with old bindings. In fact we can even make it the other way around: let the old driver always use regulators and make the new driver support only the pwrseq. Then it should be possible to drop the old hci_qca driver together with dropping the old bindings. > I would say that the Qualcomm serial devices could use a separate standalone serdev driver. A while I send an RFC for a new serdev driver. > > https://www.spinics.net/lists/linux-bluetooth/msg74918.html Any reason why your driver stayed as an RFC and never made it into the kernel? Do you plan to revive your old RFCs on H:4 and H:5? > There I had the idea that simple vendor specifics can be in that driver (like the Broadcom part I added there), but frankly the QCA specifics are a bit too specific and it should be a separate driver. However I think this would be a good starting point. > > In general a H:4 based Bluetooth driver is dead simple with the help of h4_recv.h helper we have in the kernel. The complicated part is the power management pieces or any vendor specific low-power protocol they are running on that serial line. And since you are touching this anyway, doing a driver from scratch might be lot simpler and cleaner. It would surely help all the new QCA device showing up in the future. -- With best wishes Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> To: Marcel Holtmann <marcel@holtmann.org> Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Ulf Hansson <ulf.hansson@linaro.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>, MSM <linux-arm-msm@vger.kernel.org>, linux-mmc@vger.kernel.org, open list <linux-kernel@vger.kernel.org>, "open list:BLUETOOTH SUBSYSTEM" <linux-bluetooth@vger.kernel.org>, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH 00/15] create power sequencing subsystem Date: Fri, 20 Aug 2021 16:08:21 +0300 [thread overview] Message-ID: <CAA8EJpoOxerwmwQozL3gp1nX-+oxLMFUFjVPvRy-MoVfPuvqrw@mail.gmail.com> (raw) In-Reply-To: <1CA665D1-86F0-45A1-862D-17DAB3ABA974@holtmann.org> Hi, On Thu, 19 Aug 2021 at 18:23, Marcel Holtmann <marcel@holtmann.org> wrote: > > This is an RFC of the proposed power sequencer subsystem. This is a > > generification of the MMC pwrseq code. The subsystem tries to abstract > > the idea of complex power-up/power-down/reset of the devices. > > > > The primary set of devices that promted me to create this patchset is > > the Qualcomm BT+WiFi family of chips. They reside on serial+platform > > interfaces (older generations) or on serial+PCIe (newer generations). > > They require a set of external voltage regulators to be powered on and > > (some of them) have separate WiFi and Bluetooth enable GPIOs. > > > > This patchset being an RFC tries to demonstrate the approach, design and > > usage of the pwrseq subsystem. Following issues are present in the RFC > > at this moment but will be fixed later if the overall approach would be > > viewed as acceptable: > > > > - No documentation > > While the code tries to be self-documenting proper documentation > > would be required. > > > > - Minimal device tree bindings changes > > There are no proper updates for the DT bindings (thus neither Rob > > Herring nor devicetree are included in the To/Cc lists). The dt > > schema changes would be a part of v1. > > > > - Lack of proper PCIe integration > > At this moment support for PCIe is hacked up to be able to test the > > PCIe part of qca6390. Proper PCIe support would require automatically > > powering up the devices before the scan basing on the proper device > > structure in the device tree. > > > > ---------------------------------------------------------------- > > Dmitry Baryshkov (15): > > power: add power sequencer subsystem > > pwrseq: port MMC's pwrseq drivers to new pwrseq subsystem > > mmc: core: switch to new pwrseq subsystem > > ath10k: add support for pwrseq sequencing > > Bluetooth: hci_qca: merge qca_power into qca_serdev > > Bluetooth: hci_qca: merge init paths > > Bluetooth: hci_qca: merge qca_power_on with qca_regulators_init > > Bluetooth: hci_qca: futher rework of power on/off handling > > Bluetooth: hci_qca: add support for pwrseq > > any chance you can try to abandon patching hci_qca. The serdev support in hci_uart is rather hacking into old line discipline code and it is not aging well. It is really becoming a mess. I wanted to stay away from rewriting the BT code. But... New driver would have a bonus point that I don't have to be compatible with old bindings. In fact we can even make it the other way around: let the old driver always use regulators and make the new driver support only the pwrseq. Then it should be possible to drop the old hci_qca driver together with dropping the old bindings. > I would say that the Qualcomm serial devices could use a separate standalone serdev driver. A while I send an RFC for a new serdev driver. > > https://www.spinics.net/lists/linux-bluetooth/msg74918.html Any reason why your driver stayed as an RFC and never made it into the kernel? Do you plan to revive your old RFCs on H:4 and H:5? > There I had the idea that simple vendor specifics can be in that driver (like the Broadcom part I added there), but frankly the QCA specifics are a bit too specific and it should be a separate driver. However I think this would be a good starting point. > > In general a H:4 based Bluetooth driver is dead simple with the help of h4_recv.h helper we have in the kernel. The complicated part is the power management pieces or any vendor specific low-power protocol they are running on that serial line. And since you are touching this anyway, doing a driver from scratch might be lot simpler and cleaner. It would surely help all the new QCA device showing up in the future. -- With best wishes Dmitry _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2021-08-20 13:08 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-17 0:54 [RFC PATCH 00/15] create power sequencing subsystem Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:54 ` [RFC PATCH 01/15] power: add power sequencer subsystem Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-19 23:37 ` Bjorn Andersson 2021-08-19 23:37 ` Bjorn Andersson 2021-08-17 0:54 ` [RFC PATCH 02/15] pwrseq: port MMC's pwrseq drivers to new pwrseq subsystem Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:54 ` [RFC PATCH 03/15] mmc: core: switch " Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:54 ` [RFC PATCH 04/15] ath10k: add support for pwrseq sequencing Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:54 ` [RFC PATCH 05/15] Bluetooth: hci_qca: merge qca_power into qca_serdev Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:54 ` [RFC PATCH 06/15] Bluetooth: hci_qca: merge init paths Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:54 ` [RFC PATCH 07/15] Bluetooth: hci_qca: merge qca_power_on with qca_regulators_init Dmitry Baryshkov 2021-08-17 0:54 ` Dmitry Baryshkov 2021-08-17 0:55 ` [RFC PATCH 08/15] Bluetooth: hci_qca: futher rework of power on/off handling Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-17 0:55 ` [RFC PATCH 09/15] Bluetooth: hci_qca: add support for pwrseq Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-17 0:55 ` [RFC PATCH 10/15] pwrseq: add support for QCA BT+WiFi power sequencer Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-17 22:41 ` kernel test robot 2021-08-19 23:18 ` Bjorn Andersson 2021-08-19 23:18 ` Bjorn Andersson 2021-08-20 8:10 ` Dmitry Baryshkov 2021-08-20 8:10 ` Dmitry Baryshkov 2021-08-20 16:35 ` Bjorn Andersson 2021-08-20 16:35 ` Bjorn Andersson 2021-08-17 0:55 ` [RFC PATCH 11/15] arm64: dts: qcom: sdm845-db845c: switch bt+wifi to qca " Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-19 23:40 ` Bjorn Andersson 2021-08-19 23:40 ` Bjorn Andersson 2021-08-17 0:55 ` [RFC PATCH 12/15] arm64: dts: qcom: qrb5165-rb5: add bluetooth support Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-17 0:55 ` [RFC PATCH 13/15] arm64: dts: qcom: sdm845-db845c: add second channel support to qca power sequencer Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-17 0:55 ` [RFC PATCH 14/15] WIP: PCI: qcom: use pwrseq to power up bus devices Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-19 23:44 ` Bjorn Andersson 2021-08-19 23:44 ` Bjorn Andersson 2021-08-20 8:50 ` Dmitry Baryshkov 2021-08-20 8:50 ` Dmitry Baryshkov 2021-08-17 0:55 ` [RFC PATCH 15/15] WIP: arm64: dts: qcom: qrb5165-rb5: add bus-pwrseq property to pcie0 Dmitry Baryshkov 2021-08-17 0:55 ` Dmitry Baryshkov 2021-08-19 15:23 ` [RFC PATCH 00/15] create power sequencing subsystem Marcel Holtmann 2021-08-19 15:23 ` Marcel Holtmann 2021-08-20 13:08 ` Dmitry Baryshkov [this message] 2021-08-20 13:08 ` Dmitry Baryshkov 2021-08-20 17:02 ` Bjorn Andersson 2021-08-20 17:02 ` Bjorn Andersson 2021-08-20 18:06 ` Dmitry Baryshkov 2021-08-20 18:06 ` Dmitry Baryshkov 2021-08-21 6:50 ` Marcel Holtmann 2021-08-21 6:50 ` Marcel Holtmann
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=CAA8EJpoOxerwmwQozL3gp1nX-+oxLMFUFjVPvRy-MoVfPuvqrw@mail.gmail.com \ --to=dmitry.baryshkov@linaro.org \ --cc=agross@kernel.org \ --cc=ath10k@lists.infradead.org \ --cc=bjorn.andersson@linaro.org \ --cc=davem@davemloft.net \ --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=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.