Question about userspace-consumer

Question about userspace-consumer

[Felipe Balbi]

Hi all,

I was reading userspace-consumer file ad was wondering whether would be
possible to use that in order to implement what SBS-IF [1] proposes
using sbs-enabled devices.

For doing that, probably userspace-consumer would have to be able to
set_voltage/get_voltage, set/get_current_limit and so on. So I was
thinking on changing userspace-consumer to use regulator_get() instead
of regulator_bulk_get() and make each instance of userspace-consumer to
talk to only and only one regulator.

I didn't put down any code but that seems quite plausible if we attach
userspace-consumer to the proper regulator(s) on board-file.

For doing the implementation and test part, I was thinking on getting
a bq2084evm [2] and sniffing the usb-i2c bus in order to write down some
code to use that under linux, but that's just implementation details.

Anyways, how do you guys feel about it ?

[1] http://www.sbs-forum.org
[2] http://focus.ti.com/docs/toolsw/folders/print/bq2084evm-001.html

-- 
balbi

Re: Question about userspace-consumer

[Mark Brown]

On Mon, Aug 10, 2009 at 11:05:54PM +0300, Felipe Balbi wrote:

> I was reading userspace-consumer file ad was wondering whether would be
> possible to use that in order to implement what SBS-IF [1] proposes
> using sbs-enabled devices.

Looking at that I'm not sure why you wish to push this into user space?

The existing drivers for this sort of functionality are all regular
kernel drivers (in drivers/power and to a lesser extent drivers/hwmon)
and it looks like it'd be at least as much work to rearrange the power
supply stuff to support userspace drivers.  My initial expectation would
be for a generic driver with some policy exposed to user space and some
configuration exposed for architecture code (especially for setting up
multi-battery board layouts and things).  That's not a terribly informed
opinion, though.

> For doing that, probably userspace-consumer would have to be able to
> set_voltage/get_voltage, set/get_current_limit and so on. So I was
> thinking on changing userspace-consumer to use regulator_get() instead
> of regulator_bulk_get() and make each instance of userspace-consumer to
> talk to only and only one regulator.

I'd like to preserve the bulk switch if possible - part of the thinking
was that things with more complex needs may well find it easier and/or
more robust to have custom kernel stubs which mapped one or more
regulators into the interfaces they needed.  That was more for things
like working out which of multiple supplies is which, though.

The existing virtual consumer, while intended as a test harness
originally and rather clunky as-is, is much closer to your needs.  It is
the way it is partly as a sign that you really shouldn't be using it in
production (which seems to be working!).

> Anyways, how do you guys feel about it ?

Like I say, from a quick read through of the specs I'm not sure that I'd
push this into user space but I've not thought about this deeply and may
be missing something.

Re: Question about userspace-consumer

[Felipe Balbi]

On Mon, Aug 10, 2009 at 10:58:01PM +0100, Mark Brown wrote:
> On Mon, Aug 10, 2009 at 11:05:54PM +0300, Felipe Balbi wrote:
> 
> > I was reading userspace-consumer file ad was wondering whether would be
> > possible to use that in order to implement what SBS-IF [1] proposes
> > using sbs-enabled devices.
> 
> 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

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.

> The existing drivers for this sort of functionality are all regular
> kernel drivers (in drivers/power and to a lesser extent drivers/hwmon)
> and it looks like it'd be at least as much work to rearrange the power
> supply stuff to support userspace drivers.  My initial expectation would

power supply already does what it needs, no ? It exports battery
figures (state-of-charge, time-to-charge, temperature, etc etc) via
sysfs to userland, where our "charging daemon" could read those values
from.

> be for a generic driver with some policy exposed to user space and some
> configuration exposed for architecture code (especially for setting up
> multi-battery board layouts and things).  That's not a terribly informed
> opinion, though.
> 
> > For doing that, probably userspace-consumer would have to be able to
> > set_voltage/get_voltage, set/get_current_limit and so on. So I was
> > thinking on changing userspace-consumer to use regulator_get() instead
> > of regulator_bulk_get() and make each instance of userspace-consumer to
> > talk to only and only one regulator.
> 
> I'd like to preserve the bulk switch if possible - part of the thinking
> was that things with more complex needs may well find it easier and/or
> more robust to have custom kernel stubs which mapped one or more
> regulators into the interfaces they needed.  That was more for things
> like working out which of multiple supplies is which, though.

gotcha. The only problem is that it becomes a litle difficult to access
struct regulator * for doing regulator_set_voltage() and its sibblings.

> The existing virtual consumer, while intended as a test harness
> originally and rather clunky as-is, is much closer to your needs.  It is
> the way it is partly as a sign that you really shouldn't be using it in
> production (which seems to be working!).
> 
> > Anyways, how do you guys feel about it ?
> 
> Like I say, from a quick read through of the specs I'm not sure that I'd
> push this into user space but I've not thought about this deeply and may
> be missing something.

I think kernel should, as long as possible, only provide functionalities
for userland to take decisions and actions, no ?

Handling policy in kernel space I find it a little odd, specially
because different manufacturers might have different charging algorithms
they want to implement.

that said, power supply framework and regulator framework seem to be
well enough for implementing the basic support for SBS-enabled charging
scheme.

-- 
balbi

Re: Question about userspace-consumer

[Mark Brown]

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.

> > The existing drivers for this sort of functionality are all regular
> > kernel drivers (in drivers/power and to a lesser extent drivers/hwmon)
> > and it looks like it'd be at least as much work to rearrange the power
> > supply stuff to support userspace drivers.  My initial expectation would

> power supply already does what it needs, no ? It exports battery
> figures (state-of-charge, time-to-charge, temperature, etc etc) via
> sysfs to userland, where our "charging daemon" could read those values
> from.

I'd have expected to see both the charger and the battery appear as part
of the power supply map, or to see the charger and battery merged into
one device.

> > I'd like to preserve the bulk switch if possible - part of the thinking
> > was that things with more complex needs may well find it easier and/or
> > more robust to have custom kernel stubs which mapped one or more
> > regulators into the interfaces they needed.  That was more for things
> > like working out which of multiple supplies is which, though.

> gotcha. The only problem is that it becomes a litle difficult to access
> struct regulator * for doing regulator_set_voltage() and its sibblings.

Not really, the regulator is right there in the bulk data.  It's not
intended to be an opaque struct.

> > Like I say, from a quick read through of the specs I'm not sure that I'd
> > push this into user space but I've not thought about this deeply and may
> > be missing something.

> I think kernel should, as long as possible, only provide functionalities
> for userland to take decisions and actions, no ?

Policy should be punted to user space but that doesn't mean that the
entire implementation needs to be there.  For something like this where
you're likely to be burning a very large part of the entire system power
consumption and lasting hardware damage is likely if something goes
wrong the idea of removing everything from the kernel seems very risky.

> Handling policy in kernel space I find it a little odd, specially
> because different manufacturers might have different charging algorithms
> they want to implement.

Looking at the specs (like I say I didn't look *that* closely) it
appeared that the main goal was to encapsulate the charging algorithm in
the battery so that the charger only needed to do whatever it was told
by the battery.  I'd expect the policy for user space here to be more
along the lines of setting how much power the charge is allowed to
consume than the entire algorithm.

I'd also expect that if this gets widely deployed in smaller devices (as
opposed to laptops) you'd start to see chargers that are able to do some
of the management of the charge cycle autonomously.

Re: Question about userspace-consumer

[Liam Girdwood]

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

Re: Question about userspace-consumer

[Mike Rapoport]

Felipe Balbi wrote:
> On Mon, Aug 10, 2009 at 10:58:01PM +0100, Mark Brown wrote:
>> On Mon, Aug 10, 2009 at 11:05:54PM +0300, Felipe Balbi wrote:
>>
>> The existing drivers for this sort of functionality are all regular
>> kernel drivers (in drivers/power and to a lesser extent drivers/hwmon)
>> and it looks like it'd be at least as much work to rearrange the power
>> supply stuff to support userspace drivers.  My initial expectation would
> 
> power supply already does what it needs, no ? It exports battery
> figures (state-of-charge, time-to-charge, temperature, etc etc) via
> sysfs to userland, where our "charging daemon" could read those values
> from.
> 
>> be for a generic driver with some policy exposed to user space and some
>> configuration exposed for architecture code (especially for setting up
>> multi-battery board layouts and things).  That's not a terribly informed
>> opinion, though.

+1

>>> For doing that, probably userspace-consumer would have to be able to
>>> set_voltage/get_voltage, set/get_current_limit and so on. So I was
>>> thinking on changing userspace-consumer to use regulator_get() instead
>>> of regulator_bulk_get() and make each instance of userspace-consumer to
>>> talk to only and only one regulator.

I don't think that a battery charger should identify itself like a regulator
device. It seems to me that charger driver belongs completely to the power
supply subsystem and if there's a need to add policy enforcement functionality,
it should be added to the power supply subsystem.
Moreover, extending userspace-consumer driver for battery charger needs is too
dangerous. You have to ensure that *all* critical conditions are handled
in-kernel, no matter what userspace policy is.

> I think kernel should, as long as possible, only provide functionalities
> for userland to take decisions and actions, no ?
> 
> Handling policy in kernel space I find it a little odd, specially
> because different manufacturers might have different charging algorithms
> they want to implement.

It depends on how do you define policy. If the policy includes e.g. over-charge
and over-temperature than it should be handled in-kernel.

> that said, power supply framework and regulator framework seem to be
> well enough for implementing the basic support for SBS-enabled charging
> scheme.

As far as I understood SBS scheme, the host has very little impact on the
charging process. Most of the charging is handled by Smart Battery and Smart
Battery Charger without any host intervention.


-- 
Sincerely yours,
Mike.

