> My understanding of the issue is this: > > The UART device only generates a FIFO empty interrupt if interrupts are > enabled and the FIFO goes from not empty to empty. If you then disable > the interrupt and later reenable it, the interrupt is not reasserted to > indicate that the FIFO is still empty. > > This seems like reasonable behaviour, but is not how a true 16550A > device should behave. The interrupt should be reasseted if the FIFO is > still empty and the interrupt is reenabled. > > The 8250 driver in the Linux kernel is written to depend upon this > reassertion behaviour. It has tests to detect the failure of this > behaviour and enables BUG workarounds (using a 200ms timer), if required. > > Brian's patch changes the driver to not depend on this behaviour and > so doesn't need to detect its absence or invoke workarounds. It also > avoids 200ms timer delays - which is the big bonus. > > I don't know what you did for your 2.6.30 backport, but I have it working > in a 2.6.18 backport with no real changes. > > BTW it is not just a Davinci/OMAP problem I think... >
Correct. You would think that TI should be able to make a 16550 compatible UART. I have seen a few SOCs with this feature, I seem to remember a designware UART that behaves this way too. I agree that it wil take some work to convince the maintainers of the 8250 driver (Alan Cox??) that these changes should be accepted. Even the "real" 16550 will benefit from the change as an interrupt does not have to be handled before transmission can start. /Brian _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
