[SHR-Unstable] Forcing fast-charge

[Joerg Reisenweber]

Am So  26. April 2009 schrieb Rask Ingemann Lambertsen:
> On Sat, Apr 25, 2009 at 01:16:17PM +0100, Joerg Reisenweber wrote:
> > Am Di  21. April 2009 schrieb Paul Fertser:
> > > 
> > > 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,
> 
>    The comment doesn't claim there is.
> 
> > as *allways* there 
> > will be priority on serving system by providing up to 100% of usb current 
to 
> > power it.
> 
>    Serving the system takes 0 mA in this particular case, because the device
> is off.
> 
> > Bat charge will get whatever might remain after that, *up_to* the 
> > charging limit programmed into PMU.
> 
>    Exactly.
> 
> > 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.
> 
>    The problem is not that of staying under the 1200 mA permitted for the
> battery. The problem is staying under the maximum USB current, which may be
> as little as 100 mA.  We just can't do anything about the USB current limit
> being reset to 500 mA, but we _can_ keep the charging current limited to 100
> mA, which is good enough when the only consumer is the the battery charger.

Good enough for *what*?
That's nonsense as there is no dumb charger out there not being capable of 
supplying 500mA. OTOH any management of maximum ingress current to USB by 
whatever means will inevitably fail when unplugging the charger device 
connected to FR during powerdown and replace it with a (nonexistent) weaker 
one.
Then another point to second this is: there are *lots* of silly usb gadgets 
out there that take up to 500mA without any negotiation at all (USB coffee 
mug warmers etc). Also please have a look at USB2.0 charger spec supplement.

we should use PCF50633 in the way it was designed, IMHO. Not care about 
constructed imaginary problem cases that are not to appear in real live. 
There is a reason NXP built this PMU-variant exactly this way though they 
could have done different. Actually there are different variants of PCF50633 
but OM couldn't source because the one we got now is used by other OEMs as 
well so we could get a small slice of the produced stock. I don't think those 
bigger customers of NXP specified nonsense when ordering this variant built 
by NXP to their needs.

baseline: switch USB_CURLIM to 100mA if and only if USB enum signalled host 
isn't capable of anything beyond. There's a reason FR is designed to 
resume/boot on USB insertion. It might be sensible to switch BATCHG_CURLIM to 
100mA on powerdown unconditionally, but it's mere braindead to manage 
batcharge in dependence of USB_CURLIM.

/j
-------------- 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/20090428/d5e31120/attachment.pgp