[U-Boot] serial ifdef mess

[Mike Frysinger]

On Tuesday, September 20, 2011 00:28:30 Simon Glass wrote:
> On Mon, Sep 19, 2011 at 6:07 PM, 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)
> 
> Do we really want this? Is the code overhead of SERIAL_MULTI so bad
> that people insist on not defining it? If so, can we reduce that code
> overhead? It doesn't seem like it should be large. Perhaps non-MULTI
> could be implemented by macros and inline functions in the header
> file?

MULTI: serial_puts looks up a struct in a linked list to find the device 
before calling the func pointer in that struct to the device-specific 
serial_puts

!MULTI: serial_puts writes char to hardware register

the latter sounds a lot more robust to me :).  it might not be a recommended 
or default setting, but i think we should strive to keep that simplicity 
around.

> > 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.
> 
> Prior to relocation there is a single console UART. I wonder whether
> it would be acceptable to buffer all output until after relocation?
> Serial init is the one peripheral still needed prior to reloc. At
> least this could be the default option, with something like
> CONFIG_EARLY_UART defined to revert to current behavior for debugging
> reasons.

as a debugging tool, any buffer is not interesting.  after that, it might be.

> But to truly deal with your point, I don't think the environment tells
> the serial ports much. They get their registers address and settings
> from other places (normally hard-coded in the driver, perhaps in
> future through an fdt). It should be possible for any serial driver to
> output things before the env is loaded. To implement an early UART we
> simply need the serial layer to pass serial calls straight onto the
> selected driver without going through the mux or anything else that
> needs state. That bit already works...

!MULTI gives us a working early UART now.  i know because the Blackfin port 
can output info to the serial port at pretty much power on.

> The main bugbear for me is that there is no handle passed to the
> serial functions. All of the serial devices should have an extra
> parameter at the start which is perhaps struct seral_device *, and
> that structure should have a ->priv member, pointing to a
> driver-specific structure which we can
>  use to store things like the port number / register address. So in
> other words make it like most other driver layers in U-Boot.

yes, this would be the first thing i'd fix
-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/e0ccf1e3/attachment.pgp