All of lore.kernel.org
 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 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.