From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "R, Durgadoss" <durgadoss.r@intel.com>
Cc: "linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>
Subject: Re: A new Subsystem for Current Management
Date: Thu, 10 Nov 2011 15:04:43 +0000 [thread overview]
Message-ID: <20111110150442.GG3832@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <D6D887BA8C9DFF48B5233887EF04654109F1111F6C@bgsmsx502.gar.corp.intel.com>
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.
next prev parent reply other threads:[~2011-11-10 15:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 11:28 A new Subsystem for Current Management R, Durgadoss
2011-11-10 15:04 ` Mark Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-11-08 11:09 R, Durgadoss
2011-11-08 11:15 ` Felipe Balbi
2011-11-08 11:25 ` R, Durgadoss
2011-11-08 11:58 ` Christian Gagneraud
2011-11-08 13:56 ` 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=20111110150442.GG3832@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=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).