Am Di 21. April 2009 schrieb Paul Fertser: > Joerg Reisenweber <[email protected]> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