Re: Question about userspace-consumer

[Mark Brown]

On Tue, Aug 11, 2009 at 03:09:08PM +0300, Mike Rapoport wrote:
> Felipe Balbi wrote:

> > that said, power supply framework and regulator framework seem to be
> > well enough for implementing the basic support for SBS-enabled charging
> > scheme.

> As far as I understood SBS scheme, the host has very little impact on the
> charging process. Most of the charging is handled by Smart Battery and Smart
> Battery Charger without any host intervention.

I strongly suspect that in at least some designs the battery charger
itself will be at least partially dumb and the battery charger part of
the spec done by software running on the host CPU - there's examples in
the spec which seem to back that up.

Re: Question about userspace-consumer

[Felipe Balbi]

On Tue, Aug 11, 2009 at 01:56:03PM +0100, Mark Brown wrote:
> On Tue, Aug 11, 2009 at 03:09:08PM +0300, Mike Rapoport wrote:
> > Felipe Balbi wrote:
> 
> > > that said, power supply framework and regulator framework seem to be
> > > well enough for implementing the basic support for SBS-enabled charging
> > > scheme.
> 
> > As far as I understood SBS scheme, the host has very little impact on the
> > charging process. Most of the charging is handled by Smart Battery and Smart
> > Battery Charger without any host intervention.
> 
> I strongly suspect that in at least some designs the battery charger
> itself will be at least partially dumb and the battery charger part of
> the spec done by software running on the host CPU - there's examples in
> the spec which seem to back that up.

and that's what I was talking about. I'll reply more to the other
subthread.

-- 
balbi

Smart Battery System Design (was: Re: Question about userspace-consumer)

[Felipe Balbi]

Hi,

On Tue, Aug 11, 2009 at 11:30:16AM +0100, Liam Girdwood wrote:
> 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

yeah, I understand quite well the usb standard.

> > 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.

and that's also rather obvious, specially since usb has overcurrent
protection (most of roothubs if not all), so drawing exactly 500mA
could cause current spikes that force the port to be shut off.

> > 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.

and that's all ok.

> > > 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.

What I mean is that on SBS design, the "charger daemon" doesn't have to
handle the charging algorithm per se since the battery itself reports to
charger the best condition for it to be charged, but still we need means
for a userland application to see that a power source was attached (via
power supply interface, be it USB, AC or whatever we want) and tell the
charger to _start_charging_, no ?

That's when I thought a call to regulator_enable() would seem plausible.

> > Like I say some user space control does seem reasonable but I'd not
> > expect an entirely user space implementation.

of course not, specially since according to SBS, the hardware will
handle most of it autonomously.

> I agree, I think this probably deserves both user and kernel space
> components although the dividing line between them is a little uncertain
> atm. 

+1

> 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.

and wrt SBS, that would mean basically writing a driver for that Smart
Batery Charger and the Smart Battery devices creating means for some
entity to tell _start_charging_ based on the presence of a power source.

> 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. 

Sure. Another point to be taken into account is how often to check
battery status; I mean, if the system is idle, we don't need to check
battery every second since battery temperature and juice won't change
that quickly anyways, but when doing some hardcore stuff on the CPU then
we need to check such variables more often.

-- 
balbi

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Felipe Balbi]

Hi,

On Tue, Aug 11, 2009 at 11:49:18PM +0300, Felipe Balbi wrote:
> Sure. Another point to be taken into account is how often to check
> battery status; I mean, if the system is idle, we don't need to check
> battery every second since battery temperature and juice won't change
> that quickly anyways, but when doing some hardcore stuff on the CPU then
> we need to check such variables more often.

oops, SBS Data spec already gives good information about that.
Normally check the battery once every 10 secs.

Refer to SBS Data Spec Item 4.4.5

-- 
balbi

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Tue, Aug 11, 2009 at 11:49:18PM +0300, Felipe Balbi wrote:
> On Tue, Aug 11, 2009 at 11:30:16AM +0100, Liam Girdwood wrote:
> > On Tue, 2009-08-11 at 10:40 +0100, Mark Brown wrote:

> > > 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

> yeah, I understand quite well the usb standard.

OK, good - it wasn't clear from what you said since obviously one of the
parameters the battery charger has is the current it pushes into the
battery (which is constrained by but very removed from the current
limits on any supplies).

> > > 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.

> What I mean is that on SBS design, the "charger daemon" doesn't have to
> handle the charging algorithm per se since the battery itself reports to
> charger the best condition for it to be charged, but still we need means
> for a userland application to see that a power source was attached (via
> power supply interface, be it USB, AC or whatever we want) and tell the
> charger to _start_charging_, no ?

This is already handled in kernel by the drivers/power code.  Whenever a
power supply updates its status it notifies the subsystem which will
then notify user space and also notify any other power supplies which
have been configured as being supplied by the changing supply.  This is
used by existing drivers for non-autonomous battery chargers to initiate
charging (usually via a GPIO connected to the charger).

> That's when I thought a call to regulator_enable() would seem plausible.

Yes, that's a good time to kick off a charge (other constraints
permitting) however that's done.

This is all a bit of a sidetrack, though - the issue is if there is an
in-kernel part to the SBS charger support.  With the userspace consumer
there's nothing at all, even an extremely basic stub which does nothing
more than shut the charger off when userspace exits would deal with the
issue I have here.  For dumb chargers we need to make sure that
something is taking responsibility for making sure that the battery is
not mistreated.

> > 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.

> and wrt SBS, that would mean basically writing a driver for that Smart
> Batery Charger and the Smart Battery devices creating means for some
> entity to tell _start_charging_ based on the presence of a power source.

For me the critical thing is that we ensure that the charger won't be
left charging at anything more than a trickle charge when there's
nothing monitoring the battery status.  If the charger can do the SBS
charger stuff autononmously it can look after itself (but the use of the
regulator API becomes more questionable for those devices since the
charger will be doing all the management of the regulators).  If the SBS
is done entirely in software the kernel at least needs to be able to
notice the management software exiting and clean up after it, even if
that's all it is able to do for itself.

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Felipe Balbi]

Hi,

On Tue, Aug 11, 2009 at 11:36:46PM +0100, Mark Brown wrote:
> This is already handled in kernel by the drivers/power code.  Whenever a
> power supply updates its status it notifies the subsystem which will
> then notify user space and also notify any other power supplies which
> have been configured as being supplied by the changing supply.  This is
> used by existing drivers for non-autonomous battery chargers to initiate
> charging (usually via a GPIO connected to the charger).

but that'll depend very much on the chip being used. Check bq24150, for
example. We cannot rely on a gpio since we have to tell the charger if
it can charger with up to 100mA, up to 500mA or more (in case of a
dedicated usb charger we can draw up to 2.5A if I'm not wrong, but most
chargers I've seen source up to 1.5A). A gpio would only be able to tell
the charger is present or not.

> > That's when I thought a call to regulator_enable() would seem plausible.
> 
> Yes, that's a good time to kick off a charge (other constraints
> permitting) however that's done.
> 
> This is all a bit of a sidetrack, though - the issue is if there is an
> in-kernel part to the SBS charger support.  With the userspace consumer
> there's nothing at all, even an extremely basic stub which does nothing
> more than shut the charger off when userspace exits would deal with the
> issue I have here.  For dumb chargers we need to make sure that
> something is taking responsibility for making sure that the battery is
> not mistreated.

sure, but where do we draw the line between kernel and userspace in this
case ?

do we just be sure that information goes to userland and in case there's
no application monitoring battery we stop charging ? Or do we monitor
the battery in-kernel ?

I'd go for monitoring in userland since we might have way too many
points to be tracking. One might be:

1. doing ADC conversions for fetching battery voltage (not so used since most
   battery chips can report that)
