All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH/RFC] rtc: rtc-twl: Fixed nested IRQ handling in resume from suspend
Date: Mon, 15 Sep 2014 02:41:45 +0300	[thread overview]
Message-ID: <3285590.DFfac97QLO@avalon> (raw)
In-Reply-To: <alpine.DEB.2.10.1409132108520.23397@nanos>

Hi Thomas,

On Saturday 13 September 2014 21:12:16 Thomas Gleixner wrote:
> On Sat, 13 Sep 2014, Laurent Pinchart wrote:
> > The TWL RTC interrupt is a double-nested threaded interrupt, handled
> > through the TWL SIH (Secondary Interrupt Handler) and PIH (Primary
> > Interrupt Handler).
> > 
> > When the system is woken up from suspend by a TWL RTC alarm interrupt,
> > the TWL PIH and SIH are enabled first (due to the normal IRQ enabling
> > sequence for the PIH and to the IRQF_EARLY_RESUME flag for the SIH)
> > before the TWL RTC interrupt gets enabled. This results on the interrupt
> > being processed by the TWL primary interrupt handler, forwarded to the
> > nested SIH, and then marked as pending for the RTC by handle_nested_irq
> > called from the SIH.
> > 
> > The RTC interrupt then eventually gets reenabled the kernel, which will
> > try to call its top half interrupt handler. As the interrupt is a nested
> > threaded IRQ, its primary handler has been set to the
> > irq_nested_primary_handler function, which is never supposed to be
> > called and generates a WARN_ON, without waking the IRQ thread up.
> > 
> > Fix this by setting the IRQF_EARLY_RESUME for the TWL RTC interrupt to
> > ensure it gets enabled before the parent handlers try to process it.
> > 
> > This is likely a bit of a hack, I have a feeling that a more generic
> > solution that would fix the problem for all nested threaded IRQs enabled
> > as a wake up source by enable_irq_wake would be better.
> 
> Indeed. It's a hack. This is not the first abuse of IRQF_EARLY_RESUME
> which is used to "fix" ordering issues with nested thread handlers.
> 
> I haven't come around yet to analyze the issue and come up with a proper
> core side mechanism to handle that case. I put it on the "look at it while
> trapped in a tin can" list.

Should this patch be applied in the meantime, or do you think you will be 
trapped in a tin can in the not too distant future ?

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2014-09-14 23:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-13 11:19 [PATCH/RFC] rtc: rtc-twl: Fixed nested IRQ handling in resume from suspend Laurent Pinchart
2014-09-13 19:12 ` Thomas Gleixner
2014-09-14 23:41   ` Laurent Pinchart [this message]
2014-09-17 21:57 ` Thomas Gleixner
2014-09-21  1:04   ` Rafael J. Wysocki
2015-02-26 13:05   ` Gerlando Falauto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3285590.DFfac97QLO@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rtc-linux@googlegroups.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.