A new Subsystem for Current Management

A new Subsystem for Current Management

[R, Durgadoss]

Hi All,

[Very Sorry for the big e-mail]

As we all know, Linux is increasingly being used in handhelds.
The Hardware that supports the handhelds is also becoming
Performance-centric. With this, we need a way to efficiently
monitor the current consumption of the platform and take actions
when the platform draws more current, than it should.

Where does this happen ?
------------------------
In a handheld, there are many components that demand high
Current. For example, Camera Flash, Video Streaming, 3G Voice
Call etc. Typically, two or more of these components are used
simultaneously in a real-time scenario. When this happens, the
current draw of the platform surges. If this surge lasts for
more than a specific time, it could crash the platform irrecoverably.

How do we tackle this ?
-----------------------
In Intel Medfield (Atom based) platform we had a driver that
Configures the current limits. When the platform current draws
more current than the programmed limit, the hardware generates
interrupt. The driver receives this interrupt and notifies the
user space to take appropriate actions.
The patch and the subsequent discussions can be found here:
http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197

To Generalize:
--------------
With many more platforms to come, having a separate driver for each
results in heavy code duplication. Also, there arises a problem of
where to put these kind of drivers ? Hence I propose the idea of having
a Current Management subsystem.

This will provide a generic ABI, API, so that the platform specific
drivers can register with this framework (and thus avail the basic
needs) and handle the events in their own way.

In simple terms, this framework will offer something like this:
	Current[1-N]_limit - set of current limits
	Voltage[1-X]_limit - set of voltage limits
	Controllers[1-Y]_enable - These are the components by throttling/
      disabling which the current consumption can be brought down.

With the Controllers we can follow two approaches:
A) Each component driver registers with the current framework and gets
notified when the current surge happens. On receiving the notification,
it throttles its performance. There will be a follow-up notification,
indicating that 'we are out of the high current' situation; so that
the component resumes to operation at its full performance.

B) The Current framework forwards the notification to the upper
layers and lets them decide what to do.

I agree that A) bloats the size of all the component drivers a bit,
but considering the fact that the surge has to be brought down as
soon as possible (and the delay in reacting to the event if we
pass it to the upper layers) I am inclined towards A).

I would like to see the opinion of the community on this entire
stuff, before I start writing some code.

Please Help,
Durga

Re: A new Subsystem for Current Management

[Bill Gatliff]

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

On Nov 5, 2011 2:16 AM, "R, Durgadoss" <durgadoss.r@intel.com> wrote:
> Also, there arises a problem of
> where to put these kind of drivers ? Hence I propose the idea of having
> a Current Management subsystem.

I love the idea. But is really more of an evolution of the regulator
framework rather than a completely distinct concept and API?

b.g.

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

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

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: A new Subsystem for Current Management

[Guenter Roeck]

On Sat, Nov 05, 2011 at 03:13:14AM -0400, R, Durgadoss wrote:
> Hi All,
> 
> [Very Sorry for the big e-mail]
> 
> As we all know, Linux is increasingly being used in handhelds.
> The Hardware that supports the handhelds is also becoming
> Performance-centric. With this, we need a way to efficiently
> monitor the current consumption of the platform and take actions
> when the platform draws more current, than it should.
> 
> Where does this happen ?
> ------------------------
> In a handheld, there are many components that demand high
> Current. For example, Camera Flash, Video Streaming, 3G Voice
> Call etc. Typically, two or more of these components are used
> simultaneously in a real-time scenario. When this happens, the
> current draw of the platform surges. If this surge lasts for
> more than a specific time, it could crash the platform irrecoverably.
> 
> How do we tackle this ?
> -----------------------
> In Intel Medfield (Atom based) platform we had a driver that
> Configures the current limits. When the platform current draws
> more current than the programmed limit, the hardware generates
> interrupt. The driver receives this interrupt and notifies the
> user space to take appropriate actions.
> The patch and the subsequent discussions can be found here:
> http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197
> 
> To Generalize:
> --------------
> With many more platforms to come, having a separate driver for each
> results in heavy code duplication. Also, there arises a problem of
> where to put these kind of drivers ? Hence I propose the idea of having
> a Current Management subsystem.
> 
> This will provide a generic ABI, API, so that the platform specific
> drivers can register with this framework (and thus avail the basic
> needs) and handle the events in their own way.
> 
> In simple terms, this framework will offer something like this:
> 	Current[1-N]_limit - set of current limits
> 	Voltage[1-X]_limit - set of voltage limits
> 	Controllers[1-Y]_enable - These are the components by throttling/
>       disabling which the current consumption can be brought down.
> 
hwmon already has

power[1-*]_cap
power[1-*]_crit

with explicit mention of "the system is expected take drastic action to reduce
power consumption, such as a system shutdown or a forced powerdown of some devices".

We also have

curr[1-*]_crit

though with no explicit mention of any action to be taken. We also have a pending patch
(waiting for someone to comment on it) to add notification and uevent support to sysfs ABI.
It is at the tip of my staging tree:
http://git.kernel.org/?p=linux/kernel/git/groeck/linux-staging.git;a=shortlog;h=refs/heads/hwmon-staging

Using this would address reporting to userspace. Question is how to handle any actions.
The regulator subsystem may be better suited to handle this, as already suggested.
Another approach would be to have a kernel-internal notification mechanism, which 
was already suggested for the hwmon subsystem.

Either case, I don't think a framework should be restricted to currents.
Power may be an even more important factor to determine if the system needs to be throttled.
In some cases, it may be necessary to reduce (or increase ?) voltage to reduce
current. So I think this will need a more comprehensive approach.

Thanks,
Guenter

RE: [lm-sensors] A new Subsystem for Current Management

[R, Durgadoss]

Hi,

On Nov 5, 2011 2:16 AM, "R, Durgadoss" <durgadoss.r@intel.com> wrote:
>> Also, there arises a problem of
>> where to put these kind of drivers ? Hence I propose the idea of having
>> a Current Management subsystem.

> I love the idea. But is really more of an evolution of the regulator
> framework rather than a completely distinct concept and API?

I agree. I went through the regulator framework to make this concept
fit in there. But, realistically this complete thing does not fit in
there exactly. Hence, my proposal for a new framework.

Thanks,
Durga

RE: A new Subsystem for Current Management

[R, Durgadoss]

Hi Guenter,

Thanks for the inputs.

[snip.]

> > In simple terms, this framework will offer something like this:
> > 	Current[1-N]_limit - set of current limits
> > 	Voltage[1-X]_limit - set of voltage limits
> > 	Controllers[1-Y]_enable - These are the components by throttling/
> >       disabling which the current consumption can be brought down.
> >
> hwmon already has
> 
> power[1-*]_cap
> power[1-*]_crit
> 
> with explicit mention of "the system is expected take drastic action to reduce
> power consumption, such as a system shutdown or a forced powerdown of some
> devices".
> 

Agree that we should consider 'power' also a main factor for the framework.

> We also have
> 
> curr[1-*]_crit

In the systems that I used, this 'curr' stuff is more extensive.
There are at least 3 current limits. The third one is the 'crit'
Stuff; the HW shuts down the platform when the platform hits crit.
The other two are kind of 'warnings' that the system can use to
reduce the consumption so that it never reaches 'crit'.

So, if we are using hwmon for this, we may to extend the ABI
in terms of these.

> 
> though with no explicit mention of any action to be taken. We also have a
> pending patch
> (waiting for someone to comment on it) to add notification and uevent support
> to sysfs ABI.
> It is at the tip of my staging tree:
> http://git.kernel.org/?p=linux/kernel/git/groeck/linux-
> staging.git;a=shortlog;h=refs/heads/hwmon-staging
> 
> Using this would address reporting to userspace. Question is how to handle any
> actions.

No doubt about it!!

> The regulator subsystem may be better suited to handle this, as already
> suggested.

After the discussions on my initial patch of 'intel_mid_ocd.c'
I tried to make use of regulator framework. Although theoretically
We should be able to use regulator framework, for this exact
'Current/Voltage/Power monitoring' job, it does not fit well.

> Another approach would be to have a kernel-internal notification mechanism,
> which was already suggested for the hwmon subsystem.
> 

I am all for this..

> Either case, I don't think a framework should be restricted to currents.
> Power may be an even more important factor to determine if the system needs to
> be throttled.
> In some cases, it may be necessary to reduce (or increase ?) voltage to reduce
> current. So I think this will need a more comprehensive approach.