2. checking whether we're connect to a usb host or a usb dedicated
   charger (have to kick usb charger detection as per USB Battery Charger
   Spec 1.1
3. Priotizing one or other charger (imagine a system with both usb and
   AC charger support)
4. enabling the charger after figuring out how much current we can draw
   from that supply

And a lot more, I just put these here to show that each case will fall
in one different subsystem as a different driver.

ADC would most likely go to HWMON

charger presence would go to power supply

enabling the charger could be regulator_enable() call.

prioritization of the chargers available could be even based on user
preferences (very unlikely though).

> > > 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.
> 
> > and wrt SBS, that would mean basically writing a driver for that Smart
> > Batery Charger and the Smart Battery devices creating means for some
> > entity to tell _start_charging_ based on the presence of a power source.
> 
> For me the critical thing is that we ensure that the charger won't be
> left charging at anything more than a trickle charge when there's
> nothing monitoring the battery status.  If the charger can do the SBS
> charger stuff autononmously it can look after itself (but the use of the
> regulator API becomes more questionable for those devices since the
> charger will be doing all the management of the regulators).  If the SBS
> is done entirely in software the kernel at least needs to be able to
> notice the management software exiting and clean up after it, even if
> that's all it is able to do for itself.

ok, now I got your point. Your concerned with the case where a userland
application, say, crashes and the battery is left for overcharging and
overheating.

-- 
balbi

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Wed, Aug 12, 2009 at 09:47:50AM +0300, Felipe Balbi wrote:
> On Tue, Aug 11, 2009 at 11:36:46PM +0100, Mark Brown wrote:

> > This is already handled in kernel by the drivers/power code.  Whenever a
> > power supply updates its status it notifies the subsystem which will
> > then notify user space and also notify any other power supplies which
> > have been configured as being supplied by the changing supply.  This is
> > used by existing drivers for non-autonomous battery chargers to initiate
> > charging (usually via a GPIO connected to the charger).

> but that'll depend very much on the chip being used. Check bq24150, for
> example. We cannot rely on a gpio since we have to tell the charger if

You actually get notification on any change the supply chooses to notify
the core on IIRC.

> it can charger with up to 100mA, up to 500mA or more (in case of a
> dedicated usb charger we can draw up to 2.5A if I'm not wrong, but most
> chargers I've seen source up to 1.5A). A gpio would only be able to tell
> the charger is present or not.

Well, that's just the addition of a second GPIO to put it into fast
charge mode (which has other constraints beyond the system supply
current).  It'd probably help clarity to not refer so directly to the
USB current limits here due to all the stuff in between the USB supply
and the charger.

> > This is all a bit of a sidetrack, though - the issue is if there is an
> > in-kernel part to the SBS charger support.  With the userspace consumer
> > there's nothing at all, even an extremely basic stub which does nothing

> sure, but where do we draw the line between kernel and userspace in this
> case ?

> do we just be sure that information goes to userland and in case there's
> no application monitoring battery we stop charging ? Or do we monitor
> the battery in-kernel ?

I'd be inclined to put at least some of the basic charge cycle into the
kernel but it doesn't concern me too much so long as the user/kernel
interface doesn't expose us to the risk of damaging the battery through
inattention.

> I'd go for monitoring in userland since we might have way too many
> points to be tracking. One might be:

> 1. doing ADC conversions for fetching battery voltage (not so used since most
>    battery chips can report that)
> 2. checking whether we're connect to a usb host or a usb dedicated
>    charger (have to kick usb charger detection as per USB Battery Charger
>    Spec 1.1

Or a wall supply.  The best you can get from the 100mA limit is that
it's not even worth trying a fast charge but that's not the same thing
as being able to do one, having more than that isn't that much of a
reliable guide.

> 3. Priotizing one or other charger (imagine a system with both usb and
>    AC charger support)

It's probably more interesting to think of prioritising between multiple
batteries here - most systems I've seen have power path management which
handles all the incoming power sources and uses them to maintain an
unregulated power domain which is then used as the root supply for the
rest of the system, including the battery chargers.  This takes the
supply selection well out of the domain of charging.

> 4. enabling the charger after figuring out how much current we can draw
>    from that supply

This is the really tricky bit since you need some idea of the load from
the rest of the system if the charger really is able to draw current.
Normally there's a combination of checking various gates to see if it's
possible to start charging with the current parameters and then things
like monitoring the supply voltage to the charger to make sure it's not
drooping and taking corrective action if it does.

My feeling is that in addition to what you're saying the in-kernel side
of things should also describe how the system is wired together since
that's the sort of task the kernel is doing anyway, it's something
that is fixed in the hardware and it's potentially dangerous to get
wrong.

> enabling the charger could be regulator_enable() call.

Assuming the charger also has things like voltage and current control
exposed.  I think I'd expect to see some sort of charger class which
abstracts out the functionality of the charger so that the same user
applications can also be used to set policy for more autonomous
chargers.  Those chargers may require contortions to fit them into the
regulator API depending on the control they provide to the system.  More
simple chargers may well fit cleanly into the regulator API (they're
regulators after all) but that'd be just one example of this class.

Quite how much I'd expect such a soft charger to be able to do for
itself I'm less sure about but I'd be inclined to at least look at doing
the stuff that can be done with only information from the battery in
kernel to make things more consistent for user space.

> > charger will be doing all the management of the regulators).  If the SBS
> > is done entirely in software the kernel at least needs to be able to
> > notice the management software exiting and clean up after it, even if
> > that's all it is able to do for itself.

> ok, now I got your point. Your concerned with the case where a userland
> application, say, crashes and the battery is left for overcharging and
> overheating.

Yes, exactly - there's a real danger of catastrophic system failure if
that happens.

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Felipe Balbi]

Hi,

On Wed, Aug 12, 2009 at 11:05:17AM +0100, Mark Brown wrote:
> You actually get notification on any change the supply chooses to notify
> the core on IIRC.

true, but that's only (at least on the chips I've seen) for the presence
of the charger. I haven't seen a chip that notify you based on a
threshold of e.g. voltage change or temperature change. Which would be a
really nice feature: you could give a "best" temperature value and a
threshold of +-10% and if that changes over that limit, device
interrupts processor, or something like that.

> I'd be inclined to put at least some of the basic charge cycle into the
> kernel but it doesn't concern me too much so long as the user/kernel
> interface doesn't expose us to the risk of damaging the battery through
> inattention.

sounds reasonable.

> It's probably more interesting to think of prioritising between multiple
> batteries here - most systems I've seen have power path management which
> handles all the incoming power sources and uses them to maintain an
> unregulated power domain which is then used as the root supply for the
> rest of the system, including the battery chargers.  This takes the
> supply selection well out of the domain of charging.

sounds really good. Haven't a system like that so far :-(

