[SHR-Unstable] Forcing fast-charge

[Joerg Reisenweber]

Am Di  21. April 2009 schrieb Paul Fertser:
> Joerg Reisenweber <joerg at openmoko.org> writes:
> > Am So  19. April 2009 schrieb Rask Ingemann Lambertsen:
> >> On Sat, Apr 18, 2009 at 05:11:36PM -0700, Mike Montour wrote:
> >> > chg_curlim controls the battery charger, while usb_curlim controls the 
> >> > total current that can be drawn from the USB port (charging + the 
> >> > current used by the Freerunner).
> >> 
> >>    Note that whenever you set usb_curlim (directly or indirectly by
> >> plugging in power), chg_curlim is set to the new value of usb_curlim.
> >
> > where do you find this info? I've checked shortly and e.g. 8.12.6.2 
doesn't 
> > mention this relation. Maybe I didn't realize the important part?
> 
> drivers/power/pcf50633-charger.c:
> 
> /*
> * We limit the charging current to be the USB current limit.
> * The reason is that on pcf50633, when it enters PMU Standby mode,
> * which it does when the device goes "off", the USB current limit
> * reverts to the variant default.  In at least one common case, that
> * default is 500mA.  By setting the charging current to be the same
> * as the USB limit we set here before PMU standby, we enforce it only
> * using the correct amount of current even when the USB current limit
> * gets reset to the wrong thing
> */     

Whoever wrote this amazingly puzzling comment, I think he got something 
severely wrong with operating principles of PMU PCF50633.
Datasheet of PMU clearly states there's no situation whatever that could 
result in batcharge current overloading the USB_CURLIM, as *allways* there 
will be priority on serving system by providing up to 100% of usb current to 
power it. Bat charge will get whatever might remain after that, *up_to* the 
charging limit programmed into PMU.
As we may charge our battery with 1C (=1200mA) it's perfectly safe to set bat 
chg curlim to that value, and rely on PMU managing distribution of actual USB 
supply current to system and charging according to the momentary needs.

There have been issues regarding some glitch resulting in a very short 
brownout on Vsys when *enabling* batcharge, but I don't think it's covered by 
the explanation above, and anyway afaik this has been fixed with various 
uBoot-patches and modifying the Vsys-buffering C (no boot on flat bat issue)

See my previous shorter post in this thread

cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/community/attachments/20090425/be299a0b/attachment.pgp