Re: RM9000 code broken in 8250.c

[Alex Williamson <alex.williamson@hp.com>]

Hi Thomas,

   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.  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.
Thanks,

  Alex

On Fri, 2007-12-21 at 12:50 +0100, Thomas Koeller wrote:
> Hi,
> 
> while investigating breakage of the RM9000 code in
> drivers/serial/8250.c, I found that my problems are
> caused by commit 40b36daad0ac704e6d5c1b75789f371ef5b053c1.
> My device has the characteristic of not generating a
> 'transmitter empty' interrupt immediately if interrupts
> are enabled while the transmitter is empty, it needs to
> be kicked by transmitting a character first. Before
> commit 40b36daad0ac704e6d5c1b75789f371ef5b053c1 this was
> taken care of by code in serial8250_startup() that probed
> the hardware for this bug an set the UART_BUG_TXEN flag,
> which then modified the behavior of serial8250_start_tx()
> to take the bug into account. This used to work well for
> my device.
> 
> The commit introduced another check for the same condition
> which is done earlier in serial8250_startup(), and causes
> the driver to use a periodic timer instead of the hardware
> interrupt. Now my device uses that timer, while it was
> perfectly capable of using the serial port transmit
> interrupt before.
> 
> I wonder why a new workaround has been introduced for a
> problem for which there had already been a (far superior)
> solution. Didn't this existing solution solve the problem
> for the hardware in question? If so, wouldn't it have been
> possible to modify the existing solution instead of adding
> another one that conflicts with existing code that depends
> on the old code?
> 
> regards,
> Thomas
-- 
Alex Williamson                             HP Open Source & Linux Org.