Messages in this thread | | | From | Sven Van Asbroeck <> | Date | Tue, 12 Feb 2019 22:25:39 -0500 | Subject | Re: [PATCH 1/3] iio: light: Add driver for ap3216c |
| |
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.
| |