mbox series

[RFC,00/15] create power sequencing subsystem

Message ID 20210817005507.1507580-1-dmitry.baryshkov@linaro.org (mailing list archive)
Headers show
Series create power sequencing subsystem | expand

Message

Dmitry Baryshkov Aug. 17, 2021, 12:54 a.m. UTC
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
      pwrseq: add support for QCA BT+WiFi power sequencer
      arm64: dts: qcom: sdm845-db845c: switch bt+wifi to qca power sequencer
      arm64: dts: qcom: qrb5165-rb5: add bluetooth support
      arm64: dts: qcom: sdm845-db845c: add second channel support to qca power sequencer
      WIP: PCI: qcom: use pwrseq to power up bus devices
      WIP: arm64: dts: qcom: qrb5165-rb5: add bus-pwrseq property to pcie0

 .../{mmc => power/pwrseq}/mmc-pwrseq-emmc.yaml     |   0
 .../{mmc => power/pwrseq}/mmc-pwrseq-sd8787.yaml   |   0
 .../{mmc => power/pwrseq}/mmc-pwrseq-simple.yaml   |   0
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts           |  51 +++
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts         |  28 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi               |   6 +
 drivers/bluetooth/hci_qca.c                        | 286 +++++++-------
 drivers/mmc/core/Kconfig                           |  32 --
 drivers/mmc/core/Makefile                          |   4 -
 drivers/mmc/core/core.c                            |   9 +-
 drivers/mmc/core/host.c                            |   8 +-
 drivers/mmc/core/mmc.c                             |   3 +-
 drivers/mmc/core/pwrseq.c                          | 117 ------
 drivers/mmc/core/pwrseq.h                          |  58 ---
 drivers/mmc/core/pwrseq_emmc.c                     | 120 ------
 drivers/mmc/core/pwrseq_sd8787.c                   | 107 ------
 drivers/mmc/core/pwrseq_simple.c                   | 164 --------
 drivers/net/wireless/ath/ath10k/snoc.c             |  63 +++-
 drivers/net/wireless/ath/ath10k/snoc.h             |   2 +
 drivers/pci/controller/dwc/pcie-qcom.c             |  13 +
 drivers/power/Kconfig                              |   1 +
 drivers/power/Makefile                             |   1 +
 drivers/power/pwrseq/Kconfig                       |  57 +++
 drivers/power/pwrseq/Makefile                      |  11 +
 drivers/power/pwrseq/core.c                        | 411 +++++++++++++++++++++
 drivers/power/pwrseq/pwrseq_emmc.c                 | 118 ++++++
 drivers/power/pwrseq/pwrseq_qca.c                  | 291 +++++++++++++++
 drivers/power/pwrseq/pwrseq_sd8787.c               |  97 +++++
 drivers/power/pwrseq/pwrseq_simple.c               | 160 ++++++++
 include/linux/mmc/host.h                           |   4 +-
 include/linux/pwrseq/consumer.h                    |  88 +++++
 include/linux/pwrseq/driver.h                      |  71 ++++
 32 files changed, 1592 insertions(+), 789 deletions(-)
 rename Documentation/devicetree/bindings/{mmc => power/pwrseq}/mmc-pwrseq-emmc.yaml (100%)
 rename Documentation/devicetree/bindings/{mmc => power/pwrseq}/mmc-pwrseq-sd8787.yaml (100%)
 rename Documentation/devicetree/bindings/{mmc => power/pwrseq}/mmc-pwrseq-simple.yaml (100%)
 delete mode 100644 drivers/mmc/core/pwrseq.c
 delete mode 100644 drivers/mmc/core/pwrseq.h
 delete mode 100644 drivers/mmc/core/pwrseq_emmc.c
 delete mode 100644 drivers/mmc/core/pwrseq_sd8787.c
 delete mode 100644 drivers/mmc/core/pwrseq_simple.c
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_emmc.c
 create mode 100644 drivers/power/pwrseq/pwrseq_qca.c
 create mode 100644 drivers/power/pwrseq/pwrseq_sd8787.c
 create mode 100644 drivers/power/pwrseq/pwrseq_simple.c
 create mode 100644 include/linux/pwrseq/consumer.h
 create mode 100644 include/linux/pwrseq/driver.h

Comments

Marcel Holtmann Aug. 19, 2021, 3:23 p.m. UTC | #1
Hi Dmitry,

> 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 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

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.

Regards

Marcel
Dmitry Baryshkov Aug. 20, 2021, 1:08 p.m. UTC | #2
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.
Bjorn Andersson Aug. 20, 2021, 5:02 p.m. UTC | #3
On Fri 20 Aug 06:08 PDT 2021, Dmitry Baryshkov wrote:

> 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.

It would be preferable if this was a implementation-only change and that
we kept the existing binding and existing dtb continued to work.

Regards,
Bjorn
Dmitry Baryshkov Aug. 20, 2021, 6:06 p.m. UTC | #4
On Fri, 20 Aug 2021 at 20:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Fri 20 Aug 06:08 PDT 2021, Dmitry Baryshkov wrote:
>
> > 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.
>
> It would be preferable if this was a implementation-only change and that
> we kept the existing binding and existing dtb continued to work.

This would require setting up the pwrseq from within the bt driver. I
did not have that in mind. However that'd ease the bt code, since we
won't have to handle the fallback/back-compatibility. Let me think
about it.
Marcel Holtmann Aug. 21, 2021, 6:50 a.m. UTC | #5
Hi Dmitry,

>>> 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?

I was missing enough hardware to test it on and frankly I hoped that someone would pick up this work. The HCI line discipline “hack” needs to be removed soon. It is complicated, cumbersome and has a bunch of issues with locking. Mind you that originated in 2.4.6 kernel and is at its core bit-rotting.

If you manage to put QCA support into a separate btqcauart driver, that would be awesome. The btmtkuart driver is another example where Mediatek got its own serdev based driver.

Regards

Marcel