From: Liam Girdwood <lrg@slimlogic.co.uk>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>,
Felipe Balbi <me@felipebalbi.com>
Cc: Mike Rapoport <mike@compulab.co.il>, linux-kernel@vger.kernel.org
Subject: Re: Question about userspace-consumer
Date: Tue, 11 Aug 2009 11:30:16 +0100 [thread overview]
Message-ID: <1249986616.5807.28.camel@odin> (raw)
In-Reply-To: <20090811094020.GA6762@rakim.wolfsonmicro.main>
On Tue, 2009-08-11 at 10:40 +0100, Mark Brown wrote:
> On Tue, Aug 11, 2009 at 08:44:42AM +0300, Felipe Balbi wrote:
> > On Mon, Aug 10, 2009 at 10:58:01PM +0100, Mark Brown wrote:
>
> > > Looking at that I'm not sure why you wish to push this into user space?
>
> > we need some daemon monitoring battery statuses and taking actions on
> > that. Imagine, for example, usb charging where we can:
>
> > a. charge up to 100mA when unconfigured
> > b. charge up to 500mA when configured
> > c. charge up to 2.5A when with dedicated charger
> > d. charge up to 2.5mA when bus is suspended
>
> It's more complex than that - those are the limits at the USB port that
> define the power that can be drawn by the system. The actual power
> available to the battery subsytem will be less since the rest of the
> system needs to be powered. In many cases even with 500mA available
> the battery will need to be used to provide additional power in order to
> keep the system operational rather than being charged.
>
> For USB powered operation at least some of the management here would
> usually be implemented in hardware to provide the responsiveness
> required. Waiting for software to get involved would often allow the
> main system supply to collapse.
>
> > handling all of those cases on kernel space seems a little bit odd,
> > especially because we still need to take care of state-of-charge,
> > pack temperature, time-to-charge, etc etc etc.
>
> > a big looping polling for that stuff in kernel space didn't seem ok to
> > me.
>
> No matter what you're still going to need at least some of the code
> in-kernel in order to handle the monitoring daemon exiting. For
> example, if the battery is in fast charge then something will need to
> back the charger off at least as the charge completes (if not
> immediately user space exits) otherwise the battery or entire system is
> likely to be damaged.
>
> Like I say some user space control does seem reasonable but I'd not
> expect an entirely user space implementation.
I agree, I think this probably deserves both user and kernel space
components although the dividing line between them is a little uncertain
atm.
Generally, I'd expect the kernel side to provide a guaranteed *safe*
environment for charging wrt system stability and battery status. A
simple state machine would probably suffice.
I think userspace is where we would manage policy. We would also store
past battery history in order to better manage future charging and
charge level estimation.
Liam
next prev parent reply other threads:[~2009-08-11 12:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-10 20:05 Question about userspace-consumer Felipe Balbi
2009-08-10 21:58 ` Mark Brown
2009-08-11 5:44 ` Felipe Balbi
2009-08-11 9:40 ` Mark Brown
2009-08-11 10:30 ` Liam Girdwood [this message]
2009-08-11 20:49 ` Smart Battery System Design (was: Re: Question about userspace-consumer) Felipe Balbi
2009-08-11 20:59 ` Felipe Balbi
2009-08-11 22:36 ` Mark Brown
2009-08-12 6:47 ` Felipe Balbi
2009-08-12 10:05 ` Mark Brown
2009-08-12 19:07 ` Felipe Balbi
2009-08-12 22:53 ` Mark Brown
2009-08-14 16:32 ` Pavel Machek
2009-08-15 16:43 ` Mark Brown
2009-08-15 22:34 ` Pavel Machek
2009-08-16 9:18 ` Mark Brown
2009-08-22 9:28 ` Pavel Machek
2009-08-22 10:16 ` Mark Brown
2009-08-21 14:01 ` Pavel Machek
2009-08-22 14:16 ` Mark Brown
2009-08-22 19:35 ` Pavel Machek
2009-08-23 9:08 ` Mark Brown
2009-08-11 12:09 ` Question about userspace-consumer Mike Rapoport
2009-08-11 12:56 ` Mark Brown
2009-08-11 20:40 ` Felipe Balbi
2009-08-14 16:31 ` Pavel Machek
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=1249986616.5807.28.camel@odin \
--to=lrg@slimlogic.co.uk \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@felipebalbi.com \
--cc=mike@compulab.co.il \
/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