[PATCH] uart: make *_UART_NR platform independent

Wolfram Sang wolfram at the-dreams.de
Sat May 7 09:04:39 UTC 2011


On 07/05/11 10:04, Sylvain Munaut wrote:
>> The enums should never be changed; that is the meaning of it all. The idea
>> is to have consistent ids for the type of uart across the whole tree and
>> have it mapped to the correct uart only in the platform specific uart.c
>
> But it is not "platform" specific, it is _board_ specific. So the same
> driver uart.c must deal with several mapping.

Yes, I know. Ultimately, there should be something like "#include 
<mach/uart.h>" which will pull in the correct settings per board. But 
that seemed overkill to me for now (seeing that there might be a move to 
an RTOS anyway). I thought board differences can be easier handled on a 
per-platform basis until then.

> IMHO drivers should get as parameter the index of the device you want
> to address and not some global id and map it internally to the driver.
>
> What if I want for debug to output something on UART3 or something,
> adding something like uart_putc(3, 'b') is much easier than having to
> go add a new value for the enum and its mapping ...

That is easier, but not portable. What if some other board doesn't have 
a UART3? Adding MY_DEBUG_UART does not really hurt IMHO and other boards 
will notice that there is something to take care of.

> If something doesn't get recompiled when a header change or something,
> you must fix the build system.

This is true, of course...

> The current system of trying to build for all platforms at once is
> unsustainable IMHO and we should just have something like
> make TARGET=compal_e88  make TARGET=sciphone_g2 or something and if

... right, too ...

> the TARGET is != from the last built target, just assume everything is
> dirty.

... though in my book, lib/console.c should not recompile if the 
underlying platform changes (arch is something different, of course ;)). 
If lib/* depends on the platform (like with UART numbering), to me this 
sounds like something to be fixed.

I don't feel strong about this patch, though. If it is not good enough, 
we can just skip it. I start to wonder if it makes sense to do such kind 
of work before the RTOS comes along?

Regards,

    Wolfram




More information about the baseband-devel mailing list