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
|