Re: [PATCH] serial: tegra: add serial driver

From: Mitch Bradley
Date: Mon Dec 17 2012 - 16:59:20 EST


On 12/17/2012 11:36 AM, Stephen Warren wrote:
> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>> Nvidia's Tegra has multiple uart controller which supports:
>> - APB dma based controller fifo read/write.
>> - End Of Data interrupt in incoming data to know whether end
>> of frame achieve or not.
>> - Hw controlled RTS and CTS flow control to reduce SW overhead.
>
>> diff --git a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
>
>> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver.
>> +
>> +Required properties:
>> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart".
>
> One question that isn't addressed here is:
>
> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying
> compatible = "nvidia,tegra20-uart".

The way it is supposed to work is that the compatible property should
list "nvidia,tegra30-hsuart" first, followed by a fallback name that
refers to the generic 8250 compatibility. Having the 8250.c driver bind
to the more-specific tegra30-hsuart name is wrong.

However, the 8250.c driver doesn't
> support the DMA features of this driver. This driver is an alternate
> driver for the same HW that allows DMA to be used with it, etc.
>
> Since DT is supposed to describe the HW, modifying the DT to change the
> compatible value in order to select a different driver in Linux doesn't
> seem correct, or is it? Is there any kind of precedent for how to select
> different drivers for the same HW at run-time? I'd wondered about using
> the sysfs bind/unbind "methods" from user-space as the driver selection
> mechanism...
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@xxxxxxxxxxxxxxxx
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/