* Tony Lindgren <tony@atomide.com> [041028 13:02]:
> * Russell King <rmk+lkml@arm.linux.org.uk> [041028 12:32]:
> > 
> > One of the things which previous changes have done is to move us away
> > from "port types" towards "capabilities" for serial ports, so things
> > like the FIFO, hardware flow control and so forth can be individually
> > controlled, rather than having to rely on a table of features.
> > 
> > So, it appears that OMAP ports are like a TI752 port, but with a couple
> > of extra features.  Can we use the existing TI75x feature support code
> > for these ports?
> 
> Well last time I checked at least the autoconfig failed. I can look into it
> a bit more.

OK, got it working by resetting the ports before calling
early_serial_setup(). The ports are now properly autodetected as PORT_16654,
and seem to be working :) The new patch is quite minimal, see below!

Hmm, I wonder if there would be some advantage if the ports were detected as
TI16750?

The omap specific reset function is basically:

omap_serial_outp(up, UART_OMAP_MDR1, 0x07); /* disable UART */
omap_serial_outp(up, UART_OMAP_MDR1, 0x00); /* enable UART */

Macro is_omap_port() is defined in the omap serial.h to check the port
address. Moving that to somewhere else would allow removing one ifdef.

The macro cpu_is_omap1510() is omap specific, so one ifdef is still needed.

> > Also, these ports seem to use extra address space which isn't covered by
> > a request_region/request_mem_region... that's something which should be
> > fixed.
> 
> OK, I'll change that.

This is fixed now too.

Tony