Messages in this thread | | | Subject | Re: Question about userspace-consumer | From | Liam Girdwood <> | Date | Tue, 11 Aug 2009 11:30:16 +0100 |
| |
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
| |