[PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

First, I'd like to apologize for the somewhat chaotic previous iterations
of this series and improper versioning which was rightfully pointed out
to me. I figured that the scope changed so much that it didn't make sense
to consider previous submissions part of the same series as the original
RFC but others thought otherwise so this one becomes v5 and I'll keep the
versioning going forward.

This is the summary of the work so far:

v1: Original RFC:

https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/

v2: First real patch series (should have been PATCH v2) adding what I
    referred to back then as PCI power sequencing:

https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/

v3: RFC for the DT representation of the PMU supplying the WLAN and BT
    modules inside the QCA6391 package (was largely separate from the
    series but probably should have been called PATCH or RFC v3):

https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/

v4: Second attempt at the full series with changed scope (introduction of
    the pwrseq subsystem, should have been RFC v4)

https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/

===

With that out of the way, I'd like to get down to explaining the two
problems I'm trying to solve.

Problem statement #1: Dynamic bus chicken-and-egg problem.

Certain on-board PCI devices need to be powered up before they are can be
detected but their PCI drivers won't get bound until the device is
powered-up so enabling the relevant resources in the PCI device driver
itself is impossible.

Problem statement #2: Sharing inter-dependent resources between devices.

Certain devices that use separate drivers (often on different busses)
share resources (regulators, clocks, etc.). Typically these resources
are reference-counted but in some cases there are additional interactions
between them to consider, for example specific power-up sequence timings.

===

The reason for tackling both of these problems in a single series is the
fact the the platform I'm working on - Qualcomm RB5 - deals with both and
both need to be addressed in order to enable WLAN and Bluetooth support
upstream.

The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
takes inputs from the host and exposes LDO outputs consumed by the BT and
WLAN modules which can be powered-up and down independently. However
a delay of 100ms must be respected between enabling the BT- and
WLAN-enable GPIOs[*].

===

This series is logically split into several sections. I'll go
patch-by-patch and explain each step.

Patch 1/18:

This is a commit taken from the list by Jonathan Cameron that adds
a __free() helper for OF nodes. Not strictly related to the series but
until said commit ends in next, I need to carry it with this series.

Patch 2/18:

This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
and sm8550 reference platforms use it in the WCN7850 module.

Patches 3/18-6/18:

These contain all relevant DT bindings changes. We add new documents for
the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
Qualcomm Bluetooth and ATH11K modules with regulators used by them in
QCA6390.

Patches 7/18-9/18:

These contain changes to device-tree sources for the three platforms we
work with in this series. As the WCN7850 module doesn't require any
specific timings introducing dependencies between the Bluetooth and WLAN
modules, while the QCA6390 does, we take two different approaches to how
me model them in DT.

For WCN7850 we hide the existence of the PMU as modeling it is simply not
necessary. The BT and WLAN devices on the device-tree are represented as
consuming the inputs (relevant to the functionality of each) of the PMU
directly.

For QCA6390 on RB5 we add the PMU node as a platform device. It consumes
regulators and GPIOs from the host and exposed regulators consumer in turn
by the BT and WLAN modules. This represents the internal structure of the
package.

Patches 10/18-14/18:

These contain the bulk of the PCI changes for this series. We introduce
a simple framework for powering up PCI devices before detecting them on
the bus and the first user of this library in the form of the WCN7850 PCI
power control driver.

The general approach is as follows: PCI devices that need special
treatment before they can be powered up, scanned and bound to their PCI
drivers must be described on the device-tree as child nodes of the PCI
port node. These devices will be instantiated on the platform bus. They
will in fact be generic platform devices with the compatible of the form
used for PCI devices already upstream ("pci<vendor ID>,<device ID">). We
add a new directory under drivers/pci/pwrctl/ that contains PCI pwrctl
drivers. These drivers are platform drivers that will now be matched
against the devices instantiated from port children just like any other
platform pairs.

Both the power control platform device *AND* the associated PCI device
reuse the same OF node and have access to the same properties. The goal
of the platform driver is to request and bring up any required resources
and let the pwrctl framework know that it's now OK to rescan the bus and
detect the devices. When the device is bound, we are notified about it
by the PCI bus notifier event and can establish a device link between the
power control device and the PCI device so that any future extension for
power-management will already be able to work with the correct hierachy.

The reusing of the OF node is the reason for the small changes to the PCI
OF core: as the bootloader can possibly leave the relevant regulators on
before booting linux, the PCI device can be detected before its platform
abstraction is probed. In this case, we find that device first and mark
its OF node as reused. The pwrctl framework handles the opposite case
(when the PCI device is detected only after the platform driver
successfully enabled it).

Patches 15/18-16/18:

These add a relatively simple power sequencing subsystem and the first
driver using it: the pwrseq module for the QCA6390 PMU.

For the record: Bjorn suggested a different solution: a regulator driver
that would - based on which regulators are enabled by a consumer - enable
relevant resources (drive the enable GPIOs) while respecting the
HW-specific delays. This would however require significant and yet
unprecised changed to the regulator subsystem as well as be an abuse of
the regulator provider API akin to using the reset framework for power
sequencing as proposed before.

Instead I'm proposing to add a subsystem that allows different devices to
use a shared power sequence split into consumer-specific as well as
common "units".

A power sequence provider driver registers a set of units with pwrseq
core. Each unit can be enabled and disabled and contains an optional list
of other units which must be enabled before it itself can be. A unit
represents a discreet chunk of the power sequence.

It also registers a list of targets: a target is an abstraction wrapping
a unit which allows consumers to tell pwrseq which unit they want to
reach. Real-life example is the driver we're adding here: there's a set
of common regulators, two PCIe-specific ones and two enable GPIOs: one
for Bluetooth and one for WLAN.

The Bluetooth driver requests a descriptor to the power sequencer and
names the target it wants to reach:

    pwrseq = devm_pwrseq_get(dev, "bluetooth");

The pwrseq core then knows that when the driver calls:

    pwrseq_power_on(pwrseq);

It must enable the "bluetooth-enable" unit but it depends on the
"regulators-common" unit so this one is enabled first. The provider
driver is also in charge of assuring an appropriate delay between
enabling the BT and WLAN enable GPIOs. The WLAN-specific resources are
handled by the "wlan-enable" unit and so are not enabled until the WLAN
driver requests the "wlan" target to be powered on.

Another thing worth discussing is the way we associate the consumer with
the relevant power sequencer. DT maintainers have expressed a discontent
with the existing mmc pwrseq bindings and have NAKed an earlier
initiative to introduce global pwrseq bindings to the kernel[1].

In this approach, we model the existing regulators and GPIOs in DT but
the pwrseq subsystem requires each provider to provide a .match()
callback. Whenever a consumer requests a power sequencer handle, we
iterate over the list of pwrseq drivers and call .match() for each. It's
up to the driver to verify in a platform-specific way whether it deals
with its consumer and let the core pwrseq code know.

The advantage of this over reusing the regulator or reset subsystem is
that it's more generalized and can handle resources of all kinds as well
as deal with any kind of power-on sequences: for instance, Qualcomm has
a PCI switch they want a driver for but this switch requires enabling
some resources first (PCI pwrctl) and then configuring the device over
I2C (which can be handled by the pwrseq provider).

Patch 17/18:

This patch makes the Qualcomm Bluetooth driver get and use the power
sequencer for QCA6390.

Patch 18/18:

While tiny, this patch is possibly the highlight of the entire series.
It uses the two abstraction layers we introduced before to create an
elegant power sequencing PCI power control driver and supports the ath11k
module on QCA6390.

With this series we can now enable BT and WLAN on several new Qualcomm
boards upstream.

I tested the series on RB5 while Neil tested it on sm8650-qrd and
sm8550-qrd.

Best Regards,
Bartosz Golaszewski

It's hard to list the changes between versions here as the scope changed
significantly between each iteration and some versions were not even full
series but rather RFCs for parts of the solution. For this reason, I'll
only start listing changes starting from v6.

[*] This is what the docs say. In practice it seems that this delay can be
ignored. However the subsequent model - QCA6490 - *does* require users to
respect it, so the problem remains valid.

[1] https://lore.kernel.org/netdev/20210829131305.534417-1-dmitry.baryshkov@linaro.org/

Bartosz Golaszewski (15):
  arm64: defconfig: enable ath12k as a module
  dt-bindings: regulator: describe the PMU module of the QCA6390 package
  dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
  dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on
    QCA6390
  dt-bindings: new: wireless: describe the ath12k PCI module
  arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391
  PCI: hold the rescan mutex when scanning for the first time
  PCI/pwrctl: reuse the OF node for power controlled devices
  PCI/pwrctl: create platform devices for child OF nodes of the port
    node
  PCI/pwrctl: add PCI power control core code
  PCI/pwrctl: add a power control driver for WCN7850
  power: sequencing: implement the pwrseq core
  power: pwrseq: add a driver for the QCA6390 PMU module
  Bluetooth: qca: use the power sequencer for QCA6390
  PCI/pwrctl: add a PCI power control driver for power sequenced devices

Jonathan Cameron (1):
  of: Add cleanup.h based auto release via __free(device_node) markings.

Neil Armstrong (2):
  arm64: dts: qcom: sm8550-qrd: add the Wifi node
  arm64: dts: qcom: sm8650-qrd: add the Wifi node

 .../net/bluetooth/qualcomm-bluetooth.yaml     |   17 +
 .../net/wireless/qcom,ath11k-pci.yaml         |   28 +
 .../net/wireless/qcom,ath12k-pci.yaml         |  103 ++
 .../bindings/regulator/qcom,qca6390-pmu.yaml  |  166 +++
 MAINTAINERS                                   |    8 +
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts      |  123 +-
 arch/arm64/boot/dts/qcom/sm8250.dtsi          |   10 +
 arch/arm64/boot/dts/qcom/sm8550-qrd.dts       |   37 +
 arch/arm64/boot/dts/qcom/sm8550.dtsi          |   10 +
 arch/arm64/boot/dts/qcom/sm8650-qrd.dts       |   29 +
 arch/arm64/boot/dts/qcom/sm8650.dtsi          |   10 +
 arch/arm64/configs/defconfig                  |    1 +
 drivers/bluetooth/hci_qca.c                   |   31 +
 drivers/pci/Kconfig                           |    1 +
 drivers/pci/Makefile                          |    1 +
 drivers/pci/bus.c                             |    9 +-
 drivers/pci/of.c                              |   14 +-
 drivers/pci/probe.c                           |    2 +
 drivers/pci/pwrctl/Kconfig                    |   25 +
 drivers/pci/pwrctl/Makefile                   |    7 +
 drivers/pci/pwrctl/core.c                     |  136 +++
 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c        |   84 ++
 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c       |  202 ++++
 drivers/pci/remove.c                          |    2 +
 drivers/power/Kconfig                         |    1 +
 drivers/power/Makefile                        |    1 +
 drivers/power/sequencing/Kconfig              |   28 +
 drivers/power/sequencing/Makefile             |    6 +
 drivers/power/sequencing/core.c               | 1065 +++++++++++++++++
 drivers/power/sequencing/pwrseq-qca6390.c     |  353 ++++++
 include/linux/of.h                            |    2 +
 include/linux/pci-pwrctl.h                    |   51 +
 include/linux/pwrseq/consumer.h               |   56 +
 include/linux/pwrseq/provider.h               |   75 ++
 34 files changed, 2678 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
 create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
 create mode 100644 drivers/pci/pwrctl/Kconfig
 create mode 100644 drivers/pci/pwrctl/Makefile
 create mode 100644 drivers/pci/pwrctl/core.c
 create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
 create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
 create mode 100644 drivers/power/sequencing/Kconfig
 create mode 100644 drivers/power/sequencing/Makefile
 create mode 100644 drivers/power/sequencing/core.c
 create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
 create mode 100644 include/linux/pci-pwrctl.h
 create mode 100644 include/linux/pwrseq/consumer.h
 create mode 100644 include/linux/pwrseq/provider.h

-- 
2.40.1

[PATCH v5 01/18] of: Add cleanup.h based auto release via __free(device_node) markings.

[Bartosz Golaszewski]

From: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The recent addition of scope based cleanup support to the kernel
provides a convenient tool to reduce the chances of leaking reference
counts where of_node_put() should have been called in an error path.

This enables
	struct device_node *child __free(device_node) = NULL;

	for_each_child_of_node(np, child) {
		if (test)
			return test;
	}

with no need for a manual call of of_node_put().
A following patch will reduce the scope of the child variable to the
for loop, to avoid an issues with ordering of autocleanup, and make it
obvious when this assigned a non NULL value.

In this simple example the gains are small but there are some very
complex error handling cases buried in these loops that will be
greatly simplified by enabling early returns with out the need
for this manual of_node_put() call.

Note that there are coccinelle checks in
scripts/coccinelle/iterators/for_each_child.cocci to detect a failure
to call of_node_put(). This new approach does not cause false positives.
Longer term we may want to add scripting to check this new approach is
done correctly with no double of_node_put() calls being introduced due
to the auto cleanup. It may also be useful to script finding places
this new approach is useful.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 include/linux/of.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/of.h b/include/linux/of.h
index 331e05918f11..8df240214db1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -13,6 +13,7 @@
  */
 #include <linux/types.h>
 #include <linux/bitops.h>
+#include <linux/cleanup.h>
 #include <linux/errno.h>
 #include <linux/kobject.h>
 #include <linux/mod_devicetable.h>
@@ -134,6 +135,7 @@ static inline struct device_node *of_node_get(struct device_node *node)
 }
 static inline void of_node_put(struct device_node *node) { }
 #endif /* !CONFIG_OF_DYNAMIC */
+DEFINE_FREE(device_node, struct device_node *, if (_T) of_node_put(_T))
 
 /* Pointer for first entry in chain of all nodes. */
 extern struct device_node *of_root;
-- 
2.40.1

[PATCH v5 02/18] arm64: defconfig: enable ath12k as a module

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Build the ath12k driver as a module for arm64 default config.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b8adb28185ad..23d6bb156cbc 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -409,6 +409,7 @@ CONFIG_WCN36XX=m
 CONFIG_ATH11K=m
 CONFIG_ATH11K_AHB=m
 CONFIG_ATH11K_PCI=m
+CONFIG_ATH12K=m
 CONFIG_BRCMFMAC=m
 CONFIG_MWIFIEX=m
 CONFIG_MWIFIEX_SDIO=m
-- 
2.40.1

[PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
are powered by the Power Management Unit (PMU) that takes inputs from the
host and provides LDO outputs. This document describes this module.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 .../bindings/regulator/qcom,qca6390-pmu.yaml  | 166 ++++++++++++++++++
 1 file changed, 166 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml

diff --git a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
new file mode 100644
index 000000000000..b71fa782fc63
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QCA6390 PMU Regulators
+
+maintainers:
+  - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+  The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
+  are powered by the Power Management Unit (PMU) that takes inputs from the
+  host and provides LDO outputs. This document describes this module.
+
+properties:
+  compatible:
+    const: qcom,qca6390-pmu
+
+  vddaon-supply:
+    description: VDD_AON supply regulator handle
+
+  vddpmu-supply:
+    description: VDD_PMU supply regulator handle
+
+  vddrfa0p95-supply:
+    description: VDD_RFA_0P95 supply regulator handle
+
+  vddrfa1p3-supply:
+    description: VDD_RFA_1P3 supply regulator handle
+
+  vddrfa1p9-supply:
+    description: VDD_RFA_1P9 supply regulator handle
+
+  vddpcie1p3-supply:
+    description: VDD_PCIE_1P3 supply regulator handle<S-Del>
+
+  vddpcie1p9-supply:
+    description: VDD_PCIE_1P9 supply regulator handle
+
+  vddio-supply:
+    description: VDD_IO supply regulator handle
+
+  wlan-enable-gpios:
+    maxItems: 1
+    description:
+      GPIO line enabling the ATH11K WLAN module supplied by the PMU
+
+  bt-enable-gpios:
+    maxItems: 1
+    description:
+      GPIO line enabling the ATH11K Bluetooth module supplied by the PMU
+
+  regulators:
+    type: object
+    description:
+      LDO outputs of the PMU
+
+    patternProperties:
+      "^ldo[0-9]$":
+        $ref: regulator.yaml#
+        type: object
+        unevaluatedProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - vddaon-supply
+  - vddpmu-supply
+  - vddrfa0p95-supply
+  - vddrfa1p3-supply
+  - vddrfa1p9-supply
+  - vddpcie1p3-supply
+  - vddpcie1p9-supply
+  - vddio-supply
+  - wlan-enable-gpios
+  - bt-enable-gpios
+  - regulators
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    pmu {
+        compatible = "qcom,qca6390-pmu";
+
+        pinctrl-names = "default";
+        pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+        vddaon-supply = <&vreg_s6a_0p95>;
+        vddpmu-supply = <&vreg_s2f_0p95>;
+        vddrfa0p95-supply = <&vreg_s2f_0p95>;
+        vddrfa1p3-supply = <&vreg_s8c_1p3>;
+        vddrfa1p9-supply = <&vreg_s5a_1p9>;
+        vddpcie1p3-supply = <&vreg_s8c_1p3>;
+        vddpcie1p9-supply = <&vreg_s5a_1p9>;
+        vddio-supply = <&vreg_s4a_1p8>;
+
+        wlan-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+        bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+
+        regulators {
+            vreg_pmu_rfa_cmn: ldo0 {
+                regulator-name = "vreg_pmu_rfa_cmn";
+                regulator-min-microvolt = <760000>;
+                regulator-max-microvolt = <840000>;
+            };
+
+            vreg_pmu_aon_0p59: ldo1 {
+                regulator-name = "vreg_pmu_aon_0p59";
+                regulator-min-microvolt = <540000>;
+                regulator-max-microvolt = <840000>;
+            };
+
+            vreg_pmu_wlcx_0p8: ldo2 {
+                regulator-name = "vreg_pmu_wlcx_0p8";
+                regulator-min-microvolt = <760000>;
+                regulator-max-microvolt = <840000>;
+            };
+
+            vreg_pmu_wlmx_0p85: ldo3 {
+                regulator-name = "vreg_pmu_wlmx_0p85";
+                regulator-min-microvolt = <810000>;
+                regulator-max-microvolt = <890000>;
+            };
+
+            vreg_pmu_btcmx_0p85: ldo4 {
+                regulator-name = "vreg_pmu_btcmx_0p85";
+                regulator-min-microvolt = <810000>;
+                regulator-max-microvolt = <890000>;
+            };
+
+            vreg_pmu_rfa_0p8: ldo5 {
+                regulator-name = "vreg_pmu_rfa_0p8";
+                regulator-min-microvolt = <760000>;
+                regulator-max-microvolt = <840000>;
+            };
+
+            vreg_pmu_rfa_1p2: ldo6 {
+                regulator-name = "vreg_pmu_rfa_1p2";
+                regulator-min-microvolt = <1187000>;
+                regulator-max-microvolt = <1313000>;
+            };
+
+            vreg_pmu_rfa_1p7: ldo7 {
+                regulator-name = "vreg_pmu_rfa_1p7";
+                regulator-min-microvolt = <1710000>;
+                regulator-max-microvolt = <1890000>;
+            };
+
+            vreg_pmu_pcie_0p9: ldo8 {
+                regulator-name = "vreg_pmu_pcie_0p9";
+                regulator-min-microvolt = <870000>;
+                regulator-max-microvolt = <970000>;
+            };
+
+            vreg_pmu_pcie_1p8: ldo9 {
+                regulator-name = "vreg_pmu_pcie_1p8";
+                regulator-min-microvolt = <1710000>;
+                regulator-max-microvolt = <1890000>;
+            };
+        };
+    };
-- 
2.40.1

[PATCH v5 04/18] dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

QCA6390 has a compatible listed in the bindings but is missing the
regulators description. Add the missing supply property and list the
required ones in the allOf section.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 .../net/bluetooth/qualcomm-bluetooth.yaml       | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
index eba2f3026ab0..702d04cdb247 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
@@ -62,6 +62,9 @@ properties:
   vdddig-supply:
     description: VDD_DIG supply regulator handle
 
+  vddbtcmx-supply:
+    description: VDD_BT_CMX supply regulator handle
+
   vddbtcxmx-supply:
     description: VDD_BT_CXMX supply regulator handle
 
@@ -180,6 +183,20 @@ allOf:
         - vddrfa0p8-supply
         - vddrfa1p2-supply
         - vddrfa1p9-supply
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,qca6390-bt
+    then:
+      required:
+        - vddrfacmn-supply
+        - vddaon-supply
+        - vddbtcmx-supply
+        - vddrfa0p8-supply
+        - vddrfa1p2-supply
+        - vddrfa1p7-supply
 
 examples:
   - |
-- 
2.40.1

[PATCH v5 05/18] dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on QCA6390

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a PCI compatible for the ATH11K module on QCA6390 and describe the
power inputs from the PMU that it consumes.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 .../net/wireless/qcom,ath11k-pci.yaml         | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
index 817f02a8b481..8530f01df6d9 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
@@ -16,6 +16,7 @@ description: |
 properties:
   compatible:
     enum:
+      - pci17cb,1101  # QCA6390
       - pci17cb,1103  # WCN6855
 
   reg:
@@ -27,6 +28,33 @@ properties:
       string to uniquely identify variant of the calibration data for designs
       with colliding bus and device ids
 
+  vddrfacmn-supply:
+    description: VDD_RFA_CMN supply regulator handle
+
+  vddaon-supply:
+    description: VDD_AON supply regulator handle
+
+  vddwlcx-supply:
+    description: VDD_WL_CX supply regulator handle
+
+  vddwlmx-supply:
+    description: VDD_WL_MX supply regulator handle
+
+  vddrfa0p8-supply:
+    description: VDD_RFA_0P8 supply regulator handle
+
+  vddrfa1p2-supply:
+    description: VDD_RFA_1P2 supply regulator handle
+
+  vddrfa1p7-supply:
+    description: VDD_RFA_1P7 supply regulator handle
+
+  vddpcie0p9-supply:
+    description: VDD_PCIE_0P9 supply regulator handle
+
+  vddpcie1p8-supply:
+    description: VDD_PCIE_1P8 supply regulator handle
+
 required:
   - compatible
   - reg
-- 
2.40.1

[PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add device-tree bindings for the ATH12K module found in the WCN7850
package.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 .../net/wireless/qcom,ath12k-pci.yaml         | 103 ++++++++++++++++++
 1 file changed, 103 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
new file mode 100644
index 000000000000..063c576b99a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2024 Linaro Limited
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-pci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies ath12k wireless devices (PCIe)
+
+maintainers:
+  - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+  Qualcomm Technologies IEEE 802.11ax PCIe devices
+
+properties:
+  compatible:
+    enum:
+      - pci17cb,1107  # WCN7850
+
+  reg:
+    maxItems: 1
+
+  enable-gpios:
+    maxItems: 1
+    description: GPIO line enabling the WLAN module
+
+  vdd-supply:
+    description: VDD supply regulator handle
+
+  vddio-supply:
+    description: VDD_IO supply regulator handle
+
+  vddio1p2-supply:
+    description: VDD_IO_1P2 supply regulator handle
+
+  vddaon-supply:
+    description: VDD_AON supply regulator handle
+
+  vdddig-supply:
+    description: VDD_DIG supply regulator handle
+
+  vddrfa1p2-supply:
+    description: VDD_RFA_1P2 supply regulator handle
+
+  vddrfa1p8-supply:
+    description: VDD_PCIE_1P8 supply regulator handle
+
+  clocks:
+    maxItems: 1
+    description:
+      Reference clock phandle
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+  - vddio-supply
+  - vddaon-supply
+  - vdddig-supply
+  - vddrfa1p2-supply
+  - vddrfa1p8-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,rpmh.h>
+    #include <dt-bindings/gpio/gpio.h>
+    pcie {
+        #address-cells = <3>;
+        #size-cells = <2>;
+
+        pcie@0 {
+            device_type = "pci";
+            reg = <0x0 0x0 0x0 0x0 0x0>;
+            #address-cells = <3>;
+            #size-cells = <2>;
+            ranges;
+
+            bus-range = <0x01 0xff>;
+
+            wifi@0 {
+                compatible = "pci17cb,1107";
+                reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&wlan_en>;
+
+                enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
+
+                vdd-supply = <&vreg_s4i_0p85>;
+                vddio-supply = <&vreg_l15b_1p8>;
+                vddio1p2-supply = <&vreg_l3c_1p2>;
+                vddaon-supply = <&vreg_s2c_0p8>;
+                vdddig-supply = <&vreg_s3c_0p9>;
+                vddrfa1p2-supply = <&vreg_s1c_1p2>;
+                vddrfa1p8-supply = <&vreg_s6c_1p8>;
+
+                clocks = <&rpmhcc RPMH_RF_CLK1>;
+            };
+        };
+    };
-- 
2.40.1

[PATCH v5 07/18] arm64: dts: qcom: sm8550-qrd: add the Wifi node

[Bartosz Golaszewski]

From: Neil Armstrong <neil.armstrong@linaro.org>

Describe the ath12k WLAN on-board the WCN7850 module present on the
board.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[Bartosz:
  - move the pcieport0 node into the .dtsi
  - make regulator naming consistent with existing DT code
  - add commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 37 +++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8550.dtsi    | 10 +++++++
 2 files changed, 47 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 92f015017418..67bd11e82abd 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -824,6 +824,25 @@ &pcie0 {
 	status = "okay";
 };
 
+&pcieport0 {
+	wifi@0 {
+		compatible = "pci17cb,1107";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&wlan_en>, <&pmk8550_sleep_clk>;
+
+		enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+
+		vdd-supply = <&vreg_s5g_0p85>;
+		vddio-supply = <&vreg_l15b_1p8>;
+		vddaon-supply = <&vreg_s2g_0p85>;
+		vdddig-supply = <&vreg_s4e_0p95>;
+		vddrfa1p2-supply = <&vreg_s4g_1p25>;
+		vddrfa1p8-supply = <&vreg_s6g_1p86>;
+	};
+};
+
 &pcie0_phy {
 	vdda-phy-supply = <&vreg_l1e_0p88>;
 	vdda-pll-supply = <&vreg_l3e_1p2>;
@@ -911,6 +930,17 @@ &pcie_1_phy_aux_clk {
 	clock-frequency = <1000>;
 };
 
+&pmk8550_gpios {
+	pmk8550_sleep_clk: sleep-clk-state {
+		pins = "gpio3";
+		function = "func1";
+		input-disable;
+		output-enable;
+		bias-disable;
+		power-source = <0>;
+	};
+};
+
 &qupv3_id_0 {
 	status = "okay";
 };
@@ -1084,6 +1114,13 @@ wcd_default: wcd-reset-n-active-state {
 		bias-disable;
 		output-low;
 	};
+
+	wlan_en: wlan-en-state {
+		pins = "gpio80";
+		function = "gpio";
+		drive-strength = <8>;
+		bias-pull-down;
+	};
 };
 
 &uart7 {
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 9a545087d70e..5fcf8d5ac084 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1767,6 +1767,16 @@ pcie0: pcie@1c00000 {
 			phy-names = "pciephy";
 
 			status = "disabled";
+
+			pcieport0: pcie@0 {
+				device_type = "pci";
+				reg = <0x0 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				ranges;
+
+				bus-range = <0x01 0xff>;
+			};
 		};
 
 		pcie0_phy: phy@1c06000 {
-- 
2.40.1

[PATCH v5 08/18] arm64: dts: qcom: sm8650-qrd: add the Wifi node

[Bartosz Golaszewski]

From: Neil Armstrong <neil.armstrong@linaro.org>

Describe the ath12k WLAN on-board the WCN7850 module present on the
board.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
[Bartosz:
  - move the pcieport0 node into the .dtsi
  - make regulator naming consistent with existing DT code
  - add commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 29 +++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8650.dtsi    | 10 +++++++++
 2 files changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index b07cac2e5bc8..4623c358f634 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -845,6 +845,28 @@ &pcie0 {
 	status = "okay";
 };
 
+&pcieport0 {
+	wifi@0 {
+		compatible = "pci17cb,1107";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&wlan_en>;
+
+		enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
+
+		vdd-supply = <&vreg_s4i_0p85>;
+		vddio-supply = <&vreg_l15b_1p8>;
+		vddio1p2-supply = <&vreg_l3c_1p2>;
+		vddaon-supply = <&vreg_s2c_0p8>;
+		vdddig-supply = <&vreg_s3c_0p9>;
+		vddrfa1p2-supply = <&vreg_s1c_1p2>;
+		vddrfa1p8-supply = <&vreg_s6c_1p8>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK1>;
+	};
+};
+
 &pcie0_phy {
 	vdda-phy-supply = <&vreg_l1i_0p88>;
 	vdda-pll-supply = <&vreg_l3i_1p2>;
@@ -1139,6 +1161,13 @@ wcd_default: wcd-reset-n-active-state {
 		bias-disable;
 		output-low;
 	};
+
+	wlan_en: wlan-en-state {
+		pins = "gpio16";
+		function = "gpio";
+		drive-strength = <8>;
+		bias-pull-down;
+	};
 };
 
 &uart14 {
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index d488b3b3265e..baf4932e460c 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -2293,6 +2293,16 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 			dma-coherent;
 
 			status = "disabled";
+
+			pcieport0: pcie@0 {
+				device_type = "pci";
+				reg = <0x0 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				ranges;
+
+				bus-range = <0x01 0xff>;
+			};
 		};
 
 		pcie0_phy: phy@1c06000 {
-- 
2.40.1

[PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a node for the PMU module of the QCA6391 present on the RB5 board.
Assign its LDO power outputs to the existing Bluetooth module. Add a
node for the PCIe port to sm8250.dtsi and define the WLAN node on it in
the board's .dts and also make it consume the power outputs of the PMU.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 123 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 122 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index cd0db4f31d4a..3331a3e5aaa8 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -108,6 +108,87 @@ lt9611_3v3: lt9611-3v3 {
 		regulator-always-on;
 	};
 
+	qca6390-pmu {
+		compatible = "qcom,qca6390-pmu";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+		vddaon-supply = <&vreg_s6a_0p95>;
+		vddpmu-supply = <&vreg_s2f_0p95>;
+		vddrfa0p95-supply = <&vreg_s2f_0p95>;
+		vddrfa1p3-supply = <&vreg_s8c_1p3>;
+		vddrfa1p9-supply = <&vreg_s5a_1p9>;
+		vddpcie1p3-supply = <&vreg_s8c_1p3>;
+		vddpcie1p9-supply = <&vreg_s5a_1p9>;
+		vddio-supply = <&vreg_s4a_1p8>;
+
+		wlan-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+		bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+
+		regulators {
+			vreg_pmu_rfa_cmn: ldo0 {
+				regulator-name = "vreg_pmu_rfa_cmn";
+				regulator-min-microvolt = <760000>;
+				regulator-max-microvolt = <840000>;
+			};
+
+			vreg_pmu_aon_0p59: ldo1 {
+				regulator-name = "vreg_pmu_aon_0p59";
+				regulator-min-microvolt = <540000>;
+				regulator-max-microvolt = <840000>;
+			};
+
+			vreg_pmu_wlcx_0p8: ldo2 {
+				regulator-name = "vreg_pmu_wlcx_0p8";
+				regulator-min-microvolt = <760000>;
+				regulator-max-microvolt = <840000>;
+			};
+
+			vreg_pmu_wlmx_0p85: ldo3 {
+				regulator-name = "vreg_pmu_wlmx_0p85";
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <890000>;
+			};
+
+			vreg_pmu_btcmx_0p85: ldo4 {
+				regulator-name = "vreg_pmu_btcmx_0p85";
+				regulator-min-microvolt = <810000>;
+				regulator-max-microvolt = <890000>;
+			};
+
+			vreg_pmu_rfa_0p8: ldo5 {
+				regulator-name = "vreg_pmu_rfa_0p8";
+				regulator-min-microvolt = <760000>;
+				regulator-max-microvolt = <840000>;
+			};
+
+			vreg_pmu_rfa_1p2: ldo6 {
+				regulator-name = "vreg_pmu_rfa_1p2";
+				regulator-min-microvolt = <1187000>;
+				regulator-max-microvolt = <1313000>;
+			};
+
+			vreg_pmu_rfa_1p7: ldo7 {
+				regulator-name = "vreg_pmu_rfa_1p7";
+				regulator-min-microvolt = <1710000>;
+				regulator-max-microvolt = <1890000>;
+			};
+
+			vreg_pmu_pcie_0p9: ldo8 {
+				regulator-name = "vreg_pmu_pcie_0p9";
+				regulator-min-microvolt = <870000>;
+				regulator-max-microvolt = <970000>;
+			};
+
+			vreg_pmu_pcie_1p8: ldo9 {
+				regulator-name = "vreg_pmu_pcie_1p8";
+				regulator-min-microvolt = <1710000>;
+				regulator-max-microvolt = <1890000>;
+			};
+		};
+	};
+
 	thermal-zones {
 		conn-thermal {
 			polling-delay-passive = <0>;
@@ -734,6 +815,23 @@ &pcie0_phy {
 	vdda-pll-supply = <&vreg_l9a_1p2>;
 };
 
+&pcieport0 {
+	wifi@0 {
+		compatible = "pci17cb,1101";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+	};
+};
+
 &pcie1 {
 	status = "okay";
 };
@@ -1303,6 +1401,14 @@ sdc2_card_det_n: sd-card-det-n-state {
 		function = "gpio";
 		bias-pull-up;
 	};
+
+	wlan_en_state: wlan-default-state {
+		pins = "gpio20";
+		function = "gpio";
+		drive-strength = <16>;
+		output-low;
+		bias-pull-up;
+	};
 };
 
 &uart6 {
@@ -1311,17 +1417,12 @@ &uart6 {
 	bluetooth {
 		compatible = "qcom,qca6390-bt";
 
-		pinctrl-names = "default";
-		pinctrl-0 = <&bt_en_state>;
-
-		enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
-
-		vddio-supply = <&vreg_s4a_1p8>;
-		vddpmu-supply = <&vreg_s2f_0p95>;
-		vddaon-supply = <&vreg_s6a_0p95>;
-		vddrfa0p9-supply = <&vreg_s2f_0p95>;
-		vddrfa1p3-supply = <&vreg_s8c_1p3>;
-		vddrfa1p9-supply = <&vreg_s5a_1p9>;
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index f3c70b87efad..29d2ccb5b389 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2203,6 +2203,16 @@ pcie0: pcie@1c00000 {
 			dma-coherent;
 
 			status = "disabled";
+
+			pcieport0: pcie@0 {
+				device_type = "pci";
+				reg = <0x0 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				ranges;
+
+				bus-range = <0x01 0xff>;
+			};
 		};
 
 		pcie0_phy: phy@1c06000 {
-- 
2.40.1

[PATCH v5 10/18] PCI: hold the rescan mutex when scanning for the first time

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

With the introduction of PCI device power control drivers that will be
able to trigger the port rescan when probing, we need to hold the rescan
mutex during the initial pci_host_probe() too or the two could get in
each other's way.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/probe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 467c16358f17..f8ba073ffc9b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3066,7 +3066,9 @@ int pci_host_probe(struct pci_host_bridge *bridge)
 	struct pci_bus *bus, *child;
 	int ret;
 
+	pci_lock_rescan_remove();
 	ret = pci_scan_root_bus_bridge(bridge);
+	pci_unlock_rescan_remove();
 	if (ret < 0) {
 		dev_err(bridge->dev.parent, "Scanning root bridge failed");
 		return ret;
-- 
2.40.1

[PATCH v5 11/18] PCI/pwrctl: reuse the OF node for power controlled devices

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

With PCI power control we deal with two struct device objects bound to
two different drivers but consuming the same OF node. We must not bind
the pinctrl twice. To that end: before setting the OF node of the newly
instantiated PCI device, check if a platform device consuming the same
OF node doesn't already exist on the platform bus and - if so - mark the
PCI device as reusing the OF node.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/of.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 51e3dd0ea5ab..b908fe1ae951 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -6,6 +6,7 @@
  */
 #define pr_fmt(fmt)	"PCI: OF: " fmt
 
+#include <linux/cleanup.h>
 #include <linux/irqdomain.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
@@ -13,6 +14,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
 #include <linux/of_pci.h>
+#include <linux/platform_device.h>
 #include "pci.h"
 
 #ifdef CONFIG_PCI
@@ -25,16 +27,20 @@
  */
 int pci_set_of_node(struct pci_dev *dev)
 {
-	struct device_node *node;
-
 	if (!dev->bus->dev.of_node)
 		return 0;
 
-	node = of_pci_find_child_device(dev->bus->dev.of_node, dev->devfn);
+	struct device_node *node __free(device_node) =
+		of_pci_find_child_device(dev->bus->dev.of_node, dev->devfn);
 	if (!node)
 		return 0;
 
-	device_set_node(&dev->dev, of_fwnode_handle(node));
+	struct device *pdev __free(put_device) =
+		bus_find_device_by_of_node(&platform_bus_type, node);
+	if (pdev)
+		dev->bus->dev.of_node_reused = true;
+
+	device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
 	return 0;
 }
 
-- 
2.40.1

[PATCH v5 12/18] PCI/pwrctl: create platform devices for child OF nodes of the port node

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

In preparation for introducing PCI device power control - a set of
library functions that will allow powering-up of PCI devices before
they're detected on the PCI bus - we need to populate the devices
defined on the device-tree.

We are reusing the platform bus as it provides us with all the
infrastructure we need to match the pwrctl drivers against the
compatibles from OF nodes.

These platform devices will be probed by the driver core and bound to
the PCI pwrctl drivers we'll introduce later.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/bus.c    | 9 ++++++++-
 drivers/pci/remove.c | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 826b5016a101..17ab41094c4e 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -12,6 +12,7 @@
 #include <linux/errno.h>
 #include <linux/ioport.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/proc_fs.h>
 #include <linux/slab.h>
 
@@ -342,8 +343,14 @@ void pci_bus_add_device(struct pci_dev *dev)
 	 */
 	pcibios_bus_add_device(dev);
 	pci_fixup_device(pci_fixup_final, dev);
-	if (pci_is_bridge(dev))
+	if (pci_is_bridge(dev)) {
 		of_pci_make_dev_node(dev);
+		retval = of_platform_populate(dev->dev.of_node, NULL, NULL,
+					      &dev->dev);
+		if (retval)
+			pci_err(dev, "failed to populate child OF nodes (%d)\n",
+				retval);
+	}
 	pci_create_sysfs_dev_files(dev);
 	pci_proc_attach_device(dev);
 	pci_bridge_d3_update(dev);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index d749ea8250d6..fc9db2805888 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <linux/pci.h>
 #include <linux/module.h>
+#include <linux/of_platform.h>
 #include "pci.h"
 
 static void pci_free_resources(struct pci_dev *dev)
@@ -22,6 +23,7 @@ static void pci_stop_dev(struct pci_dev *dev)
 		device_release_driver(&dev->dev);
 		pci_proc_detach_device(dev);
 		pci_remove_sysfs_dev_files(dev);
+		of_platform_depopulate(&dev->dev);
 		of_pci_remove_node(dev);
 
 		pci_dev_assign_added(dev, false);
-- 
2.40.1

[PATCH v5 13/18] PCI/pwrctl: add PCI power control core code

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Some PCI devices must be powered-on before they can be detected on the
bus. Introduce a simple framework reusing the existing PCI OF
infrastructure.

The way this works is: a DT node representing a PCI device connected to
the port can be matched against its power control platform driver. If
the match succeeds, the driver is responsible for powering-up the device
and calling pcie_pwrctl_device_set_ready() which will trigger a PCI bus
rescan as well as subscribe to PCI bus notifications.

When the device is detected and created, we'll make it consume the same
DT node that the platform device did. When the device is bound, we'll
create a device link between it and the parent power control device.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/Kconfig         |   1 +
 drivers/pci/Makefile        |   1 +
 drivers/pci/pwrctl/Kconfig  |   8 +++
 drivers/pci/pwrctl/Makefile |   4 ++
 drivers/pci/pwrctl/core.c   | 136 ++++++++++++++++++++++++++++++++++++
 include/linux/pci-pwrctl.h  |  51 ++++++++++++++
 6 files changed, 201 insertions(+)
 create mode 100644 drivers/pci/pwrctl/Kconfig
 create mode 100644 drivers/pci/pwrctl/Makefile
 create mode 100644 drivers/pci/pwrctl/core.c
 create mode 100644 include/linux/pci-pwrctl.h

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index d35001589d88..aa4d1833f442 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -296,5 +296,6 @@ source "drivers/pci/hotplug/Kconfig"
 source "drivers/pci/controller/Kconfig"
 source "drivers/pci/endpoint/Kconfig"
 source "drivers/pci/switch/Kconfig"
+source "drivers/pci/pwrctl/Kconfig"
 
 endif
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 175302036890..8ddad57934a6 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_PCI)		+= access.o bus.o probe.o host-bridge.o \
 
 obj-$(CONFIG_PCI)		+= msi/
 obj-$(CONFIG_PCI)		+= pcie/
+obj-$(CONFIG_PCI)		+= pwrctl/
 
 ifdef CONFIG_PCI
 obj-$(CONFIG_PROC_FS)		+= proc.o
diff --git a/drivers/pci/pwrctl/Kconfig b/drivers/pci/pwrctl/Kconfig
new file mode 100644
index 000000000000..96195395af69
--- /dev/null
+++ b/drivers/pci/pwrctl/Kconfig
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+menu "PCI Power control drivers"
+
+config PCI_PWRCTL
+	tristate
+
+endmenu
diff --git a/drivers/pci/pwrctl/Makefile b/drivers/pci/pwrctl/Makefile
new file mode 100644
index 000000000000..52ae0640ef7b
--- /dev/null
+++ b/drivers/pci/pwrctl/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_PCI_PWRCTL)		+= pci-pwrctl-core.o
+pci-pwrctl-core-y			:= core.o
diff --git a/drivers/pci/pwrctl/core.c b/drivers/pci/pwrctl/core.c
new file mode 100644
index 000000000000..11bd19519841
--- /dev/null
+++ b/drivers/pci/pwrctl/core.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/pci-pwrctl.h>
+#include <linux/property.h>
+#include <linux/slab.h>
+
+static int pci_pwrctl_notify(struct notifier_block *nb, unsigned long action,
+			     void *data)
+{
+	struct pci_pwrctl *pwrctl = container_of(nb, struct pci_pwrctl, nb);
+	struct device *dev = data;
+
+	if (dev_fwnode(dev) != dev_fwnode(pwrctl->dev))
+		return NOTIFY_DONE;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		/*
+		 * We will have two struct device objects bound to two different
+		 * drivers on different buses but consuming the same DT node. We
+		 * must not bind the pins twice in this case but only once for
+		 * the first device to be added.
+		 *
+		 * If we got here then the PCI device is the second after the
+		 * power control platform device. Mark its OF node as reused.
+		 */
+		dev->of_node_reused = true;
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		pwrctl->link = device_link_add(dev, pwrctl->dev,
+					       DL_FLAG_AUTOREMOVE_CONSUMER);
+		if (!pwrctl->link)
+			dev_err(pwrctl->dev, "Failed to add device link\n");
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pwrctl->link)
+			device_link_del(pwrctl->link);
+		break;
+	}
+
+	return NOTIFY_DONE;
+}
+
+/**
+ * pci_pwrctl_device_set_ready() - Notify the pwrctl subsystem that the PCI
+ * device is powered-up and ready to be detected.
+ *
+ * @pwrctl: PCI power control data
+ *
+ * Returns:
+ * 0 on success, negative error number on error.
+ *
+ * Note:
+ * This function returning 0 doesn't mean the device was detected. It means,
+ * that the bus rescan was successfully started. The device will get bound to
+ * its PCI driver asynchronously.
+ */
+int pci_pwrctl_device_set_ready(struct pci_pwrctl *pwrctl)
+{
+	int ret;
+
+	if (!pwrctl->dev)
+		return -ENODEV;
+
+	pwrctl->nb.notifier_call = pci_pwrctl_notify;
+	ret = bus_register_notifier(&pci_bus_type, &pwrctl->nb);
+	if (ret)
+		return ret;
+
+	pci_lock_rescan_remove();
+	pci_rescan_bus(to_pci_dev(pwrctl->dev->parent)->bus);
+	pci_unlock_rescan_remove();
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_pwrctl_device_set_ready);
+
+/**
+ * pci_pwrctl_device_unset_ready() - Notify the pwrctl subsystem that the PCI
+ * device is about to be powered-down.
+ *
+ * @pwrctl: PCI power control data
+ */
+void pci_pwrctl_device_unset_ready(struct pci_pwrctl *pwrctl)
+{
+	/*
+	 * We don't have to delete the link here. Typically, this function
+	 * is only called when the power control device is being detached. If
+	 * it is being detached then the child PCI device must have already
+	 * been unbound too or the device core wouldn't let us unbind.
+	 */
+	bus_unregister_notifier(&pci_bus_type, &pwrctl->nb);
+}
+EXPORT_SYMBOL_GPL(pci_pwrctl_device_unset_ready);
+
+static void devm_pci_pwrctl_device_unset_ready(void *data)
+{
+	struct pci_pwrctl *pwrctl = data;
+
+	pci_pwrctl_device_set_ready(pwrctl);
+}
+
+/**
+ * devm_pci_pwrctl_device_set_ready - Managed variant of
+ * pci_pwrctl_device_set_ready().
+ *
+ * @pwrctl: PCI power control data
+ *
+ * Returns:
+ * 0 on success, negative error number on error.
+ */
+int devm_pci_pwrctl_device_set_ready(struct device *dev,
+				     struct pci_pwrctl *pwrctl)
+{
+	int ret;
+
+	ret = pci_pwrctl_device_set_ready(pwrctl);
+	if (ret)
+		return ret;
+
+	return devm_add_action_or_reset(dev,
+					devm_pci_pwrctl_device_unset_ready,
+					pwrctl);
+}
+EXPORT_SYMBOL_GPL(devm_pci_pwrctl_device_set_ready);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("PCI Device Power Control core driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/pci-pwrctl.h b/include/linux/pci-pwrctl.h
new file mode 100644
index 000000000000..ae8324ea7eeb
--- /dev/null
+++ b/include/linux/pci-pwrctl.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#ifndef __PCI_PWRCTL_H__
+#define __PCI_PWRCTL_H__
+
+#include <linux/notifier.h>
+
+struct device;
+struct device_link;
+
+/*
+ * This is a simple framework for solving the issue of PCI devices that require
+ * certain resources (regulators, GPIOs, clocks) to be enabled before the
+ * device can actually be detected on the PCI bus.
+ *
+ * The idea is to reuse the platform bus to populate OF nodes describing the
+ * PCI device and its resources, let these platform devices probe and enable
+ * relevant resources and then trigger a rescan of the PCI bus allowing for the
+ * same device (with a second associated struct device) to be registered with
+ * the PCI subsystem.
+ *
+ * To preserve a correct hierarchy for PCI power management and device reset,
+ * we create a device link between the power control platform device (parent)
+ * and the supplied PCI device (child).
+ */
+
+/**
+ * struct pci_pwrctl - PCI device power control context.
+ * @dev - Address of the power controlling device.
+ *
+ * An object of this type must be allocated by the PCI power control device and
+ * passed to the pwrctl subsystem to trigger a bus rescan and setup a device
+ * link with the device once it's up.
+ */
+struct pci_pwrctl {
+	struct device *dev;
+
+	/* Private, don't use. */
+	struct notifier_block nb;
+	struct device_link *link;
+};
+
+int pci_pwrctl_device_set_ready(struct pci_pwrctl *pwrctl);
+void pci_pwrctl_device_unset_ready(struct pci_pwrctl *pwrctl);
+int devm_pci_pwrctl_device_set_ready(struct device *dev,
+				     struct pci_pwrctl *pwrctl);
+
+#endif /* __PCI_PWRCTL_H__ */
-- 
2.40.1

[PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a PCI power control driver that's capable of correctly powering up
the ath12k module on WCN7850 using the PCI pwrctl functionality.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/pwrctl/Kconfig              |   8 +
 drivers/pci/pwrctl/Makefile             |   2 +
 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c | 202 ++++++++++++++++++++++++
 3 files changed, 212 insertions(+)
 create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c

diff --git a/drivers/pci/pwrctl/Kconfig b/drivers/pci/pwrctl/Kconfig
index 96195395af69..b91170ebfb49 100644
--- a/drivers/pci/pwrctl/Kconfig
+++ b/drivers/pci/pwrctl/Kconfig
@@ -5,4 +5,12 @@ menu "PCI Power control drivers"
 config PCI_PWRCTL
 	tristate
 
+config PCI_PWRCTL_WCN7850
+	tristate "PCI Power Control driver for WCN7850"
+	select PCI_PWRCTL
+	default m if (ATH12K && ARCH_QCOM)
+	help
+	  Enable support for the PCI power control driver for the ath12k
+	  module of the WCN7850 WLAN/BT chip.
+
 endmenu
diff --git a/drivers/pci/pwrctl/Makefile b/drivers/pci/pwrctl/Makefile
index 52ae0640ef7b..de20c3af1b78 100644
--- a/drivers/pci/pwrctl/Makefile
+++ b/drivers/pci/pwrctl/Makefile
@@ -2,3 +2,5 @@
 
 obj-$(CONFIG_PCI_PWRCTL)		+= pci-pwrctl-core.o
 pci-pwrctl-core-y			:= core.o
+
+obj-$(CONFIG_PCI_PWRCTL_WCN7850)	+= pci-pwrctl-wcn7850.o
diff --git a/drivers/pci/pwrctl/pci-pwrctl-wcn7850.c b/drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
new file mode 100644
index 000000000000..e2b2c53bff29
--- /dev/null
+++ b/drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pci-pwrctl.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+struct pci_pwrctl_wcn7850_vreg {
+	const char *name;
+	unsigned int load_uA;
+};
+
+struct pci_pwrctl_wcn7850_pdata {
+	struct pci_pwrctl_wcn7850_vreg *vregs;
+	size_t num_vregs;
+	unsigned int delay_msec;
+};
+
+struct pci_pwrctl_wcn7850_ctx {
+	struct pci_pwrctl pwrctl;
+	const struct pci_pwrctl_wcn7850_pdata *pdata;
+	struct regulator_bulk_data *regs;
+	struct gpio_desc *en_gpio;
+	struct clk *clk;
+};
+
+static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
+	{
+		.name = "vdd",
+		.load_uA = 16000,
+	},
+	{
+		.name = "vddio",
+		.load_uA = 5000,
+	},
+	{
+		.name = "vddio1p2",
+		.load_uA = 16000,
+	},
+	{
+		.name = "vddaon",
+		.load_uA = 26000,
+	},
+	{
+		.name = "vdddig",
+		.load_uA = 126000,
+	},
+	{
+		.name = "vddrfa1p2",
+		.load_uA = 257000,
+	},
+	{
+		.name = "vddrfa1p8",
+		.load_uA = 302000,
+	},
+};
+
+static struct pci_pwrctl_wcn7850_pdata pci_pwrctl_wcn7850_of_data = {
+	.vregs = pci_pwrctl_wcn7850_vregs,
+	.num_vregs = ARRAY_SIZE(pci_pwrctl_wcn7850_vregs),
+	.delay_msec = 50,
+};
+
+static int pci_pwrctl_wcn7850_power_on(struct pci_pwrctl_wcn7850_ctx *ctx)
+{
+	int ret;
+
+	ret = regulator_bulk_enable(ctx->pdata->num_vregs, ctx->regs);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(ctx->clk);
+	if (ret)
+		return ret;
+
+	gpiod_set_value_cansleep(ctx->en_gpio, 1);
+
+	if (ctx->pdata->delay_msec)
+		msleep(ctx->pdata->delay_msec);
+
+	return 0;
+}
+
+static int pci_pwrctl_wcn7850_power_off(struct pci_pwrctl_wcn7850_ctx *ctx)
+{
+	gpiod_set_value_cansleep(ctx->en_gpio, 0);
+	clk_disable_unprepare(ctx->clk);
+
+	return regulator_bulk_disable(ctx->pdata->num_vregs, ctx->regs);
+}
+
+static void devm_pci_pwrctl_wcn7850_power_off(void *data)
+{
+	struct pci_pwrctl_wcn7850_ctx *ctx = data;
+
+	pci_pwrctl_wcn7850_power_off(ctx);
+}
+
+static int pci_pwrctl_wcn7850_probe(struct platform_device *pdev)
+{
+	struct pci_pwrctl_wcn7850_ctx *ctx;
+	struct device *dev = &pdev->dev;
+	int ret, i;
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->pdata = of_device_get_match_data(dev);
+	if (!ctx->pdata)
+		return dev_err_probe(dev, -ENODEV,
+				     "Failed to obtain platform data\n");
+
+	if (ctx->pdata->vregs) {
+		ctx->regs = devm_kcalloc(dev, ctx->pdata->num_vregs,
+					 sizeof(*ctx->regs), GFP_KERNEL);
+		if (!ctx->regs)
+			return -ENOMEM;
+
+		for (i = 0; i < ctx->pdata->num_vregs; i++)
+			ctx->regs[i].supply = ctx->pdata->vregs[i].name;
+
+		ret = devm_regulator_bulk_get(dev, ctx->pdata->num_vregs,
+					      ctx->regs);
+		if (ret < 0)
+			return dev_err_probe(dev, ret,
+					     "Failed to get all regulators\n");
+
+		for (i = 0; i < ctx->pdata->num_vregs; i++) {
+			if (!ctx->pdata->vregs[1].load_uA)
+				continue;
+
+			ret = regulator_set_load(ctx->regs[i].consumer,
+						 ctx->pdata->vregs[i].load_uA);
+			if (ret)
+				return dev_err_probe(dev, ret,
+						     "Failed to set vreg load\n");
+		}
+	}
+
+	ctx->clk = devm_clk_get_optional(dev, NULL);
+	if (IS_ERR(ctx->clk))
+		return dev_err_probe(dev, PTR_ERR(ctx->clk),
+				     "Failed to get clock\n");
+
+	ctx->en_gpio = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->en_gpio))
+		return dev_err_probe(dev, PTR_ERR(ctx->en_gpio),
+				     "Failed to get enable the GPIO\n");
+
+	ret = pci_pwrctl_wcn7850_power_on(ctx);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to power on the device\n");
+
+	ret = devm_add_action_or_reset(dev, devm_pci_pwrctl_wcn7850_power_off,
+				       ctx);
+	if (ret)
+		return ret;
+
+	ctx->pwrctl.dev = dev;
+
+	ret = devm_pci_pwrctl_device_set_ready(dev, &ctx->pwrctl);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to register the pwrctl wrapper\n");
+
+	return 0;
+}
+
+static const struct of_device_id pci_pwrctl_wcn7850_of_match[] = {
+	{
+		.compatible = "pci17cb,1107",
+		.data = &pci_pwrctl_wcn7850_of_data,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, pci_pwrctl_wcn7850_of_match);
+
+static struct platform_driver pci_pwrctl_wcn7850_driver = {
+	.driver = {
+		.name = "pci-pwrctl-wcn7850",
+		.of_match_table = pci_pwrctl_wcn7850_of_match,
+	},
+	.probe = pci_pwrctl_wcn7850_probe,
+};
+module_platform_driver(pci_pwrctl_wcn7850_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("PCI Power Sequencing module for WCN7850");
+MODULE_LICENSE("GPL");
-- 
2.40.1

[PATCH v5 15/18] power: sequencing: implement the pwrseq core

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Implement the power sequencing subsystem allowing devices to share
complex powering-up and down procedures. It's split into the consumer
and provider parts but does not implement any new DT bindings so that
the actual power sequencing is never revealed in the DT representation.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 MAINTAINERS                       |    8 +
 drivers/power/Kconfig             |    1 +
 drivers/power/Makefile            |    1 +
 drivers/power/sequencing/Kconfig  |   12 +
 drivers/power/sequencing/Makefile |    4 +
 drivers/power/sequencing/core.c   | 1065 +++++++++++++++++++++++++++++
 include/linux/pwrseq/consumer.h   |   56 ++
 include/linux/pwrseq/provider.h   |   75 ++
 8 files changed, 1222 insertions(+)
 create mode 100644 drivers/power/sequencing/Kconfig
 create mode 100644 drivers/power/sequencing/Makefile
 create mode 100644 drivers/power/sequencing/core.c
 create mode 100644 include/linux/pwrseq/consumer.h
 create mode 100644 include/linux/pwrseq/provider.h

diff --git a/MAINTAINERS b/MAINTAINERS
index cd7980e5b1ad..5187a30952e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17647,6 +17647,14 @@ F:	include/linux/pm_*
 F:	include/linux/powercap.h
 F:	kernel/configs/nopm.config
 
+POWER SEQUENCING
+M:	Bartosz Golaszewski <brgl@bgdev.pl>
+L:	linux-pm@vger.kernel.org
+S:	Maintained
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
+F:	drivers/power/sequencing/
+F:	include/linux/pwrseq/
+
 POWER STATE COORDINATION INTERFACE (PSCI)
 M:	Mark Rutland <mark.rutland@arm.com>
 M:	Lorenzo Pieralisi <lpieralisi@kernel.org>
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 696bf77a7042..9a8e44ca9ae4 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 source "drivers/power/reset/Kconfig"
+source "drivers/power/sequencing/Kconfig"
 source "drivers/power/supply/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index effbf0377f32..962a2cd30a51 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_POWER_RESET)	+= reset/
+obj-$(CONFIG_POWER_SEQUENCING)	+= sequencing/
 obj-$(CONFIG_POWER_SUPPLY)	+= supply/
diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
new file mode 100644
index 000000000000..ba5732b1dbf8
--- /dev/null
+++ b/drivers/power/sequencing/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+menuconfig POWER_SEQUENCING
+	tristate "Power Sequencing support"
+	help
+	  Say Y here to enable the Power Sequencing subsystem.
+
+	  This subsystem is designed to control power to devices that share
+	  complex resources and/or require specific power sequences to be run
+	  during power-up.
+
+	  If unsure, say no.
diff --git a/drivers/power/sequencing/Makefile b/drivers/power/sequencing/Makefile
new file mode 100644
index 000000000000..dcdf8c0c159e
--- /dev/null
+++ b/drivers/power/sequencing/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_POWER_SEQUENCING)		+= pwrseq-core.o
+pwrseq-core-y				:= core.o
diff --git a/drivers/power/sequencing/core.c b/drivers/power/sequencing/core.c
new file mode 100644
index 000000000000..00ad7964a0b6
--- /dev/null
+++ b/drivers/power/sequencing/core.c
@@ -0,0 +1,1065 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#include <linux/bug.h>
+#include <linux/cleanup.h>
+#include <linux/debugfs.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/idr.h>
+#include <linux/kernel.h>
+#include <linux/kref.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/property.h>
+#include <linux/pwrseq/consumer.h>
+#include <linux/pwrseq/provider.h>
+#include <linux/radix-tree.h>
+#include <linux/rwsem.h>
+#include <linux/slab.h>
+
+/*
+ * Power-sequencing framework for linux.
+ *
+ * This subsystem allows power sequence providers to register a set of targets
+ * that consumers may request and power-up/down.
+ *
+ * Glossary:
+ *
+ * Unit - a unit is a discreet chunk of a power sequence. For instance one unit
+ * may enable a set of regulators, another may enable a specific GPIO. Units
+ * can define dependencies in the form of other units that must be enabled
+ * before it itself can be.
+ *
+ * Target - a target is a set of units (composed of the "final" unit and its
+ * dependencies) that a consumer selects by its name when requesting a handle
+ * to the power sequencer. Via the dependency system, multiple targets may
+ * share the same parts of a power sequence but ignore parts that are
+ * irrelevant.
+ *
+ * Descriptor - a handle passed by the pwrseq core to every consumer that
+ * serves as the entry point to the provider layer. It ensures coherence
+ * between different users and keeps reference counting consistent.
+ *
+ * Each provider must define a .match() callback whose role is to determine
+ * whether a potential consumer is in fact associated with this sequencer.
+ * This allows creating abstraction layers on top of regular device-tree
+ * resources like regulators, clocks and other nodes connected to the consumer
+ * via phandle.
+ */
+
+static DEFINE_IDA(pwrseq_ida);
+
+/*
+ * Protects the device list on the pwrseq bus from concurrent modifications
+ * but allows simultaneous read-only access.
+ */
+static DECLARE_RWSEM(pwrseq_sem);
+
+/**
+ * struct pwrseq_unit - Private power-sequence unit data.
+ * @ref: Reference count for this object. When it goes to 0, the object is
+ *       destroyed.
+ * @name: Name of this target.
+ * @list: Link to siblings on the list of all units of a single sequencer.
+ * @deps: List of units on which this unit depends.
+ * @enable: Callback running the part of the power-on sequence provided by
+ *          this unit.
+ * @disable: Callback running the part of the power-off sequence provided
+ *           by this unit.
+ * @enable_count: Current number of users that enabled this unit. May be the
+ *                consumer of the power sequencer or other units that depend
+ *                on this one.
+ */
+struct pwrseq_unit {
+	struct kref ref;
+	const char *name;
+	struct list_head list;
+	struct list_head deps;
+	pwrseq_power_state_func enable;
+	pwrseq_power_state_func disable;
+	unsigned int enable_count;
+};
+
+static struct pwrseq_unit *pwrseq_unit_new(const struct pwrseq_unit_data *data)
+{
+	struct pwrseq_unit *unit;
+
+	unit = kzalloc(sizeof(*unit), GFP_KERNEL);
+	if (!unit)
+		return NULL;
+
+	unit->name = kstrdup_const(data->name, GFP_KERNEL);
+	if (!unit->name) {
+		kfree(unit);
+		return NULL;
+	}
+
+	kref_init(&unit->ref);
+	INIT_LIST_HEAD(&unit->deps);
+	unit->enable = data->enable;
+	unit->disable = data->disable;
+
+	return unit;
+}
+
+static struct pwrseq_unit *pwrseq_unit_incref(struct pwrseq_unit *unit)
+{
+	kref_get(&unit->ref);
+
+	return unit;
+}
+
+static void pwrseq_unit_release(struct kref *ref);
+
+static void pwrseq_unit_decref(struct pwrseq_unit *unit)
+{
+	kref_put(&unit->ref, pwrseq_unit_release);
+}
+
+/**
+ * struct pwrseq_unit_dep - Wrapper around a reference to the unit structure
+ *                          allowing to keep it on multiple dependency lists
+ *                          in different units.
+ * @list: Siblings on the list.
+ * @unit: Address of the referenced unit.
+ */
+struct pwrseq_unit_dep {
+	struct list_head list;
+	struct pwrseq_unit *unit;
+};
+
+static struct pwrseq_unit_dep *pwrseq_unit_dep_new(struct pwrseq_unit *unit)
+{
+	struct pwrseq_unit_dep *dep;
+
+	dep = kzalloc(sizeof(*dep), GFP_KERNEL);
+	if (!dep)
+		return NULL;
+
+	dep->unit = unit;
+
+	return dep;
+}
+
+static void pwrseq_unit_dep_free(struct pwrseq_unit_dep *ref)
+{
+	pwrseq_unit_decref(ref->unit);
+	kfree(ref);
+}
+
+static void pwrseq_unit_free_deps(struct list_head *list)
+{
+	struct pwrseq_unit_dep *dep, *next;
+
+	list_for_each_entry_safe(dep, next, list, list) {
+		list_del(&dep->list);
+		pwrseq_unit_dep_free(dep);
+	}
+}
+
+static void pwrseq_unit_release(struct kref *ref)
+{
+	struct pwrseq_unit *unit = container_of(ref, struct pwrseq_unit, ref);
+
+	pwrseq_unit_free_deps(&unit->deps);
+	list_del(&unit->list);
+	kfree_const(unit->name);
+	kfree(unit);
+}
+
+/**
+ * struct pwrseq_target - Private power-sequence target data.
+ * @list: Siblings on the list of all targets exposed by a power sequencer.
+ * @name: Name of the target.
+ * @unit: Final unit for this target.
+ * @post_enable: Callback run after the target unit has been enabled, *after*
+ *               the state lock has been released. It's useful for implementing
+ *               boot-up delays without blocking other users from powering up
+ *               using the same power sequencer.
+ */
+struct pwrseq_target {
+	struct list_head list;
+	const char *name;
+	struct pwrseq_unit *unit;
+	pwrseq_power_state_func post_enable;
+};
+
+static struct pwrseq_target *
+pwrseq_target_new(const struct pwrseq_target_data *data)
+{
+	struct pwrseq_target *target;
+
+	target = kzalloc(sizeof(*target), GFP_KERNEL);
+	if (!target)
+		return NULL;
+
+	target->name = kstrdup_const(data->name, GFP_KERNEL);
+	if (!target->name) {
+		kfree(target);
+		return NULL;
+	}
+
+	target->post_enable = data->post_enable;
+
+	return target;
+}
+
+static void pwrseq_target_free(struct pwrseq_target *target)
+{
+	pwrseq_unit_decref(target->unit);
+	kfree_const(target->name);
+	kfree(target);
+}
+
+/**
+ * struct pwrseq_device - Private power sequencing data.
+ * @dev: Device struct associated with this sequencer.
+ * @id: Device ID.
+ * @owner: Prevents removal of active power sequencing providers.
+ * @rw_lock: Protects the device from being unregistered while in use.
+ * @state_lock: Prevents multiple users running the power sequence at the same
+ *              time.
+ * @match: Power sequencer matching callback.
+ * @targets: List of targets exposed by this sequencer.
+ * @units: List of all units supported by this sequencer.
+ */
+struct pwrseq_device {
+	struct device dev;
+	int id;
+	struct module *owner;
+	struct rw_semaphore rw_lock;
+	struct mutex state_lock;
+	pwrseq_match_func match;
+	struct list_head targets;
+	struct list_head units;
+};
+
+static struct pwrseq_device *to_pwrseq_device(struct device *dev)
+{
+	return container_of(dev, struct pwrseq_device, dev);
+}
+
+static struct pwrseq_device *pwrseq_device_get(struct pwrseq_device *pwrseq)
+{
+	get_device(&pwrseq->dev);
+
+	return pwrseq;
+}
+
+static void pwrseq_device_put(struct pwrseq_device *pwrseq)
+{
+	put_device(&pwrseq->dev);
+}
+
+/**
+ * struct pwrseq_desc - Wraps access to the pwrseq_device and ensures that one
+ *                      user cannot break the reference counting for others.
+ * @pwrseq: Reference to the power sequencing device.
+ * @target: Reference to the target this descriptor allows to control.
+ * @powered_on: Power state set by the holder of the descriptor (not necessarily
+ * corresponding to the actual power state of the device).
+ */
+struct pwrseq_desc {
+	struct pwrseq_device *pwrseq;
+	struct pwrseq_target *target;
+	bool powered_on;
+};
+
+static const struct bus_type pwrseq_bus = {
+	.name = "pwrseq",
+};
+
+static void pwrseq_release(struct device *dev)
+{
+	struct pwrseq_device *pwrseq = to_pwrseq_device(dev);
+	struct pwrseq_target *target;
+
+	list_for_each_entry(target, &pwrseq->targets, list)
+		pwrseq_target_free(target);
+
+	mutex_destroy(&pwrseq->state_lock);
+	ida_free(&pwrseq_ida, pwrseq->id);
+	kfree(pwrseq);
+}
+
+static const struct device_type pwrseq_device_type = {
+	.name = "power_sequencer",
+	.release = pwrseq_release,
+};
+
+static int pwrseq_unit_setup_deps(const struct pwrseq_unit_data **data,
+				  struct list_head *dep_list,
+				  struct list_head *unit_list,
+				  struct radix_tree_root *processed_units)
+{
+	const struct pwrseq_unit_data *pos;
+	struct pwrseq_unit_dep *dep;
+	struct pwrseq_unit *unit;
+	int ret, i;
+
+	for (i = 0; data[i]; i++) {
+		pos = data[i];
+
+		unit = radix_tree_lookup(processed_units, (unsigned long)data);
+		if (unit) {
+			pwrseq_unit_incref(unit);
+		} else {
+			unit = pwrseq_unit_new(pos);
+			if (!unit)
+				return -ENOMEM;
+
+			if (pos->deps) {
+				ret = pwrseq_unit_setup_deps(pos->deps,
+							     &unit->deps,
+							     unit_list,
+							     processed_units);
+				if (ret) {
+					pwrseq_unit_decref(unit);
+					return ret;
+				}
+			}
+
+			ret = radix_tree_insert(processed_units,
+						(unsigned long)data, unit);
+			if (ret) {
+				pwrseq_unit_decref(unit);
+				return ret;
+			}
+
+			list_add_tail(&unit->list, unit_list);
+		}
+
+		dep = pwrseq_unit_dep_new(unit);
+		if (!dep) {
+			pwrseq_unit_decref(unit);
+			return -ENOMEM;
+		}
+
+		list_add_tail(&dep->list, dep_list);
+	}
+
+	return 0;
+}
+
+static int pwrseq_target_setup_unit(struct pwrseq_target *target,
+				    const struct pwrseq_unit_data *data,
+				    struct list_head *unit_list,
+				    struct radix_tree_root *processed_units)
+{
+	struct pwrseq_unit *unit;
+	int ret;
+
+	unit = radix_tree_lookup(processed_units, (unsigned long)data);
+	if (unit) {
+		target->unit = pwrseq_unit_incref(unit);
+		return 0;
+	}
+
+	unit = pwrseq_unit_new(data);
+	if (!unit)
+		return -ENOMEM;
+
+	ret = pwrseq_unit_setup_deps(data->deps, &unit->deps, unit_list,
+				     processed_units);
+	if (ret) {
+		pwrseq_unit_decref(unit);
+		return ret;
+	}
+
+	ret = radix_tree_insert(processed_units, (unsigned long)data, unit);
+	if (ret) {
+		pwrseq_unit_decref(unit);
+		return ret;
+	}
+
+	target->unit = unit;
+	list_add_tail(&unit->list, unit_list);
+
+	return 0;
+}
+
+static int pwrseq_do_setup_targets(const struct pwrseq_target_data **data,
+				   struct pwrseq_device *pwrseq,
+				   struct radix_tree_root *processed_units)
+{
+	const struct pwrseq_target_data *pos;
+	struct pwrseq_target *target;
+	int ret, i;
+
+	for (i = 0; data[i]; i++) {
+		pos = data[i];
+
+		target = pwrseq_target_new(pos);
+		if (!target)
+			return -ENOMEM;
+
+		ret = pwrseq_target_setup_unit(target, pos->unit,
+					       &pwrseq->units,
+					       processed_units);
+		if (ret) {
+			pwrseq_target_free(target);
+			return ret;
+		}
+
+		list_add_tail(&target->list, &pwrseq->targets);
+	}
+
+	return 0;
+}
+
+static int pwrseq_setup_targets(const struct pwrseq_target_data **targets,
+				struct pwrseq_device *pwrseq)
+{
+	struct radix_tree_root processed_units;
+	struct radix_tree_iter iter;
+	void __rcu **slot;
+	int ret;
+
+	INIT_RADIX_TREE(&processed_units, GFP_KERNEL);
+	ret = pwrseq_do_setup_targets(targets, pwrseq, &processed_units);
+	radix_tree_for_each_slot(slot, &processed_units, &iter, 0)
+		radix_tree_delete(&processed_units, iter.index);
+
+	return ret;
+}
+
+/**
+ * pwrseq_device_register() - Register a new power sequencer.
+ * @config: Configuration of the new power sequencing device.
+ *
+ * The config structure is only used during the call and can be freed after
+ * the function returns. The config structure *must* have the parent device
+ * as well as the match() callback and at least one target set.
+ *
+ * Returns:
+ * Returns the address of the new pwrseq device or ERR_PTR() on failure.
+ */
+struct pwrseq_device *
+pwrseq_device_register(const struct pwrseq_config *config)
+{
+	struct pwrseq_device *pwrseq;
+	int ret;
+
+	if (!config->parent || !config->match || !config->targets ||
+	    !config->targets[0])
+		return ERR_PTR(-EINVAL);
+
+	pwrseq = kzalloc(sizeof(*pwrseq), GFP_KERNEL);
+	if (!pwrseq)
+		return ERR_PTR(-ENOMEM);
+
+	pwrseq->dev.type = &pwrseq_device_type;
+	pwrseq->dev.bus = &pwrseq_bus;
+	pwrseq->dev.parent = config->parent;
+	device_set_node(&pwrseq->dev, dev_fwnode(config->parent));
+	dev_set_drvdata(&pwrseq->dev, config->drvdata);
+
+	pwrseq->id = ida_alloc(&pwrseq_ida, GFP_KERNEL);
+	if (pwrseq->id < 0) {
+		kfree(pwrseq);
+		return ERR_PTR(pwrseq->id);
+	}
+
+	/*
+	 * From this point onwards the device's release() callback is
+	 * responsible for freeing resources.
+	 */
+	device_initialize(&pwrseq->dev);
+
+	ret = dev_set_name(&pwrseq->dev, "pwrseq.%d", pwrseq->id);
+	if (ret)
+		goto err_put_pwrseq;
+
+	pwrseq->owner = config->owner ?: THIS_MODULE;
+	pwrseq->match = config->match;
+
+	init_rwsem(&pwrseq->rw_lock);
+	mutex_init(&pwrseq->state_lock);
+	INIT_LIST_HEAD(&pwrseq->targets);
+	INIT_LIST_HEAD(&pwrseq->units);
+
+	ret = pwrseq_setup_targets(config->targets, pwrseq);
+	if (ret)
+		goto err_put_pwrseq;
+
+	scoped_guard(rwsem_write, &pwrseq_sem) {
+		ret = device_add(&pwrseq->dev);
+		if (ret)
+			goto err_put_pwrseq;
+	}
+
+	return pwrseq;
+
+err_put_pwrseq:
+	pwrseq_device_put(pwrseq);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(pwrseq_device_register);
+
+/**
+ * pwrseq_device_unregister() - Unregister the power sequencer.
+ * @pwrseq: Power sequencer to unregister.
+ */
+void pwrseq_device_unregister(struct pwrseq_device *pwrseq)
+{
+	struct device *dev = &pwrseq->dev;
+	struct pwrseq_target *target;
+
+	scoped_guard(mutex, &pwrseq->state_lock) {
+		guard(rwsem_write)(&pwrseq->rw_lock);
+
+		list_for_each_entry(target, &pwrseq->targets, list)
+			WARN_ONCE(target->unit->enable_count,
+				  "REMOVING POWER SEQUENCER WITH ACTIVE USERS\n");
+
+		guard(rwsem_write)(&pwrseq_sem);
+
+		device_del(dev);
+	}
+
+	pwrseq_device_put(pwrseq);
+}
+EXPORT_SYMBOL_GPL(pwrseq_device_unregister);
+
+static void devm_pwrseq_device_unregister(void *data)
+{
+	struct pwrseq_device *pwrseq = data;
+
+	pwrseq_device_unregister(pwrseq);
+}
+
+/**
+ * devm_pwrseq_device_register() - Managed variant of pwrseq_device_register().
+ * @dev: Managing device.
+ * @config: Configuration of the new power sequencing device.
+ *
+ * Returns:
+ * Returns the address of the new pwrseq device or ERR_PTR() on failure.
+ */
+struct pwrseq_device *
+devm_pwrseq_device_register(struct device *dev,
+			    const struct pwrseq_config *config)
+{
+	struct pwrseq_device *pwrseq;
+	int ret;
+
+	pwrseq = pwrseq_device_register(config);
+	if (IS_ERR(pwrseq))
+		return pwrseq;
+
+	ret = devm_add_action_or_reset(dev, devm_pwrseq_device_unregister,
+				       pwrseq);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return pwrseq;
+}
+EXPORT_SYMBOL_GPL(devm_pwrseq_device_register);
+
+/**
+ * pwrseq_device_get_data() - Get the driver private data associated with this
+ *                            sequencer.
+ * @pwrseq: Power sequencer object.
+ *
+ * Returns:
+ * Address of the private driver data.
+ */
+void *pwrseq_device_get_drvdata(struct pwrseq_device *pwrseq)
+{
+	return dev_get_drvdata(&pwrseq->dev);
+}
+EXPORT_SYMBOL_GPL(pwrseq_device_get_drvdata);
+
+struct pwrseq_match_data {
+	struct pwrseq_desc *desc;
+	struct device *dev;
+	const char *target;
+};
+
+static int pwrseq_match_device(struct device *pwrseq_dev, void *data)
+{
+	struct pwrseq_device *pwrseq = to_pwrseq_device(pwrseq_dev);
+	struct pwrseq_match_data *match_data = data;
+	struct pwrseq_target *target;
+	int ret;
+
+	guard(rwsem_read)(&pwrseq->rw_lock);
+	if (!device_is_registered(&pwrseq->dev))
+		return 0;
+
+	ret = pwrseq->match(pwrseq, match_data->dev);
+	if (ret <= 0)
+		return ret;
+
+	/* We got the matching device, let's find the right target. */
+	list_for_each_entry(target, &pwrseq->targets, list) {
+		if (strcmp(target->name, match_data->target))
+			continue;
+
+		match_data->desc->target = target;
+	}
+
+	/*
+	 * This device does not have this target. No point in deferring as it
+	 * will not get a new target dynamically later.
+	 */
+	if (!match_data->desc->target)
+		return -ENOENT;
+
+	if (!try_module_get(pwrseq->owner))
+		return -EPROBE_DEFER;
+
+	match_data->desc->pwrseq = pwrseq_device_get(pwrseq);
+
+	return 1;
+}
+
+/**
+ * pwrseq_get() - Get the power sequencer associated with this device.
+ * @dev: Device for which to get the sequencer.
+ * @target: Name of the target exposed by the sequencer this device wants to
+ *          reach.
+ *
+ * Returns:
+ * New power sequencer descriptor for use by the consumer driver or ERR_PTR()
+ * on failure.
+ */
+struct pwrseq_desc *pwrseq_get(struct device *dev, const char *target)
+{
+	struct pwrseq_match_data match_data;
+	int ret;
+
+	struct pwrseq_desc *desc __free(kfree) = kzalloc(sizeof(*desc),
+							 GFP_KERNEL);
+	if (!desc)
+		return ERR_PTR(-ENOMEM);
+
+	match_data.desc = desc;
+	match_data.dev = dev;
+	match_data.target = target;
+
+	guard(rwsem_read)(&pwrseq_sem);
+
+	ret = bus_for_each_dev(&pwrseq_bus, NULL, &match_data,
+			       pwrseq_match_device);
+	if (ret < 0)
+		return ERR_PTR(ret);
+	if (ret == 0)
+		/* No device matched. */
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return no_free_ptr(desc);
+}
+EXPORT_SYMBOL_GPL(pwrseq_get);
+
+/**
+ * pwrseq_put() - Release the power sequencer descriptor.
+ * @desc: Descriptor to release.
+ */
+void pwrseq_put(struct pwrseq_desc *desc)
+{
+	struct pwrseq_device *pwrseq;
+
+	if (!desc)
+		return;
+
+	pwrseq = desc->pwrseq;
+
+	if (desc->powered_on)
+		pwrseq_power_off(desc);
+
+	kfree(desc);
+	module_put(pwrseq->owner);
+	pwrseq_device_put(pwrseq);
+}
+EXPORT_SYMBOL_GPL(pwrseq_put);
+
+static void devm_pwrseq_put(void *data)
+{
+	struct pwrseq_desc *desc = data;
+
+	pwrseq_put(desc);
+}
+
+/**
+ * devm_pwrseq_get() - Managed variant of pwrseq_get().
+ * @dev: Device for which to get the sequencer and which also manages its
+ *       lifetime.
+ * @target: Name of the target exposed by the sequencer this device wants to
+ *          reach.
+ *
+ * Returns:
+ * New power sequencer descriptor for use by the consumer driver or ERR_PTR()
+ * on failure.
+ */
+struct pwrseq_desc *devm_pwrseq_get(struct device *dev, const char *target)
+{
+	struct pwrseq_desc *desc;
+	int ret;
+
+	desc = pwrseq_get(dev, target);
+	if (IS_ERR(desc))
+		return desc;
+
+	ret = devm_add_action_or_reset(dev, devm_pwrseq_put, desc);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return desc;
+}
+EXPORT_SYMBOL_GPL(devm_pwrseq_get);
+
+static int pwrseq_unit_enable(struct pwrseq_device *pwrseq,
+			      struct pwrseq_unit *target);
+static int pwrseq_unit_disable(struct pwrseq_device *pwrseq,
+			       struct pwrseq_unit *target);
+
+static int pwrseq_unit_enable_deps(struct pwrseq_device *pwrseq,
+				   struct list_head *list)
+{
+	struct pwrseq_unit_dep *pos;
+	int ret = 0;
+
+	list_for_each_entry(pos, list, list) {
+		ret = pwrseq_unit_enable(pwrseq, pos->unit);
+		if (ret) {
+			list_for_each_entry_continue_reverse(pos, list, list)
+				pwrseq_unit_disable(pwrseq, pos->unit);
+			break;
+		}
+	}
+
+	return ret;
+}
+
+static int pwrseq_unit_disable_deps(struct pwrseq_device *pwrseq,
+				    struct list_head *list)
+{
+	struct pwrseq_unit_dep *pos;
+	int ret = 0;
+
+	list_for_each_entry_reverse(pos, list, list) {
+		ret = pwrseq_unit_disable(pwrseq, pos->unit);
+		if (ret) {
+			list_for_each_entry_continue(pos, list, list)
+				pwrseq_unit_enable(pwrseq, pos->unit);
+			break;
+		}
+	}
+
+	return ret;
+}
+
+static int pwrseq_unit_enable(struct pwrseq_device *pwrseq,
+			      struct pwrseq_unit *unit)
+{
+	int ret;
+
+	if (unit->enable_count != 0) {
+		unit->enable_count++;
+		return 0;
+	}
+
+	ret = pwrseq_unit_enable_deps(pwrseq, &unit->deps);
+	if (ret) {
+		dev_err(&pwrseq->dev,
+			"Failed to enable dependencies before power-on for target '%s': %d\n",
+			unit->name, ret);
+		return ret;
+	}
+
+	if (unit->enable) {
+		ret = unit->enable(pwrseq);
+		if (ret) {
+			dev_err(&pwrseq->dev,
+				"Failed to enable target '%s': %d\n",
+				unit->name, ret);
+			pwrseq_unit_disable_deps(pwrseq, &unit->deps);
+			return ret;
+		}
+	}
+
+	unit->enable_count++;
+
+	return 0;
+}
+
+static int pwrseq_unit_disable(struct pwrseq_device *pwrseq,
+			       struct pwrseq_unit *unit)
+{
+	int ret;
+
+	if (unit->enable_count == 0) {
+		WARN_ONCE(1, "Unmatched power-off for target '%s'\n",
+			  unit->name);
+		return -EBUSY;
+	}
+
+	if (unit->enable_count != 1) {
+		unit->enable_count--;
+		return 0;
+	}
+
+	if (unit->disable) {
+		ret = unit->disable(pwrseq);
+		if (ret) {
+			dev_err(&pwrseq->dev,
+				"Failed to disable target '%s': %d\n",
+				unit->name, ret);
+			return ret;
+		}
+	}
+
+	ret = pwrseq_unit_disable_deps(pwrseq, &unit->deps);
+	if (ret) {
+		dev_err(&pwrseq->dev,
+			"Failed to disable dependencies after power-off for target '%s': %d\n",
+			unit->name, ret);
+		if (unit->enable)
+			unit->enable(pwrseq);
+		return ret;
+	}
+
+	unit->enable_count--;
+
+	return 0;
+}
+
+/**
+ * pwrseq_power_on() - Issue a power-on request on behalf of the consumer
+ *                     device.
+ * @desc: Descriptor referencing the power sequencer.
+ *
+ * This function tells the power sequencer that the consumer wants to be
+ * powered-up. The sequencer may already have powered-up the device in which
+ * case the function returns 0. If the power-up sequence is already in
+ * progress, the function will block until it's done and return 0. If this is
+ * the first request, the device will be powered up.
+ *
+ * Returns:
+ * 0 on success, negative error number on failure.
+ */
+int pwrseq_power_on(struct pwrseq_desc *desc)
+{
+	struct pwrseq_device *pwrseq;
+	struct pwrseq_target *target;
+	struct pwrseq_unit *unit;
+	int ret;
+
+	might_sleep();
+
+	if (!desc || desc->powered_on)
+		return 0;
+
+	pwrseq = desc->pwrseq;
+	target = desc->target;
+	unit = target->unit;
+
+	guard(rwsem_read)(&pwrseq->rw_lock);
+	if (!device_is_registered(&pwrseq->dev))
+		return -ENODEV;
+
+	scoped_guard(mutex, &pwrseq->state_lock) {
+		ret = pwrseq_unit_enable(pwrseq, unit);
+		if (!ret)
+			desc->powered_on = true;
+	}
+
+	if (target->post_enable) {
+		ret = target->post_enable(pwrseq);
+		if (ret) {
+			pwrseq_unit_disable(pwrseq, unit);
+			desc->powered_on = false;
+		}
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(pwrseq_power_on);
+
+/**
+ * pwrseq_power_off() - Issue a power-off request on behalf of the consumer
+ *                      device.
+ * @desc: Descriptor referencing the power sequencer.
+ *
+ * This undoes the effects of pwrseq_power_on(). It issues a power-off request
+ * on behalf of the consumer and when the last remaining user does so, the
+ * power-down sequence will be started. If one is in progress, the function
+ * will block until it's complete and then return.
+ *
+ * Returns:
+ * 0 on success, negative error number on failure.
+ */
+int pwrseq_power_off(struct pwrseq_desc *desc)
+{
+	struct pwrseq_device *pwrseq;
+	struct pwrseq_unit *unit;
+	int ret;
+
+	might_sleep();
+
+	if (!desc || !desc->powered_on)
+		return 0;
+
+	pwrseq = desc->pwrseq;
+	unit = desc->target->unit;
+
+	guard(rwsem_read)(&pwrseq->rw_lock);
+	if (!device_is_registered(&pwrseq->dev))
+		return -ENODEV;
+
+	guard(mutex)(&pwrseq->state_lock);
+
+	ret = pwrseq_unit_disable(pwrseq, unit);
+	if (!ret)
+		desc->powered_on = false;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(pwrseq_power_off);
+
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+
+struct pwrseq_debugfs_count_ctx {
+	struct device *dev;
+	loff_t index;
+};
+
+static int pwrseq_debugfs_seq_count(struct device *dev, void *data)
+{
+	struct pwrseq_debugfs_count_ctx *ctx = data;
+
+	ctx->dev = dev;
+
+	return ctx->index-- ? 0 : 1;
+}
+
+static void *pwrseq_debugfs_seq_start(struct seq_file *seq, loff_t *pos)
+{
+	struct pwrseq_debugfs_count_ctx ctx;
+
+	ctx.dev = NULL;
+	ctx.index = *pos;
+
+	/*
+	 * We're holding the lock for the entire printout so no need to fiddle
+	 * with device reference count.
+	 */
+	down_read(&pwrseq_sem);
+
+	bus_for_each_dev(&pwrseq_bus, NULL, &ctx, pwrseq_debugfs_seq_count);
+	if (!ctx.index)
+		return NULL;
+
+	return ctx.dev;
+}
+
+static void *pwrseq_debugfs_seq_next(struct seq_file *seq, void *data,
+				     loff_t *pos)
+{
+	struct device *curr = data;
+
+	++*pos;
+
+	struct device *next __free(put_device) =
+			bus_find_next_device(&pwrseq_bus, curr);
+	return next;
+}
+
+static void pwrseq_debugfs_seq_show_target(struct seq_file *seq,
+					   struct pwrseq_target *target)
+{
+	seq_printf(seq, "    target: [%s] (target unit: [%s])\n",
+		   target->name, target->unit->name);
+}
+
+static void pwrseq_debugfs_seq_show_unit(struct seq_file *seq,
+					 struct pwrseq_unit *unit)
+{
+	struct pwrseq_unit_dep *ref;
+
+	seq_printf(seq, "    unit: [%s] - enable count: %u\n",
+		   unit->name, unit->enable_count);
+
+	if (list_empty(&unit->deps))
+		return;
+
+	seq_puts(seq, "      dependencies:\n");
+	list_for_each_entry(ref, &unit->deps, list)
+		seq_printf(seq, "        [%s]\n", ref->unit->name);
+}
+
+static int pwrseq_debugfs_seq_show(struct seq_file *seq, void *data)
+{
+	struct device *dev = data;
+	struct pwrseq_device *pwrseq = to_pwrseq_device(dev);
+	struct pwrseq_target *target;
+	struct pwrseq_unit *unit;
+
+	seq_printf(seq, "%s:\n", dev_name(dev));
+
+	seq_puts(seq, "  targets:\n");
+	list_for_each_entry(target, &pwrseq->targets, list)
+		pwrseq_debugfs_seq_show_target(seq, target);
+
+	seq_puts(seq, "  units:\n");
+	list_for_each_entry(unit, &pwrseq->units, list)
+		pwrseq_debugfs_seq_show_unit(seq, unit);
+
+	return 0;
+}
+
+static void pwrseq_debugfs_seq_stop(struct seq_file *seq, void *data)
+{
+	up_read(&pwrseq_sem);
+}
+
+static const struct seq_operations pwrseq_debugfs_sops = {
+	.start = pwrseq_debugfs_seq_start,
+	.next = pwrseq_debugfs_seq_next,
+	.show = pwrseq_debugfs_seq_show,
+	.stop = pwrseq_debugfs_seq_stop,
+};
+DEFINE_SEQ_ATTRIBUTE(pwrseq_debugfs);
+
+static struct dentry *pwrseq_debugfs_dentry;
+
+#endif /* CONFIG_DEBUG_FS */
+
+static int __init pwrseq_init(void)
+{
+	int ret;
+
+	ret = bus_register(&pwrseq_bus);
+	if (ret) {
+		pr_err("Failed to register the power sequencer bus\n");
+		return ret;
+	}
+
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+	pwrseq_debugfs_dentry = debugfs_create_file("pwrseq", 0444, NULL, NULL,
+						    &pwrseq_debugfs_fops);
+#endif  /* CONFIG_DEBUG_FS */
+
+	return 0;
+}
+subsys_initcall(pwrseq_init);
+
+static void __exit pwrseq_exit(void)
+{
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+	debugfs_remove_recursive(pwrseq_debugfs_dentry);
+#endif  /* CONFIG_DEBUG_FS */
+
+	bus_unregister(&pwrseq_bus);
+}
+module_exit(pwrseq_exit);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("Power Sequencing subsystem core");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/pwrseq/consumer.h b/include/linux/pwrseq/consumer.h
new file mode 100644
index 000000000000..7d583b4f266e
--- /dev/null
+++ b/include/linux/pwrseq/consumer.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#ifndef __POWER_SEQUENCING_CONSUMER_H__
+#define __POWER_SEQUENCING_CONSUMER_H__
+
+#include <linux/err.h>
+
+struct device;
+struct pwrseq_desc;
+
+#if IS_ENABLED(CONFIG_POWER_SEQUENCING)
+
+struct pwrseq_desc * __must_check
+pwrseq_get(struct device *dev, const char *target);
+void pwrseq_put(struct pwrseq_desc *desc);
+
+struct pwrseq_desc * __must_check
+devm_pwrseq_get(struct device *dev, const char *target);
+
+int pwrseq_power_on(struct pwrseq_desc *desc);
+int pwrseq_power_off(struct pwrseq_desc *desc);
+
+#else /* CONFIG_POWER_SEQUENCING */
+
+static inline struct pwrseq_desc * __must_check
+pwrseq_get(struct device *dev, const char *target)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void pwrseq_put(struct pwrseq_desc *desc)
+{
+}
+
+static inline struct pwrseq_desc * __must_check
+devm_pwrseq_get(struct device *dev, const char *target)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline int pwrseq_power_on(struct pwrseq_desc *desc)
+{
+	return -ENOSYS;
+}
+
+static inline int pwrseq_power_off(struct pwrseq_desc *desc)
+{
+	return -ENOSYS;
+}
+
+#endif /* CONFIG_POWER_SEQUENCING */
+
+#endif /* __POWER_SEQUENCING_CONSUMER_H__ */
diff --git a/include/linux/pwrseq/provider.h b/include/linux/pwrseq/provider.h
new file mode 100644
index 000000000000..e627ed2f4d91
--- /dev/null
+++ b/include/linux/pwrseq/provider.h
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#ifndef __POWER_SEQUENCING_PROVIDER_H__
+#define __POWER_SEQUENCING_PROVIDER_H__
+
+struct device;
+struct module;
+struct pwrseq_device;
+
+typedef int (*pwrseq_power_state_func)(struct pwrseq_device *);
+typedef int (*pwrseq_match_func)(struct pwrseq_device *, struct device *);
+
+/**
+ * struct pwrseq_unit_data - Configuration of a single power sequencing
+ *                           unit.
+ * @name: Name of the unit.
+ * @deps: Units that must be enabled before this one and disabled after it
+ *        in the order they come in this array.
+ * @enable: Callback running the part of the power-on sequence provided by
+ *          this unit.
+ * @disable: Callback running the part of the power-off sequence provided
+ *           by this unit.
+ */
+struct pwrseq_unit_data {
+	const char *name;
+	const struct pwrseq_unit_data **deps;
+	pwrseq_power_state_func enable;
+	pwrseq_power_state_func disable;
+};
+
+/**
+ * struct pwrseq_target_data - Configuration of a power sequencing target.
+ * @name: Name of the target.
+ * @unit: Final unit that this target must reach in order to be considered
+ *        enabled.
+ * @post_enable: Callback run after the target unit has been enabled, *after*
+ *               the state lock has been released. It's useful for implementing
+ *               boot-up delays without blocking other users from powering up
+ *               using the same power sequencer.
+ */
+struct pwrseq_target_data {
+	const char *name;
+	const struct pwrseq_unit_data *unit;
+	pwrseq_power_state_func post_enable;
+};
+
+/**
+ * struct pwrseq_config - Configuration used for registering a new provider.
+ * @parent: Parent device for the sequencer. Must be set.
+ * @owner: Module providing this device.
+ * @drvdata: Private driver data.
+ * @match: Provider callback used to match the consumer device to the sequencer.
+ * @targets: Array of targets for this power sequencer. Must be NULL-terminated.
+ */
+struct pwrseq_config {
+	struct device *parent;
+	struct module *owner;
+	void *drvdata;
+	pwrseq_match_func match;
+	const struct pwrseq_target_data **targets;
+};
+
+struct pwrseq_device *
+pwrseq_device_register(const struct pwrseq_config *config);
+void pwrseq_device_unregister(struct pwrseq_device *pwrseq);
+struct pwrseq_device *
+devm_pwrseq_device_register(struct device *dev,
+			    const struct pwrseq_config *config);
+
+void *pwrseq_device_get_drvdata(struct pwrseq_device *pwrseq);
+
+#endif /* __POWER_SEQUENCING_PROVIDER_H__ */
-- 
2.40.1

[PATCH v5 16/18] power: pwrseq: add a driver for the QCA6390 PMU module

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

This adds the power sequencing driver for the QCA6390's PMU module. It
uses the pwrseq subsystem and knows how to match the sequencer to the
consumer device by verifying the relevant properties and DT layout.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/power/sequencing/Kconfig          |  16 +
 drivers/power/sequencing/Makefile         |   2 +
 drivers/power/sequencing/pwrseq-qca6390.c | 353 ++++++++++++++++++++++
 3 files changed, 371 insertions(+)
 create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c

diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index ba5732b1dbf8..84ddf3b4ae56 100644
--- a/drivers/power/sequencing/Kconfig
+++ b/drivers/power/sequencing/Kconfig
@@ -10,3 +10,19 @@ menuconfig POWER_SEQUENCING
 	  during power-up.
 
 	  If unsure, say no.
+
+if POWER_SEQUENCING
+
+config POWER_SEQUENCING_QCA6390
+	tristate "QCA6390 PMU driver"
+	default m if ARCH_QCOM
+	help
+	  Say U here to enable the power sequencing driver for Qualcomm
+	  QCA6390.
+
+	  The QCA6390 package contains the BT and WLAN modules whose power
+	  is controlled by the PMU module. As the former two share the power-up
+	  sequence which is executed by the PMU, this driver is needed for
+	  correct power control.
+
+endif
diff --git a/drivers/power/sequencing/Makefile b/drivers/power/sequencing/Makefile
index dcdf8c0c159e..628345c4e7ae 100644
--- a/drivers/power/sequencing/Makefile
+++ b/drivers/power/sequencing/Makefile
@@ -2,3 +2,5 @@
 
 obj-$(CONFIG_POWER_SEQUENCING)		+= pwrseq-core.o
 pwrseq-core-y				:= core.o
+
+obj-$(CONFIG_POWER_SEQUENCING_QCA6390)	+= pwrseq-qca6390.o
diff --git a/drivers/power/sequencing/pwrseq-qca6390.c b/drivers/power/sequencing/pwrseq-qca6390.c
new file mode 100644
index 000000000000..5f254f9c71d7
--- /dev/null
+++ b/drivers/power/sequencing/pwrseq-qca6390.c
@@ -0,0 +1,353 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/jiffies.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/pwrseq/provider.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+struct pwrseq_qca6390_vreg {
+	const char *name;
+	unsigned int load_uA;
+};
+
+struct pwrseq_qca6390_pdata {
+	const struct pwrseq_qca6390_vreg *vregs_common;
+	size_t num_vregs_common;
+	const struct pwrseq_qca6390_vreg *vregs_wlan;
+	size_t num_vregs_wlan;
+	unsigned int pwup_delay_msec;
+};
+
+struct pwrseq_qca6390_ctx {
+	struct pwrseq_device *pwrseq;
+	struct device_node *of_node;
+	const struct pwrseq_qca6390_pdata *pdata;
+	struct regulator_bulk_data *regs_common;
+	struct regulator_bulk_data *regs_wlan;
+	struct gpio_desc *bt_gpio;
+	struct gpio_desc *wlan_gpio;
+	unsigned long last_gpio_enable;
+};
+
+static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_common[] = {
+	{
+		.name = "vddio",
+		.load_uA = 20000,
+	},
+	{
+		.name = "vddaon",
+		.load_uA = 100000,
+	},
+	{
+		.name = "vddpmu",
+		.load_uA = 1250000,
+	},
+	{
+		.name = "vddrfa0p95",
+		.load_uA = 200000,
+	},
+	{
+		.name = "vddrfa1p3",
+		.load_uA = 400000,
+	},
+	{
+		.name = "vddrfa1p9",
+		.load_uA = 400000,
+	},
+};
+
+static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_wlan[] = {
+	{
+		.name = "vddpcie1p3",
+		.load_uA = 35000,
+	},
+	{
+		.name = "vddpcie1p9",
+		.load_uA = 15000,
+	},
+};
+
+static void pwrseq_qca6390_ensure_gpio_delay(struct pwrseq_qca6390_ctx *ctx)
+{
+	unsigned long diff_jiffies = jiffies - ctx->last_gpio_enable;
+	unsigned int diff_msecs = jiffies_to_msecs(diff_jiffies);
+
+	if (diff_msecs < 100)
+		msleep(100 - diff_msecs);
+}
+
+static const struct pwrseq_qca6390_pdata pwrseq_qca6390_of_data = {
+	.vregs_common = pwrseq_qca6390_vregs_common,
+	.num_vregs_common = ARRAY_SIZE(pwrseq_qca6390_vregs_common),
+	.vregs_wlan = pwrseq_qca6390_vregs_wlan,
+	.num_vregs_wlan = ARRAY_SIZE(pwrseq_qca6390_vregs_wlan),
+	.pwup_delay_msec = 16,
+};
+
+static int pwrseq_qca6390_vregs_enable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	return regulator_bulk_enable(ctx->pdata->num_vregs_common,
+				     ctx->regs_common);
+}
+
+static int pwrseq_qca6390_vregs_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	return regulator_bulk_disable(ctx->pdata->num_vregs_common,
+				      ctx->regs_common);
+}
+
+static const struct pwrseq_unit_data pwrseq_qca6390_vregs_unit_data = {
+	.name = "regulators-enable",
+	.enable = pwrseq_qca6390_vregs_enable,
+	.disable = pwrseq_qca6390_vregs_disable,
+};
+
+static const struct pwrseq_unit_data *pwrseq_qca6390_unit_deps[] = {
+	&pwrseq_qca6390_vregs_unit_data,
+	NULL
+};
+
+static int pwrseq_qca6390_bt_enable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	pwrseq_qca6390_ensure_gpio_delay(ctx);
+	gpiod_set_value_cansleep(ctx->bt_gpio, 1);
+	ctx->last_gpio_enable = jiffies;
+
+	return 0;
+}
+
+static int pwrseq_qca6390_bt_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	gpiod_set_value_cansleep(ctx->bt_gpio, 0);
+
+	return 0;
+}
+
+static const struct pwrseq_unit_data pwrseq_qca6390_bt_unit_data = {
+	.name = "bluetooth-enable",
+	.deps = pwrseq_qca6390_unit_deps,
+	.enable = pwrseq_qca6390_bt_enable,
+	.disable = pwrseq_qca6390_bt_disable,
+};
+
+static int pwrseq_qca6390_wlan_enable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+	int ret;
+
+	ret = regulator_bulk_enable(ctx->pdata->num_vregs_wlan, ctx->regs_wlan);
+	if (ret)
+		return ret;
+
+	pwrseq_qca6390_ensure_gpio_delay(ctx);
+	gpiod_set_value_cansleep(ctx->wlan_gpio, 1);
+	ctx->last_gpio_enable = jiffies;
+
+	return 0;
+}
+
+static int pwrseq_qca6390_wlan_disable(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	gpiod_set_value_cansleep(ctx->wlan_gpio, 0);
+
+	return regulator_bulk_disable(ctx->pdata->num_vregs_wlan,
+				      ctx->regs_wlan);
+}
+
+static const struct pwrseq_unit_data pwrseq_qca6390_wlan_unit_data = {
+	.name = "wlan-enable",
+	.deps = pwrseq_qca6390_unit_deps,
+	.enable = pwrseq_qca6390_wlan_enable,
+	.disable = pwrseq_qca6390_wlan_disable,
+};
+
+static int pwrseq_qca6390_pwup_delay(struct pwrseq_device *pwrseq)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+	if (ctx->pdata->pwup_delay_msec)
+		msleep(ctx->pdata->pwup_delay_msec);
+
+	return 0;
+}
+
+static const struct pwrseq_target_data pwrseq_qca6390_bt_target_data = {
+	.name = "bluetooth",
+	.unit = &pwrseq_qca6390_bt_unit_data,
+	.post_enable = pwrseq_qca6390_pwup_delay,
+};
+
+static const struct pwrseq_target_data pwrseq_qca6390_wlan_target_data = {
+	.name = "wlan",
+	.unit = &pwrseq_qca6390_wlan_unit_data,
+	.post_enable = pwrseq_qca6390_pwup_delay,
+};
+
+static const struct pwrseq_target_data *pwrseq_qca6390_targets[] = {
+	&pwrseq_qca6390_bt_target_data,
+	&pwrseq_qca6390_wlan_target_data,
+	NULL
+};
+
+static int pwrseq_qca6390_match(struct pwrseq_device *pwrseq,
+				struct device *dev)
+{
+	struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+	struct device_node *dev_node = dev->of_node;
+
+	/*
+	 * The PMU supplies power to the Bluetooth and WLAN modules. both
+	 * consume the PMU AON output so check the presence of the
+	 * 'vddaon-supply' property and whether it leads us to the right
+	 * device.
+	 */
+	if (!of_property_present(dev_node, "vddaon-supply"))
+		return 0;
+
+	struct device_node *reg_node __free(device_node) =
+			of_parse_phandle(dev_node, "vddaon-supply", 0);
+	if (!reg_node)
+		return 0;
+
+	/*
+	 * `reg_node` is the PMU AON regulator, its parent is the `regulators`
+	 * node and finally its grandparent is the PMU device node that we're
+	 * looking for.
+	 */
+	if (!reg_node->parent || !reg_node->parent->parent ||
+	    reg_node->parent->parent != ctx->of_node)
+		return 0;
+
+	return 1;
+}
+
+static struct regulator_bulk_data *
+pwrseq_qca6390_get_regs(struct device *dev, size_t num_regs,
+			const struct pwrseq_qca6390_vreg *pdata)
+{
+	struct regulator_bulk_data *regs;
+	int ret, i;
+
+	regs = devm_kcalloc(dev, num_regs, sizeof(*regs), GFP_KERNEL);
+	if (!regs)
+		return ERR_PTR(-ENOMEM);
+
+	for (i = 0; i < num_regs; i++)
+		regs[i].supply = pdata[i].name;
+
+	ret = devm_regulator_bulk_get(dev, num_regs, regs);
+	if (ret < 0)
+		return ERR_PTR(ret);
+
+	for (i = 0; i < num_regs; i++) {
+		if (!pdata[i].load_uA)
+			continue;
+
+		ret = regulator_set_load(regs[i].consumer, pdata[i].load_uA);
+		if (ret)
+			return ERR_PTR(ret);
+	}
+
+	return regs;
+}
+
+static int pwrseq_qca6390_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct pwrseq_qca6390_ctx *ctx;
+	struct pwrseq_config config;
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->of_node = dev->of_node;
+
+	ctx->pdata = of_device_get_match_data(dev);
+	if (!ctx->pdata)
+		return dev_err_probe(dev, -ENODEV,
+				     "Failed to obtain platform data\n");
+
+	ctx->regs_common = pwrseq_qca6390_get_regs(dev,
+						   ctx->pdata->num_vregs_common,
+						   ctx->pdata->vregs_common);
+	if (IS_ERR(ctx->regs_common))
+		return dev_err_probe(dev, PTR_ERR(ctx->regs_common),
+				     "Failed to get all regulators\n");
+
+	ctx->regs_wlan = pwrseq_qca6390_get_regs(dev,
+						 ctx->pdata->num_vregs_wlan,
+						 ctx->pdata->vregs_wlan);
+	if (IS_ERR(ctx->regs_wlan))
+		return dev_err_probe(dev, PTR_ERR(ctx->regs_wlan),
+				     "Failed to get all regulators\n");
+
+	ctx->bt_gpio = devm_gpiod_get_optional(dev, "bt-enable", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->bt_gpio))
+		return dev_err_probe(dev, PTR_ERR(ctx->bt_gpio),
+				     "Failed to get the Bluetooth enable GPIO\n");
+
+	ctx->wlan_gpio = devm_gpiod_get_optional(dev, "wlan-enable",
+						 GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->wlan_gpio))
+		return dev_err_probe(dev, PTR_ERR(ctx->wlan_gpio),
+				     "Failed to get the WLAN enable GPIO\n");
+
+	memset(&config, 0, sizeof(config));
+
+	config.parent = dev;
+	config.owner = THIS_MODULE;
+	config.drvdata = ctx;
+	config.match = pwrseq_qca6390_match;
+	config.targets = pwrseq_qca6390_targets;
+
+	ctx->pwrseq = devm_pwrseq_device_register(dev, &config);
+	if (IS_ERR(ctx->pwrseq))
+		return dev_err_probe(dev, PTR_ERR(ctx->pwrseq),
+				     "Failed to register the power sequencer\n");
+
+	return 0;
+}
+
+static const struct of_device_id pwrseq_qca6390_of_match[] = {
+	{
+		.compatible = "qcom,qca6390-pmu",
+		.data = &pwrseq_qca6390_of_data,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, pwrseq_qca6390_of_match);
+
+static struct platform_driver pwrseq_qca6390_driver = {
+	.driver = {
+		.name = "pwrseq-qca6390",
+		.of_match_table = pwrseq_qca6390_of_match,
+	},
+	.probe = pwrseq_qca6390_probe,
+};
+module_platform_driver(pwrseq_qca6390_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("QCA6390 PMU power sequencing driver");
+MODULE_LICENSE("GPL");
-- 
2.40.1

[PATCH v5 17/18] Bluetooth: qca: use the power sequencer for QCA6390

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Use the pwrseq subsystem's consumer API to run the power-up sequence for
the Bluetooth module of the QCA6390 package.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/bluetooth/hci_qca.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index edd2a81b4d5e..6e747db30492 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -29,6 +29,7 @@
 #include <linux/of.h>
 #include <linux/acpi.h>
 #include <linux/platform_device.h>
+#include <linux/pwrseq/consumer.h>
 #include <linux/regulator/consumer.h>
 #include <linux/serdev.h>
 #include <linux/mutex.h>
@@ -215,6 +216,7 @@ struct qca_power {
 	struct regulator_bulk_data *vreg_bulk;
 	int num_vregs;
 	bool vregs_on;
+	struct pwrseq_desc *pwrseq;
 };
 
 struct qca_serdev {
@@ -1792,6 +1794,11 @@ static int qca_power_on(struct hci_dev *hdev)
 		ret = qca_regulator_init(hu);
 		break;
 
+	case QCA_QCA6390:
+		qcadev = serdev_device_get_drvdata(hu->serdev);
+		ret = pwrseq_power_on(qcadev->bt_power->pwrseq);
+		break;
+
 	default:
 		qcadev = serdev_device_get_drvdata(hu->serdev);
 		if (qcadev->bt_en) {
@@ -2170,6 +2177,10 @@ static void qca_power_shutdown(struct hci_uart *hu)
 		}
 		break;
 
+	case QCA_QCA6390:
+		pwrseq_power_off(qcadev->bt_power->pwrseq);
+		break;
+
 	default:
 		gpiod_set_value_cansleep(qcadev->bt_en, 0);
 	}
@@ -2308,12 +2319,25 @@ static int qca_serdev_probe(struct serdev_device *serdev)
 	case QCA_WCN6750:
 	case QCA_WCN6855:
 	case QCA_WCN7850:
+	case QCA_QCA6390:
 		qcadev->bt_power = devm_kzalloc(&serdev->dev,
 						sizeof(struct qca_power),
 						GFP_KERNEL);
 		if (!qcadev->bt_power)
 			return -ENOMEM;
+		break;
+	default:
+		break;
+	}
 
+	switch (qcadev->btsoc_type) {
+	case QCA_WCN3988:
+	case QCA_WCN3990:
+	case QCA_WCN3991:
+	case QCA_WCN3998:
+	case QCA_WCN6750:
+	case QCA_WCN6855:
+	case QCA_WCN7850:
 		qcadev->bt_power->dev = &serdev->dev;
 		err = qca_init_regulators(qcadev->bt_power, data->vregs,
 					  data->num_vregs);
@@ -2354,6 +2378,13 @@ static int qca_serdev_probe(struct serdev_device *serdev)
 		}
 		break;
 
+	case QCA_QCA6390:
+		qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->dev,
+							   "bluetooth");
+		if (IS_ERR(qcadev->bt_power->pwrseq))
+			return PTR_ERR(qcadev->bt_power->pwrseq);
+		fallthrough;
+
 	default:
 		qcadev->bt_en = devm_gpiod_get_optional(&serdev->dev, "enable",
 					       GPIOD_OUT_LOW);
-- 
2.40.1

[PATCH v5 18/18] PCI/pwrctl: add a PCI power control driver for power sequenced devices

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a PCI power control driver that's capable of correctly powering up
devices using the power sequencing subsystem. The first user of this
driver is the ath11k module on QCA6390.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/pci/pwrctl/Kconfig             |  9 +++
 drivers/pci/pwrctl/Makefile            |  1 +
 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c | 84 ++++++++++++++++++++++++++
 3 files changed, 94 insertions(+)
 create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c

diff --git a/drivers/pci/pwrctl/Kconfig b/drivers/pci/pwrctl/Kconfig
index b91170ebfb49..3880a88aa73b 100644
--- a/drivers/pci/pwrctl/Kconfig
+++ b/drivers/pci/pwrctl/Kconfig
@@ -5,6 +5,15 @@ menu "PCI Power control drivers"
 config PCI_PWRCTL
 	tristate
 
+config PCI_PWRCTL_PWRSEQ
+	tristate "PCI Power Control driver using the Power Sequencing subsystem"
+	select POWER_SEQUENCING
+	select PCI_PWRCTL
+	default m if (ATH11K_PCI && ARCH_QCOM)
+	help
+	  Enable support for the PCI power control driver for device
+	  drivers using the Power Sequencing subsystem.
+
 config PCI_PWRCTL_WCN7850
 	tristate "PCI Power Control driver for WCN7850"
 	select PCI_PWRCTL
diff --git a/drivers/pci/pwrctl/Makefile b/drivers/pci/pwrctl/Makefile
index de20c3af1b78..47ab9db1fb42 100644
--- a/drivers/pci/pwrctl/Makefile
+++ b/drivers/pci/pwrctl/Makefile
@@ -3,4 +3,5 @@
 obj-$(CONFIG_PCI_PWRCTL)		+= pci-pwrctl-core.o
 pci-pwrctl-core-y			:= core.o
 
+obj-$(CONFIG_PCI_PWRCTL_PWRSEQ)		+= pci-pwrctl-pwrseq.o
 obj-$(CONFIG_PCI_PWRCTL_WCN7850)	+= pci-pwrctl-wcn7850.o
diff --git a/drivers/pci/pwrctl/pci-pwrctl-pwrseq.c b/drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
new file mode 100644
index 000000000000..43820a727b3f
--- /dev/null
+++ b/drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 Linaro Ltd.
+ */
+
+#include <linux/device.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pci-pwrctl.h>
+#include <linux/platform_device.h>
+#include <linux/pwrseq/consumer.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+struct pci_pwrctl_pwrseq_data {
+	struct pci_pwrctl ctx;
+	struct pwrseq_desc *pwrseq;
+};
+
+static void devm_pci_pwrctl_pwrseq_power_off(void *data)
+{
+	struct pwrseq_desc *pwrseq = data;
+
+	pwrseq_power_off(pwrseq);
+}
+
+static int pci_pwrctl_pwrseq_probe(struct platform_device *pdev)
+{
+	struct pci_pwrctl_pwrseq_data *data;
+	struct device *dev = &pdev->dev;
+	int ret;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->pwrseq = devm_pwrseq_get(dev, of_device_get_match_data(dev));
+	if (IS_ERR(data->pwrseq))
+		return dev_err_probe(dev, PTR_ERR(data->pwrseq),
+				     "Failed to get the power sequencer\n");
+
+	ret = pwrseq_power_on(data->pwrseq);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to power-on the device\n");
+
+	ret = devm_add_action_or_reset(dev, devm_pci_pwrctl_pwrseq_power_off,
+				       data->pwrseq);
+	if (ret)
+		return ret;
+
+	data->ctx.dev = dev;
+
+	ret = devm_pci_pwrctl_device_set_ready(dev, &data->ctx);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "Failed to register the pwrctl wrapper\n");
+
+	return 0;
+}
+
+static const struct of_device_id pci_pwrctl_pwrseq_of_match[] = {
+	{
+		/* ATH11K in QCA6390 package. */
+		.compatible = "pci17cb,1101",
+		.data = "wlan",
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, pci_pwrctl_pwrseq_of_match);
+
+static struct platform_driver pci_pwrctl_pwrseq_driver = {
+	.driver = {
+		.name = "pci-pwrctl-pwrseq",
+		.of_match_table = pci_pwrctl_pwrseq_of_match,
+	},
+	.probe = pci_pwrctl_pwrseq_probe,
+};
+module_platform_driver(pci_pwrctl_pwrseq_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
+MODULE_DESCRIPTION("Generic PCI Power Control module for power sequenced devices");
+MODULE_LICENSE("GPL");
-- 
2.40.1

Re: [PATCH v5 08/18] arm64: dts: qcom: sm8650-qrd: add the Wifi node

[Dmitry Baryshkov]

On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Neil Armstrong <neil.armstrong@linaro.org>
>
> Describe the ath12k WLAN on-board the WCN7850 module present on the
> board.

WCN7850 is the same combo WiFi + BT chip. Is there any reason for
describing its parts separately rather than using the same PMU
approach?

>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> [Bartosz:
>   - move the pcieport0 node into the .dtsi
>   - make regulator naming consistent with existing DT code
>   - add commit message]
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 29 +++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8650.dtsi    | 10 +++++++++
>  2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> index b07cac2e5bc8..4623c358f634 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> @@ -845,6 +845,28 @@ &pcie0 {
>         status = "okay";
>  };
>
> +&pcieport0 {
> +       wifi@0 {
> +               compatible = "pci17cb,1107";
> +               reg = <0x10000 0x0 0x0 0x0 0x0>;
> +
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&wlan_en>;
> +
> +               enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
> +
> +               vdd-supply = <&vreg_s4i_0p85>;
> +               vddio-supply = <&vreg_l15b_1p8>;
> +               vddio1p2-supply = <&vreg_l3c_1p2>;
> +               vddaon-supply = <&vreg_s2c_0p8>;
> +               vdddig-supply = <&vreg_s3c_0p9>;
> +               vddrfa1p2-supply = <&vreg_s1c_1p2>;
> +               vddrfa1p8-supply = <&vreg_s6c_1p8>;
> +
> +               clocks = <&rpmhcc RPMH_RF_CLK1>;
> +       };
> +};
> +
>  &pcie0_phy {
>         vdda-phy-supply = <&vreg_l1i_0p88>;
>         vdda-pll-supply = <&vreg_l3i_1p2>;
> @@ -1139,6 +1161,13 @@ wcd_default: wcd-reset-n-active-state {
>                 bias-disable;
>                 output-low;
>         };
> +
> +       wlan_en: wlan-en-state {
> +               pins = "gpio16";
> +               function = "gpio";
> +               drive-strength = <8>;
> +               bias-pull-down;
> +       };
>  };
>
>  &uart14 {
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index d488b3b3265e..baf4932e460c 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -2293,6 +2293,16 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>                         dma-coherent;
>
>                         status = "disabled";
> +
> +                       pcieport0: pcie@0 {
> +                               device_type = "pci";
> +                               reg = <0x0 0x0 0x0 0x0 0x0>;
> +                               #address-cells = <3>;
> +                               #size-cells = <2>;
> +                               ranges;
> +
> +                               bus-range = <0x01 0xff>;
> +                       };
>                 };
>
>                 pcie0_phy: phy@1c06000 {
> --
> 2.40.1
>


-- 
With best wishes
Dmitry

Re: [PATCH v5 16/18] power: pwrseq: add a driver for the QCA6390 PMU module

[Dmitry Baryshkov]

On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> This adds the power sequencing driver for the QCA6390's PMU module. It
> uses the pwrseq subsystem and knows how to match the sequencer to the
> consumer device by verifying the relevant properties and DT layout.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  drivers/power/sequencing/Kconfig          |  16 +
>  drivers/power/sequencing/Makefile         |   2 +
>  drivers/power/sequencing/pwrseq-qca6390.c | 353 ++++++++++++++++++++++
>  3 files changed, 371 insertions(+)
>  create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
>
> diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
> index ba5732b1dbf8..84ddf3b4ae56 100644
> --- a/drivers/power/sequencing/Kconfig
> +++ b/drivers/power/sequencing/Kconfig
> @@ -10,3 +10,19 @@ menuconfig POWER_SEQUENCING
>           during power-up.
>
>           If unsure, say no.
> +
> +if POWER_SEQUENCING
> +
> +config POWER_SEQUENCING_QCA6390
> +       tristate "QCA6390 PMU driver"
> +       default m if ARCH_QCOM
> +       help
> +         Say U here to enable the power sequencing driver for Qualcomm
> +         QCA6390.
> +
> +         The QCA6390 package contains the BT and WLAN modules whose power
> +         is controlled by the PMU module. As the former two share the power-up
> +         sequence which is executed by the PMU, this driver is needed for
> +         correct power control.
> +
> +endif
> diff --git a/drivers/power/sequencing/Makefile b/drivers/power/sequencing/Makefile
> index dcdf8c0c159e..628345c4e7ae 100644
> --- a/drivers/power/sequencing/Makefile
> +++ b/drivers/power/sequencing/Makefile
> @@ -2,3 +2,5 @@
>
>  obj-$(CONFIG_POWER_SEQUENCING)         += pwrseq-core.o
>  pwrseq-core-y                          := core.o
> +
> +obj-$(CONFIG_POWER_SEQUENCING_QCA6390) += pwrseq-qca6390.o
> diff --git a/drivers/power/sequencing/pwrseq-qca6390.c b/drivers/power/sequencing/pwrseq-qca6390.c
> new file mode 100644
> index 000000000000..5f254f9c71d7
> --- /dev/null
> +++ b/drivers/power/sequencing/pwrseq-qca6390.c
> @@ -0,0 +1,353 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2024 Linaro Ltd.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/jiffies.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/pwrseq/provider.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +struct pwrseq_qca6390_vreg {
> +       const char *name;
> +       unsigned int load_uA;
> +};
> +
> +struct pwrseq_qca6390_pdata {
> +       const struct pwrseq_qca6390_vreg *vregs_common;
> +       size_t num_vregs_common;
> +       const struct pwrseq_qca6390_vreg *vregs_wlan;
> +       size_t num_vregs_wlan;
> +       unsigned int pwup_delay_msec;
> +};
> +
> +struct pwrseq_qca6390_ctx {
> +       struct pwrseq_device *pwrseq;
> +       struct device_node *of_node;
> +       const struct pwrseq_qca6390_pdata *pdata;
> +       struct regulator_bulk_data *regs_common;
> +       struct regulator_bulk_data *regs_wlan;
> +       struct gpio_desc *bt_gpio;
> +       struct gpio_desc *wlan_gpio;
> +       unsigned long last_gpio_enable;
> +};
> +
> +static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_common[] = {
> +       {
> +               .name = "vddio",
> +               .load_uA = 20000,
> +       },
> +       {
> +               .name = "vddaon",
> +               .load_uA = 100000,
> +       },
> +       {
> +               .name = "vddpmu",
> +               .load_uA = 1250000,
> +       },
> +       {
> +               .name = "vddrfa0p95",
> +               .load_uA = 200000,
> +       },
> +       {
> +               .name = "vddrfa1p3",
> +               .load_uA = 400000,
> +       },
> +       {
> +               .name = "vddrfa1p9",
> +               .load_uA = 400000,
> +       },
> +};
> +
> +static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_wlan[] = {
> +       {
> +               .name = "vddpcie1p3",
> +               .load_uA = 35000,
> +       },
> +       {
> +               .name = "vddpcie1p9",
> +               .load_uA = 15000,
> +       },
> +};

I thought that we had discussed this already. According to the docs,
all PMU supplies should be powered on when the chip is being switched
on, no matter whether it is for the WiFi or for the BT.

> +
> +static void pwrseq_qca6390_ensure_gpio_delay(struct pwrseq_qca6390_ctx *ctx)
> +{
> +       unsigned long diff_jiffies = jiffies - ctx->last_gpio_enable;
> +       unsigned int diff_msecs = jiffies_to_msecs(diff_jiffies);
> +
> +       if (diff_msecs < 100)
> +               msleep(100 - diff_msecs);
> +}
> +
> +static const struct pwrseq_qca6390_pdata pwrseq_qca6390_of_data = {
> +       .vregs_common = pwrseq_qca6390_vregs_common,
> +       .num_vregs_common = ARRAY_SIZE(pwrseq_qca6390_vregs_common),
> +       .vregs_wlan = pwrseq_qca6390_vregs_wlan,
> +       .num_vregs_wlan = ARRAY_SIZE(pwrseq_qca6390_vregs_wlan),
> +       .pwup_delay_msec = 16,
> +};
> +
> +static int pwrseq_qca6390_vregs_enable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       return regulator_bulk_enable(ctx->pdata->num_vregs_common,
> +                                    ctx->regs_common);
> +}
> +
> +static int pwrseq_qca6390_vregs_disable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       return regulator_bulk_disable(ctx->pdata->num_vregs_common,
> +                                     ctx->regs_common);
> +}
> +
> +static const struct pwrseq_unit_data pwrseq_qca6390_vregs_unit_data = {
> +       .name = "regulators-enable",
> +       .enable = pwrseq_qca6390_vregs_enable,
> +       .disable = pwrseq_qca6390_vregs_disable,
> +};
> +
> +static const struct pwrseq_unit_data *pwrseq_qca6390_unit_deps[] = {
> +       &pwrseq_qca6390_vregs_unit_data,
> +       NULL
> +};
> +
> +static int pwrseq_qca6390_bt_enable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       pwrseq_qca6390_ensure_gpio_delay(ctx);
> +       gpiod_set_value_cansleep(ctx->bt_gpio, 1);
> +       ctx->last_gpio_enable = jiffies;
> +
> +       return 0;
> +}
> +
> +static int pwrseq_qca6390_bt_disable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       gpiod_set_value_cansleep(ctx->bt_gpio, 0);
> +
> +       return 0;
> +}
> +
> +static const struct pwrseq_unit_data pwrseq_qca6390_bt_unit_data = {
> +       .name = "bluetooth-enable",
> +       .deps = pwrseq_qca6390_unit_deps,

Can we call corresponding regulator_bulk functions from bt and wlan
enable/disable? This will save us from building the tree-like
structures (and possible loops inside that tree).

> +       .enable = pwrseq_qca6390_bt_enable,
> +       .disable = pwrseq_qca6390_bt_disable,
> +};
> +
> +static int pwrseq_qca6390_wlan_enable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +       int ret;
> +
> +       ret = regulator_bulk_enable(ctx->pdata->num_vregs_wlan, ctx->regs_wlan);
> +       if (ret)
> +               return ret;
> +
> +       pwrseq_qca6390_ensure_gpio_delay(ctx);
> +       gpiod_set_value_cansleep(ctx->wlan_gpio, 1);
> +       ctx->last_gpio_enable = jiffies;
> +
> +       return 0;
> +}
> +
> +static int pwrseq_qca6390_wlan_disable(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       gpiod_set_value_cansleep(ctx->wlan_gpio, 0);
> +
> +       return regulator_bulk_disable(ctx->pdata->num_vregs_wlan,
> +                                     ctx->regs_wlan);
> +}
> +
> +static const struct pwrseq_unit_data pwrseq_qca6390_wlan_unit_data = {
> +       .name = "wlan-enable",
> +       .deps = pwrseq_qca6390_unit_deps,
> +       .enable = pwrseq_qca6390_wlan_enable,
> +       .disable = pwrseq_qca6390_wlan_disable,
> +};
> +
> +static int pwrseq_qca6390_pwup_delay(struct pwrseq_device *pwrseq)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +
> +       if (ctx->pdata->pwup_delay_msec)
> +               msleep(ctx->pdata->pwup_delay_msec);
> +
> +       return 0;
> +}
> +
> +static const struct pwrseq_target_data pwrseq_qca6390_bt_target_data = {
> +       .name = "bluetooth",
> +       .unit = &pwrseq_qca6390_bt_unit_data,
> +       .post_enable = pwrseq_qca6390_pwup_delay,
> +};
> +
> +static const struct pwrseq_target_data pwrseq_qca6390_wlan_target_data = {
> +       .name = "wlan",
> +       .unit = &pwrseq_qca6390_wlan_unit_data,
> +       .post_enable = pwrseq_qca6390_pwup_delay,
> +};
> +
> +static const struct pwrseq_target_data *pwrseq_qca6390_targets[] = {
> +       &pwrseq_qca6390_bt_target_data,
> +       &pwrseq_qca6390_wlan_target_data,
> +       NULL
> +};
> +
> +static int pwrseq_qca6390_match(struct pwrseq_device *pwrseq,
> +                               struct device *dev)
> +{
> +       struct pwrseq_qca6390_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
> +       struct device_node *dev_node = dev->of_node;
> +
> +       /*
> +        * The PMU supplies power to the Bluetooth and WLAN modules. both
> +        * consume the PMU AON output so check the presence of the
> +        * 'vddaon-supply' property and whether it leads us to the right
> +        * device.
> +        */
> +       if (!of_property_present(dev_node, "vddaon-supply"))
> +               return 0;
> +
> +       struct device_node *reg_node __free(device_node) =
> +                       of_parse_phandle(dev_node, "vddaon-supply", 0);
> +       if (!reg_node)
> +               return 0;
> +
> +       /*
> +        * `reg_node` is the PMU AON regulator, its parent is the `regulators`
> +        * node and finally its grandparent is the PMU device node that we're
> +        * looking for.
> +        */
> +       if (!reg_node->parent || !reg_node->parent->parent ||
> +           reg_node->parent->parent != ctx->of_node)
> +               return 0;
> +
> +       return 1;
> +}
> +
> +static struct regulator_bulk_data *
> +pwrseq_qca6390_get_regs(struct device *dev, size_t num_regs,
> +                       const struct pwrseq_qca6390_vreg *pdata)
> +{
> +       struct regulator_bulk_data *regs;
> +       int ret, i;
> +
> +       regs = devm_kcalloc(dev, num_regs, sizeof(*regs), GFP_KERNEL);
> +       if (!regs)
> +               return ERR_PTR(-ENOMEM);
> +
> +       for (i = 0; i < num_regs; i++)
> +               regs[i].supply = pdata[i].name;
> +
> +       ret = devm_regulator_bulk_get(dev, num_regs, regs);
> +       if (ret < 0)
> +               return ERR_PTR(ret);
> +
> +       for (i = 0; i < num_regs; i++) {
> +               if (!pdata[i].load_uA)
> +                       continue;
> +
> +               ret = regulator_set_load(regs[i].consumer, pdata[i].load_uA);
> +               if (ret)
> +                       return ERR_PTR(ret);
> +       }
> +
> +       return regs;
> +}
> +
> +static int pwrseq_qca6390_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct pwrseq_qca6390_ctx *ctx;
> +       struct pwrseq_config config;
> +
> +       ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +       if (!ctx)
> +               return -ENOMEM;
> +
> +       ctx->of_node = dev->of_node;
> +
> +       ctx->pdata = of_device_get_match_data(dev);
> +       if (!ctx->pdata)
> +               return dev_err_probe(dev, -ENODEV,
> +                                    "Failed to obtain platform data\n");
> +
> +       ctx->regs_common = pwrseq_qca6390_get_regs(dev,
> +                                                  ctx->pdata->num_vregs_common,
> +                                                  ctx->pdata->vregs_common);
> +       if (IS_ERR(ctx->regs_common))
> +               return dev_err_probe(dev, PTR_ERR(ctx->regs_common),
> +                                    "Failed to get all regulators\n");
> +
> +       ctx->regs_wlan = pwrseq_qca6390_get_regs(dev,
> +                                                ctx->pdata->num_vregs_wlan,
> +                                                ctx->pdata->vregs_wlan);
> +       if (IS_ERR(ctx->regs_wlan))
> +               return dev_err_probe(dev, PTR_ERR(ctx->regs_wlan),
> +                                    "Failed to get all regulators\n");
> +
> +       ctx->bt_gpio = devm_gpiod_get_optional(dev, "bt-enable", GPIOD_OUT_LOW);
> +       if (IS_ERR(ctx->bt_gpio))
> +               return dev_err_probe(dev, PTR_ERR(ctx->bt_gpio),
> +                                    "Failed to get the Bluetooth enable GPIO\n");
> +
> +       ctx->wlan_gpio = devm_gpiod_get_optional(dev, "wlan-enable",
> +                                                GPIOD_OUT_LOW);
> +       if (IS_ERR(ctx->wlan_gpio))
> +               return dev_err_probe(dev, PTR_ERR(ctx->wlan_gpio),
> +                                    "Failed to get the WLAN enable GPIO\n");
> +
> +       memset(&config, 0, sizeof(config));
> +
> +       config.parent = dev;
> +       config.owner = THIS_MODULE;
> +       config.drvdata = ctx;
> +       config.match = pwrseq_qca6390_match;
> +       config.targets = pwrseq_qca6390_targets;
> +
> +       ctx->pwrseq = devm_pwrseq_device_register(dev, &config);
> +       if (IS_ERR(ctx->pwrseq))
> +               return dev_err_probe(dev, PTR_ERR(ctx->pwrseq),
> +                                    "Failed to register the power sequencer\n");
> +
> +       return 0;
> +}
> +
> +static const struct of_device_id pwrseq_qca6390_of_match[] = {
> +       {
> +               .compatible = "qcom,qca6390-pmu",
> +               .data = &pwrseq_qca6390_of_data,
> +       },
> +       { }
> +};
> +MODULE_DEVICE_TABLE(of, pwrseq_qca6390_of_match);
> +
> +static struct platform_driver pwrseq_qca6390_driver = {
> +       .driver = {
> +               .name = "pwrseq-qca6390",
> +               .of_match_table = pwrseq_qca6390_of_match,
> +       },
> +       .probe = pwrseq_qca6390_probe,
> +};
> +module_platform_driver(pwrseq_qca6390_driver);
> +
> +MODULE_AUTHOR("Bartosz Golaszewski <bartosz.golaszewski@linaro.org>");
> +MODULE_DESCRIPTION("QCA6390 PMU power sequencing driver");
> +MODULE_LICENSE("GPL");
> --
> 2.40.1
>


