On Sun, Jul 28, 2013 at 8:22 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Sun, Jul 28, 2013 at 7:33 PM, Javier Martinez Canillas
> <martinez.javier@xxxxxxxxx> wrote:
>
>> 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.
>
> So if I understand this correctly, the issue is that some out-of-tree,
> i.e. unreviewed DTS files are not following the style of the in-tree
> DTS files, which mandate attributing the consumer drivers with
> interrupts= and therefore they fail?
>
Yes, that's my understanding of the issue. The fact that it was
working before is that the gpio-omap driver used to call
irq_create_mapping() for all the GPIO in the bank. e.g:
(j = 0; j < bank->width; j++) {
int irq = irq_create_mapping(bank->domain, j);
But for DT this is wrong since we use the "interrupt-parent" property
to specify the controller to which interrupts are routed (an OMAP GPIO
controller in this case) and defining an "interrupts" property will
make the IRQ core to call irq_create_of_mapping().
So, $subject changes the gpio-omap driver to not do an explicit
irq_create_mapping() call for each GPIO and let the core handle that.
The sequence:
irq = gpio_to_irq(gpio);
request[_threaded]_irq(irq, ...);
only works with $subject reverted because a mapping for *every* GPIO
was created so gpio_to_irq() worked but that is wrong in the DT case
IMHO.
> I don't feel we have an obligation to support any strange DTS
> files out there, and the ones that are in-tree for the reference
> designs should showcase the vast majority of expected
> usecases for DT boots. Else please add more DTS files for
> ever more systems so we get proper coverage, don't be shy :-)
>
> I wish we already had the DTS schema parser and checks
> in place. In that case I could just ask if the DTS is well-formed,
> and you could say "yes" or "no", and if it was no, it's just an
> invalid DTS file.
>
> Yours,
> Linus Walleij
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
