Re: RM9000 code broken in 8250.c

[Thomas Koeller <thomas@koeller.dyndns.org>]

Hi Alex,

I apologize for the long delay, I had to sort out a couple of things first,
but I am now ready to return to the issue.

>    Sorry this code is causing you trouble.  I tried the existing TXEN
> bug code, it seems to be fighting a similar, but still quite different
> bug.  The UART bug the backup timer code is trying to fix is more
> asynchronous.  It might need a kick in the middle of a transmit, not
> just at the beginning.

Is the test code you added really capable of detecting this kind of behavior?
To me it does not seem to be - it looks as if it only checks whether the
transmitter empty interrupt is raised when that interrupt is enabled
while the transmitter holding register is empty. That is the same
condition the UART_BUG_TXEN code checks for.

> Can we re-arrange the tests such that they both 
> work?  It would be fine with me if we don't run the test for the backup
> timer on ports with UART_BUG_TXEN already enabled.  The easiest
> mechanism might be to test port.type for PORT_RM9000, and not test those
> for the backup timer.  Then we don't need to re-order the code too much.

I do not think that is an option. The UART_BUG_TXEN code has been there
before I added support for the RM9000, so it probably has more users.

Looking at your description of the bug you are trying to deal with
(interrupts cease to be generated randomly in the middle of a transmission),
I wonder if it is at all possible to write a runtime check that reliably
can detect it. Wouldn't a configuration option be more appropriate here?
This would also have the added advantage of being able to leave out your
code in cases where it is not needed, reducing bloat.

thanks,
Thomas

-- 
Thomas Koeller
thomas@koeller.dyndns.org