the root cause of flip-flop charging logic if you insert wall charger

matt_hsu matt_hsu at
Thu Sep 18 05:40:49 CEST 2008

Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> | Hi all,
> |
> | If you insert wall charger to charge Neo, you will find the charging
> | indication will be successful and failed one after another.
> I saw this when I did the overshoot analysis recently.  I was powering
> the device only from USB and not battery --  so I assumed the pcf50633
> was pushing the adapter into overcurrent briefly during power-on.  But -->
> | The root cause is the signal from VBUS rasies and drops rapidly when
> | inserting a wall charger.
> | You can see attached picture named defect_usbx_signal.jpg(The other
> | picture is a correct VBUS signal which makes correct charging indication).
> | In consequence, pcf50633 driver detects a USBINS and USBREM interrupts
> | in a schedule work.
> It sounds like you were already in Linux doing this,
>  so I wonder what is
> the excuse of the adapter now to drop dead briefly on insertion?
Hmm, initially, I thought the circuit around V_BUS is suspicious. But it
doesn't happen on every insertion.
Besides, I tried to insert with a USB host cable, the signal of V_BUS
behaves as normal.
The USB-to-SYS path is somehow odd to me. :(
> | Before this, I could apply this patch to provide correct charging logic.
> | Any thoughts?
> The effect of your patch is to ignore the case where we find insertion
> and removal flags both set, but actually, it's a sign that we have no
> idea what our USB insertion status is, it's literally "undefined".
True. It's worth to keep tracking on this issue. Since we might need to
face this kind problem on GTA03.

> I applied it on to stable, but really we need to do something a bit more
> complicated here and react to the sign that we have no certainty by
> going and looking at MBCS1.usbpres after some settling period.
> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> xxoAnAiJvF+ay0USapwI0iFCUB3gMYqy
> =83zJ

More information about the openmoko-kernel mailing list