Power Domain Framework

Power Domain Framework

[Deepak Sikri]

[-- Attachment #1.1: Type: text/plain, Size: 1860 bytes --]

Hi,

In our System on chip we have several power domains. As such there is no
generic framework for the Power Domains in linux , and I find huge potential
in the software to control the domains and exploit the power management
capabilities.

There is one very small model that I could think of, something on the lines
of clock framework.

1. Essentially the model would be based on defining the attributes of a
power domain ( name, current state: on/off, usage count, wake up sources,
list head etc) and the operations to be performed on a typical power domain
( Current State Check, Target State to be moved into etc) maintained in
software data structures, that would be mapped onto hardware registers in
the architecture specific code.
2. Maintain a list of the different power domains present.
3. The devices in a specific power domain, as per the requirements would get
the power domain handler ( which would increment the usage count of the
power domain) and would release it when not in need.
4. Typically a usage count of zero for any power domain -> switch off the
power domain removing static power dissipation.
5. The same could be mapped on to the PM framework, where the devices would
release their power handlers at the time of suspend and reaquire at time of
resume operations.
6. The model could further be build upon to check any dependency in the
power domains, eg DDR in on power domain should have the power domain on, if
any of the devices in other power domain is trying to access DDR. This could
be more architecture specific.
7. The advantages of the framework could be leveraged in the CPU idle time,
by switching off the Power domains with zero usage counts.

The model could be build upon, but seek lot more inputs if there exists any
provision on which we can build upon OR develop a generic power domain
framework.

Regards
Deepak

[-- Attachment #1.2: Type: text/html, Size: 2090 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] Power Domain Framework

[Mark Brown]

On Mon, May 10, 2010 at 07:16:06PM +0530, Deepak Sikri wrote:

> In our System on chip we have several power domains. As such there is no
> generic framework for the Power Domains in linux , and I find huge potential
> in the software to control the domains and exploit the power management
> capabilities.

> There is one very small model that I could think of, something on the lines
> of clock framework.

Might be worth looking at what the OMAP and SH Mobile CPUs are doing
here, they have existing handling for power domains.  Off-SoC the
regulator API should already cope with a lot of this stuff.

Re: Power Domain Framework

[Mark Brown]

On Mon, May 10, 2010 at 07:16:06PM +0530, Deepak Sikri wrote:

> In our System on chip we have several power domains. As such there is no
> generic framework for the Power Domains in linux , and I find huge potential
> in the software to control the domains and exploit the power management
> capabilities.

> There is one very small model that I could think of, something on the lines
> of clock framework.

Might be worth looking at what the OMAP and SH Mobile CPUs are doing
here, they have existing handling for power domains.  Off-SoC the
regulator API should already cope with a lot of this stuff.

Re: [linux-pm] Power Domain Framework

[Sundar]

Hi All,

The regulator framework documentation already refers to the concept of
power domains and I think the framework *can* be extended more to
support on-SoC power domains as well.

I have been working with the regulator framework for on-chip power
domains too and....

>2. Maintain a list of the different power domains present.
>3. The devices in a specific power domain, as per the requirements would get the power
>domain...
>4. Typically a usage count of zero for any power domai..
>5. The same could be mapped on to the PM framework..
>6. The model could further be build upon to check any dependency in the power domains

the above requirements can be leveraged through the current regulator
framework itself.

However, for working with power domains within the framework, I feel that,
- support must be added to allow additional domain-specific states
like retention, idle etc.
- controlling operating points for regulators, unlike setting optimal modes.
- controlling regulator modes via constraints enforced by clients and
managing transition to various states through the client requests and
pushing the client states up to the parent regulator.

>7. The advantages of the framework could be leveraged in the CPU idle time, by switching >off the Power domains with zero usage counts.

Yes. A simple platform specific list of all regulators ( and power
domains ) can be easily used in the CPUIdle driver for determining low
power states. Further, enforcing run time PM can club together any
peripheral's power sources in terms of external regulators, on-chip
domains ( and clock sources possibly).

i have a very primitive implementation for adding operating points and
constraints into the framework and currently i am able to control
regulator aka domain states based on various child domains and
contraints.

However, with more inputs, I think we can make the regulator framework
easily manage power sources, whether on-chip domains or external
conventional regulators...

Waiting for opinions and views,

Regards,
Sundar

 Mon, May 10, 2010 at 7:35 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, May 10, 2010 at 07:16:06PM +0530, Deepak Sikri wrote:
>
>> In our System on chip we have several power domains. As such there is no
>> generic framework for the Power Domains in linux , and I find huge potential
>> in the software to control the domains and exploit the power management
>> capabilities.
>
>> There is one very small model that I could think of, something on the lines
>> of clock framework.
>
> Might be worth looking at what the OMAP and SH Mobile CPUs are doing
> here, they have existing handling for power domains.  Off-SoC the
> regulator API should already cope with a lot of this stuff.
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>

Re: Power Domain Framework

[Sundar]

Hi All,

The regulator framework documentation already refers to the concept of
power domains and I think the framework *can* be extended more to
support on-SoC power domains as well.

I have been working with the regulator framework for on-chip power
domains too and....

>2. Maintain a list of the different power domains present.
>3. The devices in a specific power domain, as per the requirements would get the power
>domain...
>4. Typically a usage count of zero for any power domai..
>5. The same could be mapped on to the PM framework..
>6. The model could further be build upon to check any dependency in the power domains

the above requirements can be leveraged through the current regulator
framework itself.

However, for working with power domains within the framework, I feel that,
- support must be added to allow additional domain-specific states
like retention, idle etc.
- controlling operating points for regulators, unlike setting optimal modes.
- controlling regulator modes via constraints enforced by clients and
managing transition to various states through the client requests and
pushing the client states up to the parent regulator.

>7. The advantages of the framework could be leveraged in the CPU idle time, by switching >off the Power domains with zero usage counts.

Yes. A simple platform specific list of all regulators ( and power
domains ) can be easily used in the CPUIdle driver for determining low
power states. Further, enforcing run time PM can club together any
peripheral's power sources in terms of external regulators, on-chip
domains ( and clock sources possibly).

i have a very primitive implementation for adding operating points and
constraints into the framework and currently i am able to control
regulator aka domain states based on various child domains and
contraints.

However, with more inputs, I think we can make the regulator framework
easily manage power sources, whether on-chip domains or external
conventional regulators...

Waiting for opinions and views,

Regards,
Sundar

 Mon, May 10, 2010 at 7:35 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, May 10, 2010 at 07:16:06PM +0530, Deepak Sikri wrote:
>
>> In our System on chip we have several power domains. As such there is no
>> generic framework for the Power Domains in linux , and I find huge potential
>> in the software to control the domains and exploit the power management
>> capabilities.
>
>> There is one very small model that I could think of, something on the lines
>> of clock framework.
>
> Might be worth looking at what the OMAP and SH Mobile CPUs are doing
> here, they have existing handling for power domains.  Off-SoC the
> regulator API should already cope with a lot of this stuff.
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>

Re: [linux-pm] Power Domain Framework

[Mark Brown]

On Sun, May 16, 2010 at 04:43:52PM +0530, Sundar wrote:

Please don't top post, it breaks the thread of discussion.

> However, for working with power domains within the framework, I feel that,
> - support must be added to allow additional domain-specific states
> like retention, idle etc.

I'm really not convinced that this is a good idea.  Generally I suspect
the implementations of these concepts that I've seen would introduce
layering violations if done via the regulator API - from what I've seen
the power domains can end up knowing rather more about the things that
are being powered than is healthy for the regulator API and...

> - controlling operating points for regulators, unlike setting optimal modes.
> - controlling regulator modes via constraints enforced by clients and
> managing transition to various states through the client requests and
> pushing the client states up to the parent regulator.

...knowing a lot about the specifics of the internal structures of the
device you're trying to model.  Cross talk with the clock API also seems
fairly common here.

I do think it's likely that you'll want something that looks like the
regulator API at the edges, but that a separate implementation that
avoids having to shoehorn through the abstractions of the regulator API
for the on-chip work seems much more sensible (and is what OMAP and SH
are already doing).  This is fairly similar to the relationship between
the clock and regulator APIs - they look a lot alike, especially from a
user point of view, but they are separate because there are enough
differences in what they are trying to represent to make it sensible to
keep them apart.

However, if you have patches it's probably easier to talk about those
than architecture astronauting; perhaps your implementation avoids my
concerns.

Re: Power Domain Framework

[Mark Brown]

On Sun, May 16, 2010 at 04:43:52PM +0530, Sundar wrote:

Please don't top post, it breaks the thread of discussion.

> However, for working with power domains within the framework, I feel that,
> - support must be added to allow additional domain-specific states
> like retention, idle etc.

I'm really not convinced that this is a good idea.  Generally I suspect
the implementations of these concepts that I've seen would introduce
layering violations if done via the regulator API - from what I've seen
the power domains can end up knowing rather more about the things that
are being powered than is healthy for the regulator API and...

> - controlling operating points for regulators, unlike setting optimal modes.
> - controlling regulator modes via constraints enforced by clients and
> managing transition to various states through the client requests and
> pushing the client states up to the parent regulator.

...knowing a lot about the specifics of the internal structures of the
device you're trying to model.  Cross talk with the clock API also seems
fairly common here.

I do think it's likely that you'll want something that looks like the
regulator API at the edges, but that a separate implementation that
avoids having to shoehorn through the abstractions of the regulator API
for the on-chip work seems much more sensible (and is what OMAP and SH
are already doing).  This is fairly similar to the relationship between
the clock and regulator APIs - they look a lot alike, especially from a
user point of view, but they are separate because there are enough
differences in what they are trying to represent to make it sensible to
keep them apart.

However, if you have patches it's probably easier to talk about those
than architecture astronauting; perhaps your implementation avoids my
concerns.

Fwd: [linux-pm] Power Domain Framework

[Sundar]

Hi,

On Mon, May 17, 2010 at 8:46 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, May 16, 2010 at 04:43:52PM +0530, Sundar wrote:
>
> Please don't top post, it breaks the thread of discussion.
Sorry.

> I'm really not convinced that this is a good idea.  Generally I suspect
> the implementations of these concepts that I've seen would introduce
> layering violations if done via the regulator API - from what I've seen
> the power domains can end up knowing rather more about the things that
> are being powered than is healthy for the regulator API and...

I am sorry but I do not understand how this can violate the framework APIs.
Even know, a regulator knows about its machine constraints, valid features
w.r.t operating modes, DRMS, load currents etc. What additional information
the regulator would be associated with would be operating points, constraints
w.r.t peripherals etc.

> I do think it's likely that you'll want something that looks like the
> regulator API at the edges, but that a separate implementation that
> avoids having to shoehorn through the abstractions of the regulator API
> for the on-chip work seems much more sensible (and is what OMAP and SH

True. But a separate implementation is not needed because the current
framework already provides me support for a majority of features. Features like
OPP control, power states which are usually associated with SoC power domains
are available on modem regulators. When such features will eventually creep in
the regular framework, then why distinguish between on-SoC power sources
and on-board power sources..

> are already doing).  This is fairly similar to the relationship between
> the clock and regulator APIs - they look a lot alike, especially from a
> user point of view, but they are separate because there are enough
> differences in what they are trying to represent to make it sensible to
> keep them apart.

Agreed. But if I compare a SoC power domain and a regulator power domain, I
dont see differences to keep them apart. Please correct me if I am wrong.

> However, if you have patches it's probably easier to talk about those
> than architecture astronauting; perhaps your implementation avoids my
> concerns.
>
Okay. I will surely send them out.

Regards,
Sundar

Fwd: Power Domain Framework

[Sundar]

Hi,

On Mon, May 17, 2010 at 8:46 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, May 16, 2010 at 04:43:52PM +0530, Sundar wrote:
>
> Please don't top post, it breaks the thread of discussion.
Sorry.

> I'm really not convinced that this is a good idea.  Generally I suspect
> the implementations of these concepts that I've seen would introduce
> layering violations if done via the regulator API - from what I've seen
> the power domains can end up knowing rather more about the things that
> are being powered than is healthy for the regulator API and...

I am sorry but I do not understand how this can violate the framework APIs.
Even know, a regulator knows about its machine constraints, valid features
w.r.t operating modes, DRMS, load currents etc. What additional information
the regulator would be associated with would be operating points, constraints
w.r.t peripherals etc.

> I do think it's likely that you'll want something that looks like the
> regulator API at the edges, but that a separate implementation that
> avoids having to shoehorn through the abstractions of the regulator API
> for the on-chip work seems much more sensible (and is what OMAP and SH

True. But a separate implementation is not needed because the current
framework already provides me support for a majority of features. Features like
OPP control, power states which are usually associated with SoC power domains
are available on modem regulators. When such features will eventually creep in
the regular framework, then why distinguish between on-SoC power sources
and on-board power sources..

> are already doing).  This is fairly similar to the relationship between
> the clock and regulator APIs - they look a lot alike, especially from a
> user point of view, but they are separate because there are enough
> differences in what they are trying to represent to make it sensible to
> keep them apart.

Agreed. But if I compare a SoC power domain and a regulator power domain, I
dont see differences to keep them apart. Please correct me if I am wrong.

> However, if you have patches it's probably easier to talk about those
> than architecture astronauting; perhaps your implementation avoids my
> concerns.
>
Okay. I will surely send them out.

Regards,
Sundar

Re: Fwd: [linux-pm] Power Domain Framework

[Mark Brown]

On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:
> On Mon, May 17, 2010 at 8:46 AM, Mark Brown

> > I'm really not convinced that this is a good idea.  Generally I suspect
> > the implementations of these concepts that I've seen would introduce
> > layering violations if done via the regulator API - from what I've seen
> > the power domains can end up knowing rather more about the things that
> > are being powered than is healthy for the regulator API and...

> I am sorry but I do not understand how this can violate the framework APIs.
> Even know, a regulator knows about its machine constraints, valid features
> w.r.t operating modes, DRMS, load currents etc. What additional information
> the regulator would be associated with would be operating points, constraints
> w.r.t peripherals etc.

There's two problems I see.  One is expressing the operating modes in a
way that is suitably abstract and will work for more than one chip.  The
other is that as soon as the regulator driver has to know something
about the consumers you're running into trouble.

The major goal of the regulator API is to allow us to match up consumer
drivers with regulator drivers without having any device specific tie
between the two.  Pushing things that need such tie in through the API
breaks that.

> > I do think it's likely that you'll want something that looks like the
> > regulator API at the edges, but that a separate implementation that
> > avoids having to shoehorn through the abstractions of the regulator API
> > for the on-chip work seems much more sensible (and is what OMAP and SH

> True. But a separate implementation is not needed because the current
> framework already provides me support for a majority of features. Features like
> OPP control, power states which are usually associated with SoC power domains
> are available on modem regulators. When such features will eventually creep in

Are you sure about these statements?  Bear in mind that with a regulator
on a separate device there is no direct way for the regulator to know
anything about what the device it is supplying is doing, and not only
are latency requirements for mode changes are very tight but there may
not be any software running when the mode changes which is in a position
to relay information to the regulator.  The trend with regulators
appears to be rather more towards removal of user visible control of the
internal operating modes of the regulator itself with the device
reconfiguring itself based on the ability to achieve good regulation at
a given load point.  This gives good responsivness and efficiency over
the full range of loads.

The physical nature of the system means that there's a very clear
abstraction point where a voltage is being supplied, possibly with some
limits on the possible current drawn.  The fact that the consumer may
have various power modes doesn't impact on the regulator except in that
it may be able to get some information about the range of currents being
supplied.  The converse also applies - the consumer doesn't really need
to know anything about what the regulator is up to internally.

> the regular framework, then why distinguish between on-SoC power sources
> and on-board power sources..

The big difference is that the on-SoC power domain configuration does
frequently rely on an abstraction other than the simple voltage plus
load one that the regulator API represents, as I said this frequently
includes a strong tie in with information about the device clocking.
Typically changing the operating mode will change or limit the clock
rates in use in various parts of the device.

It really would be worth taking a look at how the OMAP and SH platforms
are implementing this stuff.

Re: Fwd: Power Domain Framework

[Mark Brown]

On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:
> On Mon, May 17, 2010 at 8:46 AM, Mark Brown

> > I'm really not convinced that this is a good idea.  Generally I suspect
> > the implementations of these concepts that I've seen would introduce
> > layering violations if done via the regulator API - from what I've seen
> > the power domains can end up knowing rather more about the things that
> > are being powered than is healthy for the regulator API and...

> I am sorry but I do not understand how this can violate the framework APIs.
> Even know, a regulator knows about its machine constraints, valid features
> w.r.t operating modes, DRMS, load currents etc. What additional information
> the regulator would be associated with would be operating points, constraints
> w.r.t peripherals etc.

There's two problems I see.  One is expressing the operating modes in a
way that is suitably abstract and will work for more than one chip.  The
other is that as soon as the regulator driver has to know something
about the consumers you're running into trouble.

The major goal of the regulator API is to allow us to match up consumer
drivers with regulator drivers without having any device specific tie
between the two.  Pushing things that need such tie in through the API
breaks that.

> > I do think it's likely that you'll want something that looks like the
> > regulator API at the edges, but that a separate implementation that
> > avoids having to shoehorn through the abstractions of the regulator API
> > for the on-chip work seems much more sensible (and is what OMAP and SH

> True. But a separate implementation is not needed because the current
> framework already provides me support for a majority of features. Features like
> OPP control, power states which are usually associated with SoC power domains
> are available on modem regulators. When such features will eventually creep in

Are you sure about these statements?  Bear in mind that with a regulator
on a separate device there is no direct way for the regulator to know
anything about what the device it is supplying is doing, and not only
are latency requirements for mode changes are very tight but there may
not be any software running when the mode changes which is in a position
to relay information to the regulator.  The trend with regulators
appears to be rather more towards removal of user visible control of the
internal operating modes of the regulator itself with the device
reconfiguring itself based on the ability to achieve good regulation at
a given load point.  This gives good responsivness and efficiency over
the full range of loads.

The physical nature of the system means that there's a very clear
abstraction point where a voltage is being supplied, possibly with some
limits on the possible current drawn.  The fact that the consumer may
have various power modes doesn't impact on the regulator except in that
it may be able to get some information about the range of currents being
supplied.  The converse also applies - the consumer doesn't really need
to know anything about what the regulator is up to internally.

> the regular framework, then why distinguish between on-SoC power sources
> and on-board power sources..

The big difference is that the on-SoC power domain configuration does
frequently rely on an abstraction other than the simple voltage plus
load one that the regulator API represents, as I said this frequently
includes a strong tie in with information about the device clocking.
Typically changing the operating mode will change or limit the clock
rates in use in various parts of the device.

It really would be worth taking a look at how the OMAP and SH platforms
are implementing this stuff.

Re: Fwd: [linux-pm] Power Domain Framework

[Sundar]

On Mon, May 17, 2010 at 8:03 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:
>
> There's two problems I see.  One is expressing the operating modes in a
> way that is suitably abstract and will work for more than one chip.
Okay.

> other is that as soon as the regulator driver has to know something
> about the consumers you're running into trouble.
>
> The major goal of the regulator API is to allow us to match up consumer
> drivers with regulator drivers without having any device specific tie
> between the two.  Pushing things that need such tie in through the API
> breaks that.
>
Aren't machine constraints, setting maximum current limit based on total loads
similar to primitive tie ups between devices and regulator driver?

> Are you sure about these statements?  Bear in mind that with a regulator
> on a separate device there is no direct way for the regulator to know
> anything about what the device it is supplying is doing, and not only
> are latency requirements for mode changes are very tight but there may
> not be any software running when the mode changes which is in a position
> to relay information to the regulator.  The trend with regulators
> appears to be rather more towards removal of user visible control of the
> internal operating modes of the regulator itself with the device
> reconfiguring itself based on the ability to achieve good regulation at
> a given load point.  This gives good responsivness and efficiency over
> the full range of loads.
I am still confused about the knowledge of regulator about its consumer. How
I see is, with the added controls, it is still devoid of any
information about its
clients. All that a regulator still would know is if at all there are
any clients which
require it at full load. I think the function *set_optimal_load is
very similar to a OPP
control mechanism. Instead of summing up load currents, now there are
constraints.
Probably you may look at the patch set at the end of this mail and comment.

> have various power modes doesn't impact on the regulator except in that
> it may be able to get some information about the range of currents being
> supplied.  The converse also applies - the consumer doesn't really need
> to know anything about what the regulator is up to internally.
IMO, this leads to a more decisive control over what state the
regulator *can* be in;
without affecting any child clients.

> The big difference is that the on-SoC power domain configuration does
> frequently rely on an abstraction other than the simple voltage plus
> load one that the regulator API represents, as I said this frequently
which is what I see as that can be bridged down.

> includes a strong tie in with information about the device clocking.
> Typically changing the operating mode will change or limit the clock
> rates in use in various parts of the device.
cannot these be handled with existing/new notifiers in place?

Regards,
Sundar
P.S : Let me post out the patch set following on.

Re: Fwd: Power Domain Framework

[Sundar]

On Mon, May 17, 2010 at 8:03 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:
>
> There's two problems I see.  One is expressing the operating modes in a
> way that is suitably abstract and will work for more than one chip.
Okay.

> other is that as soon as the regulator driver has to know something
> about the consumers you're running into trouble.
>
> The major goal of the regulator API is to allow us to match up consumer
> drivers with regulator drivers without having any device specific tie
> between the two.  Pushing things that need such tie in through the API
> breaks that.
>
Aren't machine constraints, setting maximum current limit based on total loads
similar to primitive tie ups between devices and regulator driver?

> Are you sure about these statements?  Bear in mind that with a regulator
> on a separate device there is no direct way for the regulator to know
> anything about what the device it is supplying is doing, and not only
> are latency requirements for mode changes are very tight but there may
> not be any software running when the mode changes which is in a position
> to relay information to the regulator.  The trend with regulators
> appears to be rather more towards removal of user visible control of the
> internal operating modes of the regulator itself with the device
> reconfiguring itself based on the ability to achieve good regulation at
> a given load point.  This gives good responsivness and efficiency over
> the full range of loads.
I am still confused about the knowledge of regulator about its consumer. How
I see is, with the added controls, it is still devoid of any
information about its
clients. All that a regulator still would know is if at all there are
any clients which
require it at full load. I think the function *set_optimal_load is
very similar to a OPP
control mechanism. Instead of summing up load currents, now there are
constraints.
Probably you may look at the patch set at the end of this mail and comment.

> have various power modes doesn't impact on the regulator except in that
> it may be able to get some information about the range of currents being
> supplied.  The converse also applies - the consumer doesn't really need
> to know anything about what the regulator is up to internally.
IMO, this leads to a more decisive control over what state the
regulator *can* be in;
without affecting any child clients.

> The big difference is that the on-SoC power domain configuration does
> frequently rely on an abstraction other than the simple voltage plus
> load one that the regulator API represents, as I said this frequently
which is what I see as that can be bridged down.

> includes a strong tie in with information about the device clocking.
> Typically changing the operating mode will change or limit the clock
> rates in use in various parts of the device.
cannot these be handled with existing/new notifiers in place?

Regards,
Sundar
P.S : Let me post out the patch set following on.

Re: [linux-pm] Power Domain Framework

[Sundar R Iyer]

On Mon, 2010-05-17 at 18:23 +0200, Sundar wrote:
> P.S : Let me post out the patch set following on.

Sorry to change the email-ID; didnt want to would break patch
readability.

The implementation follows:

The regulator framework states that any source which supplies 
power to a peripheral can be modeled as a regulator. However,
in new SoCs where peripherals apart from being powered through
the conventional regulators, peripherals are also powered through
on-chip domains. These on-chip domains control enabling/disabling
and also controlling the output to the peripheral as full mode
or idle mode (retention). These power sources don.t allow control 
of parameters like DRMS, current, voltage etc. 

Also, in such designs, often individual domains are clubbed under
a unified domain. In such a case, smaller domains need to communicate
to the parent domain in case of a constraining request from its peripheral(s).

Domain ABC
	|---Periph Domain A, (100OPP/50OPP),
			to run at 100OPP, parent to run at 100OPP
	|---Periph Domain B, (100OPP),
			to run at 100OPP, parent to run at 100OPP
	|---Periph Domain C, (100OPP/50OPP),
			to run at 100OPP, parent to run at 100OPP

Thus, for ideal power saving modes, the Domain ABC can be turned
to a lower OPP if 
	- Periph B is not running
	- Periph A/C are running at 50OPP only.

This patch set adds a function for controlling the OPPs, 
not touching the existing voltage/mode functions, as they
are needed in their own way for conventional regulators.

Sundar R Iyer (1):
  regulators : Regulator Operating Points

---
 drivers/regulator/core.c           |   79 ++++++++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h |   27 ++++++++++++
 include/linux/regulator/driver.h   |    5 ++
 include/linux/regulator/machine.h  |    6 +++
 4 files changed, 117 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
old mode 100644
new mode 100755
index 2248087..7c6c5af
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1898,6 +1898,85 @@ out:
 }
 EXPORT_SYMBOL_GPL(regulator_set_optimum_mode);
 
+/* locks held by regulator_set_operating_point() */
+static int _regulator_set_operating_point(struct regulator_dev *rdev,
+		unsigned int opp)
+{
+	int ret, regulator_curr_opp = 0;
+
+	if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
+		printk(KERN_ERR "%s: operation not allowed for %s\n",
+				__func__, rdev->desc->name);
+		return -EPERM;
+	}
+
+	/* sanity checks */
+	if (!rdev->desc->ops->set_operating_point) {
+		return -EINVAL;
+	}
+
+	if (rdev->desc->ops->get_operating_point)
+		regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
+
+	/* we have no issues with upgrading the opp */
+	if (opp == REGULATOR_OPERATINGPOINT_FULL) {
+		if (rdev->constraints->opp_constraint_count < 1) {
+			if (rdev->supply)
+				ret = _regulator_set_operating_point(rdev->supply, opp);
+			ret = rdev->desc->ops->set_operating_point(rdev, opp);
+		}
+		rdev->constraints->opp_constraint_count++;
+	}
+
+	if (opp == REGULATOR_OPERATINGPOINT_IDLE) {
+		rdev->constraints->opp_constraint_count--;
+		/* if there r no constraints */
+		if (rdev->constraints->opp_constraint_count == 0) {
+			if (rdev->supply)
+				ret = _regulator_set_operating_point(rdev->supply, opp);
+
+			ret = rdev->desc->ops->set_operating_point(rdev, opp);
+		}
+	}
+
+	return ret;
+}
+
+/**
+ * regulator_set_operating_point - set regulator operating point
+ * @regulator: regulator source
+ * @opp: operating point to set
+ *
+ * sets the operating point for a regulator.
+ * this is not to be confused the regulator modes. For smart regulators
+ * that can run at varied operating points, clients can request simply
+ * operating points rather than notional load values.
+ *
+ * For eg, an on-chip regulator source for a peripheral like multimedia can
+ *  - run at a full operating point for a full 1020p,
+ *  - run at half the operating point for something like QVGA.
+ *
+ * All on-chip power domains can be modelled as regulators, and their controls
+ * through this function.
+ *
+ * Returns the new regulator operating point or error.
+ */
+int regulator_set_operating_point(struct regulator *regulator, unsigned int opp)
+{
+	struct regulator_dev *rdev = regulator->rdev;
+	int ret;
+
+	mutex_lock(&rdev->mutex);
+	ret = _regulator_set_operating_point(rdev, opp);
+	mutex_unlock(&rdev->mutex);
+
+	return ret;
+
+}
+EXPORT_SYMBOL_GPL(regulator_set_operating_point);
+
+
+
 /**
  * regulator_register_notifier - register regulator event notifier
  * @regulator: regulator source
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
old mode 100644
new mode 100755
index ebd7472..680ec30
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -82,6 +82,30 @@
 #define REGULATOR_MODE_STANDBY			0x8
 
 /*
+ * Regulator operating points
+ *
+ * Fast, switchable supplies for peripherals which are controlled
+ * via on-chip power domains are different from normal regulators
+ * which control voltages, current, drms etc. For such power domain
+ * supplies aka regulators, all that can be controlled is the operating
+ * point, OPP. Such regulators can be either on with full voltage, or
+ * partially on at retention/normal voltages (specific to SoC settings)
+ *
+ * these flags can be used to model "power domains" on SoCs in the main
+ * regulator framework
+ *
+ * Also, for such power domains, turning on/off can be handled through
+ * the regulator enable/disable calls
+ *
+ * FULL	Regulator runs at the full output
+ * HALF	Regulator runs at the half output
+ *
+ * these OPPs can be OR'ed together to make a mask of valid regulator OPPs
+ */
+#define REGULATOR_OPERATINGPOINT_FULL		0x1
+#define REGULATOR_OPERATINGPOINT_IDLE		0x2
+
+/*
  * Regulator notifier events.
  *
  * UNDER_VOLTAGE  Regulator output is under voltage.
@@ -160,6 +184,9 @@ int regulator_get_current_limit(struct regulator *regulator);
 
 int regulator_set_mode(struct regulator *regulator, unsigned int mode);
 unsigned int regulator_get_mode(struct regulator *regulator);
+
+int regulator_set_operating_point(struct regulator *regulator, unsigned int opp);
+
 int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
 
 /* regulator notifier block */
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
old mode 100644
new mode 100755
index 592cd7c..e5be16b
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -122,6 +122,11 @@ struct regulator_ops {
 
 	/* set regulator suspend operating mode (defined in regulator.h) */
 	int (*set_suspend_mode) (struct regulator_dev *, unsigned int mode);
+
+	/* set regulator operating point */
+	int (*set_operating_point) (struct regulator_dev *, int opp);
+	int (*get_operating_point) (struct regulator_dev *);
+
 };
 
 /*
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
old mode 100644
new mode 100755
index e298028..185a5d5
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -39,6 +39,7 @@ struct regulator;
 #define REGULATOR_CHANGE_MODE		0x4
 #define REGULATOR_CHANGE_STATUS		0x8
 #define REGULATOR_CHANGE_DRMS		0x10
+#define REGULATOR_CHANGE_OPP		0x20
 
 /**
  * struct regulator_state - regulator state during low power system states
@@ -109,6 +110,9 @@ struct regulation_constraints {
 	/* valid operations for regulator on this machine */
 	unsigned int valid_ops_mask;
 
+	/* valid operating point ranges for this regulator */
+	unsigned int valid_opp_mask;
+
 	/* regulator input voltage - only if supply is another regulator */
 	int input_uV;
 
@@ -125,6 +129,8 @@ struct regulation_constraints {
 	unsigned always_on:1;	/* regulator never off when system is on */
 	unsigned boot_on:1;	/* bootloader/firmware enabled regulator */
 	unsigned apply_uV:1;	/* apply uV constraint if min == max */
+	unsigned int opp_constraint_count; /* clients enforcing a constraint */
+
 };
 
 /**
-- 
1.7.0

Re: Power Domain Framework

[Sundar R Iyer]

On Mon, 2010-05-17 at 18:23 +0200, Sundar wrote:
> P.S : Let me post out the patch set following on.

Sorry to change the email-ID; didnt want to would break patch
readability.

The implementation follows:

The regulator framework states that any source which supplies 
power to a peripheral can be modeled as a regulator. However,
in new SoCs where peripherals apart from being powered through
the conventional regulators, peripherals are also powered through
on-chip domains. These on-chip domains control enabling/disabling
and also controlling the output to the peripheral as full mode
or idle mode (retention). These power sources don.t allow control 
of parameters like DRMS, current, voltage etc. 

Also, in such designs, often individual domains are clubbed under
a unified domain. In such a case, smaller domains need to communicate
to the parent domain in case of a constraining request from its peripheral(s).

Domain ABC
	|---Periph Domain A, (100OPP/50OPP),
			to run at 100OPP, parent to run at 100OPP
	|---Periph Domain B, (100OPP),
			to run at 100OPP, parent to run at 100OPP
	|---Periph Domain C, (100OPP/50OPP),
			to run at 100OPP, parent to run at 100OPP

Thus, for ideal power saving modes, the Domain ABC can be turned
to a lower OPP if 
	- Periph B is not running
	- Periph A/C are running at 50OPP only.

This patch set adds a function for controlling the OPPs, 
not touching the existing voltage/mode functions, as they
are needed in their own way for conventional regulators.

Sundar R Iyer (1):
  regulators : Regulator Operating Points

---
 drivers/regulator/core.c           |   79 ++++++++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h |   27 ++++++++++++
 include/linux/regulator/driver.h   |    5 ++
 include/linux/regulator/machine.h  |    6 +++
 4 files changed, 117 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
old mode 100644
new mode 100755
index 2248087..7c6c5af
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1898,6 +1898,85 @@ out:
 }
 EXPORT_SYMBOL_GPL(regulator_set_optimum_mode);
 
+/* locks held by regulator_set_operating_point() */
+static int _regulator_set_operating_point(struct regulator_dev *rdev,
+		unsigned int opp)
+{
+	int ret, regulator_curr_opp = 0;
+
+	if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
+		printk(KERN_ERR "%s: operation not allowed for %s\n",
+				__func__, rdev->desc->name);
+		return -EPERM;
+	}
+
+	/* sanity checks */
+	if (!rdev->desc->ops->set_operating_point) {
+		return -EINVAL;
+	}
+
+	if (rdev->desc->ops->get_operating_point)
+		regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
+
+	/* we have no issues with upgrading the opp */
+	if (opp == REGULATOR_OPERATINGPOINT_FULL) {
+		if (rdev->constraints->opp_constraint_count < 1) {
+			if (rdev->supply)
+				ret = _regulator_set_operating_point(rdev->supply, opp);
+			ret = rdev->desc->ops->set_operating_point(rdev, opp);
+		}
+		rdev->constraints->opp_constraint_count++;
+	}
+
+	if (opp == REGULATOR_OPERATINGPOINT_IDLE) {
+		rdev->constraints->opp_constraint_count--;
+		/* if there r no constraints */
+		if (rdev->constraints->opp_constraint_count == 0) {
+			if (rdev->supply)
+				ret = _regulator_set_operating_point(rdev->supply, opp);
+
+			ret = rdev->desc->ops->set_operating_point(rdev, opp);
+		}
+	}
+
+	return ret;
+}
+
+/**
+ * regulator_set_operating_point - set regulator operating point
+ * @regulator: regulator source
+ * @opp: operating point to set
+ *
+ * sets the operating point for a regulator.
+ * this is not to be confused the regulator modes. For smart regulators
+ * that can run at varied operating points, clients can request simply
+ * operating points rather than notional load values.
+ *
+ * For eg, an on-chip regulator source for a peripheral like multimedia can
+ *  - run at a full operating point for a full 1020p,
+ *  - run at half the operating point for something like QVGA.
+ *
+ * All on-chip power domains can be modelled as regulators, and their controls
+ * through this function.
+ *
+ * Returns the new regulator operating point or error.
+ */
+int regulator_set_operating_point(struct regulator *regulator, unsigned int opp)
+{
+	struct regulator_dev *rdev = regulator->rdev;
+	int ret;
+
+	mutex_lock(&rdev->mutex);
+	ret = _regulator_set_operating_point(rdev, opp);
+	mutex_unlock(&rdev->mutex);
+
+	return ret;
+
+}
+EXPORT_SYMBOL_GPL(regulator_set_operating_point);
+
+
+
 /**
  * regulator_register_notifier - register regulator event notifier
  * @regulator: regulator source
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
old mode 100644
new mode 100755
index ebd7472..680ec30
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -82,6 +82,30 @@
 #define REGULATOR_MODE_STANDBY			0x8
 
 /*
+ * Regulator operating points
+ *
+ * Fast, switchable supplies for peripherals which are controlled
+ * via on-chip power domains are different from normal regulators
+ * which control voltages, current, drms etc. For such power domain
+ * supplies aka regulators, all that can be controlled is the operating
+ * point, OPP. Such regulators can be either on with full voltage, or
+ * partially on at retention/normal voltages (specific to SoC settings)
+ *
+ * these flags can be used to model "power domains" on SoCs in the main
+ * regulator framework
+ *
+ * Also, for such power domains, turning on/off can be handled through
+ * the regulator enable/disable calls
+ *
+ * FULL	Regulator runs at the full output
+ * HALF	Regulator runs at the half output
+ *
+ * these OPPs can be OR'ed together to make a mask of valid regulator OPPs
+ */
+#define REGULATOR_OPERATINGPOINT_FULL		0x1
+#define REGULATOR_OPERATINGPOINT_IDLE		0x2
+
+/*
  * Regulator notifier events.
  *
  * UNDER_VOLTAGE  Regulator output is under voltage.
@@ -160,6 +184,9 @@ int regulator_get_current_limit(struct regulator *regulator);
 
 int regulator_set_mode(struct regulator *regulator, unsigned int mode);
 unsigned int regulator_get_mode(struct regulator *regulator);
+
+int regulator_set_operating_point(struct regulator *regulator, unsigned int opp);
+
 int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
 
 /* regulator notifier block */
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
old mode 100644
new mode 100755
index 592cd7c..e5be16b
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -122,6 +122,11 @@ struct regulator_ops {
 
 	/* set regulator suspend operating mode (defined in regulator.h) */
 	int (*set_suspend_mode) (struct regulator_dev *, unsigned int mode);
+
+	/* set regulator operating point */
+	int (*set_operating_point) (struct regulator_dev *, int opp);
+	int (*get_operating_point) (struct regulator_dev *);
+
 };
 
 /*
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
old mode 100644
new mode 100755
index e298028..185a5d5
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -39,6 +39,7 @@ struct regulator;
 #define REGULATOR_CHANGE_MODE		0x4
 #define REGULATOR_CHANGE_STATUS		0x8
 #define REGULATOR_CHANGE_DRMS		0x10
+#define REGULATOR_CHANGE_OPP		0x20
 
 /**
  * struct regulator_state - regulator state during low power system states
@@ -109,6 +110,9 @@ struct regulation_constraints {
 	/* valid operations for regulator on this machine */
 	unsigned int valid_ops_mask;
 
+	/* valid operating point ranges for this regulator */
+	unsigned int valid_opp_mask;
+
 	/* regulator input voltage - only if supply is another regulator */
 	int input_uV;
 
@@ -125,6 +129,8 @@ struct regulation_constraints {
 	unsigned always_on:1;	/* regulator never off when system is on */
 	unsigned boot_on:1;	/* bootloader/firmware enabled regulator */
 	unsigned apply_uV:1;	/* apply uV constraint if min == max */
+	unsigned int opp_constraint_count; /* clients enforcing a constraint */
+
 };
 
 /**
-- 
1.7.0

Re: [linux-pm] Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 22:05 +0530, Sundar R Iyer wrote:

> +/* locks held by regulator_set_operating_point() */
> +static int _regulator_set_operating_point(struct regulator_dev *rdev,
> +		unsigned int opp)
> +{
> +	int ret, regulator_curr_opp = 0;
> +
> +	if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
> +		printk(KERN_ERR "%s: operation not allowed for %s\n",
> +				__func__, rdev->desc->name);
> +		return -EPERM;
> +	}
> +
> +	/* sanity checks */
> +	if (!rdev->desc->ops->set_operating_point) {
> +		return -EINVAL;
> +	}
> +
> +	if (rdev->desc->ops->get_operating_point)
> +		regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
> +
> +	/* we have no issues with upgrading the opp */
> +	if (opp == REGULATOR_OPERATINGPOINT_FULL) {
> +		if (rdev->constraints->opp_constraint_count < 1) {
> +			if (rdev->supply)
> +				ret = _regulator_set_operating_point(rdev->supply, opp);
> +			ret = rdev->desc->ops->set_operating_point(rdev, opp);
> +		}
> +		rdev->constraints->opp_constraint_count++;
> +	}

This implementation is assuming that the implementation in hardware only
has two levels, and that the decision to go to the higher level is done
by a simple or of requests for the full level from the consumers. I'm
not convinced that this will be true in general, or that it's always
going to be true that the different power domains are all isolated from
each other. There doesn't seem to be any immediate reason why hardware
won't ever implement more than two modes, and I'm not convinced that the
straight or of requests will always be sufficient to determine the
operating mode for the entire power domain. For example, I can see
hardware requiring that if more than a given number of blocks are
enabled at any level a higher operating point is selected.

Are you sure that this interface is sufficiently general to work with
all hardware, not just your own? How does this map on to the OMAP or SH
hardware, for example?

Re: Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 22:05 +0530, Sundar R Iyer wrote:

> +/* locks held by regulator_set_operating_point() */
> +static int _regulator_set_operating_point(struct regulator_dev *rdev,
> +		unsigned int opp)
> +{
> +	int ret, regulator_curr_opp = 0;
> +
> +	if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
> +		printk(KERN_ERR "%s: operation not allowed for %s\n",
> +				__func__, rdev->desc->name);
> +		return -EPERM;
> +	}
> +
> +	/* sanity checks */
> +	if (!rdev->desc->ops->set_operating_point) {
> +		return -EINVAL;
> +	}
> +
> +	if (rdev->desc->ops->get_operating_point)
> +		regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
> +
> +	/* we have no issues with upgrading the opp */
> +	if (opp == REGULATOR_OPERATINGPOINT_FULL) {
> +		if (rdev->constraints->opp_constraint_count < 1) {
> +			if (rdev->supply)
> +				ret = _regulator_set_operating_point(rdev->supply, opp);
> +			ret = rdev->desc->ops->set_operating_point(rdev, opp);
> +		}
> +		rdev->constraints->opp_constraint_count++;
> +	}

This implementation is assuming that the implementation in hardware only
has two levels, and that the decision to go to the higher level is done
by a simple or of requests for the full level from the consumers. I'm
not convinced that this will be true in general, or that it's always
going to be true that the different power domains are all isolated from
each other. There doesn't seem to be any immediate reason why hardware
won't ever implement more than two modes, and I'm not convinced that the
straight or of requests will always be sufficient to determine the
operating mode for the entire power domain. For example, I can see
hardware requiring that if more than a given number of blocks are
enabled at any level a higher operating point is selected.

Are you sure that this interface is sufficiently general to work with
all hardware, not just your own? How does this map on to the OMAP or SH
hardware, for example?

Re: [linux-pm] Power Domain Framework

[Sundar R Iyer]

Hello,

> This implementation is assuming that the implementation in hardware only
> has two levels, and that the decision to go to the higher level is done
> by a simple or of requests for the full level from the consumers. I'm
> not convinced that this will be true in general, or that it's always
> going to be true that the different power domains are all isolated from
> each other. There doesn't seem to be any immediate reason why hardware
> won't ever implement more than two modes, and I'm not convinced that the
> straight or of requests will always be sufficient to determine the

Yes. Two modes is not the only level that hardware can support.
An ideal case is Full OPP/Half OPP (which is the normal operating
point)/Retention(which is the least so that the device is on).

> operating mode for the entire power domain. For example, I can see
> hardware requiring that if more than a given number of blocks are
> enabled at any level a higher operating point is selected.
Hmm...very much possible. Need to think on this further.

> Are you sure that this interface is sufficiently general to work with
> all hardware, not just your own? How does this map on to the OMAP or SH
> hardware, for example?
AFAIK and with my experience (and my current memory) with TI Davinci
arch, most of the power domains are simpler ones with on/off and
possibly some retention too. And the latest TI code also exposes domains
with on/off/retention states. So, I think if we make this sturdy, I dont
see any reason why we cannot map any generic architecture. CCing Kevin
for his inputs.

This is one of the most important aspect for such a change in the
regulator framework: bringing in the domain aspect can encourage all
newer (possibly older) architectures to come under a generic umbrella.

Anyways, let me have a bit more on the "number of blocks" thing!

Regards,
Sundar

Re: Power Domain Framework

[Sundar R Iyer]

Hello,

> This implementation is assuming that the implementation in hardware only
> has two levels, and that the decision to go to the higher level is done
> by a simple or of requests for the full level from the consumers. I'm
> not convinced that this will be true in general, or that it's always
> going to be true that the different power domains are all isolated from
> each other. There doesn't seem to be any immediate reason why hardware
> won't ever implement more than two modes, and I'm not convinced that the
> straight or of requests will always be sufficient to determine the

Yes. Two modes is not the only level that hardware can support.
An ideal case is Full OPP/Half OPP (which is the normal operating
point)/Retention(which is the least so that the device is on).

> operating mode for the entire power domain. For example, I can see
> hardware requiring that if more than a given number of blocks are
> enabled at any level a higher operating point is selected.
Hmm...very much possible. Need to think on this further.

> Are you sure that this interface is sufficiently general to work with
> all hardware, not just your own? How does this map on to the OMAP or SH
> hardware, for example?
AFAIK and with my experience (and my current memory) with TI Davinci
arch, most of the power domains are simpler ones with on/off and
possibly some retention too. And the latest TI code also exposes domains
with on/off/retention states. So, I think if we make this sturdy, I dont
see any reason why we cannot map any generic architecture. CCing Kevin
for his inputs.

This is one of the most important aspect for such a change in the
regulator framework: bringing in the domain aspect can encourage all
newer (possibly older) architectures to come under a generic umbrella.

Anyways, let me have a bit more on the "number of blocks" thing!

Regards,
Sundar

Re: Fwd: [linux-pm] Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 21:53 +0530, Sundar wrote:
> On Mon, May 17, 2010 at 8:03 PM, Mark Brown
> > On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:

> > The major goal of the regulator API is to allow us to match up consumer
> > drivers with regulator drivers without having any device specific tie
> > between the two.  Pushing things that need such tie in through the API
> > breaks that.

> Aren't machine constraints, setting maximum current limit based on total loads
> similar to primitive tie ups between devices and regulator driver?

Like I say, there are similarities - it's the way the parts of the
system are connected and the level of knowledge they can have of each
other that differs.

> I am still confused about the knowledge of regulator about its consumer. How
> I see is, with the added controls, it is still devoid of any
> information about its
> clients. All that a regulator still would know is if at all there are
> any clients which

As I said in reply to the patch I am concerned that this may be an
oversimplification relative to what general hardware needs.

> require it at full load. I think the function *set_optimal_load is
> very similar to a OPP
> control mechanism. Instead of summing up load currents, now there are
> constraints.
> Probably you may look at the patch set at the end of this mail and comment.

Right, and if we could work out some generic constraints that meshed
well with the regulator API constraints it might be sensible to do this
(though it may still be more sensible to just clone the bits shared with
regulator API if there's not enough overlap in anything except really
basic stuff like enables).

> > includes a strong tie in with information about the device clocking.
> > Typically changing the operating mode will change or limit the clock
> > rates in use in various parts of the device.

> cannot these be handled with existing/new notifiers in place?

Things may start to get complicated there when the clocking and
operating points get tightly enough interlinked, and I would worry that
you'd end up spending more time faffing about with back and forth
callbacks than would be required to just implement something specific to
operating modes.

Re: Fwd: Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 21:53 +0530, Sundar wrote:
> On Mon, May 17, 2010 at 8:03 PM, Mark Brown
> > On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote:

> > The major goal of the regulator API is to allow us to match up consumer
> > drivers with regulator drivers without having any device specific tie
> > between the two.  Pushing things that need such tie in through the API
> > breaks that.

> Aren't machine constraints, setting maximum current limit based on total loads
> similar to primitive tie ups between devices and regulator driver?

Like I say, there are similarities - it's the way the parts of the
system are connected and the level of knowledge they can have of each
other that differs.

> I am still confused about the knowledge of regulator about its consumer. How
> I see is, with the added controls, it is still devoid of any
> information about its
> clients. All that a regulator still would know is if at all there are
> any clients which

As I said in reply to the patch I am concerned that this may be an
oversimplification relative to what general hardware needs.

> require it at full load. I think the function *set_optimal_load is
> very similar to a OPP
> control mechanism. Instead of summing up load currents, now there are
> constraints.
> Probably you may look at the patch set at the end of this mail and comment.

Right, and if we could work out some generic constraints that meshed
well with the regulator API constraints it might be sensible to do this
(though it may still be more sensible to just clone the bits shared with
regulator API if there's not enough overlap in anything except really
basic stuff like enables).

> > includes a strong tie in with information about the device clocking.
> > Typically changing the operating mode will change or limit the clock
> > rates in use in various parts of the device.

> cannot these be handled with existing/new notifiers in place?

Things may start to get complicated there when the clocking and
operating points get tightly enough interlinked, and I would worry that
you'd end up spending more time faffing about with back and forth
callbacks than would be required to just implement something specific to
operating modes.

RE: [linux-pm] Power Domain Framework

[Linus WALLEIJ]

[Sundar]

> This is one of the most important aspect for such a change in the
> regulator framework: bringing in the domain aspect can encourage all
> newer (possibly older) architectures to come under a generic umbrella.

I have the same view, and I've been enouraging Sundar to bring this
discussion with the community in order to avoid code duplication.

Of course we can start inventing our own power-domain machine
like everyone else, but before we do that, let's atleast try to
do something generic, so bear with us...

Yours,
Linus Walleij

Re: Power Domain Framework

[Linus WALLEIJ]

[Sundar]

> This is one of the most important aspect for such a change in the
> regulator framework: bringing in the domain aspect can encourage all
> newer (possibly older) architectures to come under a generic umbrella.

I have the same view, and I've been enouraging Sundar to bring this
discussion with the community in order to avoid code duplication.

Of course we can start inventing our own power-domain machine
like everyone else, but before we do that, let's atleast try to
do something generic, so bear with us...

Yours,
Linus Walleij

RE: [linux-pm] Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 22:38 +0200, Linus WALLEIJ wrote:
> [Sundar]

> > This is one of the most important aspect for such a change in the
> > regulator framework: bringing in the domain aspect can encourage all
> > newer (possibly older) architectures to come under a generic umbrella.

> I have the same view, and I've been enouraging Sundar to bring this
> discussion with the community in order to avoid code duplication.

> Of course we can start inventing our own power-domain machine
> like everyone else, but before we do that, let's atleast try to
> do something generic, so bear with us...

So, there's two separate issues here: one is if it makes sense to do a
generic power domain framework and/or, and the other is if it makes
sense for that generic power domain framework to be part of the
regulator API. I do agree that separating out the common bits of power
domain implementation would be good, my concerns here are around the
level of integration with the regulator API.

Re: Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 22:38 +0200, Linus WALLEIJ wrote:
> [Sundar]

> > This is one of the most important aspect for such a change in the
> > regulator framework: bringing in the domain aspect can encourage all
> > newer (possibly older) architectures to come under a generic umbrella.

> I have the same view, and I've been enouraging Sundar to bring this
> discussion with the community in order to avoid code duplication.

> Of course we can start inventing our own power-domain machine
> like everyone else, but before we do that, let's atleast try to
> do something generic, so bear with us...

So, there's two separate issues here: one is if it makes sense to do a
generic power domain framework and/or, and the other is if it makes
sense for that generic power domain framework to be part of the
regulator API. I do agree that separating out the common bits of power
domain implementation would be good, my concerns here are around the
level of integration with the regulator API.

RE: [linux-pm] Power Domain Framework

[Linus WALLEIJ]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 643 bytes --]

