linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Westerberg, Mika" <mika.westerberg@intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Zheng, Qi" <qi.zheng@intel.com>,
	"Zha, Qipeng" <qipeng.zha@intel.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH 2/3] pinctrl:Intel: clear interrupt status for every IRQ setup
Date: Mon, 14 Mar 2016 14:54:36 +0200	[thread overview]
Message-ID: <20160314125436.GG1793@lahna.fi.intel.com> (raw)
In-Reply-To: <CACRpkdbqa2zmQ4ajH6LVQLPcWXJ+hWvHNPY5-L3TeLvA=3yg-g@mail.gmail.com>

On Mon, Mar 14, 2016 at 01:40:39PM +0100, Linus Walleij wrote:
> On Mon, Mar 14, 2016 at 9:44 AM, Westerberg, Mika
> <mika.westerberg@intel.com> wrote:
> > On Mon, Mar 14, 2016 at 03:24:06AM +0200, Zheng, Qi wrote:
> 
> >> > +   intel_gpio_irq_ack(d);
> >>
> >> > If the pin toggles right here, we still have the same issue, no?
> >>
> >> Yes. But it is very short time from here to the place IRQ got enabled.
> >
> > That is still a race.
> >
> >> To me, it is the only available platform dependent interface to do
> > the "ACK" in the flow of request_irq. Maybe you have other better
> > option here?
> (...)
> > Drivers need to deal with the fact that they might get spurious
> > interrupts from time to time. You need to check in the interrupt handler
> > if the interrupt was from the device you are driving or not.
> >
> > request_irq() enables the interrupt line and if the pin is already in
> > a state that triggers an interrupt, the driver interrupt handler will
> > be called.
> 
> This looks like something is wrong in the irqchip.

If request_irq() is called so that the interrupt is level triggered,
let's say active low, and the pin is already in that state I would
expect interrupt to trigger immediately when enabled, no?

If I understand correctly this is precisely what Zheng is describing
they are trying to solve.

> Your set_type() is supporting edges but have all IRQs
> handled by handle_simple_irq() rather than handle_edge_irq()
> for the edges, which gives a more robust control flow
> from IRQ to ACK to calling the handler.
> 
> Zheng/Mika: please look at how the level/edge
> IRQs are handled in drivers/gpio/gpio-pl061.c
> where I *tried* to do things right, switching handler
> in .set_type() using irq_set_handler_locked(). I think
> you may need to use handle_edge_irq() for the edge IRQs
> and handle_level_irq() for the level IRQs just like I do
> in the PL061 driver.

The driver is already doing that as far as I can tell (see
intel_gpio_irq_type()).

  reply	other threads:[~2016-03-14 12:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 17:06 [PATCH 1/3] pinctrl: Intel: add RX invertion config Qipeng Zha
2016-03-11  9:38 ` Mika Westerberg
2016-03-14  1:10   ` Zheng, Qi
2016-03-14  8:50     ` Westerberg, Mika
2016-03-14  8:56       ` Zheng, Qi
2016-03-14 12:26         ` Linus Walleij
2016-03-15  2:17           ` Zheng, Qi
2016-03-16 12:27             ` Linus Walleij
2016-03-16 13:34               ` Daniel Vetter
     [not found]                 ` <20160316133412.GN14170-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2016-03-17 14:41                   ` Linus Walleij
2016-03-17 15:14                     ` [Intel-gfx] " Jani Nikula
2016-03-11 17:06 ` [PATCH 2/3] pinctrl:Intel: clear interrupt status for every IRQ setup Qipeng Zha
2016-03-11  9:45   ` Mika Westerberg
2016-03-14  1:24     ` Zheng, Qi
2016-03-14  8:44       ` Westerberg, Mika
2016-03-14  9:02         ` Zheng, Qi
2016-03-14  9:20           ` Westerberg, Mika
2016-03-14 12:40         ` Linus Walleij
2016-03-14 12:54           ` Westerberg, Mika [this message]
2016-03-14 13:00             ` Westerberg, Mika
2016-03-14 14:26               ` Westerberg, Mika
2016-03-15  5:17                 ` Zheng, Qi
2016-03-11 17:06 ` [PATCH 3/3] pinctrl:Intel: make the high level interrupt working Qipeng Zha
2016-03-11  9:49   ` Mika Westerberg
2016-03-14  1:26     ` Zheng, Qi
2016-03-14  1:40     ` Zheng, Qi

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=20160314125436.GG1793@lahna.fi.intel.com \
    --to=mika.westerberg@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=qi.zheng@intel.com \
    --cc=qipeng.zha@intel.com \
    /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).