On Tue, 2008-02-26 at 01:59 +0100, Thomas Koeller wrote: > On Mittwoch, 20. Februar 2008, Alex Williamson wrote: > > > > The key is that I'm looking at the 2nd IIR read and expecting NO_INT. > > My UART passes the TXEN bug test, so the first interrupt is generated > > correctly. Does this patch help at all? > > The patch seems to be good. After applying it, my UART passes the > modified test. I never tried enabling the interrupt twice, as your > modified test does, and was not aware that in this case my hardware > would raise an interrupt. How did you know? Can we be sure that possible > other UARTS affected by UART_BUG_TXEN will also do this? Hi Thomas, What I expect to happen is that your UART will not raise the transmit empty interrupt either time (but most importantly the first time). My UART does interrupt on the first, but not the second. Thus the failure to *reassert* the interrupt as described in the comment. Are you sure your hardware is raising the interrupt? I'm hoping that it doesn't, and will fall out of my test and get caught by the original TXEN test. I placed the backup timer test before the TXEN bug test to make sure I get a clean shot at the interrupts. I was assuming that TXEN bug UARTs never assert the transmitter empty interrupt, but I either forgot to add the check that this patch does, or was hoping the backup timer would keep them running too. We could consider consolidating the tests, as they're very similar, but frankly, I'm afraid to mess with the TXEN test without having at least a couple UARTs with the issue to test. If your UART is detected correctly now and you don't have any suggestions for further improvements, I'll go ahead and submit this. Let me know. Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. - 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
