A new Subsystem for Current Management

A new Subsystem for Current Management

[R, Durgadoss]

Hi Mark,

> 
> > 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
> 
> What would the voltage limits be?  Whatever is going on here there
> should be some integration with the regulator framework, modern
> regulators are often able to report when they go out of regulator and
> able to impose current limits.

These (limits) are configurable voltage limits. The HW generates an
Interrupt when any of these configured voltage limits are crossed.
Similarly, for Current also.

Now, Say there are 3 current limits that we can program.
On the first and second limit violation we take some actions,
and control the current consumption, so that it does not hit the
worst current limit.

Do you think, we can fit this into the regulator framework ?

I went through the regulator framework inside Linux-3.1.
I could see the core driver and lot of regulator drivers using the Framework.
But I would like to see a 'consumer' driver that uses the framework
efficiently, so that I can get some more idea. Could you point to
some source files ?

Thanks,
Durga

Re: A new Subsystem for Current Management

[Mark Brown]

On Thu, Nov 10, 2011 at 04:58:27PM +0530, R, Durgadoss wrote:

> > > 	Current[1-N]_limit - set of current limits
> > > 	Voltage[1-X]_limit - set of voltage limits

> > What would the voltage limits be?  Whatever is going on here there
> > should be some integration with the regulator framework, modern
> > regulators are often able to report when they go out of regulator and
> > able to impose current limits.

> These (limits) are configurable voltage limits. The HW generates an
> Interrupt when any of these configured voltage limits are crossed.
> Similarly, for Current also.

> Now, Say there are 3 current limits that we can program.
> On the first and second limit violation we take some actions,
> and control the current consumption, so that it does not hit the
> worst current limit.

So what you mean is that these are maxima.  

I'm not sure that the voltage limits are terribly useful on regulated
supplies; the voltages tend not to be varied autonomously by hardware
and even where they are they're not directly tied to power consumption
which is usually the actual problem.  On unregulated supplies like the
battery output it's more useful and it's something that the existing
power framework already has some support for reporting current flows,
my first guess would be that for the unregulated supplies you'd build on
top of that (and there will be overlap with the charger management for
the devices that need hand holding to do that).

Current limits are more generally useful, they apply equally well to
regulated and unregulated supplies.

You probably want to tie this stuff in with the thermal management work
that people are starting to look at - it sounds like you're basically
trying to look at a different aspect of the same problem.

> Do you think, we can fit this into the regulator framework ?

That's not something that the hardware generally supports; for voltages
you'll usually just get an out of regulation notification and current
limits generally just give you a single trip point.

> But I would like to see a 'consumer' driver that uses the framework
> efficiently, so that I can get some more idea. Could you point to
> some source files ?

find linux-2.6 -type f | xargs grep -l regulator_

should show a bunch of devices, nothing actually using any form of
limiting at the minute though.  Any regulator driver which notifies will
be able to show when it goes out of regulation.

A new Subsystem for Current Management

[R, Durgadoss]

Hi All,

[Very Sorry for the Big Email]

[I have posted this on lm-sensors and platform-drivers-x86
lists earlier. As per some recommendations there, posting it
here]

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 this can 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

[Felipe Balbi]

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

Hi,

On Tue, Nov 08, 2011 at 04:39:17PM +0530, R, Durgadoss wrote:
> [Very Sorry for the Big Email]
> 
> [I have posted this on lm-sensors and platform-drivers-x86
> lists earlier. As per some recommendations there, posting it
> here]
> 
> 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 this can 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.

looks like this should be done on hwmon ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: A new Subsystem for Current Management

[R, Durgadoss]

Hi,

[snip.]
> >
> > I would like to see the opinion of the community on this entire
> > stuff, before I start writing some code.
> 
> looks like this should be done on hwmon ?

We discussed it there. The link I sent in the previous mail,
has all the discussions. 

Thanks,
Durga

Re: A new Subsystem for Current Management

[Christian Gagneraud]

On 08/11/11 11:09, R, Durgadoss wrote:
> Hi All,

Hi Durga,

>
> [Very Sorry for the Big Email]
>
> [I have posted this on lm-sensors and platform-drivers-x86
> lists earlier. As per some recommendations there, posting it
> here]
>
> 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 this can 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.

Could you elaborate a bit more on this, perhaps by taking the Medfield 
platform as an example. I don't see above any reference to timers or 
maybe it's part of {Current|Voltage}[1-X]_limit?

As well, it would be nice if this system could work nicely beside 
linux-iio. For example to provide the ability to plot currents and 
voltages, and see when/why the actions have been taken.

Chris

>
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/

Re: A new Subsystem for Current Management

[Mark Brown]

On Tue, Nov 08, 2011 at 04:39:17PM +0530, R, Durgadoss wrote:

> [I have posted this on lm-sensors and platform-drivers-x86
> lists earlier. As per some recommendations there, posting it
> here]

lkml would probably be useful.  It'd also help if you could publish code
along with your mail, in general people are much more likely to review
concrete code.

> 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

What would the voltage limits be?  Whatever is going on here there
should be some integration with the regulator framework, modern
regulators are often able to report when they go out of regulator and
able to impose current limits.