On Thu, Jun 09, 2022 at 05:08:46PM +0200, Max Krummenacher wrote: > From: Max Krummenacher <max.krummenacher@xxxxxxxxxxx> > > its power enable by using a regulator. > > The currently implemented PM domain providers are all specific to > a particular system on chip. Yes, power domains tend to be specific to an SoC... 'power-domains' is supposed to be power islands in a chip. Linux 'PM domains' can be anything... > This series adds a PM domain provider driver which enables/disables > a regulator to control its power state. Additionally, marked with RFC, > it adds two commits which actually make use of the new driver to > instantiate a power domain provider and have a number of power > domain consumers use the power domain. > > The perceived use case is to control a common power domain used by > several devices for which not all device drivers nessesarily have > a means to control a regulator. Why wouldn't they have means? > It also handles the suspend / resume use case for such devices, > the generic power domain framework will disable the domain once the > last device has been suspend and will enable it again before resuming > the first device. > The generic power domain code handles a power domain consumer > generically outside of the driver's code. (assuming the 'power-domains' > property references exactly one power domain). That's Linux implementation details. > This allows to use the "regulator-pm-pd" driver with an arbitrary > device just by adding the 'power-domains' property to the devices > device tree node. However the device's dt-bindings schema likely does > not allow the property 'power-domains'. > One way to solve this would be to allow 'power-domains' globally > similarly how 'status' and other common properties are allowed as > implicit properties. No. For 'power-domains' bindings have to define how many there are and what each one is. Rob
