[UPSTREAM 0/2] pcf50633 changes

Balaji Rao balajirrao at openmoko.org
Mon Nov 17 07:36:22 CET 2008

On Sun, Nov 16, 2008 at 06:50:45PM -0200, Werner Almesberger wrote:
> Balaji Rao wrote:
> > Here's a pcf50633 driver rewrite to use the MFD model. This has resulted
> > in pretty large number of changes. 
> Whoa, great stuff ! A few quick first comments:
> > [ Warning : This is long :) ]
> There's one major item missing:
> 0. Monolithic monstrosity broken down into comprehensible components.
> > 2. Charger detection code now moved into mach-gta02.c.
> By the way, I think mach-gta02.c would make an excellent candidate
> for breaking down into components as well. Not only is it confusing
> to have code and definitions pertaining to a dozens different areas
> of the system interleaved with each other, but it's also a pain to
> maintain patches against mach-gta02.c, because you're pretty much
> guaranteed that something changes in the context patch catches with
> its peripheral vision, requiring manual intervention over and over
> again.

Yes, I completely agree. Cleaning up mach-gta02.c might be useful even
if it's not targeted upstream right away.

> > 4. Emergency 8s shutdown has been temporarily removed from the driver
> > as it certainly does not belong there.
> What's the plan for this one ? Lots of people seem to feel a strong
> emotionally attachment to having the equivalent of ctrl-alt-del :)
Might be reasonable to implement it in the driver. We need a better way
of signalling an emergency shutdown.

> > 5. 'Suppress onkey events on resume' - must be a better way to handle
> > this. Can't it be done from userspace ?
> It seems that whoever has initiated the suspend should also take care
> of the consequences, yes. This is only about user space, not the
> hang-on-resume Matt has fixed recently, right ?

Hmm.. I dunno. Currently we call our IRQ worker when we resume to
clear any pending interrupts and renable them. Instead we could read
those interrupt registers directly from within resume itself. That way
we don't have to be explicit that we are suppressing onkey events at all.

	- Balaji

More information about the openmoko-kernel mailing list