-- 
With best wishes
Dmitry

Re: [PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module

[Kalle Valo]

Bartosz Golaszewski <brgl@bgdev.pl> writes:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Add device-tree bindings for the ATH12K module found in the WCN7850
> package.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  .../net/wireless/qcom,ath12k-pci.yaml         | 103 ++++++++++++++++++
>  1 file changed, 103 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> new file mode 100644
> index 000000000000..063c576b99a0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2024 Linaro Limited
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-pci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies ath12k wireless devices (PCIe)
> +
> +maintainers:
> +  - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Jeff and me are the ath12k driver maintainers so shouldn't we listed
here as well?

Jeff, this reminds me that we should add you to qcom,ath10k.yaml,
qcom,ath11k-pci.yaml and qcom,ath11k.yaml as maintainer.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Fri, Feb 16, 2024 at 09:32:00PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. This document describes this module.

Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module

[Bartosz Golaszewski]

On Sat, Feb 17, 2024 at 7:35 AM Kalle Valo <kvalo@kernel.org> wrote:
>
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Add device-tree bindings for the ATH12K module found in the WCN7850
> > package.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> >  .../net/wireless/qcom,ath12k-pci.yaml         | 103 ++++++++++++++++++
> >  1 file changed, 103 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> > new file mode 100644
> > index 000000000000..063c576b99a0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> > @@ -0,0 +1,103 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (c) 2024 Linaro Limited
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-pci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm Technologies ath12k wireless devices (PCIe)
> > +
> > +maintainers:
> > +  - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Jeff and me are the ath12k driver maintainers so shouldn't we listed
> here as well?
>

Sure will do. I also noticed the subject is wrong, should have been
"net" not "new".

Also, Jeff is not showing up for ath12k bindings in get_maintainer.pl.
You could consider adding an N: ath12k entry to MAINTAINERS.

Bartosz

> Jeff, this reminds me that we should add you to qcom,ath10k.yaml,
> qcom,ath11k-pci.yaml and qcom,ath11k.yaml as maintainer.
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Bartosz Golaszewski]

