Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MXC: set GPIO IRQ handler
Date: Sat, 28 Nov 2009 00:46:18 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.00.0911280005010.24119@localhost.localdomain> (raw)
In-Reply-To: <20091126075724.GA12179@pengutronix.de>

On Thu, 26 Nov 2009, Uwe Kleine-K?nig wrote:
> On Wed, Nov 25, 2009 at 07:19:58PM +0100, John Ogness wrote:
> > The irq chip function gpio_set_irq_type() correctly sets the i.MX
> > registers but does not set the irq handler.
>
> I assume you see some breakage without your patch?  In mainline?

Is there some other sensible reason why someone would send such a
patch with a completely clear change log ?

> 
>                                             This means that all
> > gpio-based irq's are handled with handle_edge_irq().

> This is not true in mainline, ...

We probably look at a different mainline, right ?

int __init mxc_gpio_init(struct mxc_gpio_port *port, int cnt)
{
....
         set_irq_chip(j, &gpio_irq_chip);
         set_irq_handler(j, handle_edge_irq);

> .... until 060d20d (imx/gpio: Use
> handle_level_irq) (currently in imx/mxc-master) hits Linus' tree ...

The patch fixes an existing problem in mainline. It does not matter
whether there is a different fix pending in some git tree which is
supposed to hit mainline at some undefined point in the future.

> > This patch corrects this by also setting the appropriate handler.
> > 
> > This patch is against 2.6.32-rc8.
> ... so there is no hurry.

Interesting conclusion: every level triggered GPIO interrupt in
2.6.32-rc8 is affected by this problem. Definitely nothing to worry
about ....

> Can you please test with 060d20d if your breakage still occurs and
> if it is still valid report some details (for me and the commit log)?

Could you please provide useful details, i.e. a short explanation why
that commit is the superior fix, instead of forcing people to clone a
git tree to figure out what you are (not) talking about ?

That's the change log of 060d20d:

    imx/gpio: Use handle_level_irq
    
    According to Russell King handle_edge_irq is only useful for "edge-based
    inputs where the controller does not remember transitions with the input
    masked."
    
    So using handle_edge_irq unconditionally for both edge and level irqs is
    wrong.  Testing showed that the controller does remember transitions
    while the interrupt is masked.  So use handle_level_irq unconditionally.

And the changelog is utter crap.

Using handle_edge_irq for level triggered interrupts has nothing to do
with Russell's observation simply because using handle_edge_irq for
level triggered interrupts is patently wrong.

The fact that the irq controller of the imx happens to be designed by
people who seem to have understood the pitfalls of edge triggered irqs
allows to use handle_level_irq for both edge and level triggered. 

That does not make John's patch incorrect. Using handle_level_irq for
both is merily an optimization which would be even more understandable
if there would be an useful comment in the code.

Thanks,

	tglx

  reply	other threads:[~2009-11-27 23:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25 18:19 [PATCH] MXC: set GPIO IRQ handler John Ogness
2009-11-26  7:57 ` Uwe Kleine-König
2009-11-27 23:46   ` Thomas Gleixner [this message]
2009-11-29 20:27     ` Uwe Kleine-König
2009-11-30  9:32       ` Thomas Gleixner
2009-11-30 16:29         ` Uwe Kleine-König
2009-11-30 15:47       ` [PATCH] MAINTAINERS: add tree and file pattern for ARM IMX Uwe Kleine-König
2009-11-30 15:53         ` [PATCH v2] " Uwe Kleine-König

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=alpine.LFD.2.00.0911280005010.24119@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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