[Mark]

> I do agree that separating out the common bits of power
> domain implementation would be good, my concerns here are around the
> level of integration with the regulator API.

The plenty talk about power domains in
Documentation/power/regulators/overview.txt
was what got us started in this regulator direction from the
beginning.

Anyhow: it will certainly be closely related even if we come
up with some different API for power domains so we're in the
right forum.

Linus
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Power Domain Framework

[Linus WALLEIJ]

[Mark]

> I do agree that separating out the common bits of power
> domain implementation would be good, my concerns here are around the
> level of integration with the regulator API.

The plenty talk about power domains in
Documentation/power/regulators/overview.txt
was what got us started in this regulator direction from the
beginning.

Anyhow: it will certainly be closely related even if we come
up with some different API for power domains so we're in the
right forum.

Linus

RE: [linux-pm] Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 23:46 +0200, Linus WALLEIJ wrote:
> [Mark]

> > I do agree that separating out the common bits of power
> > domain implementation would be good, my concerns here are around the
> > level of integration with the regulator API.

> The plenty talk about power domains in
> Documentation/power/regulators/overview.txt
> was what got us started in this regulator direction from the
> beginning.

Yeah, sure - obviously, the generic concept of power domains is
something that does exist within the off-SoC hardware, but on-SoC the
end implementation is a bit different.

