power sequencing updates for v6.12-rc1

- add support for the new PMU variant inside the WCN6855 chipset
 - add documentation for the subsystem
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmboGdwACgkQEacuoBRx
 13KsGg/9GTiUYAKZwrK41Njh79DLGp4+tbVx2/AR1Az2hkablZa6PkRQrLs8AQT5
 nOWfnWFSNuQoBXPo3XZ6Hh/NAwHBQTmJjw9lQVZUJPQAcdJC6lyo6pGH0/Exu9qB
 V69UgNhqWKJ/9Vv23+i8pBOoH/IjyhCLZJU9+NHU3X3/SJ2Ek+5g5O/mgpq3fPk9
 wgcs6/s1ITaOKAqZ5p0uPWMlCTKf9tWiszrRDik9AHOD9kpfLzzJs8SqV3f+XGZN
 P+oi3NOqgf7nQbVQcIiMrGFyd4eRM1tZAMySVZdMaqZO8KK5Aimy4MX9fdVtAIzC
 Gv42R6uyG2O/mkEpkFE7wgKL/S9r4ThZB18KbwuWOCdfRPRPDwvGSFSxvPJue272
 zRSAweIp8FPcds2Jktsb1D5ypiJ9eV9Ti+wjloKG81EXgiwp4PGgQ1sviAy+1rSl
 Wyr/E5UQ98tSpm86CXJu7KyBoenfhLOAGkotPr7zNbbGFDmRgyNODz82fSaOZMtx
 ZB+js7DtQ5vFeQZHAAHKDUoIjUY9J8KvEoamKvB+sKq81BpR2pPCyA0mPD7cOVD/
 ksfs86UffGh9fHRoz1Q+jCZyLAdA7MY4mdfVCIdXm71EFe7KpMCP886DykYoDIOp
 qiO0fJsnRiZdNzV240FD+9k4rWd+NV56o00v2pwgiAjjFeb9ROk=
 =u9Ea
 -----END PGP SIGNATURE-----

Merge tag 'pwrseq-updates-for-v6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

Pull power sequencing updates from Bartosz Golaszewski:
 "There's one change adding support for a new PMU model and another
  adding documentation for the subsystem which probably should have been
  part of the initial commit but better late than never:

   - add support for the new PMU variant inside the WCN6855 chipset

   - add documentation for the subsystem"

* tag 'pwrseq-updates-for-v6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  Documentation: add a driver API doc for the power sequencing subsystem
  power: sequencing: qcom-wcn: add support for the WCN6855 PMU
This commit is contained in:
Linus Torvalds 2024-09-18 10:46:27 +02:00
commit 2fe3c78a2c
4 changed files with 108 additions and 0 deletions

View File

@ -124,6 +124,7 @@ Subsystem-specific APIs
pps pps
ptp ptp
pwm pwm
pwrseq
regulator regulator
reset reset
rfkill rfkill

View File

@ -0,0 +1,95 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright 2024 Linaro Ltd.
====================
Power Sequencing API
====================
:Author: Bartosz Golaszewski
Introduction
============
This framework is designed to abstract complex power-up sequences that are
shared between multiple logical devices in the linux kernel.
The intention is to allow consumers to obtain a power sequencing handle
exposed by the power sequence provider and delegate the actual requesting and
control of the underlying resources as well as to allow the provider to
mitigate any potential conflicts between multiple users behind the scenes.
Glossary
--------
The power sequencing API uses a number of terms specific to the subsystem:
Unit
A unit is a discreet chunk of a power sequence. For instance one unit may
enable a set of regulators, another may enable a specific GPIO. Units can
define dependencies in the form of other units that must be enabled before
it itself can be.
Target
A target is a set of units (composed of the "final" unit and its
dependencies) that a consumer selects by its name when requesting a handle
to the power sequencer. Via the dependency system, multiple targets may
share the same parts of a power sequence but ignore parts that are
irrelevant.
Descriptor
A handle passed by the pwrseq core to every consumer that serves as the
entry point to the provider layer. It ensures coherence between different
users and keeps reference counting consistent.
Consumer interface
==================
The consumer API is aimed to be as simple as possible. The driver interested in
getting a descriptor from the power sequencer should call pwrseq_get() and
specify the name of the target it wants to reach in the sequence after calling
pwrseq_power_up(). The descriptor can be released by calling pwrseq_put() and
the consumer can request the powering down of its target with
pwrseq_power_off(). Note that there is no guarantee that pwrseq_power_off()
will have any effect as there may be multiple users of the underlying resources
who may keep them active.
Provider interface
==================
The provider API is admittedly not nearly as straightforward as the one for
consumers but it makes up for it in flexibility.
Each provider can logically split the power-up sequence into descrete chunks
(units) and define their dependencies. They can then expose named targets that
consumers may use as the final point in the sequence that they wish to reach.
To that end the providers fill out a set of configuration structures and
register with the pwrseq subsystem by calling pwrseq_device_register().
Dynamic consumer matching
-------------------------
The main difference between pwrseq and other linux kernel providers is the
mechanism for dynamic matching of consumers and providers. Every power sequence
provider driver must implement the `match()` callback and pass it to the pwrseq
core when registering with the subsystems.
When a client requests a sequencer handle, the core will call this callback for
every registered provider and let it flexibly figure out whether the proposed
client device is indeed its consumer. For example: if the provider binds to the
device-tree node representing a power management unit of a chipset and the
consumer driver controls one of its modules, the provider driver may parse the
relevant regulator supply properties in device tree and see if they lead from
the PMU to the consumer.
API reference
=============
.. kernel-doc:: include/linux/pwrseq/provider.h
:internal:
.. kernel-doc:: drivers/power/sequencing/core.c
:export:

View File

@ -18331,6 +18331,7 @@ M: Bartosz Golaszewski <brgl@bgdev.pl>
L: linux-pm@vger.kernel.org L: linux-pm@vger.kernel.org
S: Maintained S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
F: Documentation/driver-api/pwrseq.rst
F: drivers/power/sequencing/ F: drivers/power/sequencing/
F: include/linux/pwrseq/ F: include/linux/pwrseq/

View File

@ -198,6 +198,13 @@ static const struct pwrseq_qcom_wcn_pdata pwrseq_qca6390_of_data = {
.gpio_enable_delay_ms = 100, .gpio_enable_delay_ms = 100,
}; };
static const struct pwrseq_qcom_wcn_pdata pwrseq_wcn6855_of_data = {
.vregs = pwrseq_qca6390_vregs,
.num_vregs = ARRAY_SIZE(pwrseq_qca6390_vregs),
.pwup_delay_ms = 50,
.gpio_enable_delay_ms = 5,
};
static const char *const pwrseq_wcn7850_vregs[] = { static const char *const pwrseq_wcn7850_vregs[] = {
"vdd", "vdd",
"vddio", "vddio",
@ -321,6 +328,10 @@ static const struct of_device_id pwrseq_qcom_wcn_of_match[] = {
.compatible = "qcom,qca6390-pmu", .compatible = "qcom,qca6390-pmu",
.data = &pwrseq_qca6390_of_data, .data = &pwrseq_qca6390_of_data,
}, },
{
.compatible = "qcom,wcn6855-pmu",
.data = &pwrseq_wcn6855_of_data,
},
{ {
.compatible = "qcom,wcn7850-pmu", .compatible = "qcom,wcn7850-pmu",
.data = &pwrseq_wcn7850_of_data, .data = &pwrseq_wcn7850_of_data,