Re: Preventing OMAP3 serial driver to take control of all UARTs

[Grant Likely <grant.likely@secretlab.ca>]

On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> wrote:
> On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
>> Hi Tony,
>>
>> Current omap serial driver takes control of all 3 (4 on OMAP3640)
>> UARTS. However, we have such a setup where UART2 for example is used
>> by bluetooth driver. It uses the UART as non-standard way (there are
>> some Nokia extensions to H4 protocol) so we cannot use the standard
>> driver for driving the UART but have written special one for that
>> purpose.
>>
>> Question is: Is there any, upstreamable, way of preventing omap serial
>> driver to do this? Currently this is done with custom #ifdef hackery to
>> mach-omap2/serial.c. Alternative solution that comes into mind is to
>> specify UART configuration in board files and let serial driver to use
>> that instead of hard-coded one. Or do you have some nice alternatives?
>
> Previously (back around 2.6.28-rc8) in the board file, the
> omap_uart_config struct controlled which serial ports were enabled on
> startup.  It was used in omap_serial_init, and it looks like that code
> went away with the following commit:
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
>
> I'm kinda in the same boat as I want to use some of the unused serial
> port pins for GPIO, but they are setup as serial ports....

Not in mainlined yet, but I'm working on porting flattened device tree
support to OMAP to solve exactly this sort of problem.  Basically,
instead of hard coding or #ifdeffing things, a data blob gets handed
to the kernel at boot time telling it exactly what hardware is present
in a consistent, parsable format.  Device drivers then get probed
based on data in the device tree.  Here's some info on the approach:

http://www.elinux.org/Device_Trees

I expect to have my prototype ready for review mid-January, and most
of the common code should be either merged or queued up in linux-next
by that time.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html