Re: [PATCH] RM9000 serial driver

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

Hello.

Thomas Koeller wrote:

>>If you have an another standard 8250 port. this driver cannot support it
>>You should do as well as AU1X00.

> The AU1X00 code obviously assumes that every port that is not an AU1X00 is
> a standard port requiring no register mapping. However, this is of course
> not necessarily true in the most general case. There could be platforms
> with multiple ports, all non-standard, but in different ways. Handling this

    The key word here is *could*. So far, this case is purely speculative. The 
"half-compatible" UARTs seem to only reside in some SOCs for which case the 
current scheme is still adequate.
    I think I understand why such "half- compatible" hardware has appeared at 
all -- the weird 8250 addressing scheme with several registers mapped to the 
single address may be hard to implement...

> would require per-port mapping functions, which could be achieved by adding
> function pointers to struct uart_8250_port. However, this would add the
> overhead of a real, non-inlined function call to every register access.

> Also, it seems to me that the whole register-mapping stuff conflicts with
> autodetection, because autoconfig() uses serial_inp() and serial_outp()
> before the port types, and hence the mapping requirements, are known.

    Port types have nothing to do with this. Or at least they hadn't until 
your recent patch. :-)
    iotype was used to identify the addressing scheme, and it's alsready known 
beforehand.

> This is not a problem for me, however, since the correct port type is
> set up by the platform using early_serial_setup().

    There actually may be some other (and more valid than your case :-) issues 
preventing autoconfure from use with SOC UARTs. I guess autoconfigure code 
wan't intended for the case of SOC chips -- their UARTs' charactarestics are 
usually known beforehand, and the correct PORT_* might be pre-set by the 
platform setup code.

WBR, Sergei