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 <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone
