mirror of
				git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
				synced 2025-11-01 09:13:37 +00:00 
			
		
		
		
	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:
		
						commit
						2fe3c78a2c
					
				
					 4 changed files with 108 additions and 0 deletions
				
			
		| 
						 | 
				
			
			@ -124,6 +124,7 @@ Subsystem-specific APIs
 | 
			
		|||
   pps
 | 
			
		||||
   ptp
 | 
			
		||||
   pwm
 | 
			
		||||
   pwrseq
 | 
			
		||||
   regulator
 | 
			
		||||
   reset
 | 
			
		||||
   rfkill
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
							
								
								
									
										95
									
								
								Documentation/driver-api/pwrseq.rst
									
										
									
									
									
										Normal file
									
								
							
							
						
						
									
										95
									
								
								Documentation/driver-api/pwrseq.rst
									
										
									
									
									
										Normal 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:
 | 
			
		||||
| 
						 | 
				
			
			@ -18331,6 +18331,7 @@ M:	Bartosz Golaszewski <brgl@bgdev.pl>
 | 
			
		|||
L:	linux-pm@vger.kernel.org
 | 
			
		||||
S:	Maintained
 | 
			
		||||
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
 | 
			
		||||
F:	Documentation/driver-api/pwrseq.rst
 | 
			
		||||
F:	drivers/power/sequencing/
 | 
			
		||||
F:	include/linux/pwrseq/
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -198,6 +198,13 @@ static const struct pwrseq_qcom_wcn_pdata pwrseq_qca6390_of_data = {
 | 
			
		|||
	.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[] = {
 | 
			
		||||
	"vdd",
 | 
			
		||||
	"vddio",
 | 
			
		||||
| 
						 | 
				
			
			@ -321,6 +328,10 @@ static const struct of_device_id pwrseq_qcom_wcn_of_match[] = {
 | 
			
		|||
		.compatible = "qcom,qca6390-pmu",
 | 
			
		||||
		.data = &pwrseq_qca6390_of_data,
 | 
			
		||||
	},
 | 
			
		||||
	{
 | 
			
		||||
		.compatible = "qcom,wcn6855-pmu",
 | 
			
		||||
		.data = &pwrseq_wcn6855_of_data,
 | 
			
		||||
	},
 | 
			
		||||
	{
 | 
			
		||||
		.compatible = "qcom,wcn7850-pmu",
 | 
			
		||||
		.data = &pwrseq_wcn7850_of_data,
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		
		Reference in a new issue