| Message ID | 20240528-pwrseq-v8-0-d354d52b763c@linaro.org |
|---|---|
| Headers | show |
| Series | power: sequencing: implement the subsystem and add first users | expand |
On 28/05/2024 21:03, Bartosz Golaszewski wrote: > Note: I am resending this series in its entirety once more for > discussions and reviews. If there won't be any major objections, I'll > then start sending individual bits and pieces to appropriate trees. > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > can go through the wireless, regulator and arm-msm trees separately. The > bluetooth and PCI changes have a build-time dependency on the power > sequencing code. The bluetooth changes also have a run-time dependency on > the PCI pwrctl part. In order to get it into next I plan to pick up the > power sequencing code into my own tree and maintain it. I can then > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > stress about the BT runtime dependency as it will be fixed once all > changes are in next. > > The actual cover letter follows: > > -- > > 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, sm8650-hdk and sm8550-qrd. > > Changelog: > > Since v7: > - added DTS changes for sm8650-hdk > - added circular dependency detection for pwrseq units > - fixed a KASAN reported use-after-free error in remove path > - improve Kconfig descriptions > - fix typos in bindings and Kconfig > - fixed issues reported by smatch > - fix the unbind path in PCI pwrctl > - lots of minor improvements to the pwrseq core > > 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/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/ > > v5: Two different ways of handling QCA6390 and WCN7850: > > https://lore.kernel.org/lkml/20240216203215.40870-1-brgl@bgdev.pl/ > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > 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 > power: sequencing: implement the pwrseq core > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > 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 PCI power control driver for power sequenced devices > Bluetooth: qca: use the power sequencer for QCA6390 > > Neil Armstrong (1): > arm64: dts: qcom: sm8650-hdk: add the Wifi node > > .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 17 + > .../bindings/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 | 2 +- > arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 97 ++ > arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +- > arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 89 ++ > arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 89 ++ > arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +- > 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 | 3 +- > drivers/power/Kconfig | 1 + > drivers/power/Makefile | 1 + > drivers/power/sequencing/Kconfig | 28 + > drivers/power/sequencing/Makefile | 6 + > drivers/power/sequencing/core.c | 1105 ++++++++++++++++++++ > 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 ++ > 32 files changed, 2717 insertions(+), 34 deletions(-) > --- > base-commit: 6dc544b66971c7f9909ff038b62149105272d26a > change-id: 20240527-pwrseq-76fc025248a2 > > Best regards, Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Thanks, Neil
On 28/05/2024 21:03, Bartosz Golaszewski wrote: > Note: I am resending this series in its entirety once more for > discussions and reviews. If there won't be any major objections, I'll > then start sending individual bits and pieces to appropriate trees. > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > can go through the wireless, regulator and arm-msm trees separately. The > bluetooth and PCI changes have a build-time dependency on the power > sequencing code. The bluetooth changes also have a run-time dependency on > the PCI pwrctl part. In order to get it into next I plan to pick up the > power sequencing code into my own tree and maintain it. I can then > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > stress about the BT runtime dependency as it will be fixed once all > changes are in next. > > The actual cover letter follows: > > -- > > 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, sm8650-hdk and sm8550-qrd. > > Changelog: > > Since v7: > - added DTS changes for sm8650-hdk > - added circular dependency detection for pwrseq units > - fixed a KASAN reported use-after-free error in remove path > - improve Kconfig descriptions > - fix typos in bindings and Kconfig > - fixed issues reported by smatch > - fix the unbind path in PCI pwrctl > - lots of minor improvements to the pwrseq core > > 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/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/ > > v5: Two different ways of handling QCA6390 and WCN7850: > > https://lore.kernel.org/lkml/20240216203215.40870-1-brgl@bgdev.pl/ > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > 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 > power: sequencing: implement the pwrseq core > power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets > 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 PCI power control driver for power sequenced devices > Bluetooth: qca: use the power sequencer for QCA6390 > > Neil Armstrong (1): > arm64: dts: qcom: sm8650-hdk: add the Wifi node > > .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 17 + > .../bindings/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 | 2 +- > arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 97 ++ > arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +- > arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 89 ++ > arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 89 ++ > arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +- > 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 | 3 +- > drivers/power/Kconfig | 1 + > drivers/power/Makefile | 1 + > drivers/power/sequencing/Kconfig | 28 + > drivers/power/sequencing/Makefile | 6 + > drivers/power/sequencing/core.c | 1105 ++++++++++++++++++++ > 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 ++ > 32 files changed, 2717 insertions(+), 34 deletions(-) > --- > base-commit: 6dc544b66971c7f9909ff038b62149105272d26a > change-id: 20240527-pwrseq-76fc025248a2 > > Best regards Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # OnePlus 8T
On Tue, May 28, 2024 at 09:03:08PM +0200, Bartosz Golaszewski wrote: > Note: I am resending this series in its entirety once more for > discussions and reviews. If there won't be any major objections, I'll > then start sending individual bits and pieces to appropriate trees. > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > can go through the wireless, regulator and arm-msm trees separately. The > bluetooth and PCI changes have a build-time dependency on the power > sequencing code. The bluetooth changes also have a run-time dependency on > the PCI pwrctl part. In order to get it into next I plan to pick up the > power sequencing code into my own tree and maintain it. I can then > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > stress about the BT runtime dependency as it will be fixed once all > changes are in next. > ... > --- > base-commit: 6dc544b66971c7f9909ff038b62149105272d26a > change-id: 20240527-pwrseq-76fc025248a2 What does this apply to? I don't know what 6dc544b66971 is; it doesn't seem to be in upstream or linux-next.
On Tue, Jun 4, 2024 at 7:19 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Tue, May 28, 2024 at 09:03:08PM +0200, Bartosz Golaszewski wrote: > > Note: I am resending this series in its entirety once more for > > discussions and reviews. If there won't be any major objections, I'll > > then start sending individual bits and pieces to appropriate trees. > > > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > > can go through the wireless, regulator and arm-msm trees separately. The > > bluetooth and PCI changes have a build-time dependency on the power > > sequencing code. The bluetooth changes also have a run-time dependency on > > the PCI pwrctl part. In order to get it into next I plan to pick up the > > power sequencing code into my own tree and maintain it. I can then > > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > > stress about the BT runtime dependency as it will be fixed once all > > changes are in next. > > ... > > > --- > > base-commit: 6dc544b66971c7f9909ff038b62149105272d26a > > change-id: 20240527-pwrseq-76fc025248a2 > > What does this apply to? I don't know what 6dc544b66971 is; it > doesn't seem to be in upstream or linux-next. It's next-20240528 but it also applies to today's next without conflicts. What do you want me to base the PCI part when resending? Bart
On Tue, Jun 04, 2024 at 08:24:34PM +0200, Bartosz Golaszewski wrote: > On Tue, Jun 4, 2024 at 7:19 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > On Tue, May 28, 2024 at 09:03:08PM +0200, Bartosz Golaszewski wrote: > > > Note: I am resending this series in its entirety once more for > > > discussions and reviews. If there won't be any major objections, I'll > > > then start sending individual bits and pieces to appropriate trees. > > > > > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > > > can go through the wireless, regulator and arm-msm trees separately. The > > > bluetooth and PCI changes have a build-time dependency on the power > > > sequencing code. The bluetooth changes also have a run-time dependency on > > > the PCI pwrctl part. In order to get it into next I plan to pick up the > > > power sequencing code into my own tree and maintain it. I can then > > > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > > > stress about the BT runtime dependency as it will be fixed once all > > > changes are in next. > > > ... > > > > > --- > > > base-commit: 6dc544b66971c7f9909ff038b62149105272d26a > > > change-id: 20240527-pwrseq-76fc025248a2 > > > > What does this apply to? I don't know what 6dc544b66971 is; it > > doesn't seem to be in upstream or linux-next. > > It's next-20240528 but it also applies to today's next without > conflicts. What do you want me to base the PCI part when resending? For PCI, we usually apply things on topic branches based on -rc1, so that's the easiest.
On Tue, May 28, 2024 at 09:03:08PM +0200, Bartosz Golaszewski wrote: > Note: I am resending this series in its entirety once more for > discussions and reviews. If there won't be any major objections, I'll > then start sending individual bits and pieces to appropriate trees. > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > can go through the wireless, regulator and arm-msm trees separately. The > bluetooth and PCI changes have a build-time dependency on the power > sequencing code. The bluetooth changes also have a run-time dependency on > the PCI pwrctl part. In order to get it into next I plan to pick up the > power sequencing code into my own tree and maintain it. I can then > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > stress about the BT runtime dependency as it will be fixed once all > changes are in next. The PCI changes are very self-contained and any conflicts will be trivial, so rather than messing with an immutable tag, how about if I just ack them and you can include them in your tree directly?
On Wed, Jun 12, 2024 at 12:54 AM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Tue, May 28, 2024 at 09:03:08PM +0200, Bartosz Golaszewski wrote: > > Note: I am resending this series in its entirety once more for > > discussions and reviews. If there won't be any major objections, I'll > > then start sending individual bits and pieces to appropriate trees. > > > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > > can go through the wireless, regulator and arm-msm trees separately. The > > bluetooth and PCI changes have a build-time dependency on the power > > sequencing code. The bluetooth changes also have a run-time dependency on > > the PCI pwrctl part. In order to get it into next I plan to pick up the > > power sequencing code into my own tree and maintain it. I can then > > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > > stress about the BT runtime dependency as it will be fixed once all > > changes are in next. > > The PCI changes are very self-contained and any conflicts will be > trivial, so rather than messing with an immutable tag, how about if I > just ack them and you can include them in your tree directly? Sure, if you're convinced that eventual conflicts in PCI core won't be an issue then it's even better. Bart
Hello: This series was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Tue, 28 May 2024 21:03:08 +0200 you wrote: > Note: I am resending this series in its entirety once more for > discussions and reviews. If there won't be any major objections, I'll > then start sending individual bits and pieces to appropriate trees. > > Merging strategy: The DT binding and DTS changes are a no-brainer, they > can go through the wireless, regulator and arm-msm trees separately. The > bluetooth and PCI changes have a build-time dependency on the power > sequencing code. The bluetooth changes also have a run-time dependency on > the PCI pwrctl part. In order to get it into next I plan to pick up the > power sequencing code into my own tree and maintain it. I can then > provide an immutable tag for the BT and PCI trees to pull. I wouldn't > stress about the BT runtime dependency as it will be fixed once all > changes are in next. > > [...] Here is the summary with links: - [v8,01/17] regulator: dt-bindings: describe the PMU module of the QCA6390 package (no matching commit) - [v8,02/17] regulator: dt-bindings: describe the PMU module of the WCN7850 package (no matching commit) - [v8,03/17] dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390 https://git.kernel.org/bluetooth/bluetooth-next/c/251180e6dba5 - [v8,04/17] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390 (no matching commit) - [v8,05/17] dt-bindings: net: wireless: describe the ath12k PCI module (no matching commit) - [v8,06/17] arm64: dts: qcom: sm8550-qrd: add the Wifi node (no matching commit) - [v8,07/17] arm64: dts: qcom: sm8650-qrd: add the Wifi node (no matching commit) - [v8,08/17] arm64: dts: qcom: sm8650-hdk: add the Wifi node (no matching commit) - [v8,09/17] arm64: dts: qcom: qrb5165-rb5: add the Wifi node (no matching commit) - [v8,10/17] power: sequencing: implement the pwrseq core (no matching commit) - [v8,11/17] power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (no matching commit) - [v8,12/17] PCI: hold the rescan mutex when scanning for the first time (no matching commit) - [v8,13/17] PCI/pwrctl: reuse the OF node for power controlled devices (no matching commit) - [v8,14/17] PCI/pwrctl: create platform devices for child OF nodes of the port node (no matching commit) - [v8,15/17] PCI/pwrctl: add PCI power control core code (no matching commit) - [v8,16/17] PCI/pwrctl: add a PCI power control driver for power sequenced devices (no matching commit) - [v8,17/17] Bluetooth: qca: use the power sequencer for QCA6390 https://git.kernel.org/bluetooth/bluetooth-next/c/4029dba6b6f1 You are awesome, thank you!
Note: I am resending this series in its entirety once more for discussions and reviews. If there won't be any major objections, I'll then start sending individual bits and pieces to appropriate trees. Merging strategy: The DT binding and DTS changes are a no-brainer, they can go through the wireless, regulator and arm-msm trees separately. The bluetooth and PCI changes have a build-time dependency on the power sequencing code. The bluetooth changes also have a run-time dependency on the PCI pwrctl part. In order to get it into next I plan to pick up the power sequencing code into my own tree and maintain it. I can then provide an immutable tag for the BT and PCI trees to pull. I wouldn't stress about the BT runtime dependency as it will be fixed once all changes are in next. The actual cover letter follows: -- 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, sm8650-hdk and sm8550-qrd. Changelog: Since v7: - added DTS changes for sm8650-hdk - added circular dependency detection for pwrseq units - fixed a KASAN reported use-after-free error in remove path - improve Kconfig descriptions - fix typos in bindings and Kconfig - fixed issues reported by smatch - fix the unbind path in PCI pwrctl - lots of minor improvements to the pwrseq core 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/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/ v5: Two different ways of handling QCA6390 and WCN7850: https://lore.kernel.org/lkml/20240216203215.40870-1-brgl@bgdev.pl/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> --- 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 power: sequencing: implement the pwrseq core power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets 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 PCI power control driver for power sequenced devices Bluetooth: qca: use the power sequencer for QCA6390 Neil Armstrong (1): arm64: dts: qcom: sm8650-hdk: add the Wifi node .../bindings/net/bluetooth/qualcomm-bluetooth.yaml | 17 + .../bindings/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 | 2 +- arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 97 ++ arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +- arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 89 ++ arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 89 ++ arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +- 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 | 3 +- drivers/power/Kconfig | 1 + drivers/power/Makefile | 1 + drivers/power/sequencing/Kconfig | 28 + drivers/power/sequencing/Makefile | 6 + drivers/power/sequencing/core.c | 1105 ++++++++++++++++++++ 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 ++ 32 files changed, 2717 insertions(+), 34 deletions(-) --- base-commit: 6dc544b66971c7f9909ff038b62149105272d26a change-id: 20240527-pwrseq-76fc025248a2 Best regards,