Hello.
David Woodhouse wrote:
Given the existence of the boards, it looks correct to do this.
However, I wonder if it was correct for the MV64660 to claim
compatibily witn ns16550 if the programming model is not exactly
the same. The official OF serial port bindings don't mention the
reg-shift
On Saturday 07 July 2007, Sergei Shtylyov wrote:
the reg-shift property. I'll send a patch shortly, and I'll reorder the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Certainly. BTW, was there really ns8250 -- 8250 is
On Saturday 07 July 2007, David Woodhouse wrote:
Can we add properties to indicate the common high-speed modes too? The
Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not
Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
the reg-shift property. I'll send a patch shortly, and I'll reorder
the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Can we add properties to indicate
Given the existence of the boards, it looks correct to do this.
However, I wonder if it was correct for the MV64660 to claim
compatibily witn ns16550 if the programming model is not exactly
the same. The official OF serial port bindings don't mention the
reg-shift property, so it maybe would
No, you're right. http://playground.sun.com/1275/proposals/Closed/
Accepted/384-it.txt
actually mentions that the the name should be i8250. It also
mentions
that the compatible property should contain pnpPNP,501 for
ns16450 and
higher,
16550 and higher
and pnpPNP,500 for all serial
Can we add properties to indicate the common high-speed modes too?
The
Natsemi baud-base thing could be autodetected by 8250.c if you'd
let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not have enough understanding about the
The MV64660 has reg-shift==2 for its otherwise 16550-compatible uarts.
While the bootwrapper copes with this, of_serial.c doesn't. (The udbg
code doesn't either, but I'll fix that later).
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git a/drivers/serial/of_serial.c
