[U-Boot] Setup NS16550 specific parameters from platform code

[Detlev Zundel <dzu@denx.de>]

Hi Gururaja,
>
> For our upcoming SOC, we have a situation where in we need to
> configure UART console at runtime. Our SOC makes use of NS16550.
>
> I looked through the u-boot tree & found several references for doing the same. 
>
> hebbar at linux- server:~/projects/u-boot-git$ gr NS16550_init *
> board/sheldon/simpc8313/simpc8313.c:145:        NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500),
> board/ml2/serial.c:45:  (void) NS16550_init (COM_PORTS[0], clock_divisor);
> board/ml2/serial.c:48:  (void) NS16550_init (COM_PORTS[1], clock_divisor);
> board/MAI/AmigaOneG3SE/serial.c:157:    NS16550_init (Com0, clock_divisor);
> board/MAI/AmigaOneG3SE/serial.c:244:    NS16550_init (Com0, clock_divisor);
> board/freescale/mpc8313erdb/mpc8313erdb.c:138:  NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500),
> board/freescale/mpc8315erdb/mpc8315erdb.c:239:  NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500),
> board/bmw/serial.c:45:  NS16550_init (CONFIG_CONS_INDEX - 1, clock_divisor);
> board/bmw/ns16550.c:16:volatile struct NS16550 *NS16550_init (int chan, int baud_divisor)
> board/mvblue/mvblue.c:45:       NS16550_init (console, clock_divisor);
> board/Marvell/common/serial.c:101:      (void) NS16550_init (0, clock_divisor);
> board/Marvell/common/serial.c:104:      (void) NS16550_init (1, clock_divisor);
> board/Marvell/common/ns16550.c:20:volatile struct NS16550
> *NS16550_init (int chan, int baud_divisor)
> board/Marvell/common/ns16550.h:92:volatile struct NS16550 *
> NS16550_init(int chan, int baud_divisor);
> board/amirix/ap1000/serial.c:43:        (void) NS16550_init (COM_PORTS[0], clock_divisor);
> board/evb64260/serial.c:103:    (void)NS16550_init(COM_PORTS[0], clock_divisor);
> board/evb64260/serial.c:106:    (void)NS16550_init(COM_PORTS[1], clock_divisor);
>
>
> I would like to know whether this approach is correct and whether this
> approach is still allowed in current u-boot.

We know that this situation is really, ahem, far from perfect but no one
took the time to rewrite that to use only common infrastructure.

> If not, what is the correct approach? I am also looking at
> CONFIG_SERIAL_MULTI.

We should strive to handle _all_ 16550 compatible parts with only one
driver.  Actually this should be drivers/serial/ns16550.c.  Please try
to fit this into your upcoming port.  (Only recently we did indeed remove
some more duplicates of this code.)

Thanks (also in advance)
  Detlev

-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de