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

[Markus Niebel]

Am 23.07.2014 18:14, wrote Linus Walleij:
> On Tue, Jul 22, 2014 at 9:42 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
>> On Tue, Jul 22, 2014 at 09:19:22AM +0200, Markus Niebel wrote:
> 
>>> 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
>