In general, I am Ok to include 'Power' also & use in-kernel notification
Mechanisms.

May be an initial patch will make things more visible and give more idea
I guess. Then we can add/modify things from there.

Many thanks for the initial inputs.

Thanks,
Durga

Re: [lm-sensors] A new Subsystem for Current Management

[Jean Delvare]

Hi Durga,

On Sat, 5 Nov 2011 12:43:14 +0530, R, Durgadoss wrote:
> Hi All,
> 
> [Very Sorry for the big e-mail]
> 
> As we all know, Linux is increasingly being used in handhelds.
> The Hardware that supports the handhelds is also becoming
> Performance-centric. With this, we need a way to efficiently
> monitor the current consumption of the platform and take actions
> when the platform draws more current, than it should.
> 
> Where does this happen ?
> ------------------------
> In a handheld, there are many components that demand high
> Current. For example, Camera Flash, Video Streaming, 3G Voice
> Call etc. Typically, two or more of these components are used
> simultaneously in a real-time scenario. When this happens, the
> current draw of the platform surges. If this surge lasts for
> more than a specific time, it could crash the platform irrecoverably.
> 
> How do we tackle this ?
> -----------------------
> In Intel Medfield (Atom based) platform we had a driver that
> Configures the current limits. When the platform current draws
> more current than the programmed limit, the hardware generates
> interrupt. The driver receives this interrupt and notifies the
> user space to take appropriate actions.

I would argue that leaving the actions to user-space is wrong by
design. For something as critical as hardware integrity, ideally the
hardware and BIOS would be enough to guarantee it under any
circumstances. If that is not possible then I would hope that the kernel
alone can handle it. User-space may not always be there (think of the
boot sequence, or missing/broken package on the system.) Furthermore,
user-space will inevitably need to ask kernel drivers to do the job, so
you do kernel -> user-space -> kernel, which is certainly not the way
to go if you care about response times to critical events.

If user-space notification is in addition to actions already taken
directly by the kernel, then it's OK. But I admit I'm not quite sure
what extra actions user-space could take.

> The patch and the subsequent discussions can be found here:
> http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/1197
> 
> To Generalize:
> --------------
> With many more platforms to come, having a separate driver for each
> results in heavy code duplication. Also, there arises a problem of
> where to put these kind of drivers ? Hence I propose the idea of having
> a Current Management subsystem.
> 
> This will provide a generic ABI, API, so that the platform specific
> drivers can register with this framework (and thus avail the basic
> needs) and handle the events in their own way.
> 
> In simple terms, this framework will offer something like this:
> 	Current[1-N]_limit - set of current limits
> 	Voltage[1-X]_limit - set of voltage limits
> 	Controllers[1-Y]_enable - These are the components by throttling/
>       disabling which the current consumption can be brought down.
> 
> With the Controllers we can follow two approaches:
> A) Each component driver registers with the current framework and gets
> notified when the current surge happens. On receiving the notification,
> it throttles its performance. There will be a follow-up notification,
> indicating that 'we are out of the high current' situation; so that
> the component resumes to operation at its full performance.
> 
> B) The Current framework forwards the notification to the upper
> layers and lets them decide what to do.
> 
> I agree that A) bloats the size of all the component drivers a bit,
> but considering the fact that the surge has to be brought down as
> soon as possible (and the delay in reacting to the event if we
> pass it to the upper layers) I am inclined towards A).

It really depends on how much A) adds to individual drivers and how
much extra time B) takes in practice. Each option has a downside, so
it's very hard to decide without real-world numbers.

-- 
Jean Delvare

Re: [lm-sensors] A new Subsystem for Current Management

[Jean Delvare]

On Sat, 5 Nov 2011 22:06:22 +0530, R, Durgadoss wrote:
> Hi,
> 
> On Nov 5, 2011 2:16 AM, "R, Durgadoss" <durgadoss.r@intel.com> wrote:
> >> Also, there arises a problem of
> >> where to put these kind of drivers ? Hence I propose the idea of having
> >> a Current Management subsystem.
> 
> > I love the idea. But is really more of an evolution of the regulator
> > framework rather than a completely distinct concept and API?
> 
> I agree. I went through the regulator framework to make this concept
> fit in there. But, realistically this complete thing does not fit in
> there exactly. Hence, my proposal for a new framework.

