[U-Boot] serial ifdef mess

[Mike Frysinger <vapier@gentoo.org>]

On Monday, September 19, 2011 21:07:48 Graeme Russ wrote:
> a) Use a particular serial driver directly - perfect if you have only one
>    serial port (or don't care about the others)

yes.  this is what we have today with !SERIAL_MULTI.  every serial driver 
implements serial_{init,puts,putc,tstc,getc,setbrg,set_baud}.  this code works 
for exactly one device and is extremely thin.  in the case of Blackfin UARTs, 
serial_putc() does two things: wait for the hardware FIFO to free up, and then 
writes the char to the hardware registers.  serial_tstc() is a bit test of a 
single hardware status register read.  you really can't get any simpler than 
this.

> b) Use the SERIAL_MULTI 'management layer' and 'register' each relavent
>    serial port on the board. The board will need to define a (probably
>    hard-coded) a default to handle I/O until the environment can be read
>    and the hardware initialised to actually make the serial ports
>    operational.

atm, SERIAL_MULTI provides support for "early" output by means of the 
default_serial_console() function.  but even this requires going through the 
.data section in order to lookup the func pointer to the device pointers.  
which means i dont think it works for the ports which do relocation on the 
fly.  but i dont know as i havent worked at that level with the relevant 
arches before.

> So in theory, we should be able to register an arbitrary number of serial
> ports, each with potentially different hardware and therefore different
> drivers.

this works today

> The board (or SoC) init function should be able to simply call
> serial_register() for each serial port with a name and info into how to
> talk to the hardware (hardware type, base address etc).

this is doable today, but the standard is to add all devices to 
common/serial.c:serial_initialize()

> The SERIAL_MULTI framework should then simply manage the list of serial
> devices and redirect I/O based on environment settings

which is what it does

one limitation of the current serial/stdio framework is that the serial multi 
core can only have one active device at a time.  the stdio core can have one 
per channel: stdin, stderr, stdout.  so this reminds me of the other goal: 
merge serial framework into stdio framework.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110920/cd5b4bad/attachment.pgp