[PATCH] uart: make *_UART_NR platform independent
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
... 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?
More information about the baseband-devel