From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Tue, 20 Sep 2011 00:44:30 -0400 Subject: [U-Boot] serial ifdef mess In-Reply-To: References: <1316323020-4027-1-git-send-email-vapier@gentoo.org> Message-ID: <201109200044.31961.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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