linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Daniel Walker <dwalker@mvista.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Remy Bohmer <linux@bohmer.net>,
	RT <linux-rt-users@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ARM Linux Mailing List  <linux-arm-kernel@lists.arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever
Date: Thu, 29 Nov 2007 09:04:00 +0000	[thread overview]
Message-ID: <20071129090359.GA14728@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1196291955.27964.47.camel@imap.mvista.com>

On Wed, Nov 28, 2007 at 03:19:14PM -0800, Daniel Walker wrote:
> On Wed, 2007-11-28 at 23:03 +0000, Russell King - ARM Linux wrote:
> > On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
> > > 
> > > 
> > > On Wed, 28 Nov 2007, Daniel Walker wrote:
> > > 
> > > >
> > > > Ignoring the ARM side of things for a sec, handle_simple_irq() will
> > > > mask() the interrupt in the special case that an interrupt is already in
> > > > the processes of being handled.. handle_simple_irq() also unmasks when
> > > > it finishes handling an interrupt (something real time adds for some
> > > > reason) ..
> > > >
> > > > In terms of threading the irq everything is the same except there is no
> > > > unmask() call when the thread finishes ..
> > > >
> > > 
> > > OK, to be honest, I never fully understood the concept of this
> > > "simple_irq". I figured it was because of the ARM architecture.
> > 
> > If you read what I said compared with what Daniel said, you'll see that
> > adding the mask/unmask is _pointless_ because for the case where the
> > simple handler should be used, there is _no_ hardware masking available
> > except via the parent interrupt signal.
> > 
> > So actually Daniel's argument misses the basic point - that using
> > handle_simple_irq for non-simple IRQs is just WRONG.
> 
> Well we've got at least two ARM boards which need the additional unmask
> to work correctly with interrupt threading .. So there must be at least
> two ARM boards using handle_simple_irq incorrectly .. It sounds like you
> would prefer we send patches to move those handle_simple_irq users into
> another method ?

If you read my explaination of the purpose of handle_simple_irq() you'll
see that for the _correct_ case where this handler should be used, the
mask and unmask can only be empty.  To repeat for the third time - it's
for the case where the hardware supplies NO way to mask the interrupt.

So adding calls to the mask/unmask methods would be pointless for the
correct use case.

If you do have the ability to mask, then you should be using the level or
edge handlers.

  reply	other threads:[~2007-11-29  9:05 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-26 13:31 [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever Remy Bohmer
2007-11-26 13:45 ` Remy Bohmer
2007-11-27 15:11   ` Steven Rostedt
2007-11-27 15:25     ` Daniel Walker
2007-11-27 15:53       ` Daniel Walker
2007-11-28 14:38         ` Remy Bohmer
2007-11-28 15:36           ` Daniel Walker
2007-11-28 17:25           ` Russell King - ARM Linux
2007-11-28 19:04             ` Steven Rostedt
2007-11-28 20:05               ` Russell King - ARM Linux
2007-11-28 20:16                 ` Steven Rostedt
2007-11-28 20:44                   ` Daniel Walker
2007-11-28 21:13                     ` Steven Rostedt
2007-11-28 23:03                       ` Russell King - ARM Linux
2007-11-28 23:19                         ` Daniel Walker
2007-11-29  9:04                           ` Russell King - ARM Linux [this message]
2007-11-29 10:14                   ` Remy Bohmer
2007-11-29 10:25                     ` Russell King - ARM Linux
2007-11-29 11:27                       ` Remy Bohmer
2007-11-29 13:36                         ` Russell King - ARM Linux
2007-11-29 13:57                           ` Steven Rostedt
2007-11-29 14:18                           ` Remy Bohmer
2007-11-29 14:29                             ` Russell King - ARM Linux
2007-11-29 15:33                               ` Remy Bohmer
2007-11-29 16:20                                 ` Remy Bohmer
2007-11-29 16:30                                 ` Steven Rostedt
2007-11-30 21:44                           ` Thomas Gleixner
2007-12-12 19:40         ` [PATCH RT] Revert Softdisable for simple irqs Steven Rostedt
2007-12-12 19:46           ` Russell King
2007-12-12 20:05           ` Remy Bohmer
2007-12-12 20:27             ` Steven Rostedt
2007-12-12 21:38               ` Remy Bohmer
     [not found] ` <87bq9fqpoi.fsf@vence.hilman.org>
2007-11-28 14:43   ` [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever Remy Bohmer

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=20071129090359.GA14728@flint.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=dwalker@mvista.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux@bohmer.net \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).