> This is the really tricky bit since you need some idea of the load from
> the rest of the system if the charger really is able to draw current.
> Normally there's a combination of checking various gates to see if it's
> possible to start charging with the current parameters and then things
> like monitoring the supply voltage to the charger to make sure it's not
> drooping and taking corrective action if it does.
> 
> My feeling is that in addition to what you're saying the in-kernel side
> of things should also describe how the system is wired together since
> that's the sort of task the kernel is doing anyway, it's something
> that is fixed in the hardware and it's potentially dangerous to get
> wrong.

agree with you here.

> Assuming the charger also has things like voltage and current control
> exposed.  I think I'd expect to see some sort of charger class which
> abstracts out the functionality of the charger so that the same user
> applications can also be used to set policy for more autonomous
> chargers.  Those chargers may require contortions to fit them into the
> regulator API depending on the control they provide to the system.  More
> simple chargers may well fit cleanly into the regulator API (they're
> regulators after all) but that'd be just one example of this class.
> 
> Quite how much I'd expect such a soft charger to be able to do for
> itself I'm less sure about but I'd be inclined to at least look at doing
> the stuff that can be done with only information from the battery in
> kernel to make things more consistent for user space.

makes sense.

> Yes, exactly - there's a real danger of catastrophic system failure if
> that happens.

sure there is.

I believe we're reaching some conclusions here. I'll think over your
thoughts and try to get more time to read the specs over the weekend (so
much work during the week, sigh). Then let's see what could be done so
we have a good design for a charger api in kernel.

-- 
balbi

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Wed, Aug 12, 2009 at 10:07:03PM +0300, Felipe Balbi wrote:
> On Wed, Aug 12, 2009 at 11:05:17AM +0100, Mark Brown wrote:

> > You actually get notification on any change the supply chooses to notify
> > the core on IIRC.

> true, but that's only (at least on the chips I've seen) for the presence
> of the charger. I haven't seen a chip that notify you based on a
> threshold of e.g. voltage change or temperature change. Which would be a
> really nice feature: you could give a "best" temperature value and a
> threshold of +-10% and if that changes over that limit, device
> interrupts processor, or something like that.

If a chip has a generic AUX ADC (of the sort used for voltage
monitoring) it'll quite often also have some comparator functionality to
go along with it, normally configurable.

Re: Question about userspace-consumer

[Pavel Machek]

Hi!

> On Mon, Aug 10, 2009 at 10:58:01PM +0100, Mark Brown wrote:
> > On Mon, Aug 10, 2009 at 11:05:54PM +0300, Felipe Balbi wrote:
> > 
> > > I was reading userspace-consumer file ad was wondering whether would be
> > > possible to use that in order to implement what SBS-IF [1] proposes
> > > using sbs-enabled devices.
> > 
> > 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
> 
> 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.

As battery charging is done by hw on many common machines... yes it is
okay to do in kernel.

> > Like I say, from a quick read through of the specs I'm not sure that I'd
> > push this into user space but I've not thought about this deeply and may
> > be missing something.
> 
> I think kernel should, as long as possible, only provide functionalities
> for userland to take decisions and actions, no ?
> 
> Handling policy in kernel space I find it a little odd, specially
> because different manufacturers might have different charging algorithms
> they want to implement.

I don't see what policy you see in battery charging. There is
 basically single battery chemistry in use, so this is not as complex
 as you paint it...

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Pavel Machek]

Hi!

> > and wrt SBS, that would mean basically writing a driver for that Smart
> > Batery Charger and the Smart Battery devices creating means for some
> > entity to tell _start_charging_ based on the presence of a power source.
> 
> For me the critical thing is that we ensure that the charger won't be
> left charging at anything more than a trickle charge when there's
> nothing monitoring the battery status.  If the charger can do the SBS
> charger stuff autononmously it can look after itself (but the use of the
> regulator API becomes more questionable for those devices since the
> charger will be doing all the management of the regulators).  If the SBS
> is done entirely in software the kernel at least needs to be able to
> notice the management software exiting and clean up after it, even if
> that's all it is able to do for itself.

Please don't put basic fastcharge logic to userspace:

* you still want to fastcharge at init=/bin/bash boot

* you want to fastcharge while machine is in s2ram. See spitz. Doing
  that with userspace would be quite tricky.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Fri, Aug 14, 2009 at 06:32:01PM +0200, Pavel Machek wrote:

> Please don't put basic fastcharge logic to userspace:

> * you still want to fastcharge at init=/bin/bash boot

> * you want to fastcharge while machine is in s2ram. See spitz. Doing
>   that with userspace would be quite tricky.

Depending on the technologies involved and how well integrated the power
path management is with the battery charger fast charge during suspend
may not actually be desirable.  Some systems need or desire active
thermal management of the system from the CPU during fast charge.

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Pavel Machek]

