| Message ID | 1308229940-27025-1-git-send-email-premi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Sanjeev, Sanjeev Premi <premi@ti.com> writes: > 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. Kevin
> -----Original Message----- > From: Hilman, Kevin > Sent: Thursday, June 16, 2011 8:52 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source > > Hi Sanjeev, > > Sanjeev Premi <premi@ti.com> writes: > > > 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. and value of "c" is returned as 0.... leading to the warning. ~sanjeev > > Kevin >
"Premi, Sanjeev" <premi@ti.com> writes: >> -----Original Message----- >> From: Hilman, Kevin >> Sent: Thursday, June 16, 2011 8:52 PM >> To: Premi, Sanjeev >> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org >> Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source >> >> Hi Sanjeev, >> >> Sanjeev Premi <premi@ti.com> writes: >> >> > 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
> -----Original Message----- > From: Hilman, Kevin > Sent: Thursday, June 16, 2011 11:55 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source > > "Premi, Sanjeev" <premi@ti.com> writes: > > >> -----Original Message----- > >> From: Hilman, Kevin > >> Sent: Thursday, June 16, 2011 8:52 PM > >> To: Premi, Sanjeev > >> Cc: linux-omap@vger.kernel.org; > linux-arm-kernel@lists.infradead.org > >> Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source > >> > >> Hi Sanjeev, > >> > >> Sanjeev Premi <premi@ti.com> writes: > >> > >> > 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 >
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index c155c9d..d24942b 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -289,11 +289,12 @@ static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id) c = _prcm_int_handle_wakeup(); /* - * Is the MPU PRCM interrupt handler racing with the - * IVA2 PRCM interrupt handler ? + * If multiple wakeup events get handled in certain + * execution through this do-while, value of "c" will + * be returned as 0. */ - WARN(c == 0, "prcm: WARNING: PRCM indicated MPU wakeup " - "but no wakeup sources are marked\n"); + if (c == 0) + pr_debug ("prcm: no more wakeup event to handle") ; } else { /* XXX we need to expand our PRCM interrupt handler */ WARN(1, "prcm: WARNING: PRCM interrupt received, but "
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. The comment in the code, attributing this behavior to race with IVA2 along with WARN (and associated text) makes this condition appear as an error condition - while it isn't. Though the problem was found in kernel version 2.6.32 running on AM3703 (no IVA2), it is still relevant. This patch also fixes the comment that attributes current behavior to race with interrupt handler on IVA2. Quoting specific instances, on entry into the ISR, the PM_WKST_WKUP read either 0x00010101 or 0x00010001 Where, Bit 0 : ST_GPT1 - GPTIMER wakeup occurred Bit 8 : ST_IO_EN - IO pad wakeup occurred Bit 16 : ST_IO_CHAIN - The I/O wake-up scheme is enabled This time value of "c" is 2 (or 3), but then on next and immediate entry, value of "c" is 0 leading to WARN(). Another approach I considered was to keep track of the number of wakeup sources handled in previous execution of ISR, but it fails when status register indicates 3 wakeup sources. Downgrading the WARN seemed to be the simplest solution. Signed-off-by: Sanjeev Premi <premi@ti.com> --- History: v1: Original RFC posted: http://marc.info/?l=linux-omap&m=130754890807333&w=2 arch/arm/mach-omap2/pm34xx.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)