Re: APM issues

[Kristoffer E. <kri...@gm...>]

On Tue, 15 May 2007 08:26:41 +0900
Paul Mundt <le...@li...> wrote:

> On Mon, May 14, 2007 at 03:58:44PM -0700, Kristoffer Ericson wrote:
> > Bugtracking the hp6xx_apm functions and ran into some question marks. This
> > happend after the apm merger so its not a big suprise. Doesn't seem to be
> > many systems using apm in arch/sh though.
> > 
> Yes, we've started on the SH7722 work tying in to the clock framework,
> but not quite there yet. hp6xx is the only in-tree user of the code at
> the moment, so you get to run in to all of these problems before anyone
> else :-)
> 
> > Problems:
> > 1. Once powerbutton is hit IRQ 32 is generated and never stops
> >    Best approach? Clear request bit? But will that stop anything since a
> > new request will be created before the power button can be released.
> 
> Sounds like it's not acked and masked properly, start debugging the
> irq_chip handler that's got this IRQ.

I've read through the manual and perhaps its due to IRQ0->IRQ3 being set as edge instead of
level. It says in the manual that to clear edge interrupts one needs to  read corresponding bit from IRR0 (1) and then write 0. *shrug* best idea yet. It would explain why a single press would send out interrupts.

They should be set as edge by default, I've done some tests trying to set IRQ0 as level, but no boot. 


> 
> > 2. mutex_lock(&state_lock); from apm-emulation.c seems to freeze the
> > machine. adding a ifndef config_cpu_subsystem..
> >   makes it run abit longer. I noticed that the mutex lock wasn't in the
> > "old" version. Suggestions?
> 
> If it's freezing on a mutex_lock() it means it's blocked while trying to
> acquire the mutex, meaning someone got it beforehand and is never
> releasing it. Some of this could be related to your call path, I'd
> suggest turning on mutex debugging and lockdep and see if anything
> tumbles out.
> 
> > 3. Getting apm: apm queue event overflowed before it freezes (freezes
> > probably due to some mutex locks I've missed),
> >    this would indicate that more than one request is sent by the apm
> > interrupt handler?
> 
> That seems likely, and would also explain the mutex_lock() re-try before
> unlock. Debugging the interrupt handler first makes the most sense.
> 
> > 4. PM_DISK_FIRMWARE is removed, but im not sure if that will be an issue
> > since the pm is handled by board specific code which doesn't require
> > anything to be saved. It simply turns off all clocks besides tmu/rtc and
> > drops power to lcd/pcmcia. Ram shouldn't be cleared.
> > 
> This should not impact you at all, we were basically just abusing the
> definition of PM_DISK_FIRMWARE anyways. The current scheme should be more
> fundamentally correct.
> 
> > In short I need a good way for the interrupt handler to make sure only one
> > request is sent and someway to get rid off / fix the mutex_lock. It would
> > get ugly with alot of ifdefs but dont see any other solution currently.
> 
> If the IRQ is not being masked and acked, that's a serious bug, and one
> that needs to be corrected. It's not worth wasting any time trying to
> limit the number of requests it sends if it's constantly firing anyways
> (ie, you're never going to go to sleep with IRQs running wild).