+CC Linus, as this became also pinctrl related.

On 08.08.2014 20:29, Javier Martinez Canillas wrote:

Hello,

On 08/08/2014 06:38 PM, Javier Martinez Canillas wrote:

quoted

It seems as if the first call to exynos_irq_set_type() that is made by OF is a
no-op while the second call is the one that actually setups the hw correctly.
Does this make any sense? Maybe is related to the pin not being muxed in the
correct function when the "interrupts" property is parsed by OF?

So after a conversation with Tomasz Figa over IRC the problem was after all that
the pin was reconfigured. The IRQ trigger type resulted to be just a red herring
and not a direct cause.

The pinctrl-eyxnos driver does the IRQ pinmux setup in the .irq_set_type
function handler. So what happened was that OF parsed the "interrupts" property
and called exynos_irq_set_type() which did the pinmux setup.

But after that, due a DTS pinctrl configuration the pin function was changed as
a GPIO input and that happened before the atmel driver was probed. So when the
driver called request_threaded_irq(), the correct flags were used but the pin
was not configured as an IRQ anymore so IRQ were not fired.

Setting a trigger type just had the side effect of calling exynos_irq_set_type()
which again setup the pin as an IRQ.

To fix the issue a variation of patch [0] will be posted that moves the IRQ
pinmux setup from .irq_set_type to the .irq_request_resources function handler.
That way the pin will be setup as IRQ regardless of the the trigger type [1]
when someone calls request_[threaded]_irq().

Only the mentioned patch fixes the issue but Tomasz said that even a call to
gpio_direction_{input,output} can change the pin configuration so he will post
another patch that will add a bit mask to samsung_pin_bank to prevent any pinmux
reconfiguration.

To add a bit more information about the hardware, setting up a GPIO
interrupt on Samsung SoCs is a two-step operation - in addition to
trigger configuration in a dedicated register, the pinmux must be also
reconfigured to GPIO interrupt, which is a different function than
normal GPIO input, although I/O-wise they both behave in the same way
and gpio_get_value() can be used on a pin configured as IRQ as well.

I'm afraid that such design implies that handling of this in the driver
must be done on a very low level, because it involves three possible
interfaces changing the pinmux - pinctrl, GPIO and irqchip and such
subtletes like gpio_direction_input() that shouldn't neither fail if a
pin is already configured as an interrupt nor change the configuration
to normal input.

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html