I believe you'll have to elaborate a bit more than just "this complete
thing does not fit in there exactly." The problem you are trying to
tackle may be new to x86, because x86 is relatively new to the
embedded / low-power systems, but other architectures have been doing
that for over a decade.

While the regulator subsystem presents itself as aiming at power
savings to improve battery life, it doesn't seem fundamentally
different from the need you described. Whether you lower current draw
to save battery life or to prevent the hardware from dying, makes
little difference, the underlying mechanisms should be pretty similar.

Sending this post to the x86 platform driver list is the wrong approach
IMHO. You'd rather ask on lists of other embedded architectures how
they solved the problem on their side, and then see what it would take
to build on their existing solutions.

-- 
Jean Delvare

Re: [lm-sensors] A new Subsystem for Current Management

[Jean Delvare]

On Sat, 5 Nov 2011 22:20:45 +0530, R, Durgadoss wrote:
> > We also have
> > 
> > curr[1-*]_crit
> 
> In the systems that I used, this 'curr' stuff is more extensive.
> There are at least 3 current limits. The third one is the 'crit'
> Stuff; the HW shuts down the platform when the platform hits crit.
> The other two are kind of 'warnings' that the system can use to
> reduce the consumption so that it never reaches 'crit'.
> 
> So, if we are using hwmon for this, we may to extend the ABI
> in terms of these.

Note that in the hwmon sysfs interface, every input traditionally has
up to 3 upper limits: _max, _crit and _emergency in this order. While
the sysfs-interface document doesn't list all of them for each input
type, all this means is that so far no driver needed them and
libsensors doesn't know about them. But they can be added at any time
if the need exists.

> (...)
> May be an initial patch will make things more visible and give more idea
> I guess. Then we can add/modify things from there.

Certainly. It will be easier to evaluate the different options after
seeing actual code.

-- 
Jean Delvare

Re: [lm-sensors] A new Subsystem for Current Management

[Mark Brown]

On Sun, Nov 06, 2011 at 02:13:02PM +0100, Jean Delvare wrote:

> While the regulator subsystem presents itself as aiming at power
> savings to improve battery life, it doesn't seem fundamentally
> different from the need you described. Whether you lower current draw
> to save battery life or to prevent the hardware from dying, makes
> little difference, the underlying mechanisms should be pretty similar.

Actually the regulator API isn't really about power savings - it's about
voltage and current regulation.  Higher layers can use these features to
save power but it's not somethnig the regulator API cares about.  If the
documentation suggests it is we might want to fix that up.

Re: [lm-sensors] A new Subsystem for Current Management

[Jean Delvare]

Hi Mark,

On Tue, 8 Nov 2011 16:54:26 +0000, Mark Brown wrote:
> On Sun, Nov 06, 2011 at 02:13:02PM +0100, Jean Delvare wrote:
> 
> > While the regulator subsystem presents itself as aiming at power
> > savings to improve battery life, it doesn't seem fundamentally
> > different from the need you described. Whether you lower current draw
> > to save battery life or to prevent the hardware from dying, makes
> > little difference, the underlying mechanisms should be pretty similar.
> 
> Actually the regulator API isn't really about power savings - it's about
> voltage and current regulation.  Higher layers can use these features to
> save power but it's not somethnig the regulator API cares about.  If the
> documentation suggests it is we might want to fix that up.

I came up to this conclusion after reading the CONFIG_REGULATOR help
text in Kconfig. I'll let you decide if this should get improved in any
way.

-- 
Jean Delvare

Re: [lm-sensors] A new Subsystem for Current Management

[Mark Brown]

On Tue, Nov 08, 2011 at 05:57:49PM +0100, Jean Delvare wrote:
> On Tue, 8 Nov 2011 16:54:26 +0000, Mark Brown wrote:

> > Actually the regulator API isn't really about power savings - it's about
> > voltage and current regulation.  Higher layers can use these features to
> > save power but it's not somethnig the regulator API cares about.  If the
> > documentation suggests it is we might want to fix that up.

> I came up to this conclusion after reading the CONFIG_REGULATOR help
> text in Kconfig. I'll let you decide if this should get improved in any
> way.

I think the current text is OK, it's saying that it allows other
subsystems do things which save power which is what's happening.