[PATCH][FOR-2.6.39.4][SHR] s3c24xx: ACK the external interrupt source when no handler is available

[Paul Fertser]

The 2.6.39.4 version running on gta02 is sometimes (~0.5 - 4%) getting
stuck on resume. The inspection showed that it constantly reenters
s3c_irq_demux_extint8() but since all the external interrupts are
masked at that time, no downstream handler is called. As the result,
the corresponding SRCPND bit is never cleared and the handler reenters
right after exiting.

Even though the cause for external interrupts being masked while
there's a pending request present are still unclear, this patch seems
to be doing the right thing (at least for that old kernel version). My
device is running continious suspend/resume test for ~15 hours now
(while it used to hang in less than 30 minutes of the same test
before).

Thanks go to lindi- and gena2x for providing me with an openmoko debug
board.

Signed-off-by: Paul Fertser <***@gmail.com>
---
arch/arm/plat-s3c24xx/irq.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/plat-s3c24xx/irq.c
index 1317f04..0bcaccb 100644
--- a/arch/arm/plat-s3c24xx/irq.c
+++ b/arch/arm/plat-s3c24xx/irq.c
@@ -484,6 +484,11 @@ s3c_irq_demux_extint8(unsigned int irq,
eintpnd &= ~eintmsk;
eintpnd &= ~0xff; /* ignore lower irqs */

+ /* in case no IRQ is pending but we got here we still
+ must ack the parent or else we get an irq storm */
+ if (!eintpnd)
+ s3c_irq_ack(irq_get_irq_data(IRQ_EINT8t23));
+
/* we may as well handle all the pending IRQs here */

while (eintpnd) {

[Thamos]

Hi,
great news, that somebody is working on these annoying resume bugs...
Is this patch flowing somewhere in (like shr-core-staging?), or do i
have to apply them manually and build my own kernel?
Thanks for your great work!

Thamos

Post by Paul Fertser
The 2.6.39.4 version running on gta02 is sometimes (~0.5 - 4%) getting
stuck on resume. The inspection showed that it constantly reenters
s3c_irq_demux_extint8() but since all the external interrupts are
masked at that time, no downstream handler is called. As the result,
the corresponding SRCPND bit is never cleared and the handler reenters
right after exiting.
Even though the cause for external interrupts being masked while
there's a pending request present are still unclear, this patch seems
to be doing the right thing (at least for that old kernel version). My
device is running continious suspend/resume test for ~15 hours now
(while it used to hang in less than 30 minutes of the same test
before).
Thanks go to lindi- and gena2x for providing me with an openmoko debug
board.
---
arch/arm/plat-s3c24xx/irq.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/plat-s3c24xx/irq.c
index 1317f04..0bcaccb 100644
--- a/arch/arm/plat-s3c24xx/irq.c
+++ b/arch/arm/plat-s3c24xx/irq.c
@@ -484,6 +484,11 @@ s3c_irq_demux_extint8(unsigned int irq,
eintpnd &= ~eintmsk;
eintpnd &= ~0xff; /* ignore lower irqs */
+ /* in case no IRQ is pending but we got here we still
+ must ack the parent or else we get an irq storm */
+ if (!eintpnd)
+ s3c_irq_ack(irq_get_irq_data(IRQ_EINT8t23));
+
/* we may as well handle all the pending IRQs here */
while (eintpnd) {

[Martin Jansa]

Post by Thamos
Hi,
great news, that somebody is working on these annoying resume bugs...
Is this patch flowing somewhere in (like shr-core-staging?), or do i
have to apply them manually and build my own kernel?
Thanks for your great work!

I plan to add both Paul's patches to next shr-core-staging, but don't
know when I'll find time to do it :/.

Post by Thamos
Thamos

Post by Paul Fertser
The 2.6.39.4 version running on gta02 is sometimes (~0.5 - 4%) getting
stuck on resume. The inspection showed that it constantly reenters
s3c_irq_demux_extint8() but since all the external interrupts are
masked at that time, no downstream handler is called. As the result,
the corresponding SRCPND bit is never cleared and the handler reenters
right after exiting.
Even though the cause for external interrupts being masked while
there's a pending request present are still unclear, this patch seems
to be doing the right thing (at least for that old kernel version). My
device is running continious suspend/resume test for ~15 hours now
(while it used to hang in less than 30 minutes of the same test
before).
Thanks go to lindi- and gena2x for providing me with an openmoko debug
board.
---
arch/arm/plat-s3c24xx/irq.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/plat-s3c24xx/irq.c
index 1317f04..0bcaccb 100644
--- a/arch/arm/plat-s3c24xx/irq.c
+++ b/arch/arm/plat-s3c24xx/irq.c
@@ -484,6 +484,11 @@ s3c_irq_demux_extint8(unsigned int irq,
eintpnd &= ~eintmsk;
eintpnd &= ~0xff; /* ignore lower irqs */
+ /* in case no IRQ is pending but we got here we still
+ must ack the parent or else we get an irq storm */
+ if (!eintpnd)
+ s3c_irq_ack(irq_get_irq_data(IRQ_EINT8t23));
+
/* we may as well handle all the pending IRQs here */
while (eintpnd) {

--
eMails sind wie Postkarten -> deshalb verschlüsseln!
https://www.mozilla.org/de/thunderbird/
+ Enigmail AddOn
Android: K9 Mail + APG

[Paul Fertser]

Hi,

Post by Thamos
great news, that somebody is working on these annoying resume bugs...

That was too annoying for me so I had no choice but try to fix it at
least somehow (as apparently nobody else was going to do that).

Post by Thamos
Is this patch flowing somewhere in (like shr-core-staging?), or do i
have to apply them manually and build my own kernel?

The ar6000 patch will hopefully be picked up by JaMa soon. But the
resume fix makes no sense for SHR now since they're moving to 3.2 as
they need systemd compatibility. I'm not sure if I want to upgrade from
2.6.39 to 3.2 as 3.2 is still too old for my liking (I'd wish to be
close to upstream to be able to contribute) and newer kernels seem to be
neither actively developed nor tested. Since I do not feel like working
all alone I'm going to stick with whatever works for me with Debian.

[Martin Jansa]

Post by Paul Fertser
Hi,

Post by Thamos
great news, that somebody is working on these annoying resume bugs...

That was too annoying for me so I had no choice but try to fix it at
least somehow (as apparently nobody else was going to do that).

Post by Thamos
Is this patch flowing somewhere in (like shr-core-staging?), or do i
have to apply them manually and build my own kernel?

The ar6000 patch will hopefully be picked up by JaMa soon. But the
resume fix makes no sense for SHR now since they're moving to 3.2 as
they need systemd compatibility. I'm not sure if I want to upgrade from
2.6.39 to 3.2 as 3.2 is still too old for my liking (I'd wish to be
close to upstream to be able to contribute) and newer kernels seem to be
neither actively developed nor tested. Since I do not feel like working
all alone I'm going to stick with whatever works for me with Debian.

SHR is moving to 3.2 only in master branch (some future release),
current builds are from "dora" branches and still use 2.6.39 and
downgraded systemd.

So both patches do apply for SHR and will be applied in shr-core-staging
soon(ish).