On Sat, Feb 17, 2024 at 4:48 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Feb 16, 2024 at 09:32:00PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> > are powered by the Power Management Unit (PMU) that takes inputs from the
> > host and provides LDO outputs. This document describes this module.
>
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.

Mark,

This is quite vague, could you elaborate? I have no idea what is wrong
with this patch.

Bartosz

Re: [PATCH v5 08/18] arm64: dts: qcom: sm8650-qrd: add the Wifi node

[Bartosz Golaszewski]

On Sat, Feb 17, 2024 at 12:10 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Neil Armstrong <neil.armstrong@linaro.org>
> >
> > Describe the ath12k WLAN on-board the WCN7850 module present on the
> > board.
>
> WCN7850 is the same combo WiFi + BT chip. Is there any reason for
> describing its parts separately rather than using the same PMU
> approach?
>

Yes, I explained the rationale in the cover letter in detail in the
section describing the DTS changes for the series.

Bart

[snip]

Re: [PATCH v5 16/18] power: pwrseq: add a driver for the QCA6390 PMU module

[Bartosz Golaszewski]

On Sat, Feb 17, 2024 at 12:17 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > This adds the power sequencing driver for the QCA6390's PMU module. It
> > uses the pwrseq subsystem and knows how to match the sequencer to the
> > consumer device by verifying the relevant properties and DT layout.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---

[snip]

> > +
> > +static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_common[] = {
> > +       {
> > +               .name = "vddio",
> > +               .load_uA = 20000,
> > +       },
> > +       {
> > +               .name = "vddaon",
> > +               .load_uA = 100000,
> > +       },
> > +       {
> > +               .name = "vddpmu",
> > +               .load_uA = 1250000,
> > +       },
> > +       {
> > +               .name = "vddrfa0p95",
> > +               .load_uA = 200000,
> > +       },
> > +       {
> > +               .name = "vddrfa1p3",
> > +               .load_uA = 400000,
> > +       },
> > +       {
> > +               .name = "vddrfa1p9",
> > +               .load_uA = 400000,
> > +       },
> > +};
> > +
> > +static const struct pwrseq_qca6390_vreg pwrseq_qca6390_vregs_wlan[] = {
> > +       {
> > +               .name = "vddpcie1p3",
> > +               .load_uA = 35000,
> > +       },
> > +       {
> > +               .name = "vddpcie1p9",
> > +               .load_uA = 15000,
> > +       },
> > +};
>
> I thought that we had discussed this already. According to the docs,
> all PMU supplies should be powered on when the chip is being switched
> on, no matter whether it is for the WiFi or for the BT.
>

I know, I mostly did it to make Bjorn happy because he was adamant we
don't need the PCIe regulators for BT and when I checked, it does work
in practice so I thought: whatever. But indeed, the docs say
otherwise. Noted for v6.

[snip]