Re: Power Domain Framework

[Mark Brown]

On Mon, 2010-05-17 at 23:46 +0200, Linus WALLEIJ wrote:
> [Mark]

> > I do agree that separating out the common bits of power
> > domain implementation would be good, my concerns here are around the
> > level of integration with the regulator API.

> The plenty talk about power domains in
> Documentation/power/regulators/overview.txt
> was what got us started in this regulator direction from the
> beginning.

Yeah, sure - obviously, the generic concept of power domains is
something that does exist within the off-SoC hardware, but on-SoC the
end implementation is a bit different.

RE: [linux-pm] Power Domain Framework

[Sundar R Iyer]

Hi,

> Yeah, sure - obviously, the generic concept of power domains is
> something that does exist within the off-SoC hardware, but on-SoC the
> end implementation is a bit different.

Exactly. This is what I can see if we can bridge this "a bit different".

True, I am dumb to miss out some points, but I think with more inputs,
more thinking, we can definitely make it generic!

Thinking out loud ( excuse me if this is dumb), At the end of the day,
how I see this benefiting a lay driver developer is : use the regulator
API for the appropriate power sources - your SoC domain, your external
regulator domain..etc..etc and ensure a very efficient (probably) run
time PM for your device. All that the Platform guy will do is iterate 
a list of domains on the platform, provide hookups, ensure constraints 
etc and the job is done. Even if the same IP is used on a different SoC,
you still ensure efficient savings in your driver itself.

