linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Crestez Dan Leonard <leonard.crestez@intel.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Daniel Baluta <daniel.baluta@intel.com>,
	Giuseppe Barba <giuseppe.barba@st.com>,
	Denis Ciocca <denis.ciocca@st.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH 3/3] iio: st_sensors: Use level interrupts
Date: Fri, 3 Jun 2016 12:08:14 +0100	[thread overview]
Message-ID: <9cb338ec-f223-cf7f-27fb-bd10a80f7f0a@kernel.org> (raw)
In-Reply-To: <CACRpkdZfqRTrKtPRbjUuEOn6s5VEmV9PJSRx6eCr+THHCOk2uA@mail.gmail.com>

On 02/06/16 15:36, Linus Walleij wrote:
> On Sun, May 29, 2016 at 9:29 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 24/05/16 13:35, Crestez Dan Leonard wrote:
> 
>>> This might be completely crazy, but wouldn't it be possible to support
>>> gpio level interrupts purely in software? Just read the GPIO state again
>>> after the interrupt is unmasked and retrigger.
>>>
>>> This seems preferable to implementing per-driver workarounds. Perhaps it
>>> would even fit in some gpio-irqchip glue.
>>
>> That's precisely the question I raised way back when writing the lis3l02dq
>> driver.  Apparently someone once had a go but it never went anywhere...
> 
> It is maybe possible to do in some cases. What you have to do
> is to augment the GPIO irqchip driver to read the line status register
> after handling an IRQ, if level IRQ is desired, and if the line is still high
> after a rising edge or still low after a falling edge, just call the IRQ
> handler again.
> 
> This will not work with threaded interrupt handlers, because that
> code is in the "hard" path of the interrupt handling code, that
> gets executed in response to an IRQ signal.
> 
> What it would take is code to go back into the "hard" irq handler
> after the thread has run, and take a second lap in checking the
> line levels.
> 
> I don't know if that is possible to achieve in Linux, hm :/
It would probably be possible to do deep in the irq chip as you'd do
the check at the point of the interrupt being unmasked.  A little nasty
to then flip back into interrupt context to re trigger the interrupt
but could probably be done - perhaps by maintaining a parallel
interrupt chip that is closer to an IIO trigger (i.e. entirely fake).

Would be easier if only rerunning the threaded part though..

Is it worth it?  Doubtful.

Cc'd the IRQCHIP maintainers in case they want to add anything or
give pointers to a previous similar discussion.

Jonathan
> 
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2016-06-03 11:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13 18:43 [PATCH 1/3] iio: st_sensors: Init trigger before irq request Crestez Dan Leonard
2016-05-13 18:43 ` [PATCH 2/3] iio: st_sensors: Disable DRDY at init time Crestez Dan Leonard
2016-05-14 16:55   ` Jonathan Cameron
2016-05-24 11:28   ` Linus Walleij
2016-05-29 19:28     ` Jonathan Cameron
2016-05-13 18:43 ` [PATCH 3/3] iio: st_sensors: Use level interrupts Crestez Dan Leonard
2016-05-14 16:16   ` Jonathan Cameron
2016-05-24 11:40   ` Linus Walleij
2016-05-24 12:35     ` Crestez Dan Leonard
2016-05-29 19:29       ` Jonathan Cameron
2016-06-02 14:36         ` Linus Walleij
2016-06-03 11:08           ` Jonathan Cameron [this message]
2016-06-20 13:26   ` Linus Walleij
2016-05-14 16:54 ` [PATCH 1/3] iio: st_sensors: Init trigger before irq request Jonathan Cameron
2016-05-24 11:27 ` Linus Walleij
2016-05-24 12:33   ` Crestez Dan Leonard
2016-05-24 21:54     ` Linus Walleij
2016-05-29 19:26       ` Jonathan Cameron

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=9cb338ec-f223-cf7f-27fb-bd10a80f7f0a@kernel.org \
    --to=jic23@kernel.org \
    --cc=daniel.baluta@intel.com \
    --cc=denis.ciocca@st.com \
    --cc=giuseppe.barba@st.com \
    --cc=jason@lakedaemon.net \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=leonard.crestez@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=pmeerw@pmeerw.net \
    --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).