> > +
> > +static const struct pwrseq_unit_data pwrseq_qca6390_bt_unit_data = {
> > +       .name = "bluetooth-enable",
> > +       .deps = pwrseq_qca6390_unit_deps,
>
> Can we call corresponding regulator_bulk functions from bt and wlan
> enable/disable? This will save us from building the tree-like
> structures (and possible loops inside that tree).
>

Can we? Sure, but the dependency graph (yeah, we should enforce it to
be acyclic) is what makes this code future-proof and allows it to
avoid repeating calls in different targets.

[snip]

Bart

Re: [PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module

[Jeff Johnson]

On 2/17/2024 10:30 AM, Bartosz Golaszewski wrote:
> On Sat, Feb 17, 2024 at 7:35 AM Kalle Valo <kvalo@kernel.org> wrote:
>>
>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>
>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> Add device-tree bindings for the ATH12K module found in the WCN7850
>>> package.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>> ---
>>>  .../net/wireless/qcom,ath12k-pci.yaml         | 103 ++++++++++++++++++
>>>  1 file changed, 103 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>>> new file mode 100644
>>> index 000000000000..063c576b99a0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>>> @@ -0,0 +1,103 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Copyright (c) 2024 Linaro Limited
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-pci.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm Technologies ath12k wireless devices (PCIe)
>>> +
>>> +maintainers:
>>> +  - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>
>> Jeff and me are the ath12k driver maintainers so shouldn't we listed
>> here as well?
>>
> 
> Sure will do. I also noticed the subject is wrong, should have been
> "net" not "new".
> 
> Also, Jeff is not showing up for ath12k bindings in get_maintainer.pl.
> You could consider adding an N: ath12k entry to MAINTAINERS.
> 
> Bartosz
> 
>> Jeff, this reminds me that we should add you to qcom,ath10k.yaml,
>> qcom,ath11k-pci.yaml and qcom,ath11k.yaml as maintainer.

OK, I'll update those files.

And looking at MAINTAINERS, in ath10 we have an explicit path:
F:	Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml

And in ath11k we have an explicit path:
F:	Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml

However the ath11k entry is missing:
Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml

So it looks like I have a few patches:
- update my entries in MAINTAINERS to use my @kernel.org e-mail
- add myself to the existing *ath1*k*.yaml files as a maintainer
- update MAINTAINERS to replace F: *.yaml with N: ath1*k to match any
related files, including the YAML files

/jeff

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Sat, Feb 17, 2024 at 07:32:16PM +0100, Bartosz Golaszewski wrote:
> On Sat, Feb 17, 2024 at 4:48 PM Mark Brown <broonie@kernel.org> wrote:

> > Please submit patches using subject lines reflecting the style for the
> > subsystem, this makes it easier for people to identify relevant patches.
> > Look at what existing commits in the area you're changing are doing and
> > make sure your subject lines visually resemble what they're doing.
> > There's no need to resubmit to fix this alone.

> This is quite vague, could you elaborate? I have no idea what is wrong
> with this patch.

The subject line does not look like the subject line for a regulator
patch rendering it almost invisible in my inbox.  As you will see if you
follow the above suggestion and look at other commits to the same area
you should see that subject lines should start regulator:.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> First, I'd like to apologize for the somewhat chaotic previous iterations
> of this series and improper versioning which was rightfully pointed out
> to me. I figured that the scope changed so much that it didn't make sense
> to consider previous submissions part of the same series as the original
> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> versioning going forward.
>
> This is the summary of the work so far:
>
> v1: Original RFC:
>
> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
>
> v2: First real patch series (should have been PATCH v2) adding what I
>     referred to back then as PCI power sequencing:
>
> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
>
> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
>     modules inside the QCA6391 package (was largely separate from the
>     series but probably should have been called PATCH or RFC v3):
>
> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
>
> v4: Second attempt at the full series with changed scope (introduction of
>     the pwrseq subsystem, should have been RFC v4)
>
> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
>
> ===
>
> With that out of the way, I'd like to get down to explaining the two
> problems I'm trying to solve.
>
> Problem statement #1: Dynamic bus chicken-and-egg problem.
>
> Certain on-board PCI devices need to be powered up before they are can be
> detected but their PCI drivers won't get bound until the device is
> powered-up so enabling the relevant resources in the PCI device driver
> itself is impossible.
>
> Problem statement #2: Sharing inter-dependent resources between devices.
>
> Certain devices that use separate drivers (often on different busses)
> share resources (regulators, clocks, etc.). Typically these resources
> are reference-counted but in some cases there are additional interactions
> between them to consider, for example specific power-up sequence timings.
>
> ===
>
> The reason for tackling both of these problems in a single series is the
> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> both need to be addressed in order to enable WLAN and Bluetooth support
> upstream.
>
> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> takes inputs from the host and exposes LDO outputs consumed by the BT and
> WLAN modules which can be powered-up and down independently. However
> a delay of 100ms must be respected between enabling the BT- and
> WLAN-enable GPIOs[*].
>
> ===
>
> This series is logically split into several sections. I'll go
> patch-by-patch and explain each step.
>
> Patch 1/18:
>
> This is a commit taken from the list by Jonathan Cameron that adds
> a __free() helper for OF nodes. Not strictly related to the series but
> until said commit ends in next, I need to carry it with this series.
>
> Patch 2/18:
>
> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> and sm8550 reference platforms use it in the WCN7850 module.
>
> Patches 3/18-6/18:
>
> These contain all relevant DT bindings changes. We add new documents for
> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> QCA6390.
>
> Patches 7/18-9/18:
>
> These contain changes to device-tree sources for the three platforms we
> work with in this series. As the WCN7850 module doesn't require any
> specific timings introducing dependencies between the Bluetooth and WLAN
> modules, while the QCA6390 does, we take two different approaches to how
> me model them in DT.
>
> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> necessary. The BT and WLAN devices on the device-tree are represented as
> consuming the inputs (relevant to the functionality of each) of the PMU
> directly.

We are describing the hardware. From the hardware point of view, there
is a PMU. I think at some point we would really like to describe all
Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).

> For QCA6390 on RB5 we add the PMU node as a platform device. It consumes
> regulators and GPIOs from the host and exposed regulators consumer in turn
> by the BT and WLAN modules. This represents the internal structure of the
> package.
>
> Patches 10/18-14/18:
>
> These contain the bulk of the PCI changes for this series. We introduce
> a simple framework for powering up PCI devices before detecting them on
> the bus and the first user of this library in the form of the WCN7850 PCI
> power control driver.
>
> The general approach is as follows: PCI devices that need special
> treatment before they can be powered up, scanned and bound to their PCI
> drivers must be described on the device-tree as child nodes of the PCI
> port node. These devices will be instantiated on the platform bus. They
> will in fact be generic platform devices with the compatible of the form
> used for PCI devices already upstream ("pci<vendor ID>,<device ID">). We
> add a new directory under drivers/pci/pwrctl/ that contains PCI pwrctl
> drivers. These drivers are platform drivers that will now be matched
> against the devices instantiated from port children just like any other
> platform pairs.
>
> Both the power control platform device *AND* the associated PCI device
> reuse the same OF node and have access to the same properties. The goal
> of the platform driver is to request and bring up any required resources
> and let the pwrctl framework know that it's now OK to rescan the bus and
> detect the devices. When the device is bound, we are notified about it
> by the PCI bus notifier event and can establish a device link between the
> power control device and the PCI device so that any future extension for
> power-management will already be able to work with the correct hierachy.
>
> The reusing of the OF node is the reason for the small changes to the PCI
> OF core: as the bootloader can possibly leave the relevant regulators on
> before booting linux, the PCI device can be detected before its platform
> abstraction is probed. In this case, we find that device first and mark
> its OF node as reused. The pwrctl framework handles the opposite case
> (when the PCI device is detected only after the platform driver
> successfully enabled it).
>
> Patches 15/18-16/18:
>
> These add a relatively simple power sequencing subsystem and the first
> driver using it: the pwrseq module for the QCA6390 PMU.
>
> For the record: Bjorn suggested a different solution: a regulator driver
> that would - based on which regulators are enabled by a consumer - enable
> relevant resources (drive the enable GPIOs) while respecting the
> HW-specific delays. This would however require significant and yet
> unprecised changed to the regulator subsystem as well as be an abuse of
> the regulator provider API akin to using the reset framework for power
> sequencing as proposed before.
>
> Instead I'm proposing to add a subsystem that allows different devices to
> use a shared power sequence split into consumer-specific as well as
> common "units".
>
> A power sequence provider driver registers a set of units with pwrseq
> core. Each unit can be enabled and disabled and contains an optional list
> of other units which must be enabled before it itself can be. A unit
> represents a discreet chunk of the power sequence.
>
> It also registers a list of targets: a target is an abstraction wrapping
> a unit which allows consumers to tell pwrseq which unit they want to
> reach. Real-life example is the driver we're adding here: there's a set
> of common regulators, two PCIe-specific ones and two enable GPIOs: one
> for Bluetooth and one for WLAN.
>
> The Bluetooth driver requests a descriptor to the power sequencer and
> names the target it wants to reach:
>
>     pwrseq = devm_pwrseq_get(dev, "bluetooth");

Is this target tied to the device or not? If not, this might become a
limitation, if somebody installs two WiFi/BT modules to a single
device.

> The pwrseq core then knows that when the driver calls:
>
>     pwrseq_power_on(pwrseq);
>
> It must enable the "bluetooth-enable" unit but it depends on the
> "regulators-common" unit so this one is enabled first. The provider
> driver is also in charge of assuring an appropriate delay between
> enabling the BT and WLAN enable GPIOs. The WLAN-specific resources are
> handled by the "wlan-enable" unit and so are not enabled until the WLAN
> driver requests the "wlan" target to be powered on.
>
> Another thing worth discussing is the way we associate the consumer with
> the relevant power sequencer. DT maintainers have expressed a discontent
> with the existing mmc pwrseq bindings and have NAKed an earlier
> initiative to introduce global pwrseq bindings to the kernel[1].
>
> In this approach, we model the existing regulators and GPIOs in DT but
> the pwrseq subsystem requires each provider to provide a .match()
> callback. Whenever a consumer requests a power sequencer handle, we
> iterate over the list of pwrseq drivers and call .match() for each. It's
> up to the driver to verify in a platform-specific way whether it deals
> with its consumer and let the core pwrseq code know.

This looks really nice, it will allow us to migrate the BT driver to
always use pwrseq instead of regulators without touching the DT.

>
> The advantage of this over reusing the regulator or reset subsystem is
> that it's more generalized and can handle resources of all kinds as well
> as deal with any kind of power-on sequences: for instance, Qualcomm has
> a PCI switch they want a driver for but this switch requires enabling
> some resources first (PCI pwrctl) and then configuring the device over
> I2C (which can be handled by the pwrseq provider).
>
> Patch 17/18:
>
> This patch makes the Qualcomm Bluetooth driver get and use the power
> sequencer for QCA6390.
>
> Patch 18/18:
>
> While tiny, this patch is possibly the highlight of the entire series.
> It uses the two abstraction layers we introduced before to create an
> elegant power sequencing PCI power control driver and supports the ath11k
> module on QCA6390.
>
> With this series we can now enable BT and WLAN on several new Qualcomm
> boards upstream.
>
> I tested the series on RB5 while Neil tested it on sm8650-qrd and
> sm8550-qrd.
>
> Best Regards,
> Bartosz Golaszewski
>
> It's hard to list the changes between versions here as the scope changed
> significantly between each iteration and some versions were not even full
> series but rather RFCs for parts of the solution. For this reason, I'll
> only start listing changes starting from v6.
>
> [*] This is what the docs say. In practice it seems that this delay can be
> ignored. However the subsequent model - QCA6490 - *does* require users to
> respect it, so the problem remains valid.
>
> [1] https://lore.kernel.org/netdev/20210829131305.534417-1-dmitry.baryshkov@linaro.org/
>
> Bartosz Golaszewski (15):
>   arm64: defconfig: enable ath12k as a module
>   dt-bindings: regulator: describe the PMU module of the QCA6390 package
>   dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
>   dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on
>     QCA6390
>   dt-bindings: new: wireless: describe the ath12k PCI module
>   arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391
>   PCI: hold the rescan mutex when scanning for the first time
>   PCI/pwrctl: reuse the OF node for power controlled devices
>   PCI/pwrctl: create platform devices for child OF nodes of the port
>     node
>   PCI/pwrctl: add PCI power control core code
>   PCI/pwrctl: add a power control driver for WCN7850
>   power: sequencing: implement the pwrseq core
>   power: pwrseq: add a driver for the QCA6390 PMU module
>   Bluetooth: qca: use the power sequencer for QCA6390
>   PCI/pwrctl: add a PCI power control driver for power sequenced devices
>
> Jonathan Cameron (1):
>   of: Add cleanup.h based auto release via __free(device_node) markings.
>
> Neil Armstrong (2):
>   arm64: dts: qcom: sm8550-qrd: add the Wifi node
>   arm64: dts: qcom: sm8650-qrd: add the Wifi node
>
>  .../net/bluetooth/qualcomm-bluetooth.yaml     |   17 +
>  .../net/wireless/qcom,ath11k-pci.yaml         |   28 +
>  .../net/wireless/qcom,ath12k-pci.yaml         |  103 ++
>  .../bindings/regulator/qcom,qca6390-pmu.yaml  |  166 +++
>  MAINTAINERS                                   |    8 +
>  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts      |  123 +-
>  arch/arm64/boot/dts/qcom/sm8250.dtsi          |   10 +
>  arch/arm64/boot/dts/qcom/sm8550-qrd.dts       |   37 +
>  arch/arm64/boot/dts/qcom/sm8550.dtsi          |   10 +
>  arch/arm64/boot/dts/qcom/sm8650-qrd.dts       |   29 +
>  arch/arm64/boot/dts/qcom/sm8650.dtsi          |   10 +
>  arch/arm64/configs/defconfig                  |    1 +
>  drivers/bluetooth/hci_qca.c                   |   31 +
>  drivers/pci/Kconfig                           |    1 +
>  drivers/pci/Makefile                          |    1 +
>  drivers/pci/bus.c                             |    9 +-
>  drivers/pci/of.c                              |   14 +-
>  drivers/pci/probe.c                           |    2 +
>  drivers/pci/pwrctl/Kconfig                    |   25 +
>  drivers/pci/pwrctl/Makefile                   |    7 +
>  drivers/pci/pwrctl/core.c                     |  136 +++
>  drivers/pci/pwrctl/pci-pwrctl-pwrseq.c        |   84 ++
>  drivers/pci/pwrctl/pci-pwrctl-wcn7850.c       |  202 ++++
>  drivers/pci/remove.c                          |    2 +
>  drivers/power/Kconfig                         |    1 +
>  drivers/power/Makefile                        |    1 +
>  drivers/power/sequencing/Kconfig              |   28 +
>  drivers/power/sequencing/Makefile             |    6 +
>  drivers/power/sequencing/core.c               | 1065 +++++++++++++++++
>  drivers/power/sequencing/pwrseq-qca6390.c     |  353 ++++++
>  include/linux/of.h                            |    2 +
>  include/linux/pci-pwrctl.h                    |   51 +
>  include/linux/pwrseq/consumer.h               |   56 +
>  include/linux/pwrseq/provider.h               |   75 ++
>  34 files changed, 2678 insertions(+), 16 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>  create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
>  create mode 100644 drivers/pci/pwrctl/Kconfig
>  create mode 100644 drivers/pci/pwrctl/Makefile
>  create mode 100644 drivers/pci/pwrctl/core.c
>  create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
>  create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
>  create mode 100644 drivers/power/sequencing/Kconfig
>  create mode 100644 drivers/power/sequencing/Makefile
>  create mode 100644 drivers/power/sequencing/core.c
>  create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
>  create mode 100644 include/linux/pci-pwrctl.h
>  create mode 100644 include/linux/pwrseq/consumer.h
>  create mode 100644 include/linux/pwrseq/provider.h
>
> --
> 2.40.1
>


-- 
With best wishes
Dmitry

Re: [PATCH v5 02/18] arm64: defconfig: enable ath12k as a module

[Krzysztof Kozlowski]

On 16/02/2024 21:31, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> Build the ath12k driver as a module for arm64 default config.

This we see from the diff. Please tell us "why", e.g. "Board foo with
Qualcomm baz uses it."

Also this should not be in these series. It only makes the
power-sequencing patchset bigger, without any real reason.


Best regards,
Krzysztof

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Krzysztof Kozlowski]

On 17/02/2024 19:32, Bartosz Golaszewski wrote:
> On Sat, Feb 17, 2024 at 4:48 PM Mark Brown <broonie@kernel.org> wrote:
>>
>> On Fri, Feb 16, 2024 at 09:32:00PM +0100, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
>>> are powered by the Power Management Unit (PMU) that takes inputs from the
>>> host and provides LDO outputs. This document describes this module.
>>
>> Please submit patches using subject lines reflecting the style for the
>> subsystem, this makes it easier for people to identify relevant patches.
>> Look at what existing commits in the area you're changing are doing and
>> make sure your subject lines visually resemble what they're doing.
>> There's no need to resubmit to fix this alone.
> 
> Mark,
> 
> This is quite vague, could you elaborate? I have no idea what is wrong
> with this patch.

Use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

Best regards,
Krzysztof

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Krzysztof Kozlowski]

On 16/02/2024 21:32, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. This document describes this module.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  .../bindings/regulator/qcom,qca6390-pmu.yaml  | 166 ++++++++++++++++++
>  1 file changed, 166 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
> 

This matches our internal discussions and how we see the QCA6390 power
handling based on datasheet.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH v5 04/18] dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390

[Krzysztof Kozlowski]

On 16/02/2024 21:32, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> QCA6390 has a compatible listed in the bindings but is missing the
> regulators description. Add the missing supply property and list the
> required ones in the allOf section.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>


Best regards,
Krzysztof

Re: [PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module

[Krzysztof Kozlowski]

On 16/02/2024 21:32, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> Add device-tree bindings for the ATH12K module found in the WCN7850
> package.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  .../net/wireless/qcom,ath12k-pci.yaml         | 103 ++++++++++++++++++
>  1 file changed, 103 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> new file mode 100644
> index 000000000000..063c576b99a0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml

This means there can be ath12k over AHB or some other bus, which would
be quite different and not fit together in one schema file. It's that
the case?

> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2024 Linaro Limited
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-pci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies ath12k wireless devices (PCIe)
> +
> +maintainers:
> +  - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> +
> +description: |

Do not need '|' unless you need to preserve formatting.

> +  Qualcomm Technologies IEEE 802.11ax PCIe devices
> +
> +properties:
> +  compatible:
> +    enum:
> +      - pci17cb,1107  # WCN7850
> +
> +  reg:
> +    maxItems: 1
> +
> +  enable-gpios:
> +    maxItems: 1
> +    description: GPIO line enabling the WLAN module
> +
> +  vdd-supply:
> +    description: VDD supply regulator handle
> +
> +  vddio-supply:
> +    description: VDD_IO supply regulator handle
> +
> +  vddio1p2-supply:
> +    description: VDD_IO_1P2 supply regulator handle
> +
> +  vddaon-supply:
> +    description: VDD_AON supply regulator handle
> +
> +  vdddig-supply:
> +    description: VDD_DIG supply regulator handle
> +
> +  vddrfa1p2-supply:
> +    description: VDD_RFA_1P2 supply regulator handle
> +
> +  vddrfa1p8-supply:
> +    description: VDD_PCIE_1P8 supply regulator handle
> +
> +  clocks:
> +    maxItems: 1
> +    description:
> +      Reference clock phandle

These three could be just:
items:
  - description: Reference clock

(phandle is redundant in this context)

Best regards,
Krzysztof

Re: [PATCH v5 02/18] arm64: defconfig: enable ath12k as a module

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 8:31 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/02/2024 21:31, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Build the ath12k driver as a module for arm64 default config.
>
> This we see from the diff. Please tell us "why", e.g. "Board foo with
> Qualcomm baz uses it."
>
> Also this should not be in these series. It only makes the
> power-sequencing patchset bigger, without any real reason.
>
>
> Best regards,
> Krzysztof
>

Got it, I will resend it separately.

Bart

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Neil Armstrong]

On 18/02/2024 13:53, Dmitry Baryshkov wrote:
> On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>
>> First, I'd like to apologize for the somewhat chaotic previous iterations
>> of this series and improper versioning which was rightfully pointed out
>> to me. I figured that the scope changed so much that it didn't make sense
>> to consider previous submissions part of the same series as the original
>> RFC but others thought otherwise so this one becomes v5 and I'll keep the
>> versioning going forward.
>>
>> This is the summary of the work so far:
>>
>> v1: Original RFC:
>>
>> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
>>
>> v2: First real patch series (should have been PATCH v2) adding what I
>>      referred to back then as PCI power sequencing:
>>
>> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
>>
>> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
>>      modules inside the QCA6391 package (was largely separate from the
>>      series but probably should have been called PATCH or RFC v3):
>>
>> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
>>
>> v4: Second attempt at the full series with changed scope (introduction of
>>      the pwrseq subsystem, should have been RFC v4)
>>
>> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
>>
>> ===
>>
>> With that out of the way, I'd like to get down to explaining the two
>> problems I'm trying to solve.
>>
>> Problem statement #1: Dynamic bus chicken-and-egg problem.
>>
>> Certain on-board PCI devices need to be powered up before they are can be
>> detected but their PCI drivers won't get bound until the device is
>> powered-up so enabling the relevant resources in the PCI device driver
>> itself is impossible.
>>
>> Problem statement #2: Sharing inter-dependent resources between devices.
>>
>> Certain devices that use separate drivers (often on different busses)
>> share resources (regulators, clocks, etc.). Typically these resources
>> are reference-counted but in some cases there are additional interactions
>> between them to consider, for example specific power-up sequence timings.
>>
>> ===
>>
>> The reason for tackling both of these problems in a single series is the
>> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
>> both need to be addressed in order to enable WLAN and Bluetooth support
>> upstream.
>>
>> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
>> takes inputs from the host and exposes LDO outputs consumed by the BT and
>> WLAN modules which can be powered-up and down independently. However
>> a delay of 100ms must be respected between enabling the BT- and
>> WLAN-enable GPIOs[*].
>>
>> ===
>>
>> This series is logically split into several sections. I'll go
>> patch-by-patch and explain each step.
>>
>> Patch 1/18:
>>
>> This is a commit taken from the list by Jonathan Cameron that adds
>> a __free() helper for OF nodes. Not strictly related to the series but
>> until said commit ends in next, I need to carry it with this series.
>>
>> Patch 2/18:
>>
>> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
>> and sm8550 reference platforms use it in the WCN7850 module.
>>
>> Patches 3/18-6/18:
>>
>> These contain all relevant DT bindings changes. We add new documents for
>> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
>> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
>> QCA6390.
>>
>> Patches 7/18-9/18:
>>
>> These contain changes to device-tree sources for the three platforms we
>> work with in this series. As the WCN7850 module doesn't require any
>> specific timings introducing dependencies between the Bluetooth and WLAN
>> modules, while the QCA6390 does, we take two different approaches to how
>> me model them in DT.
>>
>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
>> necessary. The BT and WLAN devices on the device-tree are represented as
>> consuming the inputs (relevant to the functionality of each) of the PMU
>> directly.
> 
> We are describing the hardware. From the hardware point of view, there
> is a PMU. I think at some point we would really like to describe all
> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).

While I agree with older WiFi+BT units, I don't think it's needed for
WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
transparent.

> 
>> For QCA6390 on RB5 we add the PMU node as a platform device. It consumes
>> regulators and GPIOs from the host and exposed regulators consumer in turn
>> by the BT and WLAN modules. This represents the internal structure of the
>> package.
>>
>> Patches 10/18-14/18:
>>
>> These contain the bulk of the PCI changes for this series. We introduce
>> a simple framework for powering up PCI devices before detecting them on
>> the bus and the first user of this library in the form of the WCN7850 PCI
>> power control driver.
>>
>> The general approach is as follows: PCI devices that need special
>> treatment before they can be powered up, scanned and bound to their PCI
>> drivers must be described on the device-tree as child nodes of the PCI
>> port node. These devices will be instantiated on the platform bus. They
>> will in fact be generic platform devices with the compatible of the form
>> used for PCI devices already upstream ("pci<vendor ID>,<device ID">). We
>> add a new directory under drivers/pci/pwrctl/ that contains PCI pwrctl
>> drivers. These drivers are platform drivers that will now be matched
>> against the devices instantiated from port children just like any other
>> platform pairs.
>>
>> Both the power control platform device *AND* the associated PCI device
>> reuse the same OF node and have access to the same properties. The goal
>> of the platform driver is to request and bring up any required resources
>> and let the pwrctl framework know that it's now OK to rescan the bus and
>> detect the devices. When the device is bound, we are notified about it
>> by the PCI bus notifier event and can establish a device link between the
>> power control device and the PCI device so that any future extension for
>> power-management will already be able to work with the correct hierachy.
>>
>> The reusing of the OF node is the reason for the small changes to the PCI
>> OF core: as the bootloader can possibly leave the relevant regulators on
>> before booting linux, the PCI device can be detected before its platform
>> abstraction is probed. In this case, we find that device first and mark
>> its OF node as reused. The pwrctl framework handles the opposite case
>> (when the PCI device is detected only after the platform driver
>> successfully enabled it).
>>
>> Patches 15/18-16/18:
>>
>> These add a relatively simple power sequencing subsystem and the first
>> driver using it: the pwrseq module for the QCA6390 PMU.
>>
>> For the record: Bjorn suggested a different solution: a regulator driver
>> that would - based on which regulators are enabled by a consumer - enable
>> relevant resources (drive the enable GPIOs) while respecting the
>> HW-specific delays. This would however require significant and yet
>> unprecised changed to the regulator subsystem as well as be an abuse of
>> the regulator provider API akin to using the reset framework for power
>> sequencing as proposed before.
>>
>> Instead I'm proposing to add a subsystem that allows different devices to
>> use a shared power sequence split into consumer-specific as well as
>> common "units".
>>
>> A power sequence provider driver registers a set of units with pwrseq
>> core. Each unit can be enabled and disabled and contains an optional list
>> of other units which must be enabled before it itself can be. A unit
>> represents a discreet chunk of the power sequence.
>>
>> It also registers a list of targets: a target is an abstraction wrapping
>> a unit which allows consumers to tell pwrseq which unit they want to
>> reach. Real-life example is the driver we're adding here: there's a set
>> of common regulators, two PCIe-specific ones and two enable GPIOs: one
>> for Bluetooth and one for WLAN.
>>
>> The Bluetooth driver requests a descriptor to the power sequencer and
>> names the target it wants to reach:
>>
>>      pwrseq = devm_pwrseq_get(dev, "bluetooth");
> 
> Is this target tied to the device or not? If not, this might become a
> limitation, if somebody installs two WiFi/BT modules to a single
> device.
> 
>> The pwrseq core then knows that when the driver calls:
>>
>>      pwrseq_power_on(pwrseq);
>>
>> It must enable the "bluetooth-enable" unit but it depends on the
>> "regulators-common" unit so this one is enabled first. The provider
>> driver is also in charge of assuring an appropriate delay between
>> enabling the BT and WLAN enable GPIOs. The WLAN-specific resources are
>> handled by the "wlan-enable" unit and so are not enabled until the WLAN
>> driver requests the "wlan" target to be powered on.
>>
>> Another thing worth discussing is the way we associate the consumer with
>> the relevant power sequencer. DT maintainers have expressed a discontent
>> with the existing mmc pwrseq bindings and have NAKed an earlier
>> initiative to introduce global pwrseq bindings to the kernel[1].
>>
>> In this approach, we model the existing regulators and GPIOs in DT but
>> the pwrseq subsystem requires each provider to provide a .match()
>> callback. Whenever a consumer requests a power sequencer handle, we
>> iterate over the list of pwrseq drivers and call .match() for each. It's
>> up to the driver to verify in a platform-specific way whether it deals
>> with its consumer and let the core pwrseq code know.
> 
> This looks really nice, it will allow us to migrate the BT driver to
> always use pwrseq instead of regulators without touching the DT.
> 
>>
>> The advantage of this over reusing the regulator or reset subsystem is
>> that it's more generalized and can handle resources of all kinds as well
>> as deal with any kind of power-on sequences: for instance, Qualcomm has
>> a PCI switch they want a driver for but this switch requires enabling
>> some resources first (PCI pwrctl) and then configuring the device over
>> I2C (which can be handled by the pwrseq provider).
>>
>> Patch 17/18:
>>
>> This patch makes the Qualcomm Bluetooth driver get and use the power
>> sequencer for QCA6390.
>>
>> Patch 18/18:
>>
>> While tiny, this patch is possibly the highlight of the entire series.
>> It uses the two abstraction layers we introduced before to create an
>> elegant power sequencing PCI power control driver and supports the ath11k
>> module on QCA6390.
>>
>> With this series we can now enable BT and WLAN on several new Qualcomm
>> boards upstream.
>>
>> I tested the series on RB5 while Neil tested it on sm8650-qrd and
>> sm8550-qrd.
>>
>> Best Regards,
>> Bartosz Golaszewski
>>
>> It's hard to list the changes between versions here as the scope changed
>> significantly between each iteration and some versions were not even full
>> series but rather RFCs for parts of the solution. For this reason, I'll
>> only start listing changes starting from v6.
>>
>> [*] This is what the docs say. In practice it seems that this delay can be
>> ignored. However the subsequent model - QCA6490 - *does* require users to
>> respect it, so the problem remains valid.
>>
>> [1] https://lore.kernel.org/netdev/20210829131305.534417-1-dmitry.baryshkov@linaro.org/
>>
>> Bartosz Golaszewski (15):
>>    arm64: defconfig: enable ath12k as a module
>>    dt-bindings: regulator: describe the PMU module of the QCA6390 package
>>    dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
>>    dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on
>>      QCA6390
>>    dt-bindings: new: wireless: describe the ath12k PCI module
>>    arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391
>>    PCI: hold the rescan mutex when scanning for the first time
>>    PCI/pwrctl: reuse the OF node for power controlled devices
>>    PCI/pwrctl: create platform devices for child OF nodes of the port
>>      node
>>    PCI/pwrctl: add PCI power control core code
>>    PCI/pwrctl: add a power control driver for WCN7850
>>    power: sequencing: implement the pwrseq core
>>    power: pwrseq: add a driver for the QCA6390 PMU module
>>    Bluetooth: qca: use the power sequencer for QCA6390
>>    PCI/pwrctl: add a PCI power control driver for power sequenced devices
>>
>> Jonathan Cameron (1):
>>    of: Add cleanup.h based auto release via __free(device_node) markings.
>>
>> Neil Armstrong (2):
>>    arm64: dts: qcom: sm8550-qrd: add the Wifi node
>>    arm64: dts: qcom: sm8650-qrd: add the Wifi node
>>
>>   .../net/bluetooth/qualcomm-bluetooth.yaml     |   17 +
>>   .../net/wireless/qcom,ath11k-pci.yaml         |   28 +
>>   .../net/wireless/qcom,ath12k-pci.yaml         |  103 ++
>>   .../bindings/regulator/qcom,qca6390-pmu.yaml  |  166 +++
>>   MAINTAINERS                                   |    8 +
>>   arch/arm64/boot/dts/qcom/qrb5165-rb5.dts      |  123 +-
>>   arch/arm64/boot/dts/qcom/sm8250.dtsi          |   10 +
>>   arch/arm64/boot/dts/qcom/sm8550-qrd.dts       |   37 +
>>   arch/arm64/boot/dts/qcom/sm8550.dtsi          |   10 +
>>   arch/arm64/boot/dts/qcom/sm8650-qrd.dts       |   29 +
>>   arch/arm64/boot/dts/qcom/sm8650.dtsi          |   10 +
>>   arch/arm64/configs/defconfig                  |    1 +
>>   drivers/bluetooth/hci_qca.c                   |   31 +
>>   drivers/pci/Kconfig                           |    1 +
>>   drivers/pci/Makefile                          |    1 +
>>   drivers/pci/bus.c                             |    9 +-
>>   drivers/pci/of.c                              |   14 +-
>>   drivers/pci/probe.c                           |    2 +
>>   drivers/pci/pwrctl/Kconfig                    |   25 +
>>   drivers/pci/pwrctl/Makefile                   |    7 +
>>   drivers/pci/pwrctl/core.c                     |  136 +++
>>   drivers/pci/pwrctl/pci-pwrctl-pwrseq.c        |   84 ++
>>   drivers/pci/pwrctl/pci-pwrctl-wcn7850.c       |  202 ++++
>>   drivers/pci/remove.c                          |    2 +
>>   drivers/power/Kconfig                         |    1 +
>>   drivers/power/Makefile                        |    1 +
>>   drivers/power/sequencing/Kconfig              |   28 +
>>   drivers/power/sequencing/Makefile             |    6 +
>>   drivers/power/sequencing/core.c               | 1065 +++++++++++++++++
>>   drivers/power/sequencing/pwrseq-qca6390.c     |  353 ++++++
>>   include/linux/of.h                            |    2 +
>>   include/linux/pci-pwrctl.h                    |   51 +
>>   include/linux/pwrseq/consumer.h               |   56 +
>>   include/linux/pwrseq/provider.h               |   75 ++
>>   34 files changed, 2678 insertions(+), 16 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>>   create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
>>   create mode 100644 drivers/pci/pwrctl/Kconfig
>>   create mode 100644 drivers/pci/pwrctl/Makefile
>>   create mode 100644 drivers/pci/pwrctl/core.c
>>   create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
>>   create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
>>   create mode 100644 drivers/power/sequencing/Kconfig
>>   create mode 100644 drivers/power/sequencing/Makefile
>>   create mode 100644 drivers/power/sequencing/core.c
>>   create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
>>   create mode 100644 include/linux/pci-pwrctl.h
>>   create mode 100644 include/linux/pwrseq/consumer.h
>>   create mode 100644 include/linux/pwrseq/provider.h
>>
>> --
>> 2.40.1
>>
> 
> 

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Neil Armstrong]

