Hi,
I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
"16650A" compatible double UART built into the SoC. Using of_serial.c
causes the ports to be autoconfigured, and this fails. The loopback test
fails, because the MSR register on 824[15] doesn't implement the
UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
SOCs to skip the loopback test altogether? The latter is certainly easier
and affects much fewer systems, so, I'd go for that.
Thanks
Guennadi
---
Guennadi Liakhovetski
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
"16650A" compatible double UART built into the SoC. Using of_serial.c
causes the ports to be autoconfigured, and this fails. The loopback test
fails, because the MSR register on 824[15] doesn't implement the
UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
SOCs to skip the loopback test altogether? The latter is certainly easier
and affects much fewer systems, so, I'd go for that.
Yes, that sounds good. Just make sure you test the "compatible" property
in the device node for something appropriate. In of_platform_serial_probe(),
you can then do something like
if (of_device_is_compatible(ofdev, "mpc8241-serial"))
flags |= UPF_SKIP_TEST;
Arnd <><
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
quoted
I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
"16650A" compatible double UART built into the SoC. Using of_serial.c
causes the ports to be autoconfigured, and this fails. The loopback test
fails, because the MSR register on 824[15] doesn't implement the
UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
SOCs to skip the loopback test altogether? The latter is certainly easier
and affects much fewer systems, so, I'd go for that.
Yes, that sounds good. Just make sure you test the "compatible" property
in the device node for something appropriate. In of_platform_serial_probe(),
you can then do something like
if (of_device_is_compatible(ofdev, "mpc8241-serial"))
flags |= UPF_SKIP_TEST;
That would be a possibility, but that would mean all 8241/8245 have to
adjust their .dts. Ok, there are not so many of them in the mainline now
(in fact, hardly any apart from linkstation:-)), still. Cannot we use
something already available to just check if we're running on such a CPU?
Worst case - find and parse cpu node, or maybe using some cpu_feature?
Thanks
Guennadi
---
Guennadi Liakhovetski
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
That would be a possibility, but that would mean all 8241/8245 have to
adjust their .dts. Ok, there are not so many of them in the mainline now
(in fact, hardly any apart from linkstation:-)), still. Cannot we use
something already available to just check if we're running on such a CPU?
Worst case - find and parse cpu node, or maybe using some cpu_feature?
It's fundamentally a property of the serial controller implementation,
not of the processor, so the cpu_features are the wrong place to put
this. There should at least be a generic way to define thsi in the device
tree so that _future_ trees can just mark the port as compatible with
one that has this bug.
If you want to work around existing systems that don't mention this
in the device_tree, you could perhaps use machine_is(foo) to test
for it.
Another option altogether would be to allow the device node to
specify the linux specific serial port flags in a separate property,
like "linux,uart-port-flags" that contains the same flags that
setserial can set from user space. That would also be useful
if you want to specify UPF_MAGIC_MULTIPLIER on certain high-speed
ports, because it cannot be autoprobed.
Arnd <><
Another option altogether would be to allow the device node to
specify the linux specific serial port flags in a separate property,
like "linux,uart-port-flags" that contains the same flags that
setserial can set from user space. That would also be useful
if you want to specify UPF_MAGIC_MULTIPLIER on certain high-speed
ports, because it cannot be autoprobed.
Such high-speed ports should simply use a proper "compatible"
entry. Similarly with the problem at hand.
Segher