lkml.org 
[lkml]   [2009]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Question about userspace-consumer
From
Date
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



\
 
 \ /
  Last update: 2009-08-11 14:51    [W:0.153 / U:0.316 seconds]
©2003-2014 Jasper Spaans. Advertise on this site