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