[PATCH 1/1] uboot-pcf50633-default-curr-lim-1A.patch

Andy Green andy at openmoko.com
Thu Feb 21 00:21:51 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

>> 1) Stop PMU killing us if we don't have a battery in (by setting default
>>     current limit to 1A)

> that this code is _never_ put onto any production / 'sold' devices.  You
> cannot draw more than 100mA from USB without being configured by the

Well, it's a good point, but currently we pull more than 100mA just
waking up from the USB-no-battery case in order to make a negotiation
for > 100mA... er...

Later thismorning I will try to remove the default 1A, I put it in
because the solution was explained to me in those specific terms and I
confirmed first it made the "death with no battery" behaviour go away.
But if we do the second part of the action, "charger" detect quickly,
maybe it is not needed, since it didn't kill us until some time after
boot started.

> host.  Even in the latter case, you can only draw up to 500mA, since
> this is the maximum current requirement that your config descriptor can
> indicate.

Hum well shortly afterwards in the boot process we correct it to the
level appropriate for the "charger" installed.  Is there a better
sequence of events?  Maybe we can perform more of a staged wakeup with
this limit in mind, but I don't think we have time to do it right now.

FWIW it does not trip the current limit on this laptop (as host) with or
without a battery, although that is probably not an exhaustive test :-)

> Yes, there actually are USB ports that don't supply more than 100mA.
> Among them are all bus-powered hubs, many OTG devices and small handheld
> devices with USB host.

Well then if I understood it we can't work with such things with the LCM
on... can we?  If these guys are jealous enough of their power they will
for sure have current limits enforced by a high-side switch on the host

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list