Message-ID: <20090811223645.GA4691@sirena.org.uk>
Date:	Tue, 11 Aug 2009 23:36:46 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Felipe Balbi <me@...ipebalbi.com>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>,
	Mike Rapoport <mike@...pulab.co.il>,
	linux-kernel@...r.kernel.org
Subject: Re: Smart Battery System Design (was: Re: Question about
 userspace-consumer)

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists