RFC power domain vs generic supply regulator

RFC power domain vs generic supply regulator

[Michael Nazzareno Trimarchi]

Hi all

I'm trying to understand how to deal with devices that do not provide
a supply handle connection using the device tree, or if there is a
generic way
to connect to a regulator. The pinctrl has a generic binding inside
dd.c that allow to mux pinout during probing or it allows to define a
power domain,
According to the code I read the power domain can be only connected to
the SoC power domain but in general a generic power domain can be
connected
to any source aka a regulator. For example and spi-nor can be powered
but a gpio regulator or any kind of supply connection and bunch of
devices
can just need a supply if they are probed or binded runtime. Can
someone give me feedback on this topic?

Michael

Re: RFC power domain vs generic supply regulator

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

On Tue, Jun 08, 2021 at 08:01:20AM +0200, Michael Nazzareno Trimarchi wrote:

> I'm trying to understand how to deal with devices that do not provide
> a supply handle connection using the device tree, or if there is a
> generic way
> to connect to a regulator. The pinctrl has a generic binding inside
> dd.c that allow to mux pinout during probing or it allows to define a
> power domain,
> According to the code I read the power domain can be only connected to
> the SoC power domain but in general a generic power domain can be
> connected
> to any source aka a regulator. For example and spi-nor can be powered
> but a gpio regulator or any kind of supply connection and bunch of
> devices
> can just need a supply if they are probed or binded runtime. Can
> someone give me feedback on this topic?

I'm having a really hard time parsing the issue you're trying to solve
here.  Power domains and regulators are different things, power domains
represent blocks with a SoC which have some kind of power control which
may involve a combination of things, the drivers for the devices within
those domains generally just do runtime PM and then let the driver core
figure out what's going on with them.  Regulators are for things with
physical supplies that can be seen in the schematic for the board, in
general anything that uses a regulator should explicitly say so in its
binding - supporting some sort of generic mapping isn't great since it
means that we don't have any control over which regulator is which and
that makes it hard to add control of the regulators later.  Power
domanis may possibly have regulators among the resources they use but
that would just be a normal device binding for the power domain.  All of
this is orthogonal to when drivers for devices get loaded, that can
happen at any point while the system is running and doesn't really
affect how the relationships are described.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: RFC power domain vs generic supply regulator

[Michael Nazzareno Trimarchi]

Hi Mark

On Thu, Aug 5, 2021 at 7:23 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Jun 08, 2021 at 08:01:20AM +0200, Michael Nazzareno Trimarchi wrote:
>
> > I'm trying to understand how to deal with devices that do not provide
> > a supply handle connection using the device tree, or if there is a
> > generic way
> > to connect to a regulator. The pinctrl has a generic binding inside
> > dd.c that allow to mux pinout during probing or it allows to define a
> > power domain,
> > According to the code I read the power domain can be only connected to
> > the SoC power domain but in general a generic power domain can be
> > connected
> > to any source aka a regulator. For example and spi-nor can be powered
> > but a gpio regulator or any kind of supply connection and bunch of
> > devices
> > can just need a supply if they are probed or binded runtime. Can
> > someone give me feedback on this topic?
>
> I'm having a really hard time parsing the issue you're trying to solve
> here.  Power domains and regulators are different things, power domains
> represent blocks with a SoC which have some kind of power control which
> may involve a combination of things, the drivers for the devices within
> those domains generally just do runtime PM and then let the driver core
> figure out what's going on with them.  Regulators are for things with
> physical supplies that can be seen in the schematic for the board, in
> general anything that uses a regulator should explicitly say so in its
> binding - supporting some sort of generic mapping isn't great since it
> means that we don't have any control over which regulator is which and
> that makes it hard to add control of the regulators later.  Power
> domanis may possibly have regulators among the resources they use but
> that would just be a normal device binding for the power domain.  All of
> this is orthogonal to when drivers for devices get loaded, that can
> happen at any point while the system is running and doesn't really
> affect how the relationships are described.

So in short you said that if I have a device that has no definition of
supply in his
documentation, this device needs to support the supply in his binding
and make to sense
to create something like:

generic-supply = <&regulator_device>;

and let dd to pick them up

Michael




-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

Re: RFC power domain vs generic supply regulator

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Thu, Aug 05, 2021 at 07:39:42PM +0200, Michael Nazzareno Trimarchi wrote:

> So in short you said that if I have a device that has no definition of
> supply in his
> documentation, this device needs to support the supply in his binding
> and make to sense
> to create something like:

> generic-supply = <&regulator_device>;

No, the bindings should use the specific names that the supplies have,
generally whatever the names they are given in the datasheet for the
device.  If the device has no actual supplies then it almost certainly
shouldn't be working with the regulator API.

> and let dd to pick them up

No, the driver for the device should handle things.  The code is pretty
trivial, though if someone wants to write helpers then sure.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]