Regulators vis-a-vis Power Domains

Regulators vis-a-vis Power Domains

[Sundar R IYER]

Hello All,
?
I have a few queries about regulators vis-a-vis power domains.
?
1. The documentation for the regulators mentions "power domains" and "switches" to be modeled as regulators. I am planning to model multiple "switches" for controlling supplies to various peripherals from a main master regulator as multiple regulators, childed from the parent regulator. Is this the right way to proceed ahead? Further the options for these switches will be only?a logical on/off. (BTW, I saw lots of TI stuff which is something related to power domains, but it doesn't model the regulator framework.)
?
2. In the same example below, should I instead model just the main regulator, and in the driver specific enable/disable, iterate through the list of consumers, and then accordingly enable/disable these switches according to the calling consumer?. In this way,?I can choose not to clutter those smaller switches as regulators in my regulator as well as peripheral driver code.?
?
3. Extending the same model, I want to use the _set_optimum API. Logically, enabling/disabling the child supply or setting an optimal load on the regulator must propagate the new load to any master regulator ( which can then again be set an optimal load). My understanding of this function shows me that?currently, this is not supported in the function. Am I right in deducing this or?have I failed to overlook some other portions in the regulator code?
?
Waiting for all your valuable replies!
?
Sundar

Re: Regulators vis-a-vis Power Domains

[Mark Brown]

On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:

Please fix your mail client to word wrap within paragraphs; not doing
this makes your messages harder to read and reply to.  I've reflowed below.

> 1. The documentation for the regulators mentions "power domains" and
> "switches" to be modeled as regulators. I am planning to model multiple
> "switches" for controlling supplies to various peripherals from a main
> master regulator as multiple regulators, childed from the parent
> regulator. Is this the right way to proceed ahead? Further the options

If you want to do this in the regulator framework, yes.

> for these switches will be only a logical on/off. (BTW, I saw lots of TI
> stuff which is something related to power domains, but it doesn't model
> the regulator framework.)

Nor does the SH stuff.  With the power domains of a CPU it often doesn't
buy terribly much to use the regulator framework - the power domains are
often a small part of a much bigger picture for the CPU internal power
management, often incorporating thing 

> 2. In the same example below, should I instead model just the main
> regulator, and in the driver specific enable/disable, iterate through
> the list of consumers, and then accordingly enable/disable these
> switches according to the calling consumer?. In this way, I can choose
> not to clutter those smaller switches as regulators in my regulator as
> well as peripheral driver code.?

I'm not entirely sure what you mean here.  No regulator driver should
ever have any knowledge of its consumers, this will be handled by the
regulator core, and regulators should not be making decisions about
their own power state - this should also be done by the core.  Perhaps
if you could provide a more concrete example your question might be
clearer?

> 3. Extending the same model, I want to use the _set_optimum API.
> Logically, enabling/disabling the child supply or setting an optimal
> load on the regulator must propagate the new load to any master
> regulator ( which can then again be set an optimal load). My

This isn't entirely clear, actually.  Translating the load on a child
regulator to that on a parent regulator isn't trivial since the
performance of both regulators needs to be taken into consideration -
the child regulator will have its own requirements for the input.  These
will obviously be influenced by the load it experiences but it's not
as direct a mapping as is desirable for propagating up the tree in a
generic fashion.

> understanding of this function shows me that currently, this is not
> supported in the function. Am I right in deducing this or have I failed
> to overlook some other portions in the regulator code?

There's no code to do this at the minute - like I say, it's not as easy
as might be desirable.  The other thing to bear in mind here is that
hardware is making this less and less relevant.  With modern regulators
the regulator itself is capable of responding quickly enough to load
changes to automatically switch between most if not all of the operating
modes without software intervention.  This means that managing the mode
in software generally ends up being less efficient than just leaving the
hardware to it.

Regulators vis-a-vis Power Domains

[Mark Brown]

On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:

Please fix your mail client to word wrap within paragraphs; not doing
this makes your messages harder to read and reply to.  I've reflowed below.

> 1. The documentation for the regulators mentions "power domains" and
> "switches" to be modeled as regulators. I am planning to model multiple
> "switches" for controlling supplies to various peripherals from a main
> master regulator as multiple regulators, childed from the parent
> regulator. Is this the right way to proceed ahead? Further the options

If you want to do this in the regulator framework, yes.

> for these switches will be only?a logical on/off. (BTW, I saw lots of TI
> stuff which is something related to power domains, but it doesn't model
> the regulator framework.)

Nor does the SH stuff.  With the power domains of a CPU it often doesn't
buy terribly much to use the regulator framework - the power domains are
often a small part of a much bigger picture for the CPU internal power
management, often incorporating thing 

> 2. In the same example below, should I instead model just the main
> regulator, and in the driver specific enable/disable, iterate through
> the list of consumers, and then accordingly enable/disable these
> switches according to the calling consumer?. In this way,?I can choose
> not to clutter those smaller switches as regulators in my regulator as
> well as peripheral driver code.?

I'm not entirely sure what you mean here.  No regulator driver should
ever have any knowledge of its consumers, this will be handled by the
regulator core, and regulators should not be making decisions about
their own power state - this should also be done by the core.  Perhaps
if you could provide a more concrete example your question might be
clearer?

> 3. Extending the same model, I want to use the _set_optimum API.
> Logically, enabling/disabling the child supply or setting an optimal
> load on the regulator must propagate the new load to any master
> regulator ( which can then again be set an optimal load). My

This isn't entirely clear, actually.  Translating the load on a child
regulator to that on a parent regulator isn't trivial since the
performance of both regulators needs to be taken into consideration -
the child regulator will have its own requirements for the input.  These
will obviously be influenced by the load it experiences but it's not
as direct a mapping as is desirable for propagating up the tree in a
generic fashion.

> understanding of this function shows me that?currently, this is not
> supported in the function. Am I right in deducing this or?have I failed
> to overlook some other portions in the regulator code?

There's no code to do this at the minute - like I say, it's not as easy
as might be desirable.  The other thing to bear in mind here is that
hardware is making this less and less relevant.  With modern regulators
the regulator itself is capable of responding quickly enough to load
changes to automatically switch between most if not all of the operating
modes without software intervention.  This means that managing the mode
in software generally ends up being less efficient than just leaving the
hardware to it.

Regulators vis-a-vis Power Domains

[Ben Dooks]

On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:
> 
> Please fix your mail client to word wrap within paragraphs; not doing
> this makes your messages harder to read and reply to.  I've reflowed below.
> 
> > 1. The documentation for the regulators mentions "power domains" and
> > "switches" to be modeled as regulators. I am planning to model multiple
> > "switches" for controlling supplies to various peripherals from a main
> > master regulator as multiple regulators, childed from the parent
> > regulator. Is this the right way to proceed ahead? Further the options
> 
> If you want to do this in the regulator framework, yes.
> 
> > for these switches will be only?a logical on/off. (BTW, I saw lots of TI
> > stuff which is something related to power domains, but it doesn't model
> > the regulator framework.)
> 
> Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> buy terribly much to use the regulator framework - the power domains are
> often a small part of a much bigger picture for the CPU internal power
> management, often incorporating thing 

I personally think there is merit to having the regulator framework at
least play a part in these, as is possible the powerdomains are being
fed from external regulators and/or power switches. I see it as good
way of using existing support to do useful work.

I've already seen an example of powerdomains hacked into the clock
framework, but this isn't really the place for it to be as it ends
up adding switch-on latencies to the system and hides things from the
driver.
 
> > 2. In the same example below, should I instead model just the main
> > regulator, and in the driver specific enable/disable, iterate through
> > the list of consumers, and then accordingly enable/disable these
> > switches according to the calling consumer?. In this way,?I can choose
> > not to clutter those smaller switches as regulators in my regulator as
> > well as peripheral driver code.?
> 
> I'm not entirely sure what you mean here.  No regulator driver should
> ever have any knowledge of its consumers, this will be handled by the
> regulator core, and regulators should not be making decisions about
> their own power state - this should also be done by the core.  Perhaps
> if you could provide a more concrete example your question might be
> clearer?
> 
> > 3. Extending the same model, I want to use the _set_optimum API.
> > Logically, enabling/disabling the child supply or setting an optimal
> > load on the regulator must propagate the new load to any master
> > regulator ( which can then again be set an optimal load). My
> 
> This isn't entirely clear, actually.  Translating the load on a child
> regulator to that on a parent regulator isn't trivial since the
> performance of both regulators needs to be taken into consideration -
> the child regulator will have its own requirements for the input.  These
> will obviously be influenced by the load it experiences but it's not
> as direct a mapping as is desirable for propagating up the tree in a
> generic fashion.
> 
> > understanding of this function shows me that?currently, this is not
> > supported in the function. Am I right in deducing this or?have I failed
> > to overlook some other portions in the regulator code?
> 
> There's no code to do this at the minute - like I say, it's not as easy
> as might be desirable.  The other thing to bear in mind here is that
> hardware is making this less and less relevant.  With modern regulators
> the regulator itself is capable of responding quickly enough to load
> changes to automatically switch between most if not all of the operating
> modes without software intervention.  This means that managing the mode
> in software generally ends up being less efficient than just leaving the
> hardware to it.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: Regulators vis-a-vis Power Domains

[Liam Girdwood]

On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> > On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:
> > 
> > Please fix your mail client to word wrap within paragraphs; not doing
> > this makes your messages harder to read and reply to.  I've reflowed below.
> > 
> > > 1. The documentation for the regulators mentions "power domains" and
> > > "switches" to be modeled as regulators. I am planning to model multiple
> > > "switches" for controlling supplies to various peripherals from a main
> > > master regulator as multiple regulators, childed from the parent
> > > regulator. Is this the right way to proceed ahead? Further the options
> > 
> > If you want to do this in the regulator framework, yes.
> > 
> > > for these switches will be only a logical on/off. (BTW, I saw lots of TI
> > > stuff which is something related to power domains, but it doesn't model
> > > the regulator framework.)
> > 
> > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > buy terribly much to use the regulator framework - the power domains are
> > often a small part of a much bigger picture for the CPU internal power
> > management, often incorporating thing 
> 
> I personally think there is merit to having the regulator framework at
> least play a part in these, as is possible the powerdomains are being
> fed from external regulators and/or power switches. I see it as good
> way of using existing support to do useful work.

I tend to agree here, although I think it's still early days for this
technology and maybe some hybrid approach will eventually emerge.

Fwiw, I'm adding regulator support to other types of tightly coupled
CPU/DSP voltage control i.e. OMAP4 SmartReflex. 

Liam  

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Regulators vis-a-vis Power Domains

[Liam Girdwood]

On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> > On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:
> > 
> > Please fix your mail client to word wrap within paragraphs; not doing
> > this makes your messages harder to read and reply to.  I've reflowed below.
> > 
> > > 1. The documentation for the regulators mentions "power domains" and
> > > "switches" to be modeled as regulators. I am planning to model multiple
> > > "switches" for controlling supplies to various peripherals from a main
> > > master regulator as multiple regulators, childed from the parent
> > > regulator. Is this the right way to proceed ahead? Further the options
> > 
> > If you want to do this in the regulator framework, yes.
> > 
> > > for these switches will be only a logical on/off. (BTW, I saw lots of TI
> > > stuff which is something related to power domains, but it doesn't model
> > > the regulator framework.)
> > 
> > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > buy terribly much to use the regulator framework - the power domains are
> > often a small part of a much bigger picture for the CPU internal power
> > management, often incorporating thing 
> 
> I personally think there is merit to having the regulator framework at
> least play a part in these, as is possible the powerdomains are being
> fed from external regulators and/or power switches. I see it as good
> way of using existing support to do useful work.

I tend to agree here, although I think it's still early days for this
technology and maybe some hybrid approach will eventually emerge.

Fwiw, I'm adding regulator support to other types of tightly coupled
CPU/DSP voltage control i.e. OMAP4 SmartReflex. 

Liam  

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: Regulators vis-a-vis Power Domains

[Mark Brown]

On Tue, Apr 06, 2010 at 09:44:00PM +0100, Liam Girdwood wrote:
> On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> > On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:

> > > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > > buy terribly much to use the regulator framework - the power domains are

> > I personally think there is merit to having the regulator framework at
> > least play a part in these, as is possible the powerdomains are being
> > fed from external regulators and/or power switches. I see it as good
> > way of using existing support to do useful work.

> I tend to agree here, although I think it's still early days for this
> technology and maybe some hybrid approach will eventually emerge.

Yes, once the control goes off chip the regulator framework definitely
makes sense.  It's only for things on the same die where there may be
less of a clear separation for the power supplies and where there's
likely to not be much more than simple power switching that it *might*
be worth doing something custom which more directly represents what's
going on.

Regulators vis-a-vis Power Domains

[Mark Brown]

On Tue, Apr 06, 2010 at 09:44:00PM +0100, Liam Girdwood wrote:
> On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> > On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:

> > > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > > buy terribly much to use the regulator framework - the power domains are

> > I personally think there is merit to having the regulator framework at
> > least play a part in these, as is possible the powerdomains are being
> > fed from external regulators and/or power switches. I see it as good
> > way of using existing support to do useful work.

> I tend to agree here, although I think it's still early days for this
> technology and maybe some hybrid approach will eventually emerge.

Yes, once the control goes off chip the regulator framework definitely
makes sense.  It's only for things on the same die where there may be
less of a clear separation for the power supplies and where there's
likely to not be much more than simple power switching that it *might*
be worth doing something custom which more directly represents what's
going on.

Re: Regulators vis-a-vis Power Domains

[Liam Girdwood]

On Tue, 2010-04-06 at 22:57 +0100, Mark Brown wrote:
> On Tue, Apr 06, 2010 at 09:44:00PM +0100, Liam Girdwood wrote:
> > On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> > > On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> 
> > > > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > > > buy terribly much to use the regulator framework - the power domains are
> 
> > > I personally think there is merit to having the regulator framework at
> > > least play a part in these, as is possible the powerdomains are being
> > > fed from external regulators and/or power switches. I see it as good
> > > way of using existing support to do useful work.
> 
> > I tend to agree here, although I think it's still early days for this
> > technology and maybe some hybrid approach will eventually emerge.
> 
> Yes, once the control goes off chip the regulator framework definitely
> makes sense.  It's only for things on the same die where there may be
> less of a clear separation for the power supplies and where there's
> likely to not be much more than simple power switching that it *might*
> be worth doing something custom which more directly represents what's
> going on.

I agree, although the concepts are pretty much the same wrt software in
that both external PMIC regulators and internal on die voltage domains
both control power to their consumers. We already have supply dependency
support and consumer ref counting in regulator core so voltage domain
support _may_ work well by adding a simplified method to register a
domain graph with the regulator core. There may be other small bits and
pieces to add too but I cant think of anything major atm.

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Regulators vis-a-vis Power Domains

[Liam Girdwood]

On Tue, 2010-04-06 at 22:57 +0100, Mark Brown wrote:
> On Tue, Apr 06, 2010 at 09:44:00PM +0100, Liam Girdwood wrote:
> > On Tue, 2010-04-06 at 16:58 +0100, Ben Dooks wrote: 
> > > On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> 
> > > > Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> > > > buy terribly much to use the regulator framework - the power domains are
> 
> > > I personally think there is merit to having the regulator framework at
> > > least play a part in these, as is possible the powerdomains are being
> > > fed from external regulators and/or power switches. I see it as good
> > > way of using existing support to do useful work.
> 
> > I tend to agree here, although I think it's still early days for this
> > technology and maybe some hybrid approach will eventually emerge.
> 
> Yes, once the control goes off chip the regulator framework definitely
> makes sense.  It's only for things on the same die where there may be
> less of a clear separation for the power supplies and where there's
> likely to not be much more than simple power switching that it *might*
> be worth doing something custom which more directly represents what's
> going on.

I agree, although the concepts are pretty much the same wrt software in
that both external PMIC regulators and internal on die voltage domains
both control power to their consumers. We already have supply dependency
support and consumer ref counting in regulator core so voltage domain
support _may_ work well by adding a simplified method to register a
domain graph with the regulator core. There may be other small bits and
pieces to add too but I cant think of anything major atm.

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: Regulators vis-a-vis Power Domains

[Ben Dooks]

On Sun, Apr 04, 2010 at 02:10:58PM +0100, Mark Brown wrote:
> On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote:
> 
> Please fix your mail client to word wrap within paragraphs; not doing
> this makes your messages harder to read and reply to.  I've reflowed below.
> 
> > 1. The documentation for the regulators mentions "power domains" and
> > "switches" to be modeled as regulators. I am planning to model multiple
> > "switches" for controlling supplies to various peripherals from a main
> > master regulator as multiple regulators, childed from the parent
> > regulator. Is this the right way to proceed ahead? Further the options
> 
> If you want to do this in the regulator framework, yes.
> 
> > for these switches will be only a logical on/off. (BTW, I saw lots of TI
> > stuff which is something related to power domains, but it doesn't model
> > the regulator framework.)
> 
> Nor does the SH stuff.  With the power domains of a CPU it often doesn't
> buy terribly much to use the regulator framework - the power domains are
> often a small part of a much bigger picture for the CPU internal power
> management, often incorporating thing 

I personally think there is merit to having the regulator framework at
least play a part in these, as is possible the powerdomains are being
fed from external regulators and/or power switches. I see it as good
way of using existing support to do useful work.

I've already seen an example of powerdomains hacked into the clock
framework, but this isn't really the place for it to be as it ends
up adding switch-on latencies to the system and hides things from the
driver.
 
> > 2. In the same example below, should I instead model just the main
> > regulator, and in the driver specific enable/disable, iterate through
> > the list of consumers, and then accordingly enable/disable these
> > switches according to the calling consumer?. In this way, I can choose
> > not to clutter those smaller switches as regulators in my regulator as
> > well as peripheral driver code.?
> 
> I'm not entirely sure what you mean here.  No regulator driver should
> ever have any knowledge of its consumers, this will be handled by the
> regulator core, and regulators should not be making decisions about
> their own power state - this should also be done by the core.  Perhaps
> if you could provide a more concrete example your question might be
> clearer?
> 
> > 3. Extending the same model, I want to use the _set_optimum API.
> > Logically, enabling/disabling the child supply or setting an optimal
> > load on the regulator must propagate the new load to any master
> > regulator ( which can then again be set an optimal load). My
> 
> This isn't entirely clear, actually.  Translating the load on a child
> regulator to that on a parent regulator isn't trivial since the
> performance of both regulators needs to be taken into consideration -
> the child regulator will have its own requirements for the input.  These
> will obviously be influenced by the load it experiences but it's not
> as direct a mapping as is desirable for propagating up the tree in a
> generic fashion.
> 
> > understanding of this function shows me that currently, this is not
> > supported in the function. Am I right in deducing this or have I failed
> > to overlook some other portions in the regulator code?
> 
> There's no code to do this at the minute - like I say, it's not as easy
> as might be desirable.  The other thing to bear in mind here is that
> hardware is making this less and less relevant.  With modern regulators
> the regulator itself is capable of responding quickly enough to load
> changes to automatically switch between most if not all of the operating
> modes without software intervention.  This means that managing the mode
> in software generally ends up being less efficient than just leaving the
> hardware to it.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Regulators vis-a-vis Power Domains

[Sundar R IYER]

Hello All,
 
I have a few queries about regulators vis-a-vis power domains.
 
1. The documentation for the regulators mentions "power domains" and "switches" to be modeled as regulators. I am planning to model multiple "switches" for controlling supplies to various peripherals from a main master regulator as multiple regulators, childed from the parent regulator. Is this the right way to proceed ahead? Further the options for these switches will be only a logical on/off. (BTW, I saw lots of TI stuff which is something related to power domains, but it doesn't model the regulator framework.)
 
2. In the same example below, should I instead model just the main regulator, and in the driver specific enable/disable, iterate through the list of consumers, and then accordingly enable/disable these switches according to the calling consumer?. In this way, I can choose not to clutter those smaller switches as regulators in my regulator as well as peripheral driver code.?
 
3. Extending the same model, I want to use the _set_optimum API. Logically, enabling/disabling the child supply or setting an optimal load on the regulator must propagate the new load to any master regulator ( which can then again be set an optimal load). My understanding of this function shows me that currently, this is not supported in the function. Am I right in deducing this or have I failed to overlook some other portions in the regulator code?
 
Waiting for all your valuable replies!
 
Sundar