preparing pcf50633 for upstream

Balaji Rao balaji at
Wed Oct 1 21:16:20 CEST 2008

On Wed, 1 Oct 2008 15:59:36 -0300
Werner Almesberger <werner at> wrote:

> Balaji Rao wrote:
> > I've managed to eliminate pcf50633_global and thus removed the
> > "one-device" restriction.
> Great !
> > With that, the apm emulation code - apm_get_battery_status has to be
> > moved out. I think mach-gta02.c is a good place. What do you say ?
> It actually looks pretty platform-agnostic. The only slight platform
> dependency is in it considering USB and adapter power both to be AC.

Yes. But it needs a reference to pcf50633_global. Hence I thought it
needs to go into mach-gta02.c. I've commented it out for now. 

> The other issue is that APM seems to assume a single power supply
> while we could have multiple here. But I think the existing
> mechanism of enabling this only if the platforms sets
> flag_use_apm_emulation is good enough.
> All the calls to apm_queue_event would have to go through a function
> that tests for this, though. (Well, that's easy.) And anything apm_*
> should probably depend on CONFIG_APM_EMULATION, so that PCF50633
> can be compiled without it.
> However, I echo Sean's question: do we really need that APM stuff ?
> I don't know enough about the evolution of the power supply
> user-space interfaces to tell whether it's something that still
> makes sense or not.
> On my laptops, it's been years since I last felt the need to have
> anything that looked like APM, so it always puzzled me a little
> why we had that seemingly obsolete thing in Openmoko.
> So, two questions:
> 1) is APM emulation something new code should use at all ?
> 2) would user space developers cry bitter tears if we removed it ?

Let's see what others have to say. I don't have much idea of APM either.

	- Balaji Rao

More information about the openmoko-kernel mailing list