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

2014/1/22 Linus Walleij [off-list ref]:

On Thu, Jan 16, 2014 at 1:02 PM, Jean-Jacques Hiblot
[off-list ref] wrote:

quoted

Linus,
 the root of the issue is the fact that a GPIO can't be requested
twice. But IMO it's safe for a single device to request it more than
once and use it for different purposes (irq and electrical signal
value). Maybe we can rework the GPIO request to include this ownership
information. I can post a draft implementation for this if you think
it's worthwhile.

You are right and actually Jean-Christophe's patch is a good
start.

Hi Linus,

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)
- a gpio used as an input or interrupt only, could be safely accessed
by multiple users.
- 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.

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.

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


Jean-Jacques

You also need to use the gpio_lock_as_irq() API as shown in
other patches to the subsystem e.g. this.
commit eb7cce1ea96b6399672abce787598f6e7a4352c3

Also check my other mail in this thread.

Yours,
Linus Walleij