Thread (24 messages) flat view 24 messages, 6 authors, 2014-01-31

device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.

From: Linus Walleij <hidden>
Date: 2014-01-31 08:03:52
Also in: linux-gpio

On Thu, Jan 23, 2014 at 2:16 PM, Jean-Jacques Hiblot
[off-list ref] wrote:
I've been thinking hard on the gpio ownership and I'd like your
opinion on the following assumptions:

- a gpio used as an interrupt is always a gpio configured as an input.
(corollary : a gpio used for interrupt cannot not be an ouput)
That is the assumption made by the core. Until the day someone
comes up with a weird usecase...
- a gpio used as an input or interrupt only, could be safely accessed
by multiple users.
Multiple consumers is the term we would use. But yes.
- a gpio used as an output should be used as such by only one user.
Still other users should be allowed to read its value.
Sounds reasonable.
If those assumptions are true, I believe they can lead to a new
exclusion scheme:
- ouput is mutually exclusive with interrupt but not with input
- only 1 ouput user at a time.
Logical conclusion from the above yes.
It would do away with our sharing issue and more (chained interrupt
handlers on gpio interrupt, read/interrupt access through sysfs to a
gpio requested by a driver)

And I believe that most of the infrastructure is in place to implement this :
- direction flags in gpio_request_one
- gpio_lock_as_irq/gpio_unlock_as_irq
So I think what I need to see is a proposed patch, whether it will
hit a particular driver or the gpiolib core, but either would probably
be interesting.

Pls keep linux-gpio and Alexandre on CC for this discussion.

Yours,
Linus Walleij
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help