On Sat 2009-08-15 17:43:24, Mark Brown wrote:
> On Fri, Aug 14, 2009 at 06:32:01PM +0200, Pavel Machek wrote:
> 
> > Please don't put basic fastcharge logic to userspace:
> 
> > * you still want to fastcharge at init=/bin/bash boot
> 
> > * you want to fastcharge while machine is in s2ram. See spitz. Doing
> >   that with userspace would be quite tricky.
> 
> Depending on the technologies involved and how well integrated the power
> path management is with the battery charger fast charge during suspend
> may not actually be desirable.  Some systems need or desire active
> thermal management of the system from the CPU during fast charge.

Do you have example of some system?

Ok, well... anyway many machines _want_ fastcharge while suspended,
and putting charging into userland would break them (or make that
fairly difficult).
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Sun, Aug 16, 2009 at 12:34:34AM +0200, Pavel Machek wrote:
> On Sat 2009-08-15 17:43:24, Mark Brown wrote:

> > > * you want to fastcharge while machine is in s2ram. See spitz. Doing
> > >   that with userspace would be quite tricky.

> > Depending on the technologies involved and how well integrated the power
> > path management is with the battery charger fast charge during suspend
> > may not actually be desirable.  Some systems need or desire active
> > thermal management of the system from the CPU during fast charge.

> Do you have example of some system?

I don't know why any of these are charging while active but things like
the Nokia internet tablets and the smartphones I've used recently all
keep the phone active while charging.  Quite a few PMICs will refuse to
charge when suspended.

> Ok, well... anyway many machines _want_ fastcharge while suspended,
> and putting charging into userland would break them (or make that
> fairly difficult).

Are you sure that's a real need?  Disabling user interaction I can see
but forcing the system into sleep doesn't seem to be any particular
benefit - devices like this tend to be designed to appear to be always
on and clearly when fast charging there's no need to save power which is
the main motiviation for going into suspend.  Also bear in mind that a
soft SBS system requires constant activity from the CPU for basic
management of the charge cycle so suspend isn't going to be a real
option anyway, you'd be suspending for seconds at a time.

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Pavel Machek]

On Sat 2009-08-22 11:16:42, Mark Brown wrote:
> On Sat, Aug 22, 2009 at 11:28:45AM +0200, Pavel Machek wrote:
> 
> > At least zaurus sl-3000c is designed like a notebook -- inactive in
> > s2ram. It is quite old design.
> 
> > Charging while suspended is preffered, because it allows faster
> > charge. The machine eats non-trivial power while active, charger is
> > only 1A, and there's not enough current left for a charge with machine
> > active.
> 
> Like you say this is a very old design but even there I'm fairly
> surprised it's causing issues when charging from a wall supply.  If
> you're charging from USB then there is obviously a constraint on the
> power draw but normally a modern system has sufficiently low power draw
> when idle that it's not actually a big deal - runtime power management
> facilities have improved greatly.

Well... all the hardware I have here (zaurus, openmoko, htc dream) has
issues with power consumption while charging... so I do not think
runtime pm is solved problem.

> There's also the fact that if you're completely reliant on the CPU to
> control the charger you have to be very sure that the system will come
> back from suspend reliably due to the risk of hardware damage.  The
> hardware should have safety features to prevent serious problems but
> it's a consideration.

While crashes during suspend/resume are common on pcs, embedded
systens do better. And crashes during runtime happen, too.

First, I can't imagine system where you can damage the battery by just
crashing sw. 4.2 per cell voltage limit is just too easy to do in
hw. Maybe if you crash the sw then bring the machine outside while its
stil on charger and theres 110F outside...

And yes it should have safety features, and if they are not there its
broken hw.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Pavel Machek]

Hi!

> > Ok, well... anyway many machines _want_ fastcharge while suspended,
> > and putting charging into userland would break them (or make that
> > fairly difficult).
> 
> Are you sure that's a real need?  Disabling user interaction I can see
> but forcing the system into sleep doesn't seem to be any particular
> benefit - devices like this tend to be designed to appear to be always
> on and clearly when fast charging there's no need to save power
> > which is

At least zaurus sl-3000c is designed like a notebook -- inactive in
s2ram. It is quite old design.

Charging while suspended is preffered, because it allows faster
charge. The machine eats non-trivial power while active, charger is
only 1A, and there's not enough current left for a charge with machine
active.

> the main motiviation for going into suspend.  Also bear in mind that a
> soft SBS system requires constant activity from the CPU for basic
> management of the charge cycle so suspend isn't going to be a real
> option anyway, you'd be suspending for seconds at a time.

Well, if the code is to be useful for something else than SBS... (And
suspending for seconds at a time is okay on zaurus type machines).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Sat, Aug 22, 2009 at 11:28:45AM +0200, Pavel Machek wrote:

> At least zaurus sl-3000c is designed like a notebook -- inactive in
> s2ram. It is quite old design.

> Charging while suspended is preffered, because it allows faster
> charge. The machine eats non-trivial power while active, charger is
> only 1A, and there's not enough current left for a charge with machine
> active.

Like you say this is a very old design but even there I'm fairly
surprised it's causing issues when charging from a wall supply.  If
you're charging from USB then there is obviously a constraint on the
power draw but normally a modern system has sufficiently low power draw
when idle that it's not actually a big deal - runtime power management
facilities have improved greatly.

