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
