I have a board with an QuadUART TI16C754B chip. I set this chip
up using the usual
struct plat_serial8250_port serial_platform_data[] = ...
struct platform_device serial_device = ...
struct platform_device *devices[] __initdata =
platform_add_devices(devices, ARRAY_SIZE(devices));
way. When I now "insmod 8250.ko", the autoconfiguration tries and
emits:
ttyS0: autoconf (0x0000, 0xc8858e00): iir=3 EFRv2
950id=60:60:60:60 850id=0000 type=ST16650V2
serial8250.0: ttyS0 at MMIO 0xc00ee00 (irq = 30) is a ST16650V2
Now I "rmmod 8250" and "insmod 8250.ko" again. Now I get
ttyS0: autoconf (0x0000, 0xc8858e00): IER test failed (10, 1f)
type=unknown
>From what I found out the bit EFR[4] keeps set when I remove the
driver. This bit enables Enhanced functions and makes IIR[4] not
return 0, but the state of the sleep mode. Therefore, I can
write 0x0F into IIR and get 0x1F back.
A quick hack to get the chip working would be the setting
UPF_BUGGY_UART bit test, but I actually think that 8250.c is
buggy, maybe it should read IIR and and the result with 0x0f.
Because one cannot know the state of EFR[4], one should try to
disable the bit first with something like this:
--- linux.orig/drivers/serial/8250.c
+++ linux/drivers/serial/8250.c
@@ -902,4 +902,12 @@
up->bugs = 0;
if (!(up->port.flags & UPF_BUGGY_UART)) {
+ serial_outp(up, UART_LCR, 0xBF);
+ serial_outp(up, UART_EFR, UART_EFR_ECB);
+ serial_outp(up, UART_LCR, 0);
+ serial_outp(up, UART_IER, 0);
+ serial_outp(up, UART_LCR, 0xBF);
+ serial_outp(up, UART_EFR, 0);
+ serial_outp(up, UART_LCR, 0);
+
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
