Neo Freerunner PMU Status

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks -

The cap we added last time has resolved a bunch of troubles but I still
see bad behaviour in very specific circumstances.  Here is an update of
the situation for me today (which is still getting beat on).

 - First, with a battery in, the power situation is very stable with the
last patches and charging happens fine, smart battery is supported, etc.
 It really starts to feel like a solid device that isn't going to do
unexpected things on power -- and that is a good feeling.  I didn't have
to qualify that yet, it is working good as far as I saw.

 - I made changes to the pcf50633 driver to support async ADC, now it
knows if the 1A charger is in reliably

 - But if you remove the battery and run on USB power, there are two bad
ways it uh... "detects" you did that.

 1) I cannot mount the rootfs if no battery is in (insane but totally
repeatable) - this is the failure to fork the GC --> unable to parse the
FS.  I will start looking at that code today to come at it from that
end.  How the GC fork action becomes a "battery inserted" detector I
will be very interested to discover -- if I can.

 2) If I enable the charger during boot with no battery in, the charger
selfcontained MBC state machine decides to provide charge - after a
while examining the current flowing -- nothing -- it decides to stop
charging.  At that moment something bad happens.  The attached pictures
show VB (yellow) and VB_SYS (blue): #14 is with a 10uF cap on VB_SYS and
#15 is with a 47uF cap on VB_SYS.

Basically the MBC decides to power itself from the nonexistant battery
for a period, leading to death on VB_SYS and then everywhere else.  The
overall effect is --> "off" partway through boot.  It isn't a matter of
increasing VB_SYS cap, it has pulled power for a long period.

I think I can work around it by ensuring charger disable if battery
absent, but I have to detect battery absent by using HDQ.  Now that
pcf50633 driver already has GTA02 #ifdefs in it and is described in a
comment at the top by a previous sufferer "this driver is a monster
<smiley face>".  No it really is a monster, no smiley face!  If that
workaround works, we further stunk up that driver with dependencies on
HDQ.  Just sayin'.

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

iD8DBQFHrCaCOjLpvpq7dMoRAvfeAJ95jBfXjngmsND58TPEmzapN8CgIgCfb3c8
xepJ2nIlU6ZK+2QQVZOY6Q0=
=k9FB
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f0014tek.jpg
Type: image/jpeg
Size: 94923 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080208/7a94270a/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f0015tek.jpg
Type: image/jpeg
Size: 94451 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080208/7a94270a/attachment-0001.jpg