> As I said in reply to the patch I am concerned that this may be an
> oversimplification relative to what general hardware needs.
Ohh. for the patch set, as I said, its only a primitive implementation.
With your inputs, we can definitely make it more efficient!

Regards,
Sundar

Re: Power Domain Framework

[Sundar R Iyer]

Hi,

> Yeah, sure - obviously, the generic concept of power domains is
> something that does exist within the off-SoC hardware, but on-SoC the
> end implementation is a bit different.

Exactly. This is what I can see if we can bridge this "a bit different".

True, I am dumb to miss out some points, but I think with more inputs,
more thinking, we can definitely make it generic!

Thinking out loud ( excuse me if this is dumb), At the end of the day,
how I see this benefiting a lay driver developer is : use the regulator
API for the appropriate power sources - your SoC domain, your external
regulator domain..etc..etc and ensure a very efficient (probably) run
time PM for your device. All that the Platform guy will do is iterate 
a list of domains on the platform, provide hookups, ensure constraints 
etc and the job is done. Even if the same IP is used on a different SoC,
you still ensure efficient savings in your driver itself.

> As I said in reply to the patch I am concerned that this may be an
> oversimplification relative to what general hardware needs.
Ohh. for the patch set, as I said, its only a primitive implementation.
With your inputs, we can definitely make it more efficient!

Regards,
Sundar

Re: Power Domain Framework

[Sundar]

[-- Attachment #1.1: Type: text/plain, Size: 450 bytes --]

Hi,

> operating mode for the entire power domain. For example, I can see
> hardware requiring that if more than a given number of blocks are
> enabled at any level a higher operating point is selected.
To me, since such a requirement is a constraint on the regulator,
this can be added as a flag to the regulator details.
This flag can then be used in the set_opp* functions to check the
condition along with the client dependencies!

Thanx!
Sundar

[-- Attachment #1.2: Type: text/html, Size: 843 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [linux-pm] Power Domain Framework

[Mark Brown]

On Sat, May 22, 2010 at 09:32:10AM +0530, Sundar wrote:

> > operating mode for the entire power domain. For example, I can see
> > hardware requiring that if more than a given number of blocks are
> > enabled at any level a higher operating point is selected.

> To me, since such a requirement is a constraint on the regulator,
> this can be added as a flag to the regulator details.
> This flag can then be used in the set_opp* functions to check the
> condition along with the client dependencies!

This is just one example of something that might come up and need
fitting in to the regulator API which is substantially different to the
needs of the core regulator applications.  As I keep saying I'm just not
seeing much more overlap here with the regulator API than I do with the
clock API: it feels like you've got another use case which needs an API
with a similar structure and the reference counted enable and disable
calls but otherwise very little overlap.

I don't think the enable and disable calls are enough of an overlap to
mean that the regulator use case and the operating point use case are
going to overlap well, it feels like it'd cause pain trying to match the
concepts between the two APIs.

Re: Power Domain Framework

[Mark Brown]

On Sat, May 22, 2010 at 09:32:10AM +0530, Sundar wrote:

> > operating mode for the entire power domain. For example, I can see
> > hardware requiring that if more than a given number of blocks are
> > enabled at any level a higher operating point is selected.

> To me, since such a requirement is a constraint on the regulator,
> this can be added as a flag to the regulator details.
> This flag can then be used in the set_opp* functions to check the
> condition along with the client dependencies!

This is just one example of something that might come up and need
fitting in to the regulator API which is substantially different to the
needs of the core regulator applications.  As I keep saying I'm just not
seeing much more overlap here with the regulator API than I do with the
clock API: it feels like you've got another use case which needs an API
with a similar structure and the reference counted enable and disable
calls but otherwise very little overlap.

I don't think the enable and disable calls are enough of an overlap to
mean that the regulator use case and the operating point use case are
going to overlap well, it feels like it'd cause pain trying to match the
concepts between the two APIs.

RE: [linux-pm] Power Domain Framework

[Sundar R IYER]

Hello Mark,

>-----Original Message-----
>From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
>This is just one example of something that might come up and need
>fitting in to the regulator API which is substantially different to the
>needs of the core regulator applications.  As I keep saying I'm just not
>seeing much more overlap here with the regulator API than I do with the
>clock API: it feels like you've got another use case which needs an API
>with a similar structure and the reference counted enable and disable
>calls but otherwise very little overlap.

As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
But what is essential here is: we are talking about regulators here.
Why would we need to model a seemingly similar regulator as a clock?

>I don't think the enable and disable calls are enough of an overlap to
>mean that the regulator use case and the operating point use case are
>going to overlap well, it feels like it'd cause pain trying to match the
>concepts between the two APIs.

Again here, more similarities for a power domain with a regulator.

1. Both power domains and a regulator can be enabled/disabled.
2. Both power domains and a regulator can be controlled to a specific voltage.
3. Every peripheral is dependent on both power domains and a regulator to be essentially
   on. Turning off the clocks will disable the peripheral, but it is not the same as turning off
   the peripheral. And here is where the biggest difference from the clock API. You can disable
   the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst
   a regulator_disable is the most logical fit here.
4. Both power domains and a regulator can be enforced upon constraints from their clients.

*What* power domains and regulators differ about is:
1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually
     a fixed set of clients which don't vary, but off SoC regulators can have varying clients.
2.a On SoC regulators aka power domains allow you controlling operational states like 
     On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads.
     However, this still doesn't stop anyone from actually adding operational states to regulators.

I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator.
If you agree, from the top, reaching out to bottom, there are only subtle differences and these 
differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually 
diminishing, whereas the similarities, (1,2,3,4) can only possible increase!

Thanks,
Sundar

Re: Power Domain Framework

[Sundar R IYER]

Hello Mark,

>-----Original Message-----
>From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
>This is just one example of something that might come up and need
>fitting in to the regulator API which is substantially different to the
>needs of the core regulator applications.  As I keep saying I'm just not
>seeing much more overlap here with the regulator API than I do with the
>clock API: it feels like you've got another use case which needs an API
>with a similar structure and the reference counted enable and disable
>calls but otherwise very little overlap.

As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
But what is essential here is: we are talking about regulators here.
Why would we need to model a seemingly similar regulator as a clock?

>I don't think the enable and disable calls are enough of an overlap to
>mean that the regulator use case and the operating point use case are
>going to overlap well, it feels like it'd cause pain trying to match the
>concepts between the two APIs.

Again here, more similarities for a power domain with a regulator.

1. Both power domains and a regulator can be enabled/disabled.
2. Both power domains and a regulator can be controlled to a specific voltage.
3. Every peripheral is dependent on both power domains and a regulator to be essentially
   on. Turning off the clocks will disable the peripheral, but it is not the same as turning off
   the peripheral. And here is where the biggest difference from the clock API. You can disable
   the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst
   a regulator_disable is the most logical fit here.
4. Both power domains and a regulator can be enforced upon constraints from their clients.

*What* power domains and regulators differ about is:
1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually
     a fixed set of clients which don't vary, but off SoC regulators can have varying clients.
2.a On SoC regulators aka power domains allow you controlling operational states like 
     On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads.
     However, this still doesn't stop anyone from actually adding operational states to regulators.

I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator.
If you agree, from the top, reaching out to bottom, there are only subtle differences and these 
differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually 
diminishing, whereas the similarities, (1,2,3,4) can only possible increase!

Thanks,
Sundar

Re: [linux-pm] Power Domain Framework

[Mark Brown]

On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:

> >needs of the core regulator applications.  As I keep saying I'm just not
> >seeing much more overlap here with the regulator API than I do with the
> >clock API: it feels like you've got another use case which needs an API
> >with a similar structure and the reference counted enable and disable
> >calls but otherwise very little overlap.

> As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
> But what is essential here is: we are talking about regulators here.
> Why would we need to model a seemingly similar regulator as a clock?

You're missing the point here.  I'm not saying use the clock API, I'm
saying that it feels like you want a parallel API that's aimed at the
needs of operating points which mirrors the structure of the existing
clock and regulator APIs.

> 1. Both power domains and a regulator can be enabled/disabled.
> 2. Both power domains and a regulator can be controlled to a specific voltage.

This isn't universal by any stretch of the imagination and manner in
which this is done is very different to how a regulator consumer would
operate.  A regulator consumer knows which voltage it wants to work at
directly and is selecting that voltage purely for itself, generally in a
way that applies to all implementations of the device.  With an
operating point a voltage is not set by the individual consumer but
rather for the power domain as a whole based on the needs of all the
consumers in the power domain.  If the same consumer driver is used in
multiple SoCs it's likely that the particular voltages needed will vary 
depending on the implementation on a given device.

It's perfectly sensible for the power domain to be a regulator consumer,
but having the individual consumer devices be regulator consumers seems
non-obvious.

> 3. Every peripheral is dependent on both power domains and a regulator to be essentially
>    on. Turning off the clocks will disable the peripheral, but it is not the same as turning off
>    the peripheral. And here is where the biggest difference from the clock API. You can disable
>    the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst
>    a regulator_disable is the most logical fit here.

This is very much dependant on hardware again, some devices require a
clock for even basic functionality such as register access and there are
things such as dynamic RAM which won't even provide retention if they
are declocked.

You also need to remember that a key part of the operating point
configuration of some devices is the clock rate - normally the voltage
required by the block will be driven by the clock rates in operation in
the block.  The clock rates required may be a function of the operation
of the individual blocks but are often also driven by things like the
overall bandwidth needed on the various buses in the system.

As I keep saying the operating point selection in general hardware is
often a function of both the clocking and voltage selection, and often
chosen in a different way.

> 4. Both power domains and a regulator can be enforced upon constraints from their clients.

A different set of constraints, though - there's not much overlap here.

> *What* power domains and regulators differ about is:
> 1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually
>      a fixed set of clients which don't vary, but off SoC regulators can have varying clients.

As I keep saying the interaction between the consumer and the supplier
is also rather different between the two use cases.

> 2.a On SoC regulators aka power domains allow you controlling operational states like 
>      On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads.
>      However, this still doesn't stop anyone from actually adding operational states to regulators.

Can you identify how operating points might be added to regulators?  The
physical connection between the regulators and the devices they are
supplying is very clear and does not leave much (if any) room for
flexibility here, and as I discussed in a prior message the trend in
hardware implementation is towards reducing the control which systems
use rather than increasing it.

> I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator.
> If you agree, from the top, reaching out to bottom, there are only subtle differences and these 
> differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually 
> diminishing, whereas the similarities, (1,2,3,4) can only possible increase!

I'm still not seeing any meaningful overlap between the two things - it
seems unlikely that a substantial proportion of the drivers that need to
interact with operating points will also wish to explicitly use anything
other than enable and disable that the regulator API offers so even if
the two ended up being implemented in the same API you'd still have two
disjoint blocks of code implementing different things.

There are many interfaces in the kernel which work together to provide
power efficiency and to me it seems like you have identified a need for
a new one.  I'd also repeat my previous suggestion to look in more
detail at the operating point implementations that already exist in the
kernel and the needs of the hardware out there.

Re: Power Domain Framework

[Mark Brown]

On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:

> >needs of the core regulator applications.  As I keep saying I'm just not
> >seeing much more overlap here with the regulator API than I do with the
> >clock API: it feels like you've got another use case which needs an API
> >with a similar structure and the reference counted enable and disable
> >calls but otherwise very little overlap.

> As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
> But what is essential here is: we are talking about regulators here.
> Why would we need to model a seemingly similar regulator as a clock?

You're missing the point here.  I'm not saying use the clock API, I'm
saying that it feels like you want a parallel API that's aimed at the
needs of operating points which mirrors the structure of the existing
clock and regulator APIs.

> 1. Both power domains and a regulator can be enabled/disabled.
> 2. Both power domains and a regulator can be controlled to a specific voltage.

This isn't universal by any stretch of the imagination and manner in
which this is done is very different to how a regulator consumer would
operate.  A regulator consumer knows which voltage it wants to work at
directly and is selecting that voltage purely for itself, generally in a
way that applies to all implementations of the device.  With an
operating point a voltage is not set by the individual consumer but
rather for the power domain as a whole based on the needs of all the
consumers in the power domain.  If the same consumer driver is used in
multiple SoCs it's likely that the particular voltages needed will vary 
depending on the implementation on a given device.

It's perfectly sensible for the power domain to be a regulator consumer,
but having the individual consumer devices be regulator consumers seems
non-obvious.

> 3. Every peripheral is dependent on both power domains and a regulator to be essentially
>    on. Turning off the clocks will disable the peripheral, but it is not the same as turning off
>    the peripheral. And here is where the biggest difference from the clock API. You can disable
>    the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst
>    a regulator_disable is the most logical fit here.

This is very much dependant on hardware again, some devices require a
clock for even basic functionality such as register access and there are
things such as dynamic RAM which won't even provide retention if they
are declocked.

You also need to remember that a key part of the operating point
configuration of some devices is the clock rate - normally the voltage
required by the block will be driven by the clock rates in operation in
the block.  The clock rates required may be a function of the operation
of the individual blocks but are often also driven by things like the
overall bandwidth needed on the various buses in the system.

As I keep saying the operating point selection in general hardware is
often a function of both the clocking and voltage selection, and often
chosen in a different way.

> 4. Both power domains and a regulator can be enforced upon constraints from their clients.

A different set of constraints, though - there's not much overlap here.

> *What* power domains and regulators differ about is:
> 1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually
>      a fixed set of clients which don't vary, but off SoC regulators can have varying clients.

As I keep saying the interaction between the consumer and the supplier
is also rather different between the two use cases.

> 2.a On SoC regulators aka power domains allow you controlling operational states like 
>      On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads.
>      However, this still doesn't stop anyone from actually adding operational states to regulators.

Can you identify how operating points might be added to regulators?  The
physical connection between the regulators and the devices they are
supplying is very clear and does not leave much (if any) room for
flexibility here, and as I discussed in a prior message the trend in
hardware implementation is towards reducing the control which systems
use rather than increasing it.

> I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator.
> If you agree, from the top, reaching out to bottom, there are only subtle differences and these 
> differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually 
> diminishing, whereas the similarities, (1,2,3,4) can only possible increase!

I'm still not seeing any meaningful overlap between the two things - it
seems unlikely that a substantial proportion of the drivers that need to
interact with operating points will also wish to explicitly use anything
other than enable and disable that the regulator API offers so even if
the two ended up being implemented in the same API you'd still have two
disjoint blocks of code implementing different things.

There are many interfaces in the kernel which work together to provide
power efficiency and to me it seems like you have identified a need for
a new one.  I'd also repeat my previous suggestion to look in more
detail at the operating point implementations that already exist in the
kernel and the needs of the hardware out there.

Re: [linux-pm] Power Domain Framework

[Paul Mundt]

On Wed, May 26, 2010 at 05:07:28PM -0400, Mark Brown wrote:
> On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:
> > >needs of the core regulator applications.  As I keep saying I'm just not
> > >seeing much more overlap here with the regulator API than I do with the
> > >clock API: it feels like you've got another use case which needs an API
> > >with a similar structure and the reference counted enable and disable
> > >calls but otherwise very little overlap.
> 
> > As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
> > But what is essential here is: we are talking about regulators here.
> > Why would we need to model a seemingly similar regulator as a clock?
> 
> You're missing the point here.  I'm not saying use the clock API, I'm
> saying that it feels like you want a parallel API that's aimed at the
> needs of operating points which mirrors the structure of the existing
> clock and regulator APIs.
> 
We did something like this on SH with our hwblk API for dealing with
module power gating, which forms the basis for our runtime PM
implementation. In the SH case we simply have a set of registers that
have on/off control over the bulk of the modules in any given CPU, and we
associate that at the platform device level.

Having said that, building on top of the regulator API for these cases
wouldn't be that much work either, since it largely has all of the
infrastructure in place (ie, the static consumer case).

> It's perfectly sensible for the power domain to be a regulator consumer,
> but having the individual consumer devices be regulator consumers seems
> non-obvious.
> 
The common case on SH is that certain blocks are only available in
certain power domains, while the on/off control remains uniform (albeit
periodically ineffectual) regardless of state. We also don't have any
ability to regulate voltage outside of things like PCMCIA.

On/off control in this context is completely orthoganol from clock
control in that many peripherals without a specific input clock still
implement power gating in the same way as those that do (this is the case
for things like the L2 cache, TLB, breakpoint controller, etc). These are
presently handled through the clock API largely because there was really
no better fit for them at the time.

Re: Power Domain Framework

[Paul Mundt]

On Wed, May 26, 2010 at 05:07:28PM -0400, Mark Brown wrote:
> On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:
> > >needs of the core regulator applications.  As I keep saying I'm just not
> > >seeing much more overlap here with the regulator API than I do with the
> > >clock API: it feels like you've got another use case which needs an API
> > >with a similar structure and the reference counted enable and disable
> > >calls but otherwise very little overlap.
> 
> > As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
> > But what is essential here is: we are talking about regulators here.
> > Why would we need to model a seemingly similar regulator as a clock?
> 
> You're missing the point here.  I'm not saying use the clock API, I'm
> saying that it feels like you want a parallel API that's aimed at the
> needs of operating points which mirrors the structure of the existing
> clock and regulator APIs.
> 
We did something like this on SH with our hwblk API for dealing with
module power gating, which forms the basis for our runtime PM
implementation. In the SH case we simply have a set of registers that
have on/off control over the bulk of the modules in any given CPU, and we
associate that at the platform device level.

Having said that, building on top of the regulator API for these cases
wouldn't be that much work either, since it largely has all of the
infrastructure in place (ie, the static consumer case).

> It's perfectly sensible for the power domain to be a regulator consumer,
> but having the individual consumer devices be regulator consumers seems
> non-obvious.
> 
The common case on SH is that certain blocks are only available in
certain power domains, while the on/off control remains uniform (albeit
periodically ineffectual) regardless of state. We also don't have any
ability to regulate voltage outside of things like PCMCIA.

On/off control in this context is completely orthoganol from clock
control in that many peripherals without a specific input clock still
implement power gating in the same way as those that do (this is the case
for things like the L2 cache, TLB, breakpoint controller, etc). These are
presently handled through the clock API largely because there was really
no better fit for them at the time.

Re: [linux-pm] Power Domain Framework

[Mark Brown]

On Thu, May 27, 2010 at 12:01:00PM +0900, Paul Mundt wrote:

> Having said that, building on top of the regulator API for these cases
> wouldn't be that much work either, since it largely has all of the
> infrastructure in place (ie, the static consumer case).

On the other hand given that all you're really getting here is the
enable/disable tracking it's also pretty easy to just copy.

> > It's perfectly sensible for the power domain to be a regulator consumer,
> > but having the individual consumer devices be regulator consumers seems
> > non-obvious.

> The common case on SH is that certain blocks are only available in
> certain power domains, while the on/off control remains uniform (albeit
> periodically ineffectual) regardless of state. We also don't have any
> ability to regulate voltage outside of things like PCMCIA.

That's also the case for the power domains on ARMs at the minute, though
the bus control element is pretty common and sometimes gets rolled in to
the operating modes since it's the same IP blocks that share the
resources.

> On/off control in this context is completely orthoganol from clock
> control in that many peripherals without a specific input clock still
> implement power gating in the same way as those that do (this is the case
> for things like the L2 cache, TLB, breakpoint controller, etc). These are
> presently handled through the clock API largely because there was really
> no better fit for them at the time.

Yup, that's pretty common.  The clocking stuff mostly comes into play
when your operating points also include an element of control for the
buses that the devices are hanging off - you end up doing DVFS for the
blocks, normally over the full block rather tha individual blocks.  It's
this stuff that usually has some crossover with regulators, though
mostly as consumers.

Re: Power Domain Framework

[Mark Brown]

On Thu, May 27, 2010 at 12:01:00PM +0900, Paul Mundt wrote:

> Having said that, building on top of the regulator API for these cases
> wouldn't be that much work either, since it largely has all of the
> infrastructure in place (ie, the static consumer case).

On the other hand given that all you're really getting here is the
enable/disable tracking it's also pretty easy to just copy.

> > It's perfectly sensible for the power domain to be a regulator consumer,
> > but having the individual consumer devices be regulator consumers seems
> > non-obvious.

> The common case on SH is that certain blocks are only available in
> certain power domains, while the on/off control remains uniform (albeit
> periodically ineffectual) regardless of state. We also don't have any
> ability to regulate voltage outside of things like PCMCIA.

That's also the case for the power domains on ARMs at the minute, though
the bus control element is pretty common and sometimes gets rolled in to
the operating modes since it's the same IP blocks that share the
resources.

> On/off control in this context is completely orthoganol from clock
> control in that many peripherals without a specific input clock still
> implement power gating in the same way as those that do (this is the case
> for things like the L2 cache, TLB, breakpoint controller, etc). These are
> presently handled through the clock API largely because there was really
> no better fit for them at the time.

Yup, that's pretty common.  The clocking stuff mostly comes into play
when your operating points also include an element of control for the
buses that the devices are hanging off - you end up doing DVFS for the
blocks, normally over the full block rather tha individual blocks.  It's
this stuff that usually has some crossover with regulators, though
mostly as consumers.