Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx> writes:
> When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
> has to be made to initialize the OMAP GPIO bank before a driver
> request the IRQ. Otherwise the call to request_irq() fails.
>
> Drivers should not be aware of this neither care wether an IRQ line
> is a GPIO or not. They should just request the IRQ and this has to
> be handled by the irq_chip driver.
>
> With the current OMAP GPIO DT binding, if we define:
>
> gpio6: gpio@49058000 {
> compatible = "ti,omap3-gpio";
> reg = <0x49058000 0x200>;
> interrupts = <34>;
> ti,hwmods = "gpio6";
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> };
>
> interrupt-parent = <&gpio6>;
> interrupts = <16 8>;
>
> The GPIO is correctly mapped as an IRQ but a call to gpio_request()
> is never made. Ideally this has to be handled by the IRQ core and
> there are some work-in-progress to add this logic to the core but
> until this general solution gets into mainline we need to solve this
> on a per irq_chip driver basis.
>
> Some drivers solve this by calling gpio_request() using a custom
> .xlate function handler. But .xlate could get called many times
> while the irq domain .map function handler is called just once
> when a IRQ mapping is created with a call to irq_create_mapping().
>
> This patch-set adds a custom .map function handler for the gpio-omap
> irq_chip driver that automatically call gpio_request() when a IRQ
> mapping is created for the GPIO line used as interrupt when using DT.
> This is just a temporary solution (a.k.a a hack) until a kernel wide
> approach is implemented and added to mainline.
>
> This is a third version of a patch-set that addresses some issues pointed
> out by Grant Like, it is composed of the following patches:
>
> [PATCH v3 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT
> [PATCH v3 2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT
>
> This was tested on an OMAP3 DM3735 board (IGEPv2) and all the supported
> peripherals are working correctly with both legacy and DT booting. Further
> testing will be highly appreciated.
Was there any testing done to hit low-power modes? suspend/resume?
CPUidle enabled? etc. It is especially instructive to enable off
mode[1] on OMAP3 platforms and see if things still work as expected.
Kevin
[1] echo 1 > /sys/kerel/debug/pm_debug/enable_off_mode
> Aaro, could you please test if these changes break any of your OMAP1 boards?
> Although it shouldn't do it as far as I can tell.
>
> Many thanks to Jon Hunter and Grant Likely for their feedback and
> suggestions on how to solve this.
>
> Best regards,
> Javier
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
