Re: gpio interrupts

[mlelstv%serpens.de@localhost (Michael van Elst)]

bouyer%antioche.eu.org@localhost (Manuel Bouyer) writes:

>On Thu, Apr 07, 2016 at 07:08:52PM +0000, Michael van Elst wrote:
>> bouyer%antioche.eu.org@localhost (Manuel Bouyer) writes:
>> 
>> >The attached patch adds two functions to gpio.c:
>> >gpio_pin_wait() is called by a thread that wants to wait on an interrupt.
>> >A thread can wait only on a single pin.
>> 
>> >gpio_intr() is called from backends when an interrupt-enabled gpio is
>> >triggered. Multiple pins events can be signaled in a single call.
>> 
>> 
>> My current (non-functional) code would provide a method
>> to register an event handler with the backend for interrupts
>> that occur on a specified set of pins.
>> 
>> [...]

>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.



>> >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.


>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.

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