Neo Freerunner PMU Status

[Harald Welte]

On Fri, Feb 08, 2008 at 09:53:06AM +0000, Andy Green wrote:
> 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.

Please make sure somebody pushes this observation up to OM's excellent
nxp PMU contacts in the netherlands (don't go through the FAE).  Werner
knows the contacts, Sean too.

> 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'.

The 'monster' comment was referring to the many different things that
all happen in one driver.  It was actually put in the pcf50606 driver
when I originally wrote it.    Now given the nature of the complexity of
those PMU's, the amount of functionality is not going to get any
smaller.  I'd probably split parts into separate files if the code is
getting too long, but that's a pure source code reorganization thing.

With regard to #ifdef's: They are nice temporary hacks.  If something
like you've described above is really neccessarry, then a proper
abstraction interface via platform_data or maybe a notifier_chain should
be implemented, breaking the board (Gta02) dependent code out of that
driver.

Cheers,
-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone