Re: [PATCH v1 0/5] power: domain: Add driver for a PM domain provider which controls

[Ulf Hansson <ulf.hansson@linaro.org>]

On Thu, 9 Jun 2022 at 08:09, Max Krummenacher <max.oss.09@gmail.com> wrote:
>
> From: Max Krummenacher <max.krummenacher@toradex.com>
>
> its power enable by using a regulator.
>
> The currently implemented PM domain providers are all specific to
> a particular system on chip.
>
> 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.
>
> 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).
> 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.

I don't want to interrupt the discussion, but I still wanted to share
my overall thoughts around the suggested approach.

Rather than adding some new DT bindings and a new generic DT
compatible, I think the current power-domains bindings are sufficient
to describe these types of HWs.

To me, it looks rather like you are striving towards avoiding open
coding for power domain providers that make use of a regulator. Right?

To address that problem, I think a better option is to consider
introducing a helper library with a set of functions that can be used
by these types of power domain providers, in a way to simplify the
code.

[...]

Kind regards
Uffe