On Sun, Jul 28, 2013 at 8:22 PM, Linus Walleij <[email protected]> wrote:
> On Sun, Jul 28, 2013 at 7:33 PM, Javier Martinez Canillas
> <[email protected]> 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?
>
> 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 :-)
>

Yes, we are trying to add more DTS for OMAP boards to have a better
coverage. In fact adding support for an ethernet chip connected to the
OMAP GPMC memory controller was what showed the need for the GPIO auto
request feature that led to this patch-set.

> 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.
>

Indeed, hopefully we will have schema validation in dtc soon so we
could validate if DTS are well-formed and test if our changes breaks
valid DTS or not.

> Yours,
> Linus Walleij

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to