Re: gpio interrupts

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Apr 07, 2016 at 10:15:39PM +0000, Michael van Elst wrote:
> >This approach would put impose duplicate code in the backends I guess.
> >It's better to have this centralised in gpio, with the backend
> >calling into gpio and gpio doing the dispatch.
> 
> 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.

> 
> 
> 
> >> >The backend provides an additionnal callback: gp_pin_irqen(), called by
> >> >gpio(4) to mask/unmask an interrupt on a specific pin.
> >> >the backend masks pending interrupts before calling gpio_intr(),
> >> >and gpio_pin_wait() has to explicitely unmask the interrupt before waiting.
> >> 
> >> The gp_pin_ctl() callback is used to set characteristics of a pin.
> >> My idea was to also configure interrupts with it:
> >> 
> >> The flags GPIO_PIN_LEVEL and GPIO_PIN_FALLING were supposed to configure
> >> the interrupt type (edge/level) and polarity (falling/rising,low/high).
> >> 
> >> When you set GPIO_PIN_EVENTS you enable the interrupt. This correlates
> >> to the same flag in caps where it says that the pin does support interrupts.
> 
> >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.

> 
> 
> >On the allwinner switching to simple input to interrupt is more
> >expansive than just masking/unmasking the interrupt.
> 
> >I think configuring the pin to be an interrupt pin (vs a simple input pin)
> >has to be different from masking/unmasking interrupts. The first one is a
> >configuration action, the second is called mostly from interrupt handlers
> >(or from the thread that has been woken up by the interrupt handler).
> 
> 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). I still think a separate callback
is better.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--