On 16/02/2024 21:31, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> First, I'd like to apologize for the somewhat chaotic previous iterations
> of this series and improper versioning which was rightfully pointed out
> to me. I figured that the scope changed so much that it didn't make sense
> to consider previous submissions part of the same series as the original
> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> versioning going forward.
> 
> This is the summary of the work so far:
> 
> v1: Original RFC:
> 
> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
> 
> v2: First real patch series (should have been PATCH v2) adding what I
>      referred to back then as PCI power sequencing:
> 
> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
> 
> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
>      modules inside the QCA6391 package (was largely separate from the
>      series but probably should have been called PATCH or RFC v3):
> 
> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
> 
> v4: Second attempt at the full series with changed scope (introduction of
>      the pwrseq subsystem, should have been RFC v4)
> 
> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
> 
> ===
> 
> With that out of the way, I'd like to get down to explaining the two
> problems I'm trying to solve.
> 
> Problem statement #1: Dynamic bus chicken-and-egg problem.
> 
> Certain on-board PCI devices need to be powered up before they are can be
> detected but their PCI drivers won't get bound until the device is
> powered-up so enabling the relevant resources in the PCI device driver
> itself is impossible.
> 
> Problem statement #2: Sharing inter-dependent resources between devices.
> 
> Certain devices that use separate drivers (often on different busses)
> share resources (regulators, clocks, etc.). Typically these resources
> are reference-counted but in some cases there are additional interactions
> between them to consider, for example specific power-up sequence timings.
> 
> ===
> 
> The reason for tackling both of these problems in a single series is the
> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> both need to be addressed in order to enable WLAN and Bluetooth support
> upstream.
> 
> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> takes inputs from the host and exposes LDO outputs consumed by the BT and
> WLAN modules which can be powered-up and down independently. However
> a delay of 100ms must be respected between enabling the BT- and
> WLAN-enable GPIOs[*].
> 
> ===
> 
> This series is logically split into several sections. I'll go
> patch-by-patch and explain each step.
> 
> Patch 1/18:
> 
> This is a commit taken from the list by Jonathan Cameron that adds
> a __free() helper for OF nodes. Not strictly related to the series but
> until said commit ends in next, I need to carry it with this series.
> 
> Patch 2/18:
> 
> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> and sm8550 reference platforms use it in the WCN7850 module.
> 
> Patches 3/18-6/18:
> 
> These contain all relevant DT bindings changes. We add new documents for
> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> QCA6390.
> 
> Patches 7/18-9/18:
> 
> These contain changes to device-tree sources for the three platforms we
> work with in this series. As the WCN7850 module doesn't require any
> specific timings introducing dependencies between the Bluetooth and WLAN
> modules, while the QCA6390 does, we take two different approaches to how
> me model them in DT.
> 
> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> necessary. The BT and WLAN devices on the device-tree are represented as
> consuming the inputs (relevant to the functionality of each) of the PMU
> directly.
> 
> For QCA6390 on RB5 we add the PMU node as a platform device. It consumes
> regulators and GPIOs from the host and exposed regulators consumer in turn
> by the BT and WLAN modules. This represents the internal structure of the
> package.
> 
> Patches 10/18-14/18:
> 
> These contain the bulk of the PCI changes for this series. We introduce
> a simple framework for powering up PCI devices before detecting them on
> the bus and the first user of this library in the form of the WCN7850 PCI
> power control driver.
> 
> The general approach is as follows: PCI devices that need special
> treatment before they can be powered up, scanned and bound to their PCI
> drivers must be described on the device-tree as child nodes of the PCI
> port node. These devices will be instantiated on the platform bus. They
> will in fact be generic platform devices with the compatible of the form
> used for PCI devices already upstream ("pci<vendor ID>,<device ID">). We
> add a new directory under drivers/pci/pwrctl/ that contains PCI pwrctl
> drivers. These drivers are platform drivers that will now be matched
> against the devices instantiated from port children just like any other
> platform pairs.
> 
> Both the power control platform device *AND* the associated PCI device
> reuse the same OF node and have access to the same properties. The goal
> of the platform driver is to request and bring up any required resources
> and let the pwrctl framework know that it's now OK to rescan the bus and
> detect the devices. When the device is bound, we are notified about it
> by the PCI bus notifier event and can establish a device link between the
> power control device and the PCI device so that any future extension for
> power-management will already be able to work with the correct hierachy.
> 
> The reusing of the OF node is the reason for the small changes to the PCI
> OF core: as the bootloader can possibly leave the relevant regulators on
> before booting linux, the PCI device can be detected before its platform
> abstraction is probed. In this case, we find that device first and mark
> its OF node as reused. The pwrctl framework handles the opposite case
> (when the PCI device is detected only after the platform driver
> successfully enabled it).
> 
> Patches 15/18-16/18:
> 
> These add a relatively simple power sequencing subsystem and the first
> driver using it: the pwrseq module for the QCA6390 PMU.
> 
> For the record: Bjorn suggested a different solution: a regulator driver
> that would - based on which regulators are enabled by a consumer - enable
> relevant resources (drive the enable GPIOs) while respecting the
> HW-specific delays. This would however require significant and yet
> unprecised changed to the regulator subsystem as well as be an abuse of
> the regulator provider API akin to using the reset framework for power
> sequencing as proposed before.
> 
> Instead I'm proposing to add a subsystem that allows different devices to
> use a shared power sequence split into consumer-specific as well as
> common "units".
> 
> A power sequence provider driver registers a set of units with pwrseq
> core. Each unit can be enabled and disabled and contains an optional list
> of other units which must be enabled before it itself can be. A unit
> represents a discreet chunk of the power sequence.
> 
> It also registers a list of targets: a target is an abstraction wrapping
> a unit which allows consumers to tell pwrseq which unit they want to
> reach. Real-life example is the driver we're adding here: there's a set
> of common regulators, two PCIe-specific ones and two enable GPIOs: one
> for Bluetooth and one for WLAN.
> 
> The Bluetooth driver requests a descriptor to the power sequencer and
> names the target it wants to reach:
> 
>      pwrseq = devm_pwrseq_get(dev, "bluetooth");
> 
> The pwrseq core then knows that when the driver calls:
> 
>      pwrseq_power_on(pwrseq);
> 
> It must enable the "bluetooth-enable" unit but it depends on the
> "regulators-common" unit so this one is enabled first. The provider
> driver is also in charge of assuring an appropriate delay between
> enabling the BT and WLAN enable GPIOs. The WLAN-specific resources are
> handled by the "wlan-enable" unit and so are not enabled until the WLAN
> driver requests the "wlan" target to be powered on.
> 
> Another thing worth discussing is the way we associate the consumer with
> the relevant power sequencer. DT maintainers have expressed a discontent
> with the existing mmc pwrseq bindings and have NAKed an earlier
> initiative to introduce global pwrseq bindings to the kernel[1].
> 
> In this approach, we model the existing regulators and GPIOs in DT but
> the pwrseq subsystem requires each provider to provide a .match()
> callback. Whenever a consumer requests a power sequencer handle, we
> iterate over the list of pwrseq drivers and call .match() for each. It's
> up to the driver to verify in a platform-specific way whether it deals
> with its consumer and let the core pwrseq code know.
> 
> The advantage of this over reusing the regulator or reset subsystem is
> that it's more generalized and can handle resources of all kinds as well
> as deal with any kind of power-on sequences: for instance, Qualcomm has
> a PCI switch they want a driver for but this switch requires enabling
> some resources first (PCI pwrctl) and then configuring the device over
> I2C (which can be handled by the pwrseq provider).
> 
> Patch 17/18:
> 
> This patch makes the Qualcomm Bluetooth driver get and use the power
> sequencer for QCA6390.
> 
> Patch 18/18:
> 
> While tiny, this patch is possibly the highlight of the entire series.
> It uses the two abstraction layers we introduced before to create an
> elegant power sequencing PCI power control driver and supports the ath11k
> module on QCA6390.
> 
> With this series we can now enable BT and WLAN on several new Qualcomm
> boards upstream.
> 
> I tested the series on RB5 while Neil tested it on sm8650-qrd and
> sm8550-qrd.
> 
> Best Regards,
> Bartosz Golaszewski
> 
> It's hard to list the changes between versions here as the scope changed
> significantly between each iteration and some versions were not even full
> series but rather RFCs for parts of the solution. For this reason, I'll
> only start listing changes starting from v6.
> 
> [*] This is what the docs say. In practice it seems that this delay can be
> ignored. However the subsequent model - QCA6490 - *does* require users to
> respect it, so the problem remains valid.
> 
> [1] https://lore.kernel.org/netdev/20210829131305.534417-1-dmitry.baryshkov@linaro.org/
> 
> Bartosz Golaszewski (15):
>    arm64: defconfig: enable ath12k as a module
>    dt-bindings: regulator: describe the PMU module of the QCA6390 package
>    dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
>    dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on
>      QCA6390
>    dt-bindings: new: wireless: describe the ath12k PCI module
>    arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391
>    PCI: hold the rescan mutex when scanning for the first time
>    PCI/pwrctl: reuse the OF node for power controlled devices
>    PCI/pwrctl: create platform devices for child OF nodes of the port
>      node
>    PCI/pwrctl: add PCI power control core code
>    PCI/pwrctl: add a power control driver for WCN7850
>    power: sequencing: implement the pwrseq core
>    power: pwrseq: add a driver for the QCA6390 PMU module
>    Bluetooth: qca: use the power sequencer for QCA6390
>    PCI/pwrctl: add a PCI power control driver for power sequenced devices
> 
> Jonathan Cameron (1):
>    of: Add cleanup.h based auto release via __free(device_node) markings.
> 
> Neil Armstrong (2):
>    arm64: dts: qcom: sm8550-qrd: add the Wifi node
>    arm64: dts: qcom: sm8650-qrd: add the Wifi node
> 
>   .../net/bluetooth/qualcomm-bluetooth.yaml     |   17 +
>   .../net/wireless/qcom,ath11k-pci.yaml         |   28 +
>   .../net/wireless/qcom,ath12k-pci.yaml         |  103 ++
>   .../bindings/regulator/qcom,qca6390-pmu.yaml  |  166 +++
>   MAINTAINERS                                   |    8 +
>   arch/arm64/boot/dts/qcom/qrb5165-rb5.dts      |  123 +-
>   arch/arm64/boot/dts/qcom/sm8250.dtsi          |   10 +
>   arch/arm64/boot/dts/qcom/sm8550-qrd.dts       |   37 +
>   arch/arm64/boot/dts/qcom/sm8550.dtsi          |   10 +
>   arch/arm64/boot/dts/qcom/sm8650-qrd.dts       |   29 +
>   arch/arm64/boot/dts/qcom/sm8650.dtsi          |   10 +
>   arch/arm64/configs/defconfig                  |    1 +
>   drivers/bluetooth/hci_qca.c                   |   31 +
>   drivers/pci/Kconfig                           |    1 +
>   drivers/pci/Makefile                          |    1 +
>   drivers/pci/bus.c                             |    9 +-
>   drivers/pci/of.c                              |   14 +-
>   drivers/pci/probe.c                           |    2 +
>   drivers/pci/pwrctl/Kconfig                    |   25 +
>   drivers/pci/pwrctl/Makefile                   |    7 +
>   drivers/pci/pwrctl/core.c                     |  136 +++
>   drivers/pci/pwrctl/pci-pwrctl-pwrseq.c        |   84 ++
>   drivers/pci/pwrctl/pci-pwrctl-wcn7850.c       |  202 ++++
>   drivers/pci/remove.c                          |    2 +
>   drivers/power/Kconfig                         |    1 +
>   drivers/power/Makefile                        |    1 +
>   drivers/power/sequencing/Kconfig              |   28 +
>   drivers/power/sequencing/Makefile             |    6 +
>   drivers/power/sequencing/core.c               | 1065 +++++++++++++++++
>   drivers/power/sequencing/pwrseq-qca6390.c     |  353 ++++++
>   include/linux/of.h                            |    2 +
>   include/linux/pci-pwrctl.h                    |   51 +
>   include/linux/pwrseq/consumer.h               |   56 +
>   include/linux/pwrseq/provider.h               |   75 ++
>   34 files changed, 2678 insertions(+), 16 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>   create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
>   create mode 100644 drivers/pci/pwrctl/Kconfig
>   create mode 100644 drivers/pci/pwrctl/Makefile
>   create mode 100644 drivers/pci/pwrctl/core.c
>   create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
>   create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
>   create mode 100644 drivers/power/sequencing/Kconfig
>   create mode 100644 drivers/power/sequencing/Makefile
>   create mode 100644 drivers/power/sequencing/core.c
>   create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
>   create mode 100644 include/linux/pci-pwrctl.h
>   create mode 100644 include/linux/pwrseq/consumer.h
>   create mode 100644 include/linux/pwrseq/provider.h
> 

Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD

Thanks,
Neil

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Mon, 19 Feb 2024 at 10:14, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
> On 18/02/2024 13:53, Dmitry Baryshkov wrote:
> > On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>
> >> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>
> >> First, I'd like to apologize for the somewhat chaotic previous iterations
> >> of this series and improper versioning which was rightfully pointed out
> >> to me. I figured that the scope changed so much that it didn't make sense
> >> to consider previous submissions part of the same series as the original
> >> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> >> versioning going forward.
> >>
> >> This is the summary of the work so far:
> >>
> >> v1: Original RFC:
> >>
> >> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
> >>
> >> v2: First real patch series (should have been PATCH v2) adding what I
> >>      referred to back then as PCI power sequencing:
> >>
> >> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
> >>
> >> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
> >>      modules inside the QCA6391 package (was largely separate from the
> >>      series but probably should have been called PATCH or RFC v3):
> >>
> >> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
> >>
> >> v4: Second attempt at the full series with changed scope (introduction of
> >>      the pwrseq subsystem, should have been RFC v4)
> >>
> >> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
> >>
> >> ===
> >>
> >> With that out of the way, I'd like to get down to explaining the two
> >> problems I'm trying to solve.
> >>
> >> Problem statement #1: Dynamic bus chicken-and-egg problem.
> >>
> >> Certain on-board PCI devices need to be powered up before they are can be
> >> detected but their PCI drivers won't get bound until the device is
> >> powered-up so enabling the relevant resources in the PCI device driver
> >> itself is impossible.
> >>
> >> Problem statement #2: Sharing inter-dependent resources between devices.
> >>
> >> Certain devices that use separate drivers (often on different busses)
> >> share resources (regulators, clocks, etc.). Typically these resources
> >> are reference-counted but in some cases there are additional interactions
> >> between them to consider, for example specific power-up sequence timings.
> >>
> >> ===
> >>
> >> The reason for tackling both of these problems in a single series is the
> >> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> >> both need to be addressed in order to enable WLAN and Bluetooth support
> >> upstream.
> >>
> >> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> >> takes inputs from the host and exposes LDO outputs consumed by the BT and
> >> WLAN modules which can be powered-up and down independently. However
> >> a delay of 100ms must be respected between enabling the BT- and
> >> WLAN-enable GPIOs[*].
> >>
> >> ===
> >>
> >> This series is logically split into several sections. I'll go
> >> patch-by-patch and explain each step.
> >>
> >> Patch 1/18:
> >>
> >> This is a commit taken from the list by Jonathan Cameron that adds
> >> a __free() helper for OF nodes. Not strictly related to the series but
> >> until said commit ends in next, I need to carry it with this series.
> >>
> >> Patch 2/18:
> >>
> >> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> >> and sm8550 reference platforms use it in the WCN7850 module.
> >>
> >> Patches 3/18-6/18:
> >>
> >> These contain all relevant DT bindings changes. We add new documents for
> >> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> >> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> >> QCA6390.
> >>
> >> Patches 7/18-9/18:
> >>
> >> These contain changes to device-tree sources for the three platforms we
> >> work with in this series. As the WCN7850 module doesn't require any
> >> specific timings introducing dependencies between the Bluetooth and WLAN
> >> modules, while the QCA6390 does, we take two different approaches to how
> >> me model them in DT.
> >>
> >> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> >> necessary. The BT and WLAN devices on the device-tree are represented as
> >> consuming the inputs (relevant to the functionality of each) of the PMU
> >> directly.
> >
> > We are describing the hardware. From the hardware point of view, there
> > is a PMU. I think at some point we would really like to describe all
> > Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
>
> While I agree with older WiFi+BT units, I don't think it's needed for
> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> transparent.

I don't see any significant difference between WCN6750/WCN6855 and
WCN7850 from the PMU / power up point of view. Could you please point
me to the difference?

-- 
With best wishes
Dmitry

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[neil.armstrong]

On 19/02/2024 10:22, Dmitry Baryshkov wrote:
> On Mon, 19 Feb 2024 at 10:14, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>>
>> On 18/02/2024 13:53, Dmitry Baryshkov wrote:
>>> On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>
>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> First, I'd like to apologize for the somewhat chaotic previous iterations
>>>> of this series and improper versioning which was rightfully pointed out
>>>> to me. I figured that the scope changed so much that it didn't make sense
>>>> to consider previous submissions part of the same series as the original
>>>> RFC but others thought otherwise so this one becomes v5 and I'll keep the
>>>> versioning going forward.
>>>>
>>>> This is the summary of the work so far:
>>>>
>>>> v1: Original RFC:
>>>>
>>>> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
>>>>
>>>> v2: First real patch series (should have been PATCH v2) adding what I
>>>>       referred to back then as PCI power sequencing:
>>>>
>>>> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
>>>>
>>>> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
>>>>       modules inside the QCA6391 package (was largely separate from the
>>>>       series but probably should have been called PATCH or RFC v3):
>>>>
>>>> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
>>>>
>>>> v4: Second attempt at the full series with changed scope (introduction of
>>>>       the pwrseq subsystem, should have been RFC v4)
>>>>
>>>> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
>>>>
>>>> ===
>>>>
>>>> With that out of the way, I'd like to get down to explaining the two
>>>> problems I'm trying to solve.
>>>>
>>>> Problem statement #1: Dynamic bus chicken-and-egg problem.
>>>>
>>>> Certain on-board PCI devices need to be powered up before they are can be
>>>> detected but their PCI drivers won't get bound until the device is
>>>> powered-up so enabling the relevant resources in the PCI device driver
>>>> itself is impossible.
>>>>
>>>> Problem statement #2: Sharing inter-dependent resources between devices.
>>>>
>>>> Certain devices that use separate drivers (often on different busses)
>>>> share resources (regulators, clocks, etc.). Typically these resources
>>>> are reference-counted but in some cases there are additional interactions
>>>> between them to consider, for example specific power-up sequence timings.
>>>>
>>>> ===
>>>>
>>>> The reason for tackling both of these problems in a single series is the
>>>> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
>>>> both need to be addressed in order to enable WLAN and Bluetooth support
>>>> upstream.
>>>>
>>>> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
>>>> takes inputs from the host and exposes LDO outputs consumed by the BT and
>>>> WLAN modules which can be powered-up and down independently. However
>>>> a delay of 100ms must be respected between enabling the BT- and
>>>> WLAN-enable GPIOs[*].
>>>>
>>>> ===
>>>>
>>>> This series is logically split into several sections. I'll go
>>>> patch-by-patch and explain each step.
>>>>
>>>> Patch 1/18:
>>>>
>>>> This is a commit taken from the list by Jonathan Cameron that adds
>>>> a __free() helper for OF nodes. Not strictly related to the series but
>>>> until said commit ends in next, I need to carry it with this series.
>>>>
>>>> Patch 2/18:
>>>>
>>>> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
>>>> and sm8550 reference platforms use it in the WCN7850 module.
>>>>
>>>> Patches 3/18-6/18:
>>>>
>>>> These contain all relevant DT bindings changes. We add new documents for
>>>> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
>>>> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
>>>> QCA6390.
>>>>
>>>> Patches 7/18-9/18:
>>>>
>>>> These contain changes to device-tree sources for the three platforms we
>>>> work with in this series. As the WCN7850 module doesn't require any
>>>> specific timings introducing dependencies between the Bluetooth and WLAN
>>>> modules, while the QCA6390 does, we take two different approaches to how
>>>> me model them in DT.
>>>>
>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
>>>> necessary. The BT and WLAN devices on the device-tree are represented as
>>>> consuming the inputs (relevant to the functionality of each) of the PMU
>>>> directly.
>>>
>>> We are describing the hardware. From the hardware point of view, there
>>> is a PMU. I think at some point we would really like to describe all
>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
>>
>> While I agree with older WiFi+BT units, I don't think it's needed for
>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
>> transparent.
> 
> I don't see any significant difference between WCN6750/WCN6855 and
> WCN7850 from the PMU / power up point of view. Could you please point
> me to the difference?
> 

The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
and BT_EN ordering and the only requirement is to have all input regulators
up before pulling up WLAN_EN and/or BT_EN.

This makes the PMU transparent and BT and WLAN can be described as independent.

Neil

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Mon, 19 Feb 2024 at 11:42, <neil.armstrong@linaro.org> wrote:
>
> On 19/02/2024 10:22, Dmitry Baryshkov wrote:
> > On Mon, 19 Feb 2024 at 10:14, Neil Armstrong <neil.armstrong@linaro.org> wrote:
> >>
> >> On 18/02/2024 13:53, Dmitry Baryshkov wrote:
> >>> On Fri, 16 Feb 2024 at 22:33, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>>>
> >>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>>
> >>>> First, I'd like to apologize for the somewhat chaotic previous iterations
> >>>> of this series and improper versioning which was rightfully pointed out
> >>>> to me. I figured that the scope changed so much that it didn't make sense
> >>>> to consider previous submissions part of the same series as the original
> >>>> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> >>>> versioning going forward.
> >>>>
> >>>> This is the summary of the work so far:
> >>>>
> >>>> v1: Original RFC:
> >>>>
> >>>> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
> >>>>
> >>>> v2: First real patch series (should have been PATCH v2) adding what I
> >>>>       referred to back then as PCI power sequencing:
> >>>>
> >>>> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
> >>>>
> >>>> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
> >>>>       modules inside the QCA6391 package (was largely separate from the
> >>>>       series but probably should have been called PATCH or RFC v3):
> >>>>
> >>>> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
> >>>>
> >>>> v4: Second attempt at the full series with changed scope (introduction of
> >>>>       the pwrseq subsystem, should have been RFC v4)
> >>>>
> >>>> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
> >>>>
> >>>> ===
> >>>>
> >>>> With that out of the way, I'd like to get down to explaining the two
> >>>> problems I'm trying to solve.
> >>>>
> >>>> Problem statement #1: Dynamic bus chicken-and-egg problem.
> >>>>
> >>>> Certain on-board PCI devices need to be powered up before they are can be
> >>>> detected but their PCI drivers won't get bound until the device is
> >>>> powered-up so enabling the relevant resources in the PCI device driver
> >>>> itself is impossible.
> >>>>
> >>>> Problem statement #2: Sharing inter-dependent resources between devices.
> >>>>
> >>>> Certain devices that use separate drivers (often on different busses)
> >>>> share resources (regulators, clocks, etc.). Typically these resources
> >>>> are reference-counted but in some cases there are additional interactions
> >>>> between them to consider, for example specific power-up sequence timings.
> >>>>
> >>>> ===
> >>>>
> >>>> The reason for tackling both of these problems in a single series is the
> >>>> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> >>>> both need to be addressed in order to enable WLAN and Bluetooth support
> >>>> upstream.
> >>>>
> >>>> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> >>>> takes inputs from the host and exposes LDO outputs consumed by the BT and
> >>>> WLAN modules which can be powered-up and down independently. However
> >>>> a delay of 100ms must be respected between enabling the BT- and
> >>>> WLAN-enable GPIOs[*].
> >>>>
> >>>> ===
> >>>>
> >>>> This series is logically split into several sections. I'll go
> >>>> patch-by-patch and explain each step.
> >>>>
> >>>> Patch 1/18:
> >>>>
> >>>> This is a commit taken from the list by Jonathan Cameron that adds
> >>>> a __free() helper for OF nodes. Not strictly related to the series but
> >>>> until said commit ends in next, I need to carry it with this series.
> >>>>
> >>>> Patch 2/18:
> >>>>
> >>>> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> >>>> and sm8550 reference platforms use it in the WCN7850 module.
> >>>>
> >>>> Patches 3/18-6/18:
> >>>>
> >>>> These contain all relevant DT bindings changes. We add new documents for
> >>>> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> >>>> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> >>>> QCA6390.
> >>>>
> >>>> Patches 7/18-9/18:
> >>>>
> >>>> These contain changes to device-tree sources for the three platforms we
> >>>> work with in this series. As the WCN7850 module doesn't require any
> >>>> specific timings introducing dependencies between the Bluetooth and WLAN
> >>>> modules, while the QCA6390 does, we take two different approaches to how
> >>>> me model them in DT.
> >>>>
> >>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> >>>> necessary. The BT and WLAN devices on the device-tree are represented as
> >>>> consuming the inputs (relevant to the functionality of each) of the PMU
> >>>> directly.
> >>>
> >>> We are describing the hardware. From the hardware point of view, there
> >>> is a PMU. I think at some point we would really like to describe all
> >>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> >>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> >>
> >> While I agree with older WiFi+BT units, I don't think it's needed for
> >> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> >> transparent.
> >
> > I don't see any significant difference between WCN6750/WCN6855 and
> > WCN7850 from the PMU / power up point of view. Could you please point
> > me to the difference?
> >
>
> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> and BT_EN ordering and the only requirement is to have all input regulators
> up before pulling up WLAN_EN and/or BT_EN.
>
> This makes the PMU transparent and BT and WLAN can be described as independent.

From the hardware perspective, there is a PMU. It has several LDOs. So
the device tree should have the same style as the previous
generations.

-- 
With best wishes
Dmitry

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>

[snip]

> > >>>>
> > >>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > >>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > >>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > >>>> directly.
> > >>>
> > >>> We are describing the hardware. From the hardware point of view, there
> > >>> is a PMU. I think at some point we would really like to describe all
> > >>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > >>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > >>
> > >> While I agree with older WiFi+BT units, I don't think it's needed for
> > >> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > >> transparent.
> > >
> > > I don't see any significant difference between WCN6750/WCN6855 and
> > > WCN7850 from the PMU / power up point of view. Could you please point
> > > me to the difference?
> > >
> >
> > The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > and BT_EN ordering and the only requirement is to have all input regulators
> > up before pulling up WLAN_EN and/or BT_EN.
> >
> > This makes the PMU transparent and BT and WLAN can be described as independent.
>
> From the hardware perspective, there is a PMU. It has several LDOs. So
> the device tree should have the same style as the previous
> generations.
>

My thinking was this: yes, there is a PMU but describing it has no
benefit (unlike QCA6x90). If we do describe, then we'll end up having
to use pwrseq here despite it not being needed because now we won't be
able to just get regulators from WLAN/BT drivers directly.

So I also vote for keeping it this way. Let's go into the package
detail only if it's required.

Bartosz

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
>
> [snip]
>
> > > >>>>
> > > >>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > > >>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > > >>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > > >>>> directly.
> > > >>>
> > > >>> We are describing the hardware. From the hardware point of view, there
> > > >>> is a PMU. I think at some point we would really like to describe all
> > > >>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > > >>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > > >>
> > > >> While I agree with older WiFi+BT units, I don't think it's needed for
> > > >> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > > >> transparent.
> > > >
> > > > I don't see any significant difference between WCN6750/WCN6855 and
> > > > WCN7850 from the PMU / power up point of view. Could you please point
> > > > me to the difference?
> > > >
> > >
> > > The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > > and BT_EN ordering and the only requirement is to have all input regulators
> > > up before pulling up WLAN_EN and/or BT_EN.
> > >
> > > This makes the PMU transparent and BT and WLAN can be described as independent.
> >
> > From the hardware perspective, there is a PMU. It has several LDOs. So
> > the device tree should have the same style as the previous
> > generations.
> >
>
> My thinking was this: yes, there is a PMU but describing it has no
> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> to use pwrseq here despite it not being needed because now we won't be
> able to just get regulators from WLAN/BT drivers directly.
>
> So I also vote for keeping it this way. Let's go into the package
> detail only if it's required.

The WiFi / BT parts are not powered up by the board regulators. They
are powered up by the PSU. So we are not describing it in the accurate
way.

Moreover, I think we definitely want to move BT driver to use only the
pwrseq power up method. Doing it in the other way results in the code
duplication and possible issues because of the regulator / pwrseq
taking different code paths.


-- 
With best wishes
Dmitry

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 8:32 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 17/02/2024 19:32, Bartosz Golaszewski wrote:
> > On Sat, Feb 17, 2024 at 4:48 PM Mark Brown <broonie@kernel.org> wrote:
> >>
> >> On Fri, Feb 16, 2024 at 09:32:00PM +0100, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>
> >>> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> >>> are powered by the Power Management Unit (PMU) that takes inputs from the
> >>> host and provides LDO outputs. This document describes this module.
> >>
> >> Please submit patches using subject lines reflecting the style for the
> >> subsystem, this makes it easier for people to identify relevant patches.
> >> Look at what existing commits in the area you're changing are doing and
> >> make sure your subject lines visually resemble what they're doing.
> >> There's no need to resubmit to fix this alone.
> >
> > Mark,
> >
> > This is quite vague, could you elaborate? I have no idea what is wrong
> > with this patch.
>
> Use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
>
> Best regards,
> Krzysztof
>

Yes, I always do. And for Documentation/devicetree/bindings/regulator/
the subjects are split 50:50 between "dt-bindings: regulator: ..." and
"regulator: dt-bindings: ...". For Documentation/devicetree/bindings/
it's overwhelmingly "dt-bindings: <subsystem>: ...". It's the first
time someone wants me to send a DT bindings patch without
"dt-bindings" coming first in the subject.

I mean: I can do it alright but it's not stated anywhere explicitly.

Bartosz

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[neil.armstrong]

On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
>> <dmitry.baryshkov@linaro.org> wrote:
>>>
>>
>> [snip]
>>
>>>>>>>>
>>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
>>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
>>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
>>>>>>>> directly.
>>>>>>>
>>>>>>> We are describing the hardware. From the hardware point of view, there
>>>>>>> is a PMU. I think at some point we would really like to describe all
>>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
>>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
>>>>>>
>>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
>>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
>>>>>> transparent.
>>>>>
>>>>> I don't see any significant difference between WCN6750/WCN6855 and
>>>>> WCN7850 from the PMU / power up point of view. Could you please point
>>>>> me to the difference?
>>>>>
>>>>
>>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
>>>> and BT_EN ordering and the only requirement is to have all input regulators
>>>> up before pulling up WLAN_EN and/or BT_EN.
>>>>
>>>> This makes the PMU transparent and BT and WLAN can be described as independent.
>>>
>>>  From the hardware perspective, there is a PMU. It has several LDOs. So
>>> the device tree should have the same style as the previous
>>> generations.
>>>
>>
>> My thinking was this: yes, there is a PMU but describing it has no
>> benefit (unlike QCA6x90). If we do describe, then we'll end up having
>> to use pwrseq here despite it not being needed because now we won't be
>> able to just get regulators from WLAN/BT drivers directly.
>>
>> So I also vote for keeping it this way. Let's go into the package
>> detail only if it's required.
> 
> The WiFi / BT parts are not powered up by the board regulators. They
> are powered up by the PSU. So we are not describing it in the accurate
> way.

I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
this situation the PCIe part is powered with the M.2 slot and the BT side
is powered separately as we currently do it now.

So yes there's a PMU, but it's not an always visible hardware part, from the
SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.

Neil

> 
> Moreover, I think we definitely want to move BT driver to use only the
> pwrseq power up method. Doing it in the other way results in the code
> duplication and possible issues because of the regulator / pwrseq
> taking different code paths.
> 
> 

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Fri, Feb 16, 2024 at 09:32:11PM +0100, Bartosz Golaszewski wrote:

> +static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
> +	{
> +		.name = "vdd",
> +		.load_uA = 16000,
> +	},

I know a bunch of the QC stuff includes these load numbers but are they
actually doing anything constructive?  It keeps coming up that they're
causing a bunch of work and it's not clear that they have any great
effect on modern systems.

> +static int pci_pwrctl_wcn7850_power_on(struct pci_pwrctl_wcn7850_ctx *ctx)
> +{
> +	int ret;
> +
> +	ret = regulator_bulk_enable(ctx->pdata->num_vregs, ctx->regs);
> +	if (ret)
> +		return ret;
> +
> +	ret = clk_prepare_enable(ctx->clk);
> +	if (ret)
> +		return ret;

This won't disable the regulators on error.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:

> +			vreg_pmu_aon_0p59: ldo1 {
> +				regulator-name = "vreg_pmu_aon_0p59";
> +				regulator-min-microvolt = <540000>;
> +				regulator-max-microvolt = <840000>;
> +			};

That's a *very* wide voltage range for a supply that's got a name ending
in _0_p59 which sounds a lot like it should be fixed at 0.59V.
Similarly for a bunch of the other supplies, and I'm not seeing any
evidence that the consumers do any voltage changes here?  There doesn't
appear to be any logic here, I'm not convinced these are validated or
safe constraints.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
>
> > +                     vreg_pmu_aon_0p59: ldo1 {
> > +                             regulator-name = "vreg_pmu_aon_0p59";
> > +                             regulator-min-microvolt = <540000>;
> > +                             regulator-max-microvolt = <840000>;
> > +                     };
>
> That's a *very* wide voltage range for a supply that's got a name ending
> in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> Similarly for a bunch of the other supplies, and I'm not seeing any
> evidence that the consumers do any voltage changes here?  There doesn't
> appear to be any logic here, I'm not convinced these are validated or
> safe constraints.

No, the users don't request any regulators (or rather: software
representations thereof) because - as per the cover letter - no
regulators are created by the PMU driver. This is what is physically
on the board - as the schematics and the datasheet define it. I took
the values from the docs verbatim. In C, we create a power sequencing
provider which doesn't use the regulator framework at all.

Bartosz

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:

> > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > +                             regulator-min-microvolt = <540000>;
> > > +                             regulator-max-microvolt = <840000>;
> > > +                     };

> > That's a *very* wide voltage range for a supply that's got a name ending
> > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > Similarly for a bunch of the other supplies, and I'm not seeing any
> > evidence that the consumers do any voltage changes here?  There doesn't
> > appear to be any logic here, I'm not convinced these are validated or
> > safe constraints.

> No, the users don't request any regulators (or rather: software
> representations thereof) because - as per the cover letter - no
> regulators are created by the PMU driver. This is what is physically
> on the board - as the schematics and the datasheet define it. I took

The above makes no sense.  How can constraints be "what is physically on
the board", particularly variable constrants when there isn't even a
consumer?  What values are you taking from which documentation?  

The cover letter and binding both claimed (buried after large amounts of
changelog) that these PMUs were exposing regulators to consumers and the
DTS puports to do exactly that...

> the values from the docs verbatim. In C, we create a power sequencing
> provider which doesn't use the regulator framework at all.

