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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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 <[hidden email]>
---
 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) {
--
1.7.10


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Thomas Munker
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



Am 26.11.2013 12:22, schrieb 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 <[hidden email]>
> ---
>  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!
GnuPG: http://www.gpg4win.de/ + Thunderbird:
https://www.mozilla.org/de/thunderbird/
 + Enigmail AddOn
Android: K9 Mail + APG

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martin Jansa
On Thu, Nov 28, 2013 at 01:16:01PM +0100, Thamos wrote:
> 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 :/.

>
> Thamos
>
>
>
> Am 26.11.2013 12:22, schrieb 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 <[hidden email]>
> > ---
> >  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!
> GnuPG: http://www.gpg4win.de/ + Thunderbird:
> https://www.mozilla.org/de/thunderbird/
>  + Enigmail AddOn
> Android: K9 Mail + APG
>
--
Martin 'JaMa' Jansa     jabber: [hidden email]

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Paul Fertser
In reply to this post by Thomas Munker
Hi,

Thamos <[hidden email]> writes:
> 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).

> 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.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martin Jansa
On Thu, Nov 28, 2013 at 06:28:53PM +0400, Paul Fertser wrote:

> Hi,
>
> Thamos <[hidden email]> writes:
> > 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).
>
> > 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).

--
Martin 'JaMa' Jansa     jabber: [hidden email]

signature.asc (205 bytes) Download Attachment
Loading...