[Top] [All Lists]

Re: [PATCH] RM9000 serial driver

To: Thomas Koeller <>
Subject: Re: [PATCH] RM9000 serial driver
From: Sergei Shtylyov <>
Date: Tue, 29 Aug 2006 19:14:37 +0400
Cc: Yoichi Yuasa <>,,,,, Thomas Köller <>
In-reply-to: <>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803

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

<Prev in Thread] Current Thread [Next in Thread>