[[RFC PATCH]] gpio: gpio-mxc: make sure gpio is input when request IRQ

Am 23.07.2014 18:14, wrote Linus Walleij:

On Tue, Jul 22, 2014 at 9:42 AM, Shawn Guo [off-list ref] wrote:

quoted

On Tue, Jul 22, 2014 at 09:19:22AM +0200, Markus Niebel wrote:

quoted

quoted

Currently client drivers have simply interrupts and interrupt-parent
in their bindings, but no interrupt-gpios. Therefore in this case a
client does not know about a dedicated gpio which is to be requested
and configured.

Okay.  I understand your problem now.  This is an issue in case we
specify a GPIO to be used as interrupt from device tree.  In non-DT
world, client driver knows this is an interrupt on GPIO, and therefore
takes the responsibility to request and configure the GPIO to work as
interrupt.  But in DT case, client driver does not know whether it's an
IRQ line or GPIO based interrupt.  The consequence is that GPIO
subsystem, OF subsystem, client driver, none of the three is requesting
and configuring the GPIO to be used as interrupt.

This is a common issue instead of i.MX specific, and should be addressed
globally, I think.

This is very well documented in Documentation/gpio/driver.txt these
days. Quoting:

Sorry for not carefully reading the docs and many thanks for the helpful comments.

"
It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
irq_chip are orthogonal, and offering their services independent of each
other.

gpiod_to_irq() is just a convenience function to figure out the IRQ for a
certain GPIO line and should not be relied upon to have been called before
the IRQ is used.

So always prepare the hardware and make it ready for action in respective
callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
been called first.

So a gpio driver is responsible to read status of gpio lines and flag any gpio line 
currently configured as out (base on the information read from hardware registers) 
on driver probe time - correct? If yes is the driver allowed to call 
gpiod_get_direction() to have the FLAG_IS_OUT set in the gpiolib layer?

This orthogonality leads to ambiguities that we need to solve: if there is
competition inside the subsystem which side is using the resource (a certain
GPIO line and register for example) it needs to deny certain operations and
keep track of usage inside of the gpiolib subsystem. This is why the API
below exists.


Locking IRQ usage
-----------------
Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
to mark the GPIO as being used as an IRQ:

        int gpiod_lock_as_irq(struct gpio_desc *desc)

This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
is released:

        void gpiod_unlock_as_irq(struct gpio_desc *desc)

When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .startup() and .shutdown() callbacks from the
irqchip.
"

So: make sure each API can be used orthogonally by just poking
into the hardware registers. Do not call gpio_request_one().

Makes sense.

Thanks again

Markus

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html