Hello,
Being the author of these patches I'm ashamed that they are causing a
regression. I did my best to make sure that it would work on OMAP1 and
OMAP2+ platforms booting with both legacy board files and DT.
Also, I didn't come with this solution in a vacuum. This was deeply
discussed with Jon Hunter, Grant Likely, Jean-Christophe
PLAGNIOL-VILLARD and others on a 90+ emails linux-omap thread [1] and
over IRC in #linaro-kernel channel.
The final agreement was that when a GPIO line is mapped in the IRQ
domain with irq_create_of_mapping(), the core has to take care to
request the GPIO and configure it as input.
But until we have this general solution we have to do it on a per irq
chip driver basis and the less hack-ish solution is to have a custom
.map function handler that request the GPIO used as IRQ.
Now, this assumes that irq_create_of_mapping() will always be called
for all GPIO lines that are going to be used as an IRQ. But this
doesn't seem to be true for the omap_hsmmc driver when the "cd-gpios"
mmc property is used in the omap-mmc device node.
I'm ok if you decide to revert these patches but I think we should do
it with care and be sure that the assumption that a IRQ-GPIO mapping
can happen without an explicit call to irq_create_of_mapping() is
actually true and this is not and issue in the omap_hsmmc driver or
its DT bindings.
According to Documentation/devicetree/bindings/mmc/mmc.txt:
cd-gpios: Specify GPIOs for card detection, see gpio binding
So it just says that it is a GPIO for card detection and not an IRQ so
this assumption comes from either the omap_hsmmc driver or Alexander'
DTS is missing something like:
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
which will call irq_create_of_mapping() and the mapping for the
GPIO-IRQ will be created, thus making
irq = gpio_to_irq(gpio);
request[_threaded]_irq(irq, ...);
to succeed.
On Sun, Jul 28, 2013 at 6:29 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Sun, Jul 28, 2013 at 4:37 PM, Shilimkar, Santosh
> <santosh.shilimkar@xxxxxx> wrote:
>
>> I think the default OMAP DT files will continue to work with
>> these patches applied and mostly doesn't break anything
>> in default configuration.
>
> What does "mostly" mean? Hm hm. OK I feel a little
> bit better about this now...
>
I think Santosh meant that
$ grep cd-gpios arch/arm/boot/dts/omap*
doesn't find any usage of the cd-gpios property so that's why this
issue was not found on my tests.
>> Ofcourse with the DT modification as done
>> by Alexander will expose the issue.
>
> So this is all caused by non-upstream code or
> non-upstream DTS files?
>
It seems so, I'm not familiar with the omap_hsmmc so I'm not sure if
this issue is with Alexander DTS, the omap_hsmmc driver or my
assumption that irq_create_of_mapping() will always be called for GPIO
mapped as IRQ is wrong.
>> I really wanted to have the auto request GPIO supported
>> when used as IRQ line but surely not at expense of
>> breaking the client drivers.
>
> If things are working for the default DTS files in the
> kernel then I am OK with it.
>
It's working with the default DTS afaict. At least I didn't find any
regression with my tests using an OMAP3 and OMAP4 boards and neither
did Enric whose tested-by I have in the patches.
> However moving forward to support the cases that
> Alexander is highlighting, I really really thin we need
> to put the information about taken GPIOs "input-hogs"
> into the gpio DT node.
>
I do agree with you that this information should be added to the DT to
prevent this kind of issues.
> Yours,
> Linus Walleij
> --
Hope this helps...
Thanks a lot and 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
