tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gpio interrupts



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.

> 
> 
> If you want to wait for a pin you can simply use a condition variable
> and make the eventhandler trigger it.

yes, of course. I'll reply more in details on this topic to jared's mail

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

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


Home | Main Index | Thread Index | Old Index