Hi,
I'm having an intermittent problem with my 16550 which is integrated in
a W83627DHG-P SuperIO chipset on a stable 2.6.32 kernel (though things
haven't changed much in 8250.c)
The sequence of events is as follows:
1. I get an interrupt for ttyS1 and IIR=0xc2 is read. This indicates
that the Transmitter Holding Register (THR) is empty and the handle_port
function is entered.
2. The LSR is read as LSR=0x00, indicating that the THR is non-empty. At
this point we don't call the transmit_chars function as this is decided
by the LSR reading.
3. After this I only hear from the serial port once, and then it goes
completely quiet; no more interrutps. This single interrupt has a
IIR=0xc1, so nothing interesting.
Checking the LSR later it is set to LSR=0x60 indicating that now the THR
is empty.
After this my serial port is permanently out of the game as no more
interrupts are generated.
Looking through the W83627DHG-P SuperIO chipset datasheet the only thing
I can come up with is that this is some sort of bug where the LSR is not
set concurrently with the IIR and I'm having terribly bad luck as the
LSR doesn't agree with the IIR. The other possibility is that something
is in fact writing to the serial port, though as I'm printk'ing from
each serial_in and serial_out I'm quite sure this isn't the case.
I see some solutions, but I don't think they're very pretty. One is to
stop and restart the tx interrupt each time we call start_tx, this
should guarantee fresh interrupts.
Another solution would be to actually ignore the LSR in the interrupt
routine and just decode the IIR. This seems to be what the datasheet
intended. I'm guessing there are reasons not to do things this way, but
it does sort of make sense.
All help and feedback much appreciated.
Nils Carlson
--
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
