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 15:00:41 +0200 [thread overview]
Message-ID: <20160314130041.GH1793@lahna.fi.intel.com> (raw)
In-Reply-To: <20160314125436.GG1793@lahna.fi.intel.com>
On Mon, Mar 14, 2016 at 02:54:36PM +0200, Westerberg, Mika wrote:
> 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.
Scratch that. I just re-read the patch changelog and they are
configuring the pin as edge triggered.
> > 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()).
I will check again if we are still missing something there.
next prev parent reply other threads:[~2016-03-14 13:00 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
2016-03-14 13:00 ` Westerberg, Mika [this message]
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=20160314130041.GH1793@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).