From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Tue, 20 Sep 2011 00:40:03 -0400 Subject: [U-Boot] serial ifdef mess In-Reply-To: References: <1316323020-4027-1-git-send-email-vapier@gentoo.org> <201109192052.30059.vapier@gentoo.org> Message-ID: <201109200040.04589.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 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