[PATCH] Xilinx UART Lite 2.6.18 driver
David H. Lynch Jr.
dhlii at dlasys.net
Sat Oct 28 13:29:14 EST 2006
Peter Korsgaard wrote:
>
> static int __init ulite_console_setup(struct console *co, char *options)
> {
> + int i, ret;
> struct uart_port *port;
> -
> + struct platform_device *pdev;
> +
> if (co->index < 0 || co->index >= ULITE_NR_UARTS)
> return -EINVAL;
>
> port = &ports[co->index];
>
> /* not initialized yet? */
> - if (!port->membase)
> - return -ENODEV;
> + if (!port->membase) {
> + /* We might be early console */
>
> Is this really necessary? The platform probe get's called quite early, E.G.:
>
> Breakpoint 2, ulite_probe (pdev=0xc01c84d0) at drivers/serial/uartlite.c:392
There is a substantial time/code difference between the time
ulite_console_setup() is called and the time the platform device is
initiallized.
If you are actually doing board bringup, you want output as soon as
you can get it and you do not want to have to stuff calls to
ppc_md.progress() to do so.
Regardless, I think this is an issue of style and personal preference.
> 392 {
> (gdb) print __log_buf
> $1 = "<5>Linux version 2.6.19-rc3 (peko at sleipner) (gcc version 3.4.5) #19 Fri Oct 27 16:39:00 CEST 2006\n<6>Barco ThinLite (V2P) <peter.korsgaard at barco.com>\n<7>Entering add_active_range(0, 0, 15360) 0 entrie"...
>
> You can always use the ppc_md.progress() stuff for really early
> debugging if needed. I would prefer to keep this workaround out of
> uartlite.c if it isn't needed.
>
>
I will absolutely agree that trying to resolve the the
dissimilarities between the console_setup() call and the platform device
init is ugly.
But I would have changed the platform device init code to use
the uart_port structure in the platform device data as all the other
drivers that have early console support do.
At some point I suspect a cleaner more structured approach to
modularizing the relationship between early serial code and serial
drivers will force this issue one way or another.
But for now, if you are not going to bother making console_settup()
work you might as well not put the rest of the early serial code in at all.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii at dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
More information about the Linuxppc-embedded
mailing list