For something that doesn't use the regulator framework at all what
appears to be a provider in patch 16 ("power: pwrseq: add a driver for
the QCA6390 PMU module") seems to have a lot of regualtor API calls?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package

[Krzysztof Kozlowski]

On 19/02/2024 13:53, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 8:32 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 17/02/2024 19:32, Bartosz Golaszewski wrote:
>>> On Sat, Feb 17, 2024 at 4:48 PM Mark Brown <broonie@kernel.org> wrote:
>>>>
>>>> On Fri, Feb 16, 2024 at 09:32:00PM +0100, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>
>>>>> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
>>>>> are powered by the Power Management Unit (PMU) that takes inputs from the
>>>>> host and provides LDO outputs. This document describes this module.
>>>>
>>>> Please submit patches using subject lines reflecting the style for the
>>>> subsystem, this makes it easier for people to identify relevant patches.
>>>> Look at what existing commits in the area you're changing are doing and
>>>> make sure your subject lines visually resemble what they're doing.
>>>> There's no need to resubmit to fix this alone.
>>>
>>> Mark,
>>>
>>> This is quite vague, could you elaborate? I have no idea what is wrong
>>> with this patch.
>>
>> Use subject prefixes matching the subsystem. You can get them for
>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>> your patch is touching.
>>
>> Best regards,
>> Krzysztof
>>
> 
> Yes, I always do. And for Documentation/devicetree/bindings/regulator/
> the subjects are split 50:50 between "dt-bindings: regulator: ..." and

No, there are only ~54 "dt + regulator" ones and around 400 starting
with "regulator" (Mark removes first prefix if it is not regulator:). So
50 to 400 is not 50:50.


> "regulator: dt-bindings: ...". For Documentation/devicetree/bindings/
> it's overwhelmingly "dt-bindings: <subsystem>: ...". It's the first
> time someone wants me to send a DT bindings patch without
> "dt-bindings" coming first in the subject.
> 
> I mean: I can do it alright but it's not stated anywhere explicitly.

Well, practice was kind of known and obvious, but it is also stated:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/submitting-patches.rst?h=next-20240219#n18



Best regards,
Krzysztof

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
>
> On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> > On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>
> >> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> >> <dmitry.baryshkov@linaro.org> wrote:
> >>>
> >>
> >> [snip]
> >>
> >>>>>>>>
> >>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> >>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
> >>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
> >>>>>>>> directly.
> >>>>>>>
> >>>>>>> We are describing the hardware. From the hardware point of view, there
> >>>>>>> is a PMU. I think at some point we would really like to describe all
> >>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> >>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> >>>>>>
> >>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
> >>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> >>>>>> transparent.
> >>>>>
> >>>>> I don't see any significant difference between WCN6750/WCN6855 and
> >>>>> WCN7850 from the PMU / power up point of view. Could you please point
> >>>>> me to the difference?
> >>>>>
> >>>>
> >>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> >>>> and BT_EN ordering and the only requirement is to have all input regulators
> >>>> up before pulling up WLAN_EN and/or BT_EN.
> >>>>
> >>>> This makes the PMU transparent and BT and WLAN can be described as independent.
> >>>
> >>>  From the hardware perspective, there is a PMU. It has several LDOs. So
> >>> the device tree should have the same style as the previous
> >>> generations.
> >>>
> >>
> >> My thinking was this: yes, there is a PMU but describing it has no
> >> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> >> to use pwrseq here despite it not being needed because now we won't be
> >> able to just get regulators from WLAN/BT drivers directly.
> >>
> >> So I also vote for keeping it this way. Let's go into the package
> >> detail only if it's required.
> >
> > The WiFi / BT parts are not powered up by the board regulators. They
> > are powered up by the PSU. So we are not describing it in the accurate
> > way.
>
> I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
> this situation the PCIe part is powered with the M.2 slot and the BT side
> is powered separately as we currently do it now.

QCA6390 can also be used as a discrete M.2 card.

> So yes there's a PMU, but it's not an always visible hardware part, from the
> SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.

From the hardware point:
- There is a PMU
- The PMU is connected to the board supplies
- Both WiFi and BT parts are connected to the PMU
- The BT_EN / WLAN_EN pins are not connected to the PMU

So, not representing the PMU in the device tree is a simplification.

>
> Neil
>
> >
> > Moreover, I think we definitely want to move BT driver to use only the
> > pwrseq power up method. Doing it in the other way results in the code
> > duplication and possible issues because of the regulator / pwrseq
> > taking different code paths.

-- 
With best wishes
Dmitry

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
>
> > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > +                             regulator-min-microvolt = <540000>;
> > > > +                             regulator-max-microvolt = <840000>;
> > > > +                     };
>
> > > That's a *very* wide voltage range for a supply that's got a name ending

Because it's an error, it should have been 640000. Thanks for spotting it.

> > > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > > Similarly for a bunch of the other supplies, and I'm not seeing any
> > > evidence that the consumers do any voltage changes here?  There doesn't
> > > appear to be any logic here, I'm not convinced these are validated or
> > > safe constraints.
>
> > No, the users don't request any regulators (or rather: software
> > representations thereof) because - as per the cover letter - no
> > regulators are created by the PMU driver. This is what is physically
> > on the board - as the schematics and the datasheet define it. I took
>
> The above makes no sense.  How can constraints be "what is physically on
> the board", particularly variable constrants when there isn't even a
> consumer?  What values are you taking from which documentation?
>

The operating conditions for PMU outputs. I took them from a
confidential datasheet. There's a table for input constraints and
possible output values.

And what do you mean by there not being any consumers? The WLAN and BT
*are* the consumers.

> The cover letter and binding both claimed (buried after large amounts of
> changelog) that these PMUs were exposing regulators to consumers and the
> DTS puports to do exactly that...
>

Yes, but I'm not sure what the question is.

> > the values from the docs verbatim. In C, we create a power sequencing
> > provider which doesn't use the regulator framework at all.
>
> For something that doesn't use the regulator framework at all what
> appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> the QCA6390 PMU module") seems to have a lot of regualtor API calls?

This driver is a power sequencing *provider* but also a regulator
*consumer*. It gets regulators from the host and exposes a power
sequencer to *its* consumers (WLAN and BT). On DT it exposes
regulators (LDO outputs of the PMU) but we don't instantiate them in
C.

Bart

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 6:50 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Feb 16, 2024 at 09:32:11PM +0100, Bartosz Golaszewski wrote:
>
> > +static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
> > +     {
> > +             .name = "vdd",
> > +             .load_uA = 16000,
> > +     },
>
> I know a bunch of the QC stuff includes these load numbers but are they
> actually doing anything constructive?  It keeps coming up that they're
> causing a bunch of work and it's not clear that they have any great
> effect on modern systems.
>

Yes, we have what is called a high-power mode and a low-power mode in
regulators and these values are used to determine which one to use.

> > +static int pci_pwrctl_wcn7850_power_on(struct pci_pwrctl_wcn7850_ctx *ctx)
> > +{
> > +     int ret;
> > +
> > +     ret = regulator_bulk_enable(ctx->pdata->num_vregs, ctx->regs);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = clk_prepare_enable(ctx->clk);
> > +     if (ret)
> > +             return ret;
>
> This won't disable the regulators on error.

Indeed. Thanks for catching this.

Bart

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Tue, Feb 20, 2024 at 12:22:42PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 6:50 PM Mark Brown <broonie@kernel.org> wrote:
> > On Fri, Feb 16, 2024 at 09:32:11PM +0100, Bartosz Golaszewski wrote:

> > > +static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
> > > +     {
> > > +             .name = "vdd",
> > > +             .load_uA = 16000,
> > > +     },

> > I know a bunch of the QC stuff includes these load numbers but are they
> > actually doing anything constructive?  It keeps coming up that they're
> > causing a bunch of work and it's not clear that they have any great
> > effect on modern systems.

> Yes, we have what is called a high-power mode and a low-power mode in
> regulators and these values are used to determine which one to use.

Are you *sure* this actually happens (and that the regulators don't
figure it out by themselves), especially given that the consumers are
just specifying the load once rather than varying it dynamically at
runtime which is supposed to be the use case for this API?  This API is
intended to be used dynamically, if the regulator always needs to be in
a particular mode just configure that statically.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:

> > > No, the users don't request any regulators (or rather: software
> > > representations thereof) because - as per the cover letter - no
> > > regulators are created by the PMU driver. This is what is physically
> > > on the board - as the schematics and the datasheet define it. I took

> > The above makes no sense.  How can constraints be "what is physically on
> > the board", particularly variable constrants when there isn't even a
> > consumer?  What values are you taking from which documentation?

> The operating conditions for PMU outputs. I took them from a
> confidential datasheet. There's a table for input constraints and
> possible output values.

That sounds like you're just putting the maximum range of voltages that
the PMU can output in there.  This is a fundamental misunderstanding of
what the constraints are for, the constraints exist to specify what is
safe on a specific board which will in essentially all cases be much
more restricted.  The regulator driver should describe whatever the PMU
can support by itself, the constraints whatever is actually safe and
functional on the specific board.

> And what do you mean by there not being any consumers? The WLAN and BT
> *are* the consumers.

There are no drivers that bind to the regulators and vary the voltages
at runtime.

> > > the values from the docs verbatim. In C, we create a power sequencing
> > > provider which doesn't use the regulator framework at all.

> > For something that doesn't use the regulator framework at all what
> > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > the QCA6390 PMU module") seems to have a lot of regualtor API calls?

> This driver is a power sequencing *provider* but also a regulator
> *consumer*. It gets regulators from the host and exposes a power
> sequencer to *its* consumers (WLAN and BT). On DT it exposes
> regulators (LDO outputs of the PMU) but we don't instantiate them in
> C.

Right, which sounds a lot like being a user of the regualtor framework.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Feb 20, 2024 at 2:31 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
> > On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
>
> > > > No, the users don't request any regulators (or rather: software
> > > > representations thereof) because - as per the cover letter - no
> > > > regulators are created by the PMU driver. This is what is physically
> > > > on the board - as the schematics and the datasheet define it. I took
>
> > > The above makes no sense.  How can constraints be "what is physically on
> > > the board", particularly variable constrants when there isn't even a
> > > consumer?  What values are you taking from which documentation?
>
> > The operating conditions for PMU outputs. I took them from a
> > confidential datasheet. There's a table for input constraints and
> > possible output values.
>
> That sounds like you're just putting the maximum range of voltages that
> the PMU can output in there.  This is a fundamental misunderstanding of
> what the constraints are for, the constraints exist to specify what is
> safe on a specific board which will in essentially all cases be much
> more restricted.  The regulator driver should describe whatever the PMU
> can support by itself, the constraints whatever is actually safe and
> functional on the specific board.
>

Ok, got it. Yeah I misunderstood that, but I think it's maybe the
second or third time I'm adding a regulators node myself to DT. I'll
change that.

> > And what do you mean by there not being any consumers? The WLAN and BT
> > *are* the consumers.
>
> There are no drivers that bind to the regulators and vary the voltages
> at runtime.
>

Even with the above misunderstanding clarified: so what? DT is the
representation of hardware. There's nothing that obligates us to model
DT sources in drivers 1:1.

> > > > the values from the docs verbatim. In C, we create a power sequencing
> > > > provider which doesn't use the regulator framework at all.
>
> > > For something that doesn't use the regulator framework at all what
> > > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > > the QCA6390 PMU module") seems to have a lot of regualtor API calls?
>
> > This driver is a power sequencing *provider* but also a regulator
> > *consumer*. It gets regulators from the host and exposes a power
> > sequencer to *its* consumers (WLAN and BT). On DT it exposes
> > regulators (LDO outputs of the PMU) but we don't instantiate them in
> > C.
>
> Right, which sounds a lot like being a user of the regualtor framework.

Ok, I meant "user" as a regulator provider but maybe I wasn't clear enough.

Bart

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Tue, Feb 20, 2024 at 02:38:33PM +0100, Bartosz Golaszewski wrote:
> On Tue, Feb 20, 2024 at 2:31 PM Mark Brown <broonie@kernel.org> wrote:
> > On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:

> > > And what do you mean by there not being any consumers? The WLAN and BT
> > > *are* the consumers.

> > There are no drivers that bind to the regulators and vary the voltages
> > at runtime.

> Even with the above misunderstanding clarified: so what? DT is the
> representation of hardware. There's nothing that obligates us to model
> DT sources in drivers 1:1.

It is generally a bad sign if there is a voltage range specified on a
regulator that's not got any indication that the voltage is going to be
actively managed, especially in situations like with several of the
supplies the DT was specifying where there are clear indications that
the supply is intended to be fixed voltage (or cases where every single
supply has a voltage range which would be highly unusual).  Looking at
the consumers might provide an explanation for such unusual and likely
incorrect constraints, and the lack of any consumers in conjunction with 
other warning signs reenforces those warning signs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Feb 20, 2024 at 2:48 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 20, 2024 at 02:38:33PM +0100, Bartosz Golaszewski wrote:
> > On Tue, Feb 20, 2024 at 2:31 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
>
> > > > And what do you mean by there not being any consumers? The WLAN and BT
> > > > *are* the consumers.
>
> > > There are no drivers that bind to the regulators and vary the voltages
> > > at runtime.
>
> > Even with the above misunderstanding clarified: so what? DT is the
> > representation of hardware. There's nothing that obligates us to model
> > DT sources in drivers 1:1.
>
> It is generally a bad sign if there is a voltage range specified on a
> regulator that's not got any indication that the voltage is going to be
> actively managed, especially in situations like with several of the
> supplies the DT was specifying where there are clear indications that
> the supply is intended to be fixed voltage (or cases where every single
> supply has a voltage range which would be highly unusual).  Looking at
> the consumers might provide an explanation for such unusual and likely
> incorrect constraints, and the lack of any consumers in conjunction with
> other warning signs reenforces those warning signs.

What do you recommend? No values at all in these regulators as it's
the PMU which will manage those on its own once powered up by the host
PMIC?

Bartosz

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Tue, Feb 20, 2024 at 02:51:25PM +0100, Bartosz Golaszewski wrote:
> On Tue, Feb 20, 2024 at 2:48 PM Mark Brown <broonie@kernel.org> wrote:

> > It is generally a bad sign if there is a voltage range specified on a
> > regulator that's not got any indication that the voltage is going to be
> > actively managed, especially in situations like with several of the
> > supplies the DT was specifying where there are clear indications that
> > the supply is intended to be fixed voltage (or cases where every single
> > supply has a voltage range which would be highly unusual).  Looking at
> > the consumers might provide an explanation for such unusual and likely
> > incorrect constraints, and the lack of any consumers in conjunction with
> > other warning signs reenforces those warning signs.

> What do you recommend? No values at all in these regulators as it's
> the PMU which will manage those on its own once powered up by the host
> PMIC?

Unless something is actively going to change the voltages at runtime
or Linux needs to set a specific voltage (in which case minimum and
maximum should be identical) there should be nothing specified.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Dmitry Baryshkov]

On Tue, 20 Feb 2024 at 13:16, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> >
> > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> >
> > > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > > +                             regulator-min-microvolt = <540000>;
> > > > > +                             regulator-max-microvolt = <840000>;
> > > > > +                     };
> >
> > > > That's a *very* wide voltage range for a supply that's got a name ending
>
> Because it's an error, it should have been 640000. Thanks for spotting it.

According to the datasheet, VDD08_PMU_AON_O goes up to 0.85V then down
to 0.59V, which is the working voltage.

VDD08_PMU_RFA_CMN is normally at 0.8V, but goes to 0.4V during sleep.

>
> > > > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > > > Similarly for a bunch of the other supplies, and I'm not seeing any
> > > > evidence that the consumers do any voltage changes here?  There doesn't
> > > > appear to be any logic here, I'm not convinced these are validated or
> > > > safe constraints.
> >
> > > No, the users don't request any regulators (or rather: software
> > > representations thereof) because - as per the cover letter - no
> > > regulators are created by the PMU driver. This is what is physically
> > > on the board - as the schematics and the datasheet define it. I took
> >
> > The above makes no sense.  How can constraints be "what is physically on
> > the board", particularly variable constrants when there isn't even a
> > consumer?  What values are you taking from which documentation?
> >
>
> The operating conditions for PMU outputs. I took them from a
> confidential datasheet. There's a table for input constraints and
> possible output values.
>
> And what do you mean by there not being any consumers? The WLAN and BT
> *are* the consumers.
>
> > The cover letter and binding both claimed (buried after large amounts of
> > changelog) that these PMUs were exposing regulators to consumers and the
> > DTS puports to do exactly that...
> >
>
> Yes, but I'm not sure what the question is.
>
> > > the values from the docs verbatim. In C, we create a power sequencing
> > > provider which doesn't use the regulator framework at all.
> >
> > For something that doesn't use the regulator framework at all what
> > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > the QCA6390 PMU module") seems to have a lot of regualtor API calls?
>
> This driver is a power sequencing *provider* but also a regulator
> *consumer*. It gets regulators from the host and exposes a power
> sequencer to *its* consumers (WLAN and BT). On DT it exposes
> regulators (LDO outputs of the PMU) but we don't instantiate them in
> C.
>
> Bart



-- 
With best wishes
Dmitry

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Feb 20, 2024 at 5:30 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Tue, 20 Feb 2024 at 13:16, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > >
> > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > > > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> > >
> > > > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > > > +                             regulator-min-microvolt = <540000>;
> > > > > > +                             regulator-max-microvolt = <840000>;
> > > > > > +                     };
> > >
> > > > > That's a *very* wide voltage range for a supply that's got a name ending
> >
> > Because it's an error, it should have been 640000. Thanks for spotting it.
>
> According to the datasheet, VDD08_PMU_AON_O goes up to 0.85V then down
> to 0.59V, which is the working voltage.
>

Hmm indeed this is what figure 3.4 says but table 3-2 says the maximum is 0.64V.

> VDD08_PMU_RFA_CMN is normally at 0.8V, but goes to 0.4V during sleep.
>

Again figure 3.4 and table 3-2 disagree unless I'm missing something.

Bart

[snip]

Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Dmitry Baryshkov]

On Tue, 20 Feb 2024 at 19:53, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Tue, Feb 20, 2024 at 5:30 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Tue, 20 Feb 2024 at 13:16, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > > > > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> > > >
> > > > > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > > > > +                             regulator-min-microvolt = <540000>;
> > > > > > > +                             regulator-max-microvolt = <840000>;
> > > > > > > +                     };
> > > >
> > > > > > That's a *very* wide voltage range for a supply that's got a name ending
> > >
> > > Because it's an error, it should have been 640000. Thanks for spotting it.
> >
> > According to the datasheet, VDD08_PMU_AON_O goes up to 0.85V then down
> > to 0.59V, which is the working voltage.
> >
>
> Hmm indeed this is what figure 3.4 says but table 3-2 says the maximum is 0.64V.
>
> > VDD08_PMU_RFA_CMN is normally at 0.8V, but goes to 0.4V during sleep.
> >
>
> Again figure 3.4 and table 3-2 disagree unless I'm missing something.

I suspect that the table you have mentioned provides normal working
conditions for the PMU, while power-up and sleep might be outside of
'normal' conditions.

I suppose that these outputs are underspecified in the datasheet. I
think we can omit the values here.

-- 
With best wishes
Dmitry

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Konrad Dybcio]

On 20.02.2024 13:47, Mark Brown wrote:
> On Tue, Feb 20, 2024 at 12:22:42PM +0100, Bartosz Golaszewski wrote:
>> On Mon, Feb 19, 2024 at 6:50 PM Mark Brown <broonie@kernel.org> wrote:
>>> On Fri, Feb 16, 2024 at 09:32:11PM +0100, Bartosz Golaszewski wrote:
> 
>>>> +static struct pci_pwrctl_wcn7850_vreg pci_pwrctl_wcn7850_vregs[] = {
>>>> +     {
>>>> +             .name = "vdd",
>>>> +             .load_uA = 16000,
>>>> +     },
> 
>>> I know a bunch of the QC stuff includes these load numbers but are they
>>> actually doing anything constructive?  It keeps coming up that they're
>>> causing a bunch of work and it's not clear that they have any great
>>> effect on modern systems.
> 
>> Yes, we have what is called a high-power mode and a low-power mode in
>> regulators and these values are used to determine which one to use.
> 
> Are you *sure* this actually happens (and that the regulators don't
> figure it out by themselves), especially given that the consumers are
> just specifying the load once rather than varying it dynamically at
> runtime which is supposed to be the use case for this API?  This API is
> intended to be used dynamically, if the regulator always needs to be in
> a particular mode just configure that statically.

*AFAIU*

The regulators aggregate the requested current (there may be
multiple consumers) and then it's decided if it's high enough
to jump into HPM.

Konrad

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Tue, Feb 20, 2024 at 10:21:04PM +0100, Konrad Dybcio wrote:
> On 20.02.2024 13:47, Mark Brown wrote:

> > Are you *sure* this actually happens (and that the regulators don't
> > figure it out by themselves), especially given that the consumers are
> > just specifying the load once rather than varying it dynamically at
> > runtime which is supposed to be the use case for this API?  This API is
> > intended to be used dynamically, if the regulator always needs to be in
> > a particular mode just configure that statically.

> *AFAIU*

> The regulators aggregate the requested current (there may be
> multiple consumers) and then it's decided if it's high enough
> to jump into HPM.

Yes, that's the theory - I just question if it actually does something
useful in practice.  Between regulators getting more and more able to
figure out mode switching autonomously based on load monitoring and them
getting more efficient it's become very unclear if this actually
accomplishes anything, the only usage is the Qualcomm stuff and that's
all really unsophisticated and has an air of something that's being
cut'n'pasted forwards rather than delivering practical results.  There
is some value at ultra low loads, but that's more for suspend modes than
for actual use.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Bartosz Golaszewski]

On Wed, Feb 21, 2024 at 12:44 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 20, 2024 at 10:21:04PM +0100, Konrad Dybcio wrote:
> > On 20.02.2024 13:47, Mark Brown wrote:
>
> > > Are you *sure* this actually happens (and that the regulators don't
> > > figure it out by themselves), especially given that the consumers are
> > > just specifying the load once rather than varying it dynamically at
> > > runtime which is supposed to be the use case for this API?  This API is
> > > intended to be used dynamically, if the regulator always needs to be in
> > > a particular mode just configure that statically.
>
> > *AFAIU*
>
> > The regulators aggregate the requested current (there may be
> > multiple consumers) and then it's decided if it's high enough
> > to jump into HPM.
>
> Yes, that's the theory - I just question if it actually does something
> useful in practice.  Between regulators getting more and more able to
> figure out mode switching autonomously based on load monitoring and them
> getting more efficient it's become very unclear if this actually
> accomplishes anything, the only usage is the Qualcomm stuff and that's
> all really unsophisticated and has an air of something that's being
> cut'n'pasted forwards rather than delivering practical results.  There
> is some value at ultra low loads, but that's more for suspend modes than
> for actual use.

Removing it would be out of scope for this series and I don't really
want to introduce any undefined behavior when doing a big development
like that. I'll think about it separately.

Bart

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Bartosz Golaszewski]

On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
> >
> > On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> > > On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >>
> > >> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> > >> <dmitry.baryshkov@linaro.org> wrote:
> > >>>
> > >>
> > >> [snip]
> > >>
> > >>>>>>>>
> > >>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > >>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > >>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > >>>>>>>> directly.
> > >>>>>>>
> > >>>>>>> We are describing the hardware. From the hardware point of view, there
> > >>>>>>> is a PMU. I think at some point we would really like to describe all
> > >>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > >>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > >>>>>>
> > >>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
> > >>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > >>>>>> transparent.
> > >>>>>
> > >>>>> I don't see any significant difference between WCN6750/WCN6855 and
> > >>>>> WCN7850 from the PMU / power up point of view. Could you please point
> > >>>>> me to the difference?
> > >>>>>
> > >>>>
> > >>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > >>>> and BT_EN ordering and the only requirement is to have all input regulators
> > >>>> up before pulling up WLAN_EN and/or BT_EN.
> > >>>>
> > >>>> This makes the PMU transparent and BT and WLAN can be described as independent.
> > >>>
> > >>>  From the hardware perspective, there is a PMU. It has several LDOs. So
> > >>> the device tree should have the same style as the previous
> > >>> generations.
> > >>>
> > >>
> > >> My thinking was this: yes, there is a PMU but describing it has no
> > >> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> > >> to use pwrseq here despite it not being needed because now we won't be
> > >> able to just get regulators from WLAN/BT drivers directly.
> > >>
> > >> So I also vote for keeping it this way. Let's go into the package
> > >> detail only if it's required.
> > >
> > > The WiFi / BT parts are not powered up by the board regulators. They
> > > are powered up by the PSU. So we are not describing it in the accurate
> > > way.
> >
> > I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
> > this situation the PCIe part is powered with the M.2 slot and the BT side
> > is powered separately as we currently do it now.
>
> QCA6390 can also be used as a discrete M.2 card.
>
> > So yes there's a PMU, but it's not an always visible hardware part, from the
> > SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
>
> From the hardware point:
> - There is a PMU
> - The PMU is connected to the board supplies
> - Both WiFi and BT parts are connected to the PMU
> - The BT_EN / WLAN_EN pins are not connected to the PMU
>
> So, not representing the PMU in the device tree is a simplification.
>

What about the existing WLAN and BT users of similar packages? We
would have to deprecate a lot of existing bindings. I don't think it's
worth it.

The WCN7850 is already described in bindings as consuming what is PMUs
inputs and not its outputs.

Bart

> >
> > Neil
> >
> > >
> > > Moreover, I think we definitely want to move BT driver to use only the
> > > pwrseq power up method. Doing it in the other way results in the code
> > > duplication and possible issues because of the regulator / pwrseq
> > > taking different code paths.
>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Thu, 22 Feb 2024 at 13:00, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
> > >
> > > On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> > > > On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > >>
> > > >> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> > > >> <dmitry.baryshkov@linaro.org> wrote:
> > > >>>
> > > >>
> > > >> [snip]
> > > >>
> > > >>>>>>>>
> > > >>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > > >>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > > >>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > > >>>>>>>> directly.
> > > >>>>>>>
> > > >>>>>>> We are describing the hardware. From the hardware point of view, there
> > > >>>>>>> is a PMU. I think at some point we would really like to describe all
> > > >>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > > >>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > > >>>>>>
> > > >>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
> > > >>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > > >>>>>> transparent.
> > > >>>>>
> > > >>>>> I don't see any significant difference between WCN6750/WCN6855 and
> > > >>>>> WCN7850 from the PMU / power up point of view. Could you please point
> > > >>>>> me to the difference?
> > > >>>>>
> > > >>>>
> > > >>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > > >>>> and BT_EN ordering and the only requirement is to have all input regulators
> > > >>>> up before pulling up WLAN_EN and/or BT_EN.
> > > >>>>
> > > >>>> This makes the PMU transparent and BT and WLAN can be described as independent.
> > > >>>
> > > >>>  From the hardware perspective, there is a PMU. It has several LDOs. So
> > > >>> the device tree should have the same style as the previous
> > > >>> generations.
> > > >>>
> > > >>
> > > >> My thinking was this: yes, there is a PMU but describing it has no
> > > >> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> > > >> to use pwrseq here despite it not being needed because now we won't be
> > > >> able to just get regulators from WLAN/BT drivers directly.
> > > >>
> > > >> So I also vote for keeping it this way. Let's go into the package
> > > >> detail only if it's required.
> > > >
> > > > The WiFi / BT parts are not powered up by the board regulators. They
> > > > are powered up by the PSU. So we are not describing it in the accurate
> > > > way.
> > >
> > > I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
> > > this situation the PCIe part is powered with the M.2 slot and the BT side
> > > is powered separately as we currently do it now.
> >
> > QCA6390 can also be used as a discrete M.2 card.
> >
> > > So yes there's a PMU, but it's not an always visible hardware part, from the
> > > SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
> >
> > From the hardware point:
> > - There is a PMU
> > - The PMU is connected to the board supplies
> > - Both WiFi and BT parts are connected to the PMU
> > - The BT_EN / WLAN_EN pins are not connected to the PMU
> >
> > So, not representing the PMU in the device tree is a simplification.
> >
>
> What about the existing WLAN and BT users of similar packages? We
> would have to deprecate a lot of existing bindings. I don't think it's
> worth it.

We have bindings that are not reflecting the hardware. So yes, we
should gradually update them once the powerseq is merged.

> The WCN7850 is already described in bindings as consuming what is PMUs
> inputs and not its outputs.

So do WCN6855 and QCA6391 BlueTooth parts.

>
> Bart
>
> > >
> > > Neil
> > >
> > > >
> > > > Moreover, I think we definitely want to move BT driver to use only the
> > > > pwrseq power up method. Doing it in the other way results in the code
> > > > duplication and possible issues because of the regulator / pwrseq
> > > > taking different code paths.
> >
> > --
> > With best wishes
> > Dmitry



-- 
With best wishes
Dmitry

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On Thu, Feb 22, 2024 at 10:22:50AM +0100, Bartosz Golaszewski wrote:
> On Wed, Feb 21, 2024 at 12:44 AM Mark Brown <broonie@kernel.org> wrote:

> > Yes, that's the theory - I just question if it actually does something
> > useful in practice.  Between regulators getting more and more able to
> > figure out mode switching autonomously based on load monitoring and them
> > getting more efficient it's become very unclear if this actually
> > accomplishes anything, the only usage is the Qualcomm stuff and that's
> > all really unsophisticated and has an air of something that's being
> > cut'n'pasted forwards rather than delivering practical results.  There
> > is some value at ultra low loads, but that's more for suspend modes than
> > for actual use.

> Removing it would be out of scope for this series and I don't really
> want to introduce any undefined behavior when doing a big development
> like that. I'll think about it separately.

This is new code?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Bartosz Golaszewski]

On Thu, Feb 22, 2024 at 1:21 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Feb 22, 2024 at 10:22:50AM +0100, Bartosz Golaszewski wrote:
> > On Wed, Feb 21, 2024 at 12:44 AM Mark Brown <broonie@kernel.org> wrote:
>
> > > Yes, that's the theory - I just question if it actually does something
> > > useful in practice.  Between regulators getting more and more able to
> > > figure out mode switching autonomously based on load monitoring and them
> > > getting more efficient it's become very unclear if this actually
> > > accomplishes anything, the only usage is the Qualcomm stuff and that's
> > > all really unsophisticated and has an air of something that's being
> > > cut'n'pasted forwards rather than delivering practical results.  There
> > > is some value at ultra low loads, but that's more for suspend modes than
> > > for actual use.
>
> > Removing it would be out of scope for this series and I don't really
> > want to introduce any undefined behavior when doing a big development
> > like that. I'll think about it separately.
>
> This is new code?

It's a new driver but Qualcomm standard has been to provide the load
values. If it's really unnecessary then maybe let's consider it
separately and possibly rework globally?

Bart

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Bartosz Golaszewski]

On Thu, Feb 22, 2024 at 12:27 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Thu, 22 Feb 2024 at 13:00, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> > >
> > > On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
> > > >
> > > > On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> > > > > On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > >>
> > > > >> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> > > > >> <dmitry.baryshkov@linaro.org> wrote:
> > > > >>>
> > > > >>
> > > > >> [snip]
> > > > >>
> > > > >>>>>>>>
> > > > >>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > > > >>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > > > >>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > > > >>>>>>>> directly.
> > > > >>>>>>>
> > > > >>>>>>> We are describing the hardware. From the hardware point of view, there
> > > > >>>>>>> is a PMU. I think at some point we would really like to describe all
> > > > >>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > > > >>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > > > >>>>>>
> > > > >>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
> > > > >>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > > > >>>>>> transparent.
> > > > >>>>>
> > > > >>>>> I don't see any significant difference between WCN6750/WCN6855 and
> > > > >>>>> WCN7850 from the PMU / power up point of view. Could you please point
> > > > >>>>> me to the difference?
> > > > >>>>>
> > > > >>>>
> > > > >>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > > > >>>> and BT_EN ordering and the only requirement is to have all input regulators
> > > > >>>> up before pulling up WLAN_EN and/or BT_EN.
> > > > >>>>
> > > > >>>> This makes the PMU transparent and BT and WLAN can be described as independent.
> > > > >>>
> > > > >>>  From the hardware perspective, there is a PMU. It has several LDOs. So
> > > > >>> the device tree should have the same style as the previous
> > > > >>> generations.
> > > > >>>
> > > > >>
> > > > >> My thinking was this: yes, there is a PMU but describing it has no
> > > > >> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> > > > >> to use pwrseq here despite it not being needed because now we won't be
> > > > >> able to just get regulators from WLAN/BT drivers directly.
> > > > >>
> > > > >> So I also vote for keeping it this way. Let's go into the package
> > > > >> detail only if it's required.
> > > > >
> > > > > The WiFi / BT parts are not powered up by the board regulators. They
> > > > > are powered up by the PSU. So we are not describing it in the accurate
> > > > > way.
> > > >
> > > > I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
> > > > this situation the PCIe part is powered with the M.2 slot and the BT side
> > > > is powered separately as we currently do it now.
> > >
> > > QCA6390 can also be used as a discrete M.2 card.
> > >
> > > > So yes there's a PMU, but it's not an always visible hardware part, from the
> > > > SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
> > >
> > > From the hardware point:
> > > - There is a PMU
> > > - The PMU is connected to the board supplies
> > > - Both WiFi and BT parts are connected to the PMU
> > > - The BT_EN / WLAN_EN pins are not connected to the PMU
> > >
> > > So, not representing the PMU in the device tree is a simplification.
> > >
> >
> > What about the existing WLAN and BT users of similar packages? We
> > would have to deprecate a lot of existing bindings. I don't think it's
> > worth it.
>
> We have bindings that are not reflecting the hardware. So yes, we
> should gradually update them once the powerseq is merged.
>
> > The WCN7850 is already described in bindings as consuming what is PMUs
> > inputs and not its outputs.
>
> So do WCN6855 and QCA6391 BlueTooth parts.
>

That is not true for the latter, this series is adding regulators for it.

Bart

> >
> > Bart
> >
> > > >
> > > > Neil
> > > >
> > > > >
> > > > > Moreover, I think we definitely want to move BT driver to use only the
> > > > > pwrseq power up method. Doing it in the other way results in the code
> > > > > duplication and possible issues because of the regulator / pwrseq
> > > > > taking different code paths.
> > >
> > > --
> > > With best wishes
> > > Dmitry
>
>
>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Dmitry Baryshkov]

On Thu, 22 Feb 2024 at 14:27, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Thu, Feb 22, 2024 at 12:27 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Thu, 22 Feb 2024 at 13:00, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
> > > <dmitry.baryshkov@linaro.org> wrote:
> > > >
> > > > On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
> > > > >
> > > > > On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> > > > > > On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > > >>
> > > > > >> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> > > > > >> <dmitry.baryshkov@linaro.org> wrote:
> > > > > >>>
> > > > > >>
> > > > > >> [snip]
> > > > > >>
> > > > > >>>>>>>>
> > > > > >>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > > > > >>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > > > > >>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > > > > >>>>>>>> directly.
> > > > > >>>>>>>
> > > > > >>>>>>> We are describing the hardware. From the hardware point of view, there
> > > > > >>>>>>> is a PMU. I think at some point we would really like to describe all
> > > > > >>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > > > > >>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > > > > >>>>>>
> > > > > >>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
> > > > > >>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > > > > >>>>>> transparent.
> > > > > >>>>>
> > > > > >>>>> I don't see any significant difference between WCN6750/WCN6855 and
> > > > > >>>>> WCN7850 from the PMU / power up point of view. Could you please point
> > > > > >>>>> me to the difference?
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > > > > >>>> and BT_EN ordering and the only requirement is to have all input regulators
> > > > > >>>> up before pulling up WLAN_EN and/or BT_EN.
> > > > > >>>>
> > > > > >>>> This makes the PMU transparent and BT and WLAN can be described as independent.
> > > > > >>>
> > > > > >>>  From the hardware perspective, there is a PMU. It has several LDOs. So
> > > > > >>> the device tree should have the same style as the previous
> > > > > >>> generations.
> > > > > >>>
> > > > > >>
> > > > > >> My thinking was this: yes, there is a PMU but describing it has no
> > > > > >> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> > > > > >> to use pwrseq here despite it not being needed because now we won't be
> > > > > >> able to just get regulators from WLAN/BT drivers directly.
> > > > > >>
> > > > > >> So I also vote for keeping it this way. Let's go into the package
> > > > > >> detail only if it's required.
> > > > > >
> > > > > > The WiFi / BT parts are not powered up by the board regulators. They
> > > > > > are powered up by the PSU. So we are not describing it in the accurate
> > > > > > way.
> > > > >
> > > > > I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
> > > > > this situation the PCIe part is powered with the M.2 slot and the BT side
> > > > > is powered separately as we currently do it now.
> > > >
> > > > QCA6390 can also be used as a discrete M.2 card.
> > > >
> > > > > So yes there's a PMU, but it's not an always visible hardware part, from the
> > > > > SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
> > > >
> > > > From the hardware point:
> > > > - There is a PMU
> > > > - The PMU is connected to the board supplies
> > > > - Both WiFi and BT parts are connected to the PMU
> > > > - The BT_EN / WLAN_EN pins are not connected to the PMU
> > > >
> > > > So, not representing the PMU in the device tree is a simplification.
> > > >
> > >
> > > What about the existing WLAN and BT users of similar packages? We
> > > would have to deprecate a lot of existing bindings. I don't think it's
> > > worth it.
> >
> > We have bindings that are not reflecting the hardware. So yes, we
> > should gradually update them once the powerseq is merged.
> >
> > > The WCN7850 is already described in bindings as consuming what is PMUs
> > > inputs and not its outputs.
> >
> > So do WCN6855 and QCA6391 BlueTooth parts.
> >
>
> That is not true for the latter, this series is adding regulators for it.

But the bindings exist already, so you still have to extend it,
deprecating regulator-less bindings.

Bartosz, I really don't understand what is the issue there. There is a
PMU. As such it should be represented in the DT and it can be handled
by the same driver as you are adding for QCA6390.

>
> Bart
>
> > >
> > > Bart
> > >
> > > > >
> > > > > Neil
> > > > >
> > > > > >
> > > > > > Moreover, I think we definitely want to move BT driver to use only the
> > > > > > pwrseq power up method. Doing it in the other way results in the code
> > > > > > duplication and possible issues because of the regulator / pwrseq
> > > > > > taking different code paths.
> > > >
> > > > --
> > > > With best wishes
> > > > Dmitry
> >
> >
> >
> > --
> > With best wishes
> > Dmitry



-- 
With best wishes
Dmitry

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Bartosz Golaszewski]

On Thu, Feb 22, 2024 at 1:47 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Thu, 22 Feb 2024 at 14:27, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Thu, Feb 22, 2024 at 12:27 PM Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> > >
> > > On Thu, 22 Feb 2024 at 13:00, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > >
> > > > On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
> > > > <dmitry.baryshkov@linaro.org> wrote:
> > > > >
> > > > > On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
> > > > > >
> > > > > > On 19/02/2024 13:33, Dmitry Baryshkov wrote:
> > > > > > > On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > > > >>
> > > > > > >> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
> > > > > > >> <dmitry.baryshkov@linaro.org> wrote:
> > > > > > >>>
> > > > > > >>
> > > > > > >> [snip]
> > > > > > >>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> > > > > > >>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
> > > > > > >>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
> > > > > > >>>>>>>> directly.
> > > > > > >>>>>>>
> > > > > > >>>>>>> We are describing the hardware. From the hardware point of view, there
> > > > > > >>>>>>> is a PMU. I think at some point we would really like to describe all
> > > > > > >>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
> > > > > > >>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
> > > > > > >>>>>>
> > > > > > >>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
> > > > > > >>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
> > > > > > >>>>>> transparent.
> > > > > > >>>>>
> > > > > > >>>>> I don't see any significant difference between WCN6750/WCN6855 and
> > > > > > >>>>> WCN7850 from the PMU / power up point of view. Could you please point
> > > > > > >>>>> me to the difference?
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
> > > > > > >>>> and BT_EN ordering and the only requirement is to have all input regulators
> > > > > > >>>> up before pulling up WLAN_EN and/or BT_EN.
> > > > > > >>>>
> > > > > > >>>> This makes the PMU transparent and BT and WLAN can be described as independent.
> > > > > > >>>
> > > > > > >>>  From the hardware perspective, there is a PMU. It has several LDOs. So
> > > > > > >>> the device tree should have the same style as the previous
> > > > > > >>> generations.
> > > > > > >>>
> > > > > > >>
> > > > > > >> My thinking was this: yes, there is a PMU but describing it has no
> > > > > > >> benefit (unlike QCA6x90). If we do describe, then we'll end up having
> > > > > > >> to use pwrseq here despite it not being needed because now we won't be
> > > > > > >> able to just get regulators from WLAN/BT drivers directly.
> > > > > > >>
> > > > > > >> So I also vote for keeping it this way. Let's go into the package
> > > > > > >> detail only if it's required.
> > > > > > >
> > > > > > > The WiFi / BT parts are not powered up by the board regulators. They
> > > > > > > are powered up by the PSU. So we are not describing it in the accurate
> > > > > > > way.
> > > > > >
> > > > > > I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
> > > > > > this situation the PCIe part is powered with the M.2 slot and the BT side
> > > > > > is powered separately as we currently do it now.
> > > > >
> > > > > QCA6390 can also be used as a discrete M.2 card.
> > > > >
> > > > > > So yes there's a PMU, but it's not an always visible hardware part, from the
> > > > > > SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
> > > > >
> > > > > From the hardware point:
> > > > > - There is a PMU
> > > > > - The PMU is connected to the board supplies
> > > > > - Both WiFi and BT parts are connected to the PMU
> > > > > - The BT_EN / WLAN_EN pins are not connected to the PMU
> > > > >
> > > > > So, not representing the PMU in the device tree is a simplification.
> > > > >
> > > >
> > > > What about the existing WLAN and BT users of similar packages? We
> > > > would have to deprecate a lot of existing bindings. I don't think it's
> > > > worth it.
> > >
> > > We have bindings that are not reflecting the hardware. So yes, we
> > > should gradually update them once the powerseq is merged.
> > >
> > > > The WCN7850 is already described in bindings as consuming what is PMUs
> > > > inputs and not its outputs.
> > >
> > > So do WCN6855 and QCA6391 BlueTooth parts.
> > >
> >
> > That is not true for the latter, this series is adding regulators for it.
>
> But the bindings exist already, so you still have to extend it,
> deprecating regulator-less bindings.
>
> Bartosz, I really don't understand what is the issue there. There is a
> PMU. As such it should be represented in the DT and it can be handled
> by the same driver as you are adding for QCA6390.
>

The issue is that we'll pull in the pwrseq subsystem for WCN7850 which
clearly does not require it in practice.

I'd like to hear Krzysztof, Conor or Rob chime in here and make the
decision on how to proceed.

Bart

> >
> > Bart
> >
> > > >
> > > > Bart
> > > >
> > > > > >
> > > > > > Neil
> > > > > >
> > > > > > >
> > > > > > > Moreover, I think we definitely want to move BT driver to use only the
> > > > > > > pwrseq power up method. Doing it in the other way results in the code
> > > > > > > duplication and possible issues because of the regulator / pwrseq
> > > > > > > taking different code paths.
> > > > >
> > > > > --
> > > > > With best wishes
> > > > > Dmitry
> > >
> > >
> > >
> > > --
> > > With best wishes
> > > Dmitry
>
>
>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Thu, Feb 22, 2024 at 01:26:59PM +0100, Bartosz Golaszewski wrote:
> On Thu, Feb 22, 2024 at 1:21 PM Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Feb 22, 2024 at 10:22:50AM +0100, Bartosz Golaszewski wrote:

> > > Removing it would be out of scope for this series and I don't really
> > > want to introduce any undefined behavior when doing a big development
> > > like that. I'll think about it separately.

> > This is new code?

> It's a new driver but Qualcomm standard has been to provide the load
> values. If it's really unnecessary then maybe let's consider it
> separately and possibly rework globally?

That doesn't seem a great reason to add more instances of this - it's
more instances that need to be removed later, and somewhere else people
can cut'n'paste from to introduce new usage.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850

[Bartosz Golaszewski]

On Thu, Feb 22, 2024 at 2:15 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Feb 22, 2024 at 01:26:59PM +0100, Bartosz Golaszewski wrote:
> > On Thu, Feb 22, 2024 at 1:21 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Thu, Feb 22, 2024 at 10:22:50AM +0100, Bartosz Golaszewski wrote:
>
> > > > Removing it would be out of scope for this series and I don't really
> > > > want to introduce any undefined behavior when doing a big development
> > > > like that. I'll think about it separately.
>
> > > This is new code?
>
> > It's a new driver but Qualcomm standard has been to provide the load
> > values. If it's really unnecessary then maybe let's consider it
> > separately and possibly rework globally?
>
> That doesn't seem a great reason to add more instances of this - it's
> more instances that need to be removed later, and somewhere else people
> can cut'n'paste from to introduce new usage.

Ok, whatever, I'll drop these until they're needed.

Bartosz

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[neil.armstrong]

On 22/02/2024 13:50, Bartosz Golaszewski wrote:
> On Thu, Feb 22, 2024 at 1:47 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
>>
>> On Thu, 22 Feb 2024 at 14:27, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>
>>> On Thu, Feb 22, 2024 at 12:27 PM Dmitry Baryshkov
>>> <dmitry.baryshkov@linaro.org> wrote:
>>>>
>>>> On Thu, 22 Feb 2024 at 13:00, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>
>>>>> On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
>>>>> <dmitry.baryshkov@linaro.org> wrote:
>>>>>>
>>>>>> On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
>>>>>>>
>>>>>>> On 19/02/2024 13:33, Dmitry Baryshkov wrote:
>>>>>>>> On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
>>>>>>>>> <dmitry.baryshkov@linaro.org> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
>>>>>>>>>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
>>>>>>>>>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
>>>>>>>>>>>>>>> directly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are describing the hardware. From the hardware point of view, there
>>>>>>>>>>>>>> is a PMU. I think at some point we would really like to describe all
>>>>>>>>>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
>>>>>>>>>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
>>>>>>>>>>>>>
>>>>>>>>>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
>>>>>>>>>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
>>>>>>>>>>>>> transparent.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't see any significant difference between WCN6750/WCN6855 and
>>>>>>>>>>>> WCN7850 from the PMU / power up point of view. Could you please point
>>>>>>>>>>>> me to the difference?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
>>>>>>>>>>> and BT_EN ordering and the only requirement is to have all input regulators
>>>>>>>>>>> up before pulling up WLAN_EN and/or BT_EN.
>>>>>>>>>>>
>>>>>>>>>>> This makes the PMU transparent and BT and WLAN can be described as independent.
>>>>>>>>>>
>>>>>>>>>>   From the hardware perspective, there is a PMU. It has several LDOs. So
>>>>>>>>>> the device tree should have the same style as the previous
>>>>>>>>>> generations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My thinking was this: yes, there is a PMU but describing it has no
>>>>>>>>> benefit (unlike QCA6x90). If we do describe, then we'll end up having
>>>>>>>>> to use pwrseq here despite it not being needed because now we won't be
>>>>>>>>> able to just get regulators from WLAN/BT drivers directly.
>>>>>>>>>
>>>>>>>>> So I also vote for keeping it this way. Let's go into the package
>>>>>>>>> detail only if it's required.
>>>>>>>>
>>>>>>>> The WiFi / BT parts are not powered up by the board regulators. They
>>>>>>>> are powered up by the PSU. So we are not describing it in the accurate
>>>>>>>> way.
>>>>>>>
>>>>>>> I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
>>>>>>> this situation the PCIe part is powered with the M.2 slot and the BT side
>>>>>>> is powered separately as we currently do it now.
>>>>>>
>>>>>> QCA6390 can also be used as a discrete M.2 card.
>>>>>>
>>>>>>> So yes there's a PMU, but it's not an always visible hardware part, from the
>>>>>>> SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
>>>>>>
>>>>>>  From the hardware point:
>>>>>> - There is a PMU
>>>>>> - The PMU is connected to the board supplies
>>>>>> - Both WiFi and BT parts are connected to the PMU
>>>>>> - The BT_EN / WLAN_EN pins are not connected to the PMU
>>>>>>
>>>>>> So, not representing the PMU in the device tree is a simplification.
>>>>>>
>>>>>
>>>>> What about the existing WLAN and BT users of similar packages? We
>>>>> would have to deprecate a lot of existing bindings. I don't think it's
>>>>> worth it.
>>>>
>>>> We have bindings that are not reflecting the hardware. So yes, we
>>>> should gradually update them once the powerseq is merged.
>>>>
>>>>> The WCN7850 is already described in bindings as consuming what is PMUs
>>>>> inputs and not its outputs.
>>>>
>>>> So do WCN6855 and QCA6391 BlueTooth parts.
>>>>
>>>
>>> That is not true for the latter, this series is adding regulators for it.
>>
>> But the bindings exist already, so you still have to extend it,
>> deprecating regulator-less bindings.
>>
>> Bartosz, I really don't understand what is the issue there. There is a
>> PMU. As such it should be represented in the DT and it can be handled
>> by the same driver as you are adding for QCA6390.
>>
> 
> The issue is that we'll pull in the pwrseq subsystem for WCN7850 which
> clearly does not require it in practice.
> 
> I'd like to hear Krzysztof, Conor or Rob chime in here and make the
> decision on how to proceed.

For WCN7850 we'll be describing the PMU which is basically discrete, so we
could also add dummy fixed regulators, and it would be the same.

Neil

> 
> Bart
> 
>>>
>>> Bart
>>>
>>>>>
>>>>> Bart
>>>>>
>>>>>>>
>>>>>>> Neil
>>>>>>>
>>>>>>>>
>>>>>>>> Moreover, I think we definitely want to move BT driver to use only the
>>>>>>>> pwrseq power up method. Doing it in the other way results in the code
>>>>>>>> duplication and possible issues because of the regulator / pwrseq
>>>>>>>> taking different code paths.
>>>>>>
>>>>>> --
>>>>>> With best wishes
>>>>>> Dmitry
>>>>
>>>>
>>>>
>>>> --
>>>> With best wishes
>>>> Dmitry
>>
>>
>>
>> --
>> With best wishes
>> Dmitry

Re: [PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module

[Rob Herring]

On Fri, Feb 16, 2024 at 09:32:03PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

s/new/net/ in the subject.

> 
> Add device-tree bindings for the ATH12K module found in the WCN7850
> package.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  .../net/wireless/qcom,ath12k-pci.yaml         | 103 ++++++++++++++++++
>  1 file changed, 103 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Krzysztof Kozlowski]

On 22/02/2024 13:50, Bartosz Golaszewski wrote:
> On Thu, Feb 22, 2024 at 1:47 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
>>
>> On Thu, 22 Feb 2024 at 14:27, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>
>>> On Thu, Feb 22, 2024 at 12:27 PM Dmitry Baryshkov
>>> <dmitry.baryshkov@linaro.org> wrote:
>>>>
>>>> On Thu, 22 Feb 2024 at 13:00, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>
>>>>> On Mon, Feb 19, 2024 at 11:21 PM Dmitry Baryshkov
>>>>> <dmitry.baryshkov@linaro.org> wrote:
>>>>>>
>>>>>> On Mon, 19 Feb 2024 at 19:18, <neil.armstrong@linaro.org> wrote:
>>>>>>>
>>>>>>> On 19/02/2024 13:33, Dmitry Baryshkov wrote:
>>>>>>>> On Mon, 19 Feb 2024 at 14:23, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Feb 19, 2024 at 11:26 AM Dmitry Baryshkov
>>>>>>>>> <dmitry.baryshkov@linaro.org> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For WCN7850 we hide the existence of the PMU as modeling it is simply not
>>>>>>>>>>>>>>> necessary. The BT and WLAN devices on the device-tree are represented as
>>>>>>>>>>>>>>> consuming the inputs (relevant to the functionality of each) of the PMU
>>>>>>>>>>>>>>> directly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are describing the hardware. From the hardware point of view, there
>>>>>>>>>>>>>> is a PMU. I think at some point we would really like to describe all
>>>>>>>>>>>>>> Qualcomm/Atheros WiFI+BT units using this PMU approach, including the
>>>>>>>>>>>>>> older ath10k units present on RB3 (WCN3990) and db820c (QCA6174).
>>>>>>>>>>>>>
>>>>>>>>>>>>> While I agree with older WiFi+BT units, I don't think it's needed for
>>>>>>>>>>>>> WCN7850 since BT+WiFi are now designed to be fully independent and PMU is
>>>>>>>>>>>>> transparent.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't see any significant difference between WCN6750/WCN6855 and
>>>>>>>>>>>> WCN7850 from the PMU / power up point of view. Could you please point
>>>>>>>>>>>> me to the difference?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The WCN7850 datasheet clearly states there's not contraint on the WLAN_EN
>>>>>>>>>>> and BT_EN ordering and the only requirement is to have all input regulators
>>>>>>>>>>> up before pulling up WLAN_EN and/or BT_EN.
>>>>>>>>>>>
>>>>>>>>>>> This makes the PMU transparent and BT and WLAN can be described as independent.
>>>>>>>>>>
>>>>>>>>>>  From the hardware perspective, there is a PMU. It has several LDOs. So
>>>>>>>>>> the device tree should have the same style as the previous
>>>>>>>>>> generations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My thinking was this: yes, there is a PMU but describing it has no
>>>>>>>>> benefit (unlike QCA6x90). If we do describe, then we'll end up having
>>>>>>>>> to use pwrseq here despite it not being needed because now we won't be
>>>>>>>>> able to just get regulators from WLAN/BT drivers directly.
>>>>>>>>>
>>>>>>>>> So I also vote for keeping it this way. Let's go into the package
>>>>>>>>> detail only if it's required.
>>>>>>>>
>>>>>>>> The WiFi / BT parts are not powered up by the board regulators. They
>>>>>>>> are powered up by the PSU. So we are not describing it in the accurate
>>>>>>>> way.
>>>>>>>
>>>>>>> I disagree, the WCN7850 can also be used as a discrete PCIe M.2 card, and in
>>>>>>> this situation the PCIe part is powered with the M.2 slot and the BT side
>>>>>>> is powered separately as we currently do it now.
>>>>>>
>>>>>> QCA6390 can also be used as a discrete M.2 card.
>>>>>>
>>>>>>> So yes there's a PMU, but it's not an always visible hardware part, from the
>>>>>>> SoC PoV, only the separate PCIe and BT subsystems are visible/controllable/powerable.
>>>>>>
>>>>>> From the hardware point:
>>>>>> - There is a PMU
>>>>>> - The PMU is connected to the board supplies
>>>>>> - Both WiFi and BT parts are connected to the PMU
>>>>>> - The BT_EN / WLAN_EN pins are not connected to the PMU
>>>>>>
>>>>>> So, not representing the PMU in the device tree is a simplification.
>>>>>>
>>>>>
>>>>> What about the existing WLAN and BT users of similar packages? We
>>>>> would have to deprecate a lot of existing bindings. I don't think it's
>>>>> worth it.
>>>>
>>>> We have bindings that are not reflecting the hardware. So yes, we
>>>> should gradually update them once the powerseq is merged.
>>>>
>>>>> The WCN7850 is already described in bindings as consuming what is PMUs
>>>>> inputs and not its outputs.
>>>>
>>>> So do WCN6855 and QCA6391 BlueTooth parts.
>>>>
>>>
>>> That is not true for the latter, this series is adding regulators for it.
>>
>> But the bindings exist already, so you still have to extend it,
>> deprecating regulator-less bindings.
>>
>> Bartosz, I really don't understand what is the issue there. There is a
>> PMU. As such it should be represented in the DT and it can be handled
>> by the same driver as you are adding for QCA6390.
>>
> 
> The issue is that we'll pull in the pwrseq subsystem for WCN7850 which
> clearly does not require it in practice.
> 
> I'd like to hear Krzysztof, Conor or Rob chime in here and make the
> decision on how to proceed.

There's like 12 emails here, so please don't just point "MR X, please
read everything to find the question I want to ask", but just ask the
question with short intro. We all (and I bet you as well) are way too
busy to read long threads...

If I got it correctly, you ask if some other, existing QCA/WCN chips
should be changed to this PMU approach?

If yes, then:
1. It depends whether they have the PMU, so some sort of analysis of
datasheet should be done.
2. You could but you don't have to. Bindings were done, they represent
the hardware more-or-less, maybe less, but still good enough.
3. It does not have to impact actual behavior of Linux. You don't have
to bind entire pwrseq driver to that QCA/WCN compatible. Anyway Linux
behavior is here a bit separate question - it can change, it can stay
the same, up to you.

Best regards,
Krzysztof

Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users

[Amit Pundir]

On Sat, 17 Feb 2024 at 02:03, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> First, I'd like to apologize for the somewhat chaotic previous iterations
> of this series and improper versioning which was rightfully pointed out
> to me. I figured that the scope changed so much that it didn't make sense
> to consider previous submissions part of the same series as the original
> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> versioning going forward.
>
> This is the summary of the work so far:
>
> v1: Original RFC:
>
> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
>
> v2: First real patch series (should have been PATCH v2) adding what I
>     referred to back then as PCI power sequencing:
>
> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
>
> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
>     modules inside the QCA6391 package (was largely separate from the
>     series but probably should have been called PATCH or RFC v3):
>
> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
>
> v4: Second attempt at the full series with changed scope (introduction of
>     the pwrseq subsystem, should have been RFC v4)
>
> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
>
> ===
>
> With that out of the way, I'd like to get down to explaining the two
> problems I'm trying to solve.
>
> Problem statement #1: Dynamic bus chicken-and-egg problem.
>
> Certain on-board PCI devices need to be powered up before they are can be
> detected but their PCI drivers won't get bound until the device is
> powered-up so enabling the relevant resources in the PCI device driver
> itself is impossible.
>
> Problem statement #2: Sharing inter-dependent resources between devices.
>
> Certain devices that use separate drivers (often on different busses)
> share resources (regulators, clocks, etc.). Typically these resources
> are reference-counted but in some cases there are additional interactions
> between them to consider, for example specific power-up sequence timings.
>
> ===
>
> The reason for tackling both of these problems in a single series is the
> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> both need to be addressed in order to enable WLAN and Bluetooth support
> upstream.
>
> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> takes inputs from the host and exposes LDO outputs consumed by the BT and
> WLAN modules which can be powered-up and down independently. However
> a delay of 100ms must be respected between enabling the BT- and
> WLAN-enable GPIOs[*].
>
> ===
>
> This series is logically split into several sections. I'll go
> patch-by-patch and explain each step.
>
> Patch 1/18:
>
> This is a commit taken from the list by Jonathan Cameron that adds
> a __free() helper for OF nodes. Not strictly related to the series but
> until said commit ends in next, I need to carry it with this series.
>
> Patch 2/18:
>
> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> and sm8550 reference platforms use it in the WCN7850 module.
>
> Patches 3/18-6/18:
>
> These contain all relevant DT bindings changes. We add new documents for
> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> QCA6390.
>
> Patches 7/18-9/18:
>
> These contain changes to device-tree sources for the three platforms we
> work with in this series. As the WCN7850 module doesn't require any
> specific timings introducing dependencies between the Bluetooth and WLAN
> modules, while the QCA6390 does, we take two different approaches to how
> me model them in DT.
>
> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> necessary. The BT and WLAN devices on the device-tree are represented as
> consuming the inputs (relevant to the functionality of each) of the PMU
> directly.
>
> For QCA6390 on RB5 we add the PMU node as a platform device. It consumes
> regulators and GPIOs from the host and exposed regulators consumer in turn
> by the BT and WLAN modules. This represents the internal structure of the
> package.
>
> Patches 10/18-14/18:
>
> These contain the bulk of the PCI changes for this series. We introduce
> a simple framework for powering up PCI devices before detecting them on
> the bus and the first user of this library in the form of the WCN7850 PCI
> power control driver.
>
> The general approach is as follows: PCI devices that need special
> treatment before they can be powered up, scanned and bound to their PCI
> drivers must be described on the device-tree as child nodes of the PCI
> port node. These devices will be instantiated on the platform bus. They
> will in fact be generic platform devices with the compatible of the form
> used for PCI devices already upstream ("pci<vendor ID>,<device ID">). We
> add a new directory under drivers/pci/pwrctl/ that contains PCI pwrctl
> drivers. These drivers are platform drivers that will now be matched
> against the devices instantiated from port children just like any other
> platform pairs.
>
> Both the power control platform device *AND* the associated PCI device
> reuse the same OF node and have access to the same properties. The goal
> of the platform driver is to request and bring up any required resources
> and let the pwrctl framework know that it's now OK to rescan the bus and
> detect the devices. When the device is bound, we are notified about it
> by the PCI bus notifier event and can establish a device link between the
> power control device and the PCI device so that any future extension for
> power-management will already be able to work with the correct hierachy.
>
> The reusing of the OF node is the reason for the small changes to the PCI
> OF core: as the bootloader can possibly leave the relevant regulators on
> before booting linux, the PCI device can be detected before its platform
> abstraction is probed. In this case, we find that device first and mark
> its OF node as reused. The pwrctl framework handles the opposite case
> (when the PCI device is detected only after the platform driver
> successfully enabled it).
>
> Patches 15/18-16/18:
>
> These add a relatively simple power sequencing subsystem and the first
> driver using it: the pwrseq module for the QCA6390 PMU.
>
> For the record: Bjorn suggested a different solution: a regulator driver
> that would - based on which regulators are enabled by a consumer - enable
> relevant resources (drive the enable GPIOs) while respecting the
> HW-specific delays. This would however require significant and yet
> unprecised changed to the regulator subsystem as well as be an abuse of
> the regulator provider API akin to using the reset framework for power
> sequencing as proposed before.
>
> Instead I'm proposing to add a subsystem that allows different devices to
> use a shared power sequence split into consumer-specific as well as
> common "units".
>
> A power sequence provider driver registers a set of units with pwrseq
> core. Each unit can be enabled and disabled and contains an optional list
> of other units which must be enabled before it itself can be. A unit
> represents a discreet chunk of the power sequence.
>
> It also registers a list of targets: a target is an abstraction wrapping
> a unit which allows consumers to tell pwrseq which unit they want to
> reach. Real-life example is the driver we're adding here: there's a set
> of common regulators, two PCIe-specific ones and two enable GPIOs: one
> for Bluetooth and one for WLAN.
>
> The Bluetooth driver requests a descriptor to the power sequencer and
> names the target it wants to reach:
>
>     pwrseq = devm_pwrseq_get(dev, "bluetooth");
>
> The pwrseq core then knows that when the driver calls:
>
>     pwrseq_power_on(pwrseq);
>
> It must enable the "bluetooth-enable" unit but it depends on the
> "regulators-common" unit so this one is enabled first. The provider
> driver is also in charge of assuring an appropriate delay between
> enabling the BT and WLAN enable GPIOs. The WLAN-specific resources are
> handled by the "wlan-enable" unit and so are not enabled until the WLAN
> driver requests the "wlan" target to be powered on.
>
> Another thing worth discussing is the way we associate the consumer with
> the relevant power sequencer. DT maintainers have expressed a discontent
> with the existing mmc pwrseq bindings and have NAKed an earlier
> initiative to introduce global pwrseq bindings to the kernel[1].
>
> In this approach, we model the existing regulators and GPIOs in DT but
> the pwrseq subsystem requires each provider to provide a .match()
> callback. Whenever a consumer requests a power sequencer handle, we
> iterate over the list of pwrseq drivers and call .match() for each. It's
> up to the driver to verify in a platform-specific way whether it deals
> with its consumer and let the core pwrseq code know.
>
> The advantage of this over reusing the regulator or reset subsystem is
> that it's more generalized and can handle resources of all kinds as well
> as deal with any kind of power-on sequences: for instance, Qualcomm has
> a PCI switch they want a driver for but this switch requires enabling
> some resources first (PCI pwrctl) and then configuring the device over
> I2C (which can be handled by the pwrseq provider).
>
> Patch 17/18:
>
> This patch makes the Qualcomm Bluetooth driver get and use the power
> sequencer for QCA6390.
>
> Patch 18/18:
>
> While tiny, this patch is possibly the highlight of the entire series.
> It uses the two abstraction layers we introduced before to create an
> elegant power sequencing PCI power control driver and supports the ath11k
> module on QCA6390.
>
> With this series we can now enable BT and WLAN on several new Qualcomm
> boards upstream.
>
> I tested the series on RB5 while Neil tested it on sm8650-qrd and
> sm8550-qrd.

Tested-by: Amit Pundir <amit.pundir@linaro.org> # On RB5 running AOSP

>
> Best Regards,
> Bartosz Golaszewski
>
> It's hard to list the changes between versions here as the scope changed
> significantly between each iteration and some versions were not even full
> series but rather RFCs for parts of the solution. For this reason, I'll
> only start listing changes starting from v6.
>
> [*] This is what the docs say. In practice it seems that this delay can be
> ignored. However the subsequent model - QCA6490 - *does* require users to
> respect it, so the problem remains valid.
>
> [1] https://lore.kernel.org/netdev/20210829131305.534417-1-dmitry.baryshkov@linaro.org/
>
> Bartosz Golaszewski (15):
>   arm64: defconfig: enable ath12k as a module
>   dt-bindings: regulator: describe the PMU module of the QCA6390 package
>   dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
>   dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on
>     QCA6390
>   dt-bindings: new: wireless: describe the ath12k PCI module
>   arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391
>   PCI: hold the rescan mutex when scanning for the first time
>   PCI/pwrctl: reuse the OF node for power controlled devices
>   PCI/pwrctl: create platform devices for child OF nodes of the port
>     node
>   PCI/pwrctl: add PCI power control core code
>   PCI/pwrctl: add a power control driver for WCN7850
>   power: sequencing: implement the pwrseq core
>   power: pwrseq: add a driver for the QCA6390 PMU module
>   Bluetooth: qca: use the power sequencer for QCA6390
>   PCI/pwrctl: add a PCI power control driver for power sequenced devices
>
> Jonathan Cameron (1):
>   of: Add cleanup.h based auto release via __free(device_node) markings.
>
> Neil Armstrong (2):
>   arm64: dts: qcom: sm8550-qrd: add the Wifi node
>   arm64: dts: qcom: sm8650-qrd: add the Wifi node
>
>  .../net/bluetooth/qualcomm-bluetooth.yaml     |   17 +
>  .../net/wireless/qcom,ath11k-pci.yaml         |   28 +
>  .../net/wireless/qcom,ath12k-pci.yaml         |  103 ++
>  .../bindings/regulator/qcom,qca6390-pmu.yaml  |  166 +++
>  MAINTAINERS                                   |    8 +
>  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts      |  123 +-
>  arch/arm64/boot/dts/qcom/sm8250.dtsi          |   10 +
>  arch/arm64/boot/dts/qcom/sm8550-qrd.dts       |   37 +
>  arch/arm64/boot/dts/qcom/sm8550.dtsi          |   10 +
>  arch/arm64/boot/dts/qcom/sm8650-qrd.dts       |   29 +
>  arch/arm64/boot/dts/qcom/sm8650.dtsi          |   10 +
>  arch/arm64/configs/defconfig                  |    1 +
>  drivers/bluetooth/hci_qca.c                   |   31 +
>  drivers/pci/Kconfig                           |    1 +
>  drivers/pci/Makefile                          |    1 +
>  drivers/pci/bus.c                             |    9 +-
>  drivers/pci/of.c                              |   14 +-
>  drivers/pci/probe.c                           |    2 +
>  drivers/pci/pwrctl/Kconfig                    |   25 +
>  drivers/pci/pwrctl/Makefile                   |    7 +
>  drivers/pci/pwrctl/core.c                     |  136 +++
>  drivers/pci/pwrctl/pci-pwrctl-pwrseq.c        |   84 ++
>  drivers/pci/pwrctl/pci-pwrctl-wcn7850.c       |  202 ++++
>  drivers/pci/remove.c                          |    2 +
>  drivers/power/Kconfig                         |    1 +
>  drivers/power/Makefile                        |    1 +
>  drivers/power/sequencing/Kconfig              |   28 +
>  drivers/power/sequencing/Makefile             |    6 +
>  drivers/power/sequencing/core.c               | 1065 +++++++++++++++++
>  drivers/power/sequencing/pwrseq-qca6390.c     |  353 ++++++
>  include/linux/of.h                            |    2 +
>  include/linux/pci-pwrctl.h                    |   51 +
>  include/linux/pwrseq/consumer.h               |   56 +
>  include/linux/pwrseq/provider.h               |   75 ++
>  34 files changed, 2678 insertions(+), 16 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
>  create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
>  create mode 100644 drivers/pci/pwrctl/Kconfig
>  create mode 100644 drivers/pci/pwrctl/Makefile
>  create mode 100644 drivers/pci/pwrctl/core.c
>  create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
>  create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
>  create mode 100644 drivers/power/sequencing/Kconfig
>  create mode 100644 drivers/power/sequencing/Makefile
>  create mode 100644 drivers/power/sequencing/core.c
>  create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
>  create mode 100644 include/linux/pci-pwrctl.h
>  create mode 100644 include/linux/pwrseq/consumer.h
>  create mode 100644 include/linux/pwrseq/provider.h
>
> --
> 2.40.1
>
>