From: "R, Durgadoss" <durgadoss.r@intel.com>
To: "linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>
Subject: A new Subsystem for Current Management
Date: Tue, 8 Nov 2011 16:39:17 +0530 [thread overview]
Message-ID: <D6D887BA8C9DFF48B5233887EF04654109F10AF2C7@bgsmsx502.gar.corp.intel.com> (raw)
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
next reply other threads:[~2011-11-08 11:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-08 11:09 R, Durgadoss [this message]
2011-11-08 11:15 ` A new Subsystem for Current Management Felipe Balbi
2011-11-08 11:25 ` R, Durgadoss
2011-11-08 11:58 ` Christian Gagneraud
2011-11-08 13:56 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2011-11-10 11:28 R, Durgadoss
2011-11-10 15:04 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D6D887BA8C9DFF48B5233887EF04654109F10AF2C7@bgsmsx502.gar.corp.intel.com \
--to=durgadoss.r@intel.com \
--cc=linux-embedded@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).