From: Sven Van Asbroeck <thesven73@gmail.com>
To: Robert Eshleman <bobbyeshleman@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/3] iio: light: Add driver for ap3216c
Date: Tue, 12 Feb 2019 22:25:39 -0500 [thread overview]
Message-ID: <CAGngYiUvEpSgESzFGJOtYjLi+_xmZ18GwiSTxaaMjEmjk2pu4Q@mail.gmail.com> (raw)
In-Reply-To: <20190213021753.GA19621@bobby.localdomain>
Hi Bobby,
On Tue, Feb 12, 2019 at 9:17 PM Robert Eshleman <bobbyeshleman@gmail.com> wrote:
>
> First, thank you for the feedback.
First of all, thank _you_ for doing the hard work on this driver !
I very much respect what you've done here.
>
> I had initially went with a similar design, but there is
> the case in which the interrupt fires and then before the status
> register is read by the handler a user process reads the data and
> clears the interrupt. When the handler continues execution it will
> read a zero status and return IRQ_NONE. My understanding of how
> Linux handles IRQ_NONE is pretty poor, but I felt that this behavior
> is incorrect even if inconsequential. This could be avoided by
> doing a status register read with every data read, and buffering
> that as well, but then we lose the benefit altogether by increasing
> I2C reads.
>
> In the approach you describe here, it seems like that would
> work if this driver wasn't supporting shared interrupts. In the
> case that a user-space read happens to clear the interrupt before
> the handler reads the status register, I think we would end up
> falsely returning IRQ_NONE.
>
> Is my understanding of this correct? It's very possible I'm
> misunderstanding IRQ_NONE and shared interrupts.
>
Yes, I can see how one can run into those issues.
I believe that this whole class of problems goes away if PS/ALS
are _exclusively_ read inside the interrupt, and cached.
Then, whenever a user process wants to read the data, the function
does not touch the h/w, but simply return the cached value.
But hang on, I will have more to say on this when replying to Jonathan's
feedback.
next prev parent reply other threads:[~2019-02-13 3:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-10 20:36 [PATCH 1/3] iio: light: Add driver for ap3216c Robert Eshleman
2019-02-10 20:39 ` [PATCH 3/3] dt-bindings: iio: light: Add ap3216c Robert Eshleman
2019-02-11 14:58 ` [PATCH 1/3] iio: light: Add driver for ap3216c Peter Meerwald-Stadler
2019-02-13 16:33 ` Robert Eshleman
2019-02-11 19:09 ` Sven Van Asbroeck
2019-02-11 21:27 ` Jonathan Cameron
2019-02-11 22:30 ` Sven Van Asbroeck
2019-02-12 20:47 ` Jonathan Cameron
2019-02-13 4:40 ` Sven Van Asbroeck
2019-02-13 4:56 ` Sven Van Asbroeck
2019-02-18 15:16 ` Jonathan Cameron
2019-02-18 19:35 ` Sven Van Asbroeck
2019-02-20 12:32 ` Jonathan Cameron
2019-02-20 15:09 ` Sven Van Asbroeck
2019-02-13 16:18 ` Robert Eshleman
2019-02-11 19:29 ` Sven Van Asbroeck
2019-02-13 2:17 ` Robert Eshleman
2019-02-13 3:25 ` Sven Van Asbroeck [this message]
2019-02-18 15:22 ` Jonathan Cameron
2019-02-18 17:13 ` Sven Van Asbroeck
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=CAGngYiUvEpSgESzFGJOtYjLi+_xmZ18GwiSTxaaMjEmjk2pu4Q@mail.gmail.com \
--to=thesven73@gmail.com \
--cc=bobbyeshleman@gmail.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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).