Some integrated PMICs will even refuse to do a fast charge when the
system is fully suspended, if only because the suspend mode of the PMIC
is intended to drive the power consumption from the PMIC itself down to
the very lowest level possible.

> > the main motiviation for going into suspend.  Also bear in mind that a
> > soft SBS system requires constant activity from the CPU for basic
> > management of the charge cycle so suspend isn't going to be a real
> > option anyway, you'd be suspending for seconds at a time.

> Well, if the code is to be useful for something else than SBS... (And
> suspending for seconds at a time is okay on zaurus type machines).

It's not too bad but it's not great either - without the ability to do
things like per-device suspend during runtime (which I see is coming
along but it's not there yet) some systems end up spending a lot of the
time on bouncing the power.

There's also the fact that if you're completely reliant on the CPU to
control the charger you have to be very sure that the system will come
back from suspend reliably due to the risk of hardware damage.  The
hardware should have safety features to prevent serious problems but
it's a consideration.

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Fri, Aug 21, 2009 at 04:01:26PM +0200, Pavel Machek wrote:
> On Sat 2009-08-22 11:16:42, Mark Brown wrote:

> > Like you say this is a very old design but even there I'm fairly
> > surprised it's causing issues when charging from a wall supply.  If
> > you're charging from USB then there is obviously a constraint on the
> > power draw but normally a modern system has sufficiently low power draw
> > when idle that it's not actually a big deal - runtime power management
> > facilities have improved greatly.

> Well... all the hardware I have here (zaurus, openmoko, htc dream) has
> issues with power consumption while charging... so I do not think
> runtime pm is solved problem.

The Zaurus and OpenMoko aren't exactly modern designs.  The Dream does
surprise me, though.  I can't find any references to issues with this -
any pointers?  If the phone were actually in use I'd expect it to have
trouble charging off USB but sitting idle it's a lot more surprising,
especially running Android.

> While crashes during suspend/resume are common on pcs, embedded
> systens do better. And crashes during runtime happen, too.

Not really; the situation is similar in both cases - if your hardware is
well supported then everything will generally run smoothly.  If your
hardware is not so well supported then things get more interesting.
It's probably fair to say that it's easier to fix embedded systems that
don't work (and as a result to find existing ones that work well) but
it's not massively different, especially if you're working with things
like reference hardware for new devices.

> First, I can't imagine system where you can damage the battery by just
> crashing sw. 4.2 per cell voltage limit is just too easy to do in
> hw. Maybe if you crash the sw then bring the machine outside while its
> stil on charger and theres 110F outside...

Remember that the goal here is to pull the charging algorithm out of the
charger where it currently is and base it on data supplied by the
battery instead.  If SBS is implemented in software it's not clear that
the charger is going to be able to do anything for itself except
possibly shut off if it or the battery goes over temperature (since SBS
does require NTC those should both be possible).

> And yes it should have safety features, and if they are not there its
> broken hw.

That's not unambiguously clear.  Even with current charger designs some
of the safety comes from appropriate configuration being provided to the
hardware by software - things like the maximum charging current which
the design can sustain.  The unavoidable safety limits provided by the
components tend to be high and while they should prevent catastrophic
issues you normally don't want to be relying on them during normal
operation.

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Pavel Machek]

Hi!

> > > Like you say this is a very old design but even there I'm fairly
> > > surprised it's causing issues when charging from a wall supply.  If
> > > you're charging from USB then there is obviously a constraint on the
> > > power draw but normally a modern system has sufficiently low power draw
> > > when idle that it's not actually a big deal - runtime power management
> > > facilities have improved greatly.
> 
> > Well... all the hardware I have here (zaurus, openmoko, htc dream) has
> > issues with power consumption while charging... so I do not think
> > runtime pm is solved problem.
> 
> The Zaurus and OpenMoko aren't exactly modern designs.  The Dream does
> surprise me, though.  I can't find any references to issues with this -
> any pointers?  If the phone were actually in use I'd expect it to have
> trouble charging off USB but sitting idle it's a lot more surprising,
> especially running Android.

Well, I'd like the older designs to work well too. (Actually, the
Dream... was on wifi when I got bad problems charging it from
usb.... so maybe charging while suspended would not help there).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Smart Battery System Design (was: Re: Question about userspace-consumer)

[Mark Brown]

On Sat, Aug 22, 2009 at 09:35:15PM +0200, Pavel Machek wrote:

> Well, I'd like the older designs to work well too. (Actually, the

There's not likely to be implementing things like SBS, though.

> Dream... was on wifi when I got bad problems charging it from
> usb.... so maybe charging while suspended would not help there).

Radios are one of the biggest consumers of power, especially when
transmitting, 3G being particularly bad.  If the phone was sitting idle
it should've been fine but if it's actually using the WiFi I'd expect
that to slow down the charge.