[PATCH] omap3: pm: Downgrade WARN for no wakeup source

STALE5563d

2 messages, 2 authors, 2011-06-16 · open the first message on its own page

[PATCH] omap3: pm: Downgrade WARN for no wakeup source

From: Kevin Hilman <hidden>
Date: 2011-06-16 18:25:15

"Premi, Sanjeev" [off-list ref] writes:
quoted
-----Original Message-----
From: Hilman, Kevin 
Sent: Thursday, June 16, 2011 8:52 PM
To: Premi, Sanjeev
Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source

Hi Sanjeev,

Sanjeev Premi [off-list ref] writes:
quoted
When multiple wakeup sources are defined in a system,
there is a small window, when more than one source
can trigger wakeup interrupt.

In the current implementation, the do-while() loop
can handle all wakeup sources that are recorded when
probing the status register in prcm_interrupt_handler().

When the ISR executes due to next queued wakeup, it
there is nothing to be handled and value of "c" is 0.
Thanks for tracking this one down.

However, It's still not clear to me what is happening here.

Why is the IRQ firing if there is nothing to be handled?  
That suggests
to me that the IRQ status is not properly being cleared.
[SP] On the contrary the IRQ status is actually getting cleared,
     but there are more than "1" PRCM interrupts queued.

     The do-while() clears all the interrupt sources that
     are flagged in the status register.

     When the next wakeup interrupt is getting processed, the
     status register doesn't contain any "source" to handle.
Still confused.

If a wakeup interrupt is fired, it was caused by something.  

IOW, if "the status register doesn't contain any source",  how is

		if (irqstatus_mpu & (OMAP3430_WKUP_ST_MASK |
				     OMAP3430_IO_ST_MASK)) 

ever true?

Kevin

[PATCH] omap3: pm: Downgrade WARN for no wakeup source

From: Premi, Sanjeev <hidden>
Date: 2011-06-16 20:16:36

-----Original Message-----
From: Hilman, Kevin 
Sent: Thursday, June 16, 2011 11:55 PM
To: Premi, Sanjeev
Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source

"Premi, Sanjeev" [off-list ref] writes:
quoted
quoted
-----Original Message-----
From: Hilman, Kevin 
Sent: Thursday, June 16, 2011 8:52 PM
To: Premi, Sanjeev
Cc: linux-omap at vger.kernel.org; 
linux-arm-kernel at lists.infradead.org
quoted
quoted
Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source

Hi Sanjeev,

Sanjeev Premi [off-list ref] writes:
quoted
When multiple wakeup sources are defined in a system,
there is a small window, when more than one source
can trigger wakeup interrupt.

In the current implementation, the do-while() loop
can handle all wakeup sources that are recorded when
probing the status register in prcm_interrupt_handler().

When the ISR executes due to next queued wakeup, it
there is nothing to be handled and value of "c" is 0.
Thanks for tracking this one down.

However, It's still not clear to me what is happening here.

Why is the IRQ firing if there is nothing to be handled?  
That suggests
to me that the IRQ status is not properly being cleared.
[SP] On the contrary the IRQ status is actually getting cleared,
     but there are more than "1" PRCM interrupts queued.

     The do-while() clears all the interrupt sources that
     are flagged in the status register.

     When the next wakeup interrupt is getting processed, the
     status register doesn't contain any "source" to handle.
Still confused.

If a wakeup interrupt is fired, it was caused by something.  

IOW, if "the status register doesn't contain any source",  how is

		if (irqstatus_mpu & (OMAP3430_WKUP_ST_MASK |
				     OMAP3430_IO_ST_MASK)) 

ever true?
[sp] I had been hesitant to say "nesting" because the wakeup
     interrupts seem to be independent of each other. But now
     I think - from SW perspective, it should/could be considered
     as nesting.

~sanjeev
Kevin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help