power: sequencing: implement the subsystem and add first users
Subsystems (13)
v7 cover power: sequencing: implement the subsystem and add first users
From: Bartosz Golaszewski <[email protected]>
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.
A similar design with a discreet PMU is also employed in other models of the WCN family of chips although we can often do without the delays. With this series we add support for the WCN7850 as well.
===
We introduce a new subsystem here - the power sequencing framework. The qcom-wcn driver that we add is its first user. It implements the power-up sequences for QCA6390 and WCN7850 chips. However - we only use it to power-up the bluetooth module in the former. We use it to driver the WLAN modules in both. The reason for this is that for WCN7850 we have comprehensive bindings already upstream together with existing DT users. Porting them to using the pwrseq subsystem can be done separately and in an incremental manner once the subsystem itself is upstream. We will also have to ensure backward DT compatibility. To avoid overcomplicating this series, let's leave it out for now.
===
This series is logically split into several sections. I'll go patch-by-patch and explain each step.
Patches 1/16-5/16:
These contain all relevant DT bindings changes. We add new documents for the QCA6390 & WCN7850 PMUs and ATH12K devices as well as extend the bindings for the Qualcomm Bluetooth and ATH11K modules with regulators used by them in QCA6390.
Patches 6/16-8/16:
These contain changes to device-tree sources for the three platforms we work with in this series. We model the PMUs of the WLAN/BT chips as top-level platform devices on the device tree. In order to limit the scope of this series and not introduce an excessive amount of confusion with deprecating DT bindings, we leave the Bluetooth nodes on sm8650 and sm8550 as is (meaning: they continue to consumer the GPIOs and power inputs from the host). As the WCN7850 module doesn't require any specific timings, we can incrementally change that later.
In both cases we add WLAN nodes that consume the power outputs of the PMU. For QCA6390 we also make the Bluetooth node of the RB5 consume the outputs of the PMU - we can do it as the bindings for this chip did not define any supply handles prior to this series meaning we are able to get this correct right away.
Patches 9/16-12/16:
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.
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).
Patch 13/16 - 14/16:
These add a relatively simple power sequencing subsystem and the first driver using it: the pwrseq module for the PMUs on the WCN family of chips.
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 15:
This patch makes the Qualcomm Bluetooth driver get and use the power sequencer for QCA6390.
Patch 16:
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 and ath12k on WCN7850.
With this series we can now enable BT and WLAN on several new Qualcomm boards upstream.
Tested on RB5, sm8650-qrd and sm8550-qrd.
Changelog:
Since v6:
- kernel doc fixes
- drop myself from the DT bindings maintainers list for ath12k
- wait until the PCI bridge device is fully added before creating the PCI pwrctl platform devices for its sub-nodes, otherwise we may see sysfs and procfs attribute failures (due to duplication, we're basically trying to probe the same device twice at the same time)
- I kept the regulators for QCA6390's ath11k as required as they only apply to this specific Qualcomm package
Since v5:
- unify the approach to modelling the WCN WLAN/BT chips by always exposing the PMU node on the device tree and making the WLAN and BT nodes become consumers of its power outputs; this includes a major rework of the DT sources, bindings and driver code; there's no more a separate PCI pwrctl driver for WCN7850, instead its power-up sequence was moved into the pwrseq driver common for all WCN chips
- don't set load_uA from new regulator consumers
- fix reported kerneldoc issues
- drop voltage ranges for PMU outputs from DT
- many minor tweaks and reworks
v1: Original RFC:
https://lore.kernel.org/lkml/[email protected]/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/[email protected]/T/
v5: Two different ways of handling QCA6390 and WCN7850:
https://lore.kernel.org/lkml/[email protected]/
Bartosz Golaszewski (16):
regulator: dt-bindings: describe the PMU module of the QCA6390 package
regulator: dt-bindings: describe the PMU module of the WCN7850 package
dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on
QCA6390
dt-bindings: net: wireless: describe the ath12k PCI module
arm64: dts: qcom: sm8550-qrd: add the Wifi node
arm64: dts: qcom: sm8650-qrd: add the Wifi node
arm64: dts: qcom: qrb5165-rb5: add the Wifi node
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
power: sequencing: implement the pwrseq core
power: pwrseq: add a driver for the PMU module on the QCom WCN
chipsets
Bluetooth: qca: use the power sequencer for QCA6390 PCI/pwrctl: add a PCI power control driver for power sequenced devices
.../net/bluetooth/qualcomm-bluetooth.yaml | 17 + .../net/wireless/qcom,ath11k-pci.yaml | 46 + .../bindings/net/wireless/qcom,ath12k.yaml | 99 ++ .../bindings/regulator/qcom,qca6390-pmu.yaml | 185 +++ MAINTAINERS | 8 + arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 103 +- arch/arm64/boot/dts/qcom/sm8250.dtsi | 10 + arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 97 ++ arch/arm64/boot/dts/qcom/sm8550.dtsi | 10 + arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 89 ++ arch/arm64/boot/dts/qcom/sm8650.dtsi | 10 + drivers/bluetooth/hci_qca.c | 74 +- 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 | 17 + drivers/pci/pwrctl/Makefile | 6 + drivers/pci/pwrctl/core.c | 137 +++ drivers/pci/pwrctl/pci-pwrctl-pwrseq.c | 89 ++ 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-qcom-wcn.c | 336 ++++++ include/linux/pci-pwrctl.h | 51 + include/linux/pwrseq/consumer.h | 56 + include/linux/pwrseq/provider.h | 75 ++ 31 files changed, 2615 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.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/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-qcom-wcn.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
Signature · 1 line
2.40.1
PATCH v7 1/16 regulator: dt-bindings: describe the PMU module of the QCA6390 package
From: Bartosz Golaszewski <[email protected]>
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.
--- .../bindings/regulator/qcom,qca6390-pmu.yaml | 151 ++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml new file +151 -0
@@ -0,0 +1,151 @@ +# 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 <[email protected]> + +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 + - regulators + +allOf: + - if: + properties: + compatible: + contains: + const: qcom,qca6390-pmu + then: + required: + - vddaon-supply + - vddpmu-supply + - vddrfa0p95-supply + - vddrfa1p3-supply + - vddrfa1p9-supply + - vddpcie1p3-supply + - vddpcie1p9-supply + - vddio-supply + +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"; + }; + + vreg_pmu_aon_0p59: ldo1 { + regulator-name = "vreg_pmu_aon_0p59"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p85: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p85"; + }; + + vreg_pmu_btcmx_0p85: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p85"; + }; + + vreg_pmu_rfa_0p8: ldo5 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo6 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p7: ldo7 { + regulator-name = "vreg_pmu_rfa_1p7"; + }; + + vreg_pmu_pcie_0p9: ldo8 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_pcie_1p8: ldo9 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + }; + };
Signature · 1 line
2.40.1
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=843230
---Test result---
Test Summary:
CheckPatch FAIL 16.93 seconds GitLint FAIL 8.77 seconds SubjectPrefix FAIL 2.19 seconds BuildKernel PASS 30.45 seconds CheckAllWarning PASS 32.94 seconds CheckSparse PASS 40.05 seconds CheckSmatch FAIL 35.10 seconds BuildKernel32 PASS 29.13 seconds TestRunnerSetup PASS 522.11 seconds TestRunner_l2cap-tester PASS 18.32 seconds TestRunner_iso-tester PASS 30.89 seconds TestRunner_bnep-tester PASS 4.70 seconds TestRunner_mgmt-tester PASS 114.43 seconds TestRunner_rfcomm-tester PASS 7.31 seconds TestRunner_sco-tester PASS 14.99 seconds TestRunner_ioctl-tester PASS 7.73 seconds TestRunner_mesh-tester PASS 5.79 seconds TestRunner_smp-tester PASS 7.01 seconds TestRunner_userchan-tester PASS 4.84 seconds IncrementalBuild PASS 96.94 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v7,01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #151:
new file mode 100644
total: 0 errors, 1 warnings, 151 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624277.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,05/16] dt-bindings: net: wireless: describe the ath12k PCI module
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #149:
new file mode 100644
total: 0 errors, 1 warnings, 99 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624281.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,06/16] arm64: dts: qcom: sm8550-qrd: add the Wifi node
WARNING: DT compatible string vendor "pci17cb" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml #227: FILE: arch/arm64/boot/dts/qcom/sm8550-qrd.dts:891:
+ compatible = "pci17cb,1107";
total: 0 errors, 1 warnings, 137 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624282.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,07/16] arm64: dts: qcom: sm8650-qrd: add the Wifi node
WARNING: DT compatible string vendor "pci17cb" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml #230: FILE: arch/arm64/boot/dts/qcom/sm8650-qrd.dts:915:
+ compatible = "pci17cb,1107";
total: 0 errors, 1 warnings, 123 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624283.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,08/16] arm64: dts: qcom: qrb5165-rb5: add the Wifi node
WARNING: DT compatible string vendor "pci17cb" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml #225: FILE: arch/arm64/boot/dts/qcom/qrb5165-rb5.dts:800:
+ compatible = "pci17cb,1101";
total: 0 errors, 1 warnings, 143 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624284.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,12/16] PCI/pwrctl: add PCI power control core code
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #188:
new file mode 100644
total: 0 errors, 1 warnings, 213 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624288.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,13/16] power: sequencing: implement the pwrseq core
WARNING: ENOSYS means 'invalid syscall nr' and nothing else #1330: FILE: include/linux/pwrseq/consumer.h:31:
+ return ERR_PTR(-ENOSYS);
WARNING: ENOSYS means 'invalid syscall nr' and nothing else #1340: FILE: include/linux/pwrseq/consumer.h:41:
+ return ERR_PTR(-ENOSYS);
WARNING: ENOSYS means 'invalid syscall nr' and nothing else #1345: FILE: include/linux/pwrseq/consumer.h:46:
+ return -ENOSYS;
WARNING: ENOSYS means 'invalid syscall nr' and nothing else #1350: FILE: include/linux/pwrseq/consumer.h:51:
+ return -ENOSYS;
total: 0 errors, 4 warnings, 1234 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624290.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,14/16] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #185:
new file mode 100644
total: 0 errors, 1 warnings, 360 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624289.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v7,16/16] PCI/pwrctl: add a PCI power control driver for power sequenced devices
WARNING: please write a help paragraph that fully describes the config symbol #157: FILE: drivers/pci/pwrctl/Kconfig:8:
+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.
+
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #178:
new file mode 100644
WARNING: DT compatible string vendor "pci17cb" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml #248: FILE: drivers/pci/pwrctl/pci-pwrctl-pwrseq.c:66:
+ .compatible = "pci17cb,1101",
WARNING: DT compatible string vendor "pci17cb" appears un-documented -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml #253: FILE: drivers/pci/pwrctl/pci-pwrctl-pwrseq.c:71:
+ .compatible = "pci17cb,1107",
total: 0 errors, 4 warnings, 107 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/src/13624292.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v7,01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (81>80): "[v7,01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package"
15: B1 Line exceeds max length (85>80): " create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml"
[v7,02/16] regulator: dt-bindings: describe the PMU module of the WCN7850 package
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (81>80): "[v7,02/16] regulator: dt-bindings: describe the PMU module of the WCN7850 package"
[v7,03/16] dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (81>80): "[v7,03/16] dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390"
[v7,04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (82>80): "[v7,04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390"
[v7,05/16] dt-bindings: net: wireless: describe the ath12k PCI module
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
13: B1 Line exceeds max length (83>80): " create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml"
[v7,11/16] PCI/pwrctl: create platform devices for child OF nodes of the port node
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (82>80): "[v7,11/16] PCI/pwrctl: create platform devices for child OF nodes of the port node"
[v7,14/16] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (82>80): "[v7,14/16] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets"
[v7,16/16] PCI/pwrctl: add a PCI power control driver for power sequenced devices
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
1: T1 Title exceeds max length (81>80): "[v7,16/16] PCI/pwrctl: add a PCI power control driver for power sequenced devices"
##############################
Test: SubjectPrefix - FAIL
Desc: Check subject contains "Bluetooth" prefix
Output:
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
"Bluetooth: " prefix is not specified in the subject
##############################
Test: CheckSmatch - FAIL
Desc: Run smatch tool with source
Output:
Segmentation fault (core dumped)
make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139 make[4]: *** Deleting file 'net/bluetooth/hci_core.o'
make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: net] Error 2
make[2]: *** Waiting for unfinished jobs....
Segmentation fault (core dumped)
make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139 make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o'
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2 make[2]: *** [scripts/Makefile.build:485: drivers] Error 2
make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2
make: *** [Makefile:240: __sub-make] Error 2
---
Regards,
Linux Bluetooth
Re: [PATCH v7 01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
In reply to Bartosz GolaszewskiQuoted 62 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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 <[email protected]>Acked-by Mark Brown <[email protected]>Reviewed-by Krzysztof Kozlowski <[email protected]>--- .../bindings/regulator/qcom,qca6390-pmu.yaml | 151 ++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yamlDocumentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml new file +41
-0@@ -0,0 +1,151 @@ +# 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 <[email protected]> + +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 +
Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml line 51
Quoted 10 lines
Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml new file +10
-0+ 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
As a side node, I think we should also steal swctrl pin from the bluetooth device node. It represents the status of the PMU and as such it is not BT-specific.
Quoted 103 lines
Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml new file +100
-1+ + regulators: + type: object + description: + LDO outputs of the PMU + + patternProperties: + "^ldo[0-9]$": + $ref: regulator.yaml# + type: object + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - regulators + +allOf: + - if: + properties: + compatible: + contains: + const: qcom,qca6390-pmu + then: + required: + - vddaon-supply + - vddpmu-supply + - vddrfa0p95-supply + - vddrfa1p3-supply + - vddrfa1p9-supply + - vddpcie1p3-supply + - vddpcie1p9-supply + - vddio-supply + +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"; + }; + + vreg_pmu_aon_0p59: ldo1 { + regulator-name = "vreg_pmu_aon_0p59"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p85: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p85"; + }; + + vreg_pmu_btcmx_0p85: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p85"; + }; + + vreg_pmu_rfa_0p8: ldo5 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo6 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p7: ldo7 { + regulator-name = "vreg_pmu_rfa_1p7"; + }; + + vreg_pmu_pcie_0p9: ldo8 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_pcie_1p8: ldo9 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + }; + }; --2.40.1
Signature · 2 lines
With best wishes Dmitry
PATCH v7 2/16 regulator: dt-bindings: describe the PMU module of the WCN7850 package
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
The WCN7850 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. Extend the bindings for QCA6390 to also document this model.
--- .../bindings/regulator/qcom,qca6390-pmu.yaml | 36 ++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml +35 -1
@@ -16,20 +16,37 @@ description: properties: compatible: - const: qcom,qca6390-pmu + enum: + - qcom,qca6390-pmu + - qcom,wcn7850-pmu + + vdd-supply: + description: VDD supply regulator handle vddaon-supply: description: VDD_AON supply regulator handle + vdddig-supply: + description: VDD_DIG supply regulator handle + vddpmu-supply: description: VDD_PMU supply regulator handle + vddio1p2-supply: + description: VDD_IO_1P2 supply regulator handle + vddrfa0p95-supply: description: VDD_RFA_0P95 supply regulator handle + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + vddrfa1p3-supply: description: VDD_RFA_1P3 supply regulator handle + vddrfa1p8-supply: + description: VDD_RFA_1P8 supply regulator handle + vddrfa1p9-supply: description: VDD_RFA_1P9 supply regulator handle
@@ -50,6 +67,10 @@ properties: maxItems: 1 description: GPIO line enabling the ATH11K Bluetooth module supplied by the PMU + clocks: + maxItems: 1 + description: Reference clock handle + regulators: type: object description:
@@ -83,6 +104,19 @@ allOf: - vddpcie1p3-supply - vddpcie1p9-supply - vddio-supply + - if: + properties: + compatible: + contains: + const: qcom,wcn7850-pmu + then: + required: + - vdd-supply + - vddio-supply + - vddaon-supply + - vdddig-supply + - vddrfa1p2-supply + - vddrfa1p8-supply additionalProperties: false
Signature · 1 line
2.40.1
PATCH v7 3/16 dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- .../net/bluetooth/qualcomm-bluetooth.yaml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +17 -0
@@ -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: - |
Signature · 1 line
2.40.1
PATCH v7 4/16 dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Add a PCI compatible for the ATH11K module on QCA6390 and describe the power inputs from the PMU that it consumes.
--- .../net/wireless/qcom,ath11k-pci.yaml | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+)
Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml +46 -0
@@ -17,6 +17,7 @@ description: | properties: compatible: enum: + - pci17cb,1101 # QCA6390 - pci17cb,1103 # WCN6855 reg:
@@ -28,10 +29,55 @@ 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 +allOf: + - if: + properties: + compatible: + contains: + const: pci17cb,1101 + then: + required: + - vddrfacmn-supply + - vddaon-supply + - vddwlcx-supply + - vddwlmx-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p7-supply + - vddpcie0p9-supply + - vddpcie1p8-supply + additionalProperties: false examples:
Signature · 1 line
2.40.1
Re: [PATCH v7 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
Quoted 7 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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 <[email protected]>---
Best regards,
Krzysztof
PATCH v7 5/16 dt-bindings: net: wireless: describe the ath12k PCI module
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Add device-tree bindings for the ATH12K module found in the WCN7850 package.
--- .../bindings/net/wireless/qcom,ath12k.yaml | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml new file +99 -0
@@ -0,0 +1,99 @@ +# 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.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies ath12k wireless devices (PCIe) + +maintainers: + - Jeff Johnson <[email protected]> + - Kalle Valo <[email protected]> + +description: + Qualcomm Technologies IEEE 802.11ax PCIe devices. + +properties: + compatible: + enum: + - pci17cb,1107 # WCN7850 + + reg: + maxItems: 1 + + vddaon-supply: + description: VDD_AON supply regulator handle + + vddwlcx-supply: + description: VDD_WLCX supply regulator handle + + vddwlmx-supply: + description: VDD_WLMX supply regulator handle + + vddrfacmn-supply: + description: VDD_RFA_CMN supply regulator handle + + vddrfa0p8-supply: + description: VDD_RFA_0P8 supply regulator handle + + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + + vddrfa1p8-supply: + description: VDD_RFA_1P8 supply regulator handle + + vddpcie0p9-supply: + description: VDD_PCIE_0P9 supply regulator handle + + vddpcie1p8-supply: + description: VDD_PCIE_1P8 supply regulator handle + +required: + - compatible + - reg + - vddaon-supply + - vddwlcx-supply + - vddwlmx-supply + - vddrfacmn-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p8-supply + - vddpcie0p9-supply + - vddpcie1p8-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>; + + vddaon-supply = <&vreg_pmu_aon_0p59>; + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; + vddwlmx-supply = <&vreg_pmu_wlmx_0p85>; + vddrfacmn-supply = <&vreg_pmu_rfa_cmn>; + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; + vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>; + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; + }; + }; + };
Signature · 1 line
2.40.1
Re: [PATCH v7 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
On 4/10/2024 5:46 AM, Bartosz Golaszewski wrote:
[...]
Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml line 15
Quoted 2 lines
Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml new file +2
-0+description: + Qualcomm Technologies IEEE 802.11ax PCIe devices.
if you respin, nit: s/11ax/11be/
PATCH v7 6/16 arm64: dts: qcom: sm8550-qrd: add the Wifi node
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Describe the ath12k WLAN on-board the WCN7850 module present on the board.
--- arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 97 +++++++++++++++++++++++++ arch/arm64/boot/dts/qcom/sm8550.dtsi | 10 +++ 2 files changed, 107 insertions(+)
arch/arm64/boot/dts/qcom/sm8550-qrd.dts +97 -0
@@ -214,6 +214,68 @@ vph_pwr: vph-pwr-regulator { regulator-always-on; regulator-boot-on; }; + + wcn7850-pmu { + compatible = "qcom,wcn7850-pmu"; + + pinctrl-names = "default"; + pinctrl-0 = <&wlan_en>, <&pmk8550_sleep_clk>; + + wlan-enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>; + /* + * TODO Add bt-enable-gpios once the Bluetooth driver is + * converted to using the power sequencer. + */ + + 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>; + + regulators { + vreg_pmu_rfa_cmn: ldo0 { + regulator-name = "vreg_pmu_rfa_cmn"; + }; + + vreg_pmu_aon_0p59: ldo1 { + regulator-name = "vreg_pmu_aon_0p59"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p85: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p85"; + }; + + vreg_pmu_btcmx_0p85: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p85"; + }; + + vreg_pmu_rfa_0p8: ldo5 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo6 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p8: ldo7 { + regulator-name = "vreg_pmu_rfa_1p8"; + }; + + vreg_pmu_pcie_0p9: ldo8 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_pcie_1p8: ldo9 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + }; + }; }; &apps_rsc {
@@ -824,6 +886,23 @@ &pcie0 { status = "okay"; }; +&pcieport0 { + wifi@0 { + compatible = "pci17cb,1107"; + 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>; + vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>; + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; + }; +}; + &pcie0_phy { vdda-phy-supply = <&vreg_l1e_0p88>; vdda-pll-supply = <&vreg_l3e_1p2>;
@@ -911,6 +990,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 +1174,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 {
arch/arm64/boot/dts/qcom/sm8550.dtsi +10 -0
@@ -1770,6 +1770,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 {
Signature · 1 line
2.40.1
PATCH v7 7/16 arm64: dts: qcom: sm8650-qrd: add the Wifi node
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Describe the ath12k WLAN on-board the WCN7850 module present on the board.
--- arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 89 +++++++++++++++++++++++++ arch/arm64/boot/dts/qcom/sm8650.dtsi | 10 +++ 2 files changed, 99 insertions(+)
arch/arm64/boot/dts/qcom/sm8650-qrd.dts +89 -0
@@ -203,6 +203,71 @@ wcd_codec_headset_in: endpoint { }; }; }; + + wcn7850-pmu { + compatible = "qcom,wcn7850-pmu"; + + pinctrl-names = "default"; + pinctrl-0 = <&wlan_en>; + + wlan-enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>; + /* + * TODO Add bt-enable-gpios once the Bluetooth driver is + * converted to using the power sequencer. + */ + + 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>; + + regulators { + vreg_pmu_rfa_cmn: ldo0 { + regulator-name = "vreg_pmu_rfa_cmn"; + }; + + vreg_pmu_aon_0p59: ldo1 { + regulator-name = "vreg_pmu_aon_0p59"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p85: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p85"; + }; + + vreg_pmu_btcmx_0p85: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p85"; + }; + + vreg_pmu_rfa_0p8: ldo5 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo6 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p8: ldo7 { + regulator-name = "vreg_pmu_rfa_1p8"; + }; + + vreg_pmu_pcie_0p9: ldo8 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_pcie_1p8: ldo9 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + }; + }; }; &apps_rsc {
@@ -845,6 +910,23 @@ &pcie0 { status = "okay"; }; +&pcieport0 { + wifi@0 { + compatible = "pci17cb,1107"; + 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>; + vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>; + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; + }; +}; + &pcie0_phy { vdda-phy-supply = <&vreg_l1i_0p88>; vdda-pll-supply = <&vreg_l3i_1p2>;
@@ -1139,6 +1221,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 {
arch/arm64/boot/dts/qcom/sm8650.dtsi +10 -0
@@ -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 {
Signature · 1 line
2.40.1
PATCH v7 8/16 arm64: dts: qcom: qrb5165-rb5: add the Wifi node
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 103 ++++++++++++++++++++--- arch/arm64/boot/dts/qcom/sm8250.dtsi | 10 +++ 2 files changed, 102 insertions(+), 11 deletions(-)
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +92 -11
@@ -108,6 +108,67 @@ 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"; + }; + + vreg_pmu_aon_0p59: ldo1 { + regulator-name = "vreg_pmu_aon_0p59"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p85: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p85"; + }; + + vreg_pmu_btcmx_0p85: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p85"; + }; + + vreg_pmu_rfa_0p8: ldo5 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo6 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p7: ldo7 { + regulator-name = "vreg_pmu_rfa_1p7"; + }; + + vreg_pmu_pcie_0p9: ldo8 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_pcie_1p8: ldo9 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + }; + }; + thermal-zones { conn-thermal { polling-delay-passive = <0>;
@@ -734,6 +795,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 +1381,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 +1397,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>; }; };
arch/arm64/boot/dts/qcom/sm8250.dtsi +10 -0
@@ -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 {
Signature · 1 line
2.40.1
PATCH v7 9/16 PCI: hold the rescan mutex when scanning for the first time
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/pci/probe.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pci/probe.c +2 -0
@@ -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;
Signature · 1 line
2.40.1
PATCH v7 10/16 PCI/pwrctl: reuse the OF node for power controlled devices
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/pci/of.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
drivers/pci/of.c +10 -4
@@ -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 ; }
Signature · 1 line
2.40.1
PATCH v7 11/16 PCI/pwrctl: create platform devices for child OF nodes of the port node
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/pci/bus.c | 9 +++++++++ drivers/pci/remove.c | 2 ++ 2 files changed, 11 insertions(+)
drivers/pci/bus.c +9 -0
@@ -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>
@@ -354,6 +355,14 @@ void pci_bus_add_device(struct pci_dev *dev)pci_warn (dev,"device attach failed (%d)\n" , retval);pci_dev_assign_added (dev, true); + +if (pci_is_bridge (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); + } }EXPORT_SYMBOL_GPL (pci_bus_add_device);
drivers/pci/remove.c +2 -0
@@ -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);
Signature · 1 line
2.40.1
PATCH v7 12/16 PCI/pwrctl: add PCI power control core code
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/pci/Kconfig | 1 + drivers/pci/Makefile | 1 + drivers/pci/pwrctl/Kconfig | 8 +++ drivers/pci/pwrctl/Makefile | 4 ++ drivers/pci/pwrctl/core.c | 137 ++++++++++++++++++++++++++++++++++++ include/linux/pci-pwrctl.h | 51 ++++++++++++++ 6 files changed, 202 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
drivers/pci/Kconfig +1 -0
@@ -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
drivers/pci/Makefile +1 -0
@@ -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
drivers/pci/pwrctl/Kconfig new file +8 -0
@@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0-only + +menu "PCI Power control drivers" + +config PCI_PWRCTL + tristate + +endmenu
drivers/pci/pwrctl/Makefile new file +4 -0
@@ -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
drivers/pci/pwrctl/core.c new file +137 -0
137 lines not on this page · raw message
include/linux/pci-pwrctl.h new file +51 -0
51 lines not on this page · raw message
Signature · 1 line
2.40.1
PATCH v7 13/16 power: sequencing: implement the pwrseq core
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- 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
MAINTAINERS +8 -0
@@ -17631,6 +17631,14 @@ F: include/linux/pm_* F: include/linux/powercap.h F: kernel/configs/nopm.config +POWER SEQUENCING +M: Bartosz Golaszewski <[email protected]> +L: [email protected] +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 <[email protected]> M: Lorenzo Pieralisi <[email protected]>
drivers/power/Kconfig +1 -0
@@ -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"
drivers/power/Makefile +1 -0
@@ -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/
drivers/power/sequencing/Kconfig new file +12 -0
@@ -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.
drivers/power/sequencing/Makefile new file +4 -0
@@ -0,0 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_POWER_SEQUENCING) += pwrseq-core.o +pwrseq-core-y := core.o
drivers/power/sequencing/core.c new file +1065 -0
1,065 lines not on this page · raw message
include/linux/pwrseq/consumer.h new file +56 -0
56 lines not on this page · raw message
include/linux/pwrseq/provider.h new file +75 -0
75 lines not on this page · raw message
Signature · 1 line
2.40.1
Simon Horman
reviewerRe: [PATCH v7 13/16] power: sequencing: implement the pwrseq core
On Wed, Apr 10, 2024 at 02:46:25PM +0200, Bartosz Golaszewski wrote:
...
Quoted 24 lines
drivers/power/sequencing/core.c new file +24
-0+/** +* 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 );
drivers/power/sequencing/core.c line 464
Quoted 10 lines
drivers/power/sequencing/core.c new file +10
-0+ + 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);
Hi Bartosz,
pwrseq is freed on the line above,
so it should not be dereferenced on the line below.
Flagged by Smatch.
Quoted 2 lines
drivers/power/sequencing/core.c new file +2
-0+return ERR_PTR (pwrseq->id); + }
...
PATCH v7 14/16 power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
This adds the power sequencing driver for the PMU modules present on the Qualcomm WCN Bluetooth and Wifi chipsets. It uses the pwrseq subsystem and knows how to match the sequencer to the consumer device by verifying the relevant properties and DT layout.
--- drivers/power/sequencing/Kconfig | 16 + drivers/power/sequencing/Makefile | 2 + drivers/power/sequencing/pwrseq-qcom-wcn.c | 336 +++++++++++++++++++++ 3 files changed, 354 insertions(+) create mode 100644 drivers/power/sequencing/pwrseq-qcom-wcn.c
drivers/power/sequencing/Kconfig +16 -0
@@ -10,3 +10,19 @@ menuconfig POWER_SEQUENCING during power-up. If unsure, say no. + +if POWER_SEQUENCING + +config POWER_SEQUENCING_QCOM_WCN + tristate "Qualcomm WCN family PMU driver" + default m if ARCH_QCOM + help + Say U here to enable the power sequencing driver for Qualcomm + WCN Bluetooth/WLAN chipsets. + + Typically, a package from the Qualcomm WCN family 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
drivers/power/sequencing/Makefile +2 -0
@@ -2,3 +2,5 @@ obj-$(CONFIG_POWER_SEQUENCING) += pwrseq-core.o pwrseq-core-y := core.o + +obj-$(CONFIG_POWER_SEQUENCING_QCOM_WCN) += pwrseq-qcom-wcn.o
drivers/power/sequencing/pwrseq-qcom-wcn.c new file +336 -0
336 lines not on this page · raw message
Signature · 1 line
2.40.1
Re: [PATCH v7 14/16] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
On 4/10/2024 5:46 AM, Bartosz Golaszewski wrote:
[...]
drivers/power/sequencing/Kconfig menuconfig POWER_SEQUENCING · line 20
Quoted 7 lines
drivers/power/sequencing/Kconfig +7
-0+if POWER_SEQUENCING + +config POWER_SEQUENCING_QCOM_WCN + tristate "Qualcomm WCN family PMU driver" + default m if ARCH_QCOM + help + Say U here to enable the power sequencing driver for Qualcomm
did you mean: Say Y here?
Quoted 1 line
drivers/power/sequencing/Kconfig +1
-0+ WCN Bluetooth/WLAN chipsets.
Simon Horman
reviewerRe: [PATCH v7 14/16] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
In reply to Bartosz GolaszewskiOn Wed, Apr 10, 2024 at 02:46:26PM +0200, Bartosz Golaszewski wrote:
...
Quoted 20 lines
drivers/power/sequencing/pwrseq-qcom-wcn.c new file +20
-0+static int pwrseq_qcom_wcn_probe (struct platform_device *pdev) +{ +struct device *dev = &pdev->dev; +struct pwrseq_qcom_wcn_ctx *ctx; +struct pwrseq_config config; +int i, ret; + + 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 =devm_kcalloc (dev, ctx->pdata->num_vregs, +sizeof (*ctx->regs),GFP_KERNEL );
drivers/power/sequencing/pwrseq-qcom-wcn.c line 278
Quoted 10 lines
drivers/power/sequencing/pwrseq-qcom-wcn.c new file +10
-0+if (!ctx->regs) +return -ENOMEM ; + +for (i =0 ; i < ctx->pdata->num_vregs; i++) + ctx->regs[i].supply = ctx->pdata->vregs[i]; + + ret =devm_regulator_bulk_get (dev, ctx->pdata->num_vregs, ctx->regs); +if (ret <0 ) +return dev_err_probe (dev,PTR_ERR (ctx->regs), +"Failed to get all regulators\n" );
Hi Bartosz,
It looks like ctx->regs is not an error pointer here, should this be:
return dev_err_probe(dev, ret, ...
Flagged by Smatch.
Quoted 32 lines
drivers/power/sequencing/pwrseq-qcom-wcn.c new file +32
-0+ + 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" ); + + 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 the reference clock\n" ); + +memset (&config,0 ,sizeof (config)); + + config.parent = dev; + config.owner =THIS_MODULE ; + config.drvdata = ctx; + config.match = pwrseq_qcom_wcn_match; + config.targets = pwrseq_qcom_wcn_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 ; +}
...
PATCH v7 15/16 Bluetooth: qca: use the power sequencer for QCA6390
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Use the pwrseq subsystem's consumer API to run the power-up sequence for the Bluetooth module of the QCA6390 package.
--- drivers/bluetooth/hci_qca.c | 74 +++++++++++++++++++++++++++++-------- 1 file changed, 59 insertions(+), 15 deletions(-)
drivers/bluetooth/hci_qca.c +59 -15
@@ -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 {
@@ -1682,6 +1684,27 @@ static bool qca_wakeup(struct hci_dev *hdev)return wakeup; } +static int qca_port_reopen (struct hci_uart *hu) +{ +int ret; + +/* Now the device is in ready state to communicate with host. +* To sync host with device we need to reopen port. +* Without this, we will have RTS and CTS synchronization +* issues. +*/ +serdev_device_close (hu->serdev); + ret =serdev_device_open (hu->serdev); +if (ret) { +bt_dev_err (hu->hdev,"failed to open port" ); +return ret; + } + +hci_uart_set_flow_control (hu, false); + +return 0 ; +} +static int qca_regulator_init (struct hci_uart *hu) {enum qca_btsoc_type soc_type =qca_soc_type (hu);
@@ -1750,21 +1773,7 @@ static int qca_regulator_init(struct hci_uart *hu)break ; } -/* Now the device is in ready state to communicate with host. -* To sync host with device we need to reopen port. -* Without this, we will have RTS and CTS synchronization -* issues. -*/ -serdev_device_close (hu->serdev); - ret =serdev_device_open (hu->serdev); -if (ret) { -bt_dev_err (hu->hdev,"failed to open port" ); -return ret; - } - -hci_uart_set_flow_control (hu, false); - -return 0 ; +return qca_port_reopen (hu); }static int qca_power_on (struct hci_dev *hdev)
@@ -1792,6 +1801,17 @@ 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); +if (ret) +return ret; + + ret =qca_port_reopen (hu); +if (ret) +return ret; +break ; +default : qcadev =serdev_device_get_drvdata (hu->serdev);if (qcadev->bt_en) {
@@ -2170,6 +2190,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 +2332,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 +2391,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 );
Signature · 1 line
2.40.1
PATCH v7 16/16 PCI/pwrctl: add a PCI power control driver for power sequenced devices
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/pci/pwrctl/Kconfig | 9 +++ drivers/pci/pwrctl/Makefile | 2 + drivers/pci/pwrctl/pci-pwrctl-pwrseq.c | 89 ++++++++++++++++++++++++++ 3 files changed, 100 insertions(+) create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
drivers/pci/pwrctl/Kconfig +9 -0
@@ -5,4 +5,13 @@ 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. + endmenu
drivers/pci/pwrctl/Makefile +2 -0
@@ -2,3 +2,5 @@ obj-$(CONFIG_PCI_PWRCTL) += pci-pwrctl-core.o pci-pwrctl-core-y := core.o + +obj-$(CONFIG_PCI_PWRCTL_PWRSEQ) += pci-pwrctl-pwrseq.o
drivers/pci/pwrctl/pci-pwrctl-pwrseq.c new file +89 -0
89 lines not on this page · raw message
Signature · 1 line
2.40.1
Re: [PATCH v7 16/16] PCI/pwrctl: add a PCI power control driver for power sequenced devices
Quoted 5 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.
[...]
Quoted 5 lines
drivers/pci/pwrctl/Kconfig +5
-0+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)
[...]
drivers/pci/pwrctl/pci-pwrctl-pwrseq.c line 72
Quoted 10 lines
drivers/pci/pwrctl/pci-pwrctl-pwrseq.c new file +10
-0+static const struct of_device_id pci_pwrctl_pwrseq_of_match[] = { + { +/* ATH11K in QCA6390 package. */ + .compatible ="pci17cb,1101" , + .data ="wlan" , + }, + { +/* ATH12K in WCN7850 package. */ + .compatible ="pci17cb,1107" , + .data ="wlan" ,
since you are adding both ath11k and ath12k packages, should you update the commit text and the config "default m if" condition to include ath12k?
/jeff
Quoted 176 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.
A similar design with a discreet PMU is also employed in other models of the WCN family of chips although we can often do without the delays. With this series we add support for the WCN7850 as well.
===
We introduce a new subsystem here - the power sequencing framework. The qcom-wcn driver that we add is its first user. It implements the power-up sequences for QCA6390 and WCN7850 chips. However - we only use it to power-up the bluetooth module in the former. We use it to driver the WLAN modules in both. The reason for this is that for WCN7850 we have comprehensive bindings already upstream together with existing DT users. Porting them to using the pwrseq subsystem can be done separately and in an incremental manner once the subsystem itself is upstream. We will also have to ensure backward DT compatibility. To avoid overcomplicating this series, let's leave it out for now.
===
This series is logically split into several sections. I'll go patch-by-patch and explain each step.
Patches 1/16-5/16:
These contain all relevant DT bindings changes. We add new documents for the QCA6390 & WCN7850 PMUs and ATH12K devices as well as extend the bindings for the Qualcomm Bluetooth and ATH11K modules with regulators used by them in QCA6390.
Patches 6/16-8/16:
These contain changes to device-tree sources for the three platforms we work with in this series. We model the PMUs of the WLAN/BT chips as top-level platform devices on the device tree. In order to limit the scope of this series and not introduce an excessive amount of confusion with deprecating DT bindings, we leave the Bluetooth nodes on sm8650 and sm8550 as is (meaning: they continue to consumer the GPIOs and power inputs from the host). As the WCN7850 module doesn't require any specific timings, we can incrementally change that later.
In both cases we add WLAN nodes that consume the power outputs of the PMU. For QCA6390 we also make the Bluetooth node of the RB5 consume the outputs of the PMU - we can do it as the bindings for this chip did not define any supply handles prior to this series meaning we are able to get this correct right away.
Patches 9/16-12/16:
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.
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).
Patch 13/16 - 14/16:
These add a relatively simple power sequencing subsystem and the first driver using it: the pwrseq module for the PMUs on the WCN family of chips.
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 15:
This patch makes the Qualcomm Bluetooth driver get and use the power sequencer for QCA6390.
Patch 16:
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 and ath12k on WCN7850.
Quoted 4 lines
With this series we can now enable BT and WLAN on several new Qualcomm boards upstream.
Tested on RB5, sm8650-qrd and sm8550-qrd.
Tested WiFi-BT on sm8550-hdk running AOSP with a DT patch similar to sm8550-qrd from this series.
Regards,
Amit Pundir
Quoted 119 lines
Changelog:
Since v6:
- kernel doc fixes
- drop myself from the DT bindings maintainers list for ath12k
- wait until the PCI bridge device is fully added before creating the PCI pwrctl platform devices for its sub-nodes, otherwise we may see sysfs and procfs attribute failures (due to duplication, we're basically trying to probe the same device twice at the same time)
- I kept the regulators for QCA6390's ath11k as required as they only apply to this specific Qualcomm packageSince v5:
- unify the approach to modelling the WCN WLAN/BT chips by always exposing the PMU node on the device tree and making the WLAN and BT nodes become consumers of its power outputs; this includes a major rework of the DT sources, bindings and driver code; there's no more a separate PCI pwrctl driver for WCN7850, instead its power-up sequence was moved into the pwrseq driver common for all WCN chips
- don't setload_uAfrom new regulator consumers
- fix reported kerneldoc issues
- drop voltage ranges for PMU outputs from DT
- many minor tweaks and reworksv1: Original RFC:
https://lore.kernel.org/lkml/[email protected]/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/[email protected]/T/
v5: Two different ways of handling QCA6390 and WCN7850:
https://lore.kernel.org/lkml/[email protected]/
Bartosz Golaszewski (16):
regulator: dt-bindings: describe the PMU module of the QCA6390 package
regulator: dt-bindings: describe the PMU module of the WCN7850 package
dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
dt-bindings: net: wireless: qcom,ath11k: describe the ath11k onQCA6390dt-bindings: net: wireless: describe the ath12k PCI module
arm64: dts: qcom: sm8550-qrd: add the Wifi node
arm64: dts: qcom: sm8650-qrd: add the Wifi node
arm64: dts: qcom: qrb5165-rb5: add the Wifi node
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
power: sequencing: implement the pwrseq core
power: pwrseq: add a driver for the PMU module on the QCom WCN
chipsets
Bluetooth: qca: use the power sequencer for QCA6390 PCI/pwrctl: add a PCI power control driver for power sequenced devices.../net/bluetooth/qualcomm-bluetooth.yaml | 17 + .../net/wireless/qcom,ath11k-pci.yaml | 46 + .../bindings/net/wireless/qcom,ath12k.yaml | 99 ++ .../bindings/regulator/qcom,qca6390-pmu.yaml | 185 +++ MAINTAINERS | 8 + arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 103 +- arch/arm64/boot/dts/qcom/sm8250.dtsi | 10 + arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 97 ++ arch/arm64/boot/dts/qcom/sm8550.dtsi | 10 + arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 89 ++ arch/arm64/boot/dts/qcom/sm8650.dtsi | 10 + drivers/bluetooth/hci_qca.c | 74 +- 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 | 17 + drivers/pci/pwrctl/Makefile | 6 + drivers/pci/pwrctl/core.c | 137 +++ drivers/pci/pwrctl/pci-pwrctl-pwrseq.c | 89 ++ 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-qcom-wcn.c | 336 ++++++ include/linux/pci-pwrctl.h | 51 + include/linux/pwrseq/consumer.h | 56 + include/linux/pwrseq/provider.h | 75 ++ 31 files changed, 2615 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.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/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-qcom-wcn.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