Re: Suspending with keypad bug (RFC)

[Tony Lindgren <tony@atomide.com>]

* andrzej zaborowski <balrog@zabor.org> [060810 07:56]:
> On 06/08/06, Juha Yrjölä <juha.yrjola@solidboot.com> wrote:
> >andrzej zaborowski wrote:
> >
> >> I came up with a different fix, in the keypad driver but it's a bit
> >> more intrusive. With this the device sleeps peacefully until another
> >> key-press is detected. What should be the correct behavior?
> >> I'm attaching both changes.
> >
> >This approach is better; the generic PM code should not have to care
> >that much about different wakeup sources.
> >
> >I'm not exactly sure in which state the system is when the suspend
> >function is called.  Can there still be timer activity, for example?
> 
> I think yes, some suspend functions may rely on timers because they
> are not obliged to return immdiately.
> 
> >Nevertheless, you're safer doing a spin_lock_irqsave() in the suspend
> >function first, and releasing the lock only after setting the suspended
> >variable and re-enabling the interrupt.
> >
> >You should also check whether you're actually running on OMAP1 before
> >you write to the register.
> >
> >In the IRQ handler, you should also do a spin_lock_irqsave() before
> >accessing the suspended variable.
> 
> Thanks for help! I'm attaching the corrected version, it works nicely.
> 
> In the irq handler I release the lock just after accessing the
> "suspended" variable because as I understand an irq handler will never
> be interrupted by something that calls the suspend function.

Can you please repost with proper comments and Signed-off-by?

Thanks,

Tony