Re: gpio interrupts

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Fri, Apr 08, 2016 at 07:19:30AM +0200, Manuel Bouyer wrote:

> > Yes, probably, but it follows the same schema as the other callbacks
> > which are only a very thin layer above the code in the backend.
> 
> Because for other callbacks, there isn't much that can be done at
> the MI level.

Well, not so much...

Anyway, moving common code into the gpio MI layer is nothing I'm against
it, just describing why my current code looks like it does.


> > >You need a way to select if you want the pin to be an input pin, or an
> > >interrupt pin. Some hardware can't do both at the same time.
> > 
> > That is more a question on how you far you abstract from the
> > real hardware. Currently any combination of flags is possible
> > (so you can say interrupt or input or both) and the backend
> > decides how to interpret that.
> 
> or reject if it can't do that, I guess.

Yes. That's also how other flags are handled. The backends just
pick anything they like.



> > Yes, that's possible, and mostly asks for another flag bit to distinguish
> > both cases.
> 
> masking/unmasking is something that needs to be really fast, and is
> different in nature from other configuration options (this is not a
> configuration operation).

For many GPIOs that's just writing a mask register instead of writing a
configuration register. Sometimes is even the same register controlling
a single mode as in off/level/edge.


> I still think a separate callback
> is better.

Maybe it cuts a few nanoseconds, but I fear it will just support
the assumption that masking works in a specific way. If you make
a new callback then it should also give a new quality. E.g.
acting as a barrier to ensure that no interrupts occur when the
callback returns.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."