On 15/02/10 21:07, Bansal, Prateek wrote: > Hi Brian, > > Thanks for sharing the patch. We tested this on 2.6.32 kernel on DM355 device > and it worked fine however we are yet to get this working with 2.6.30 kernel. > > > One of the things that we are trying to investigate is why the transmit FIFO > empty interrupts are not generated. If you have more visibility into this, I > would appreciate any details. Considering we see this issue across number of > devices OMAP-L137, DM6446 and DM355, it points to a software issue rather > than hardware one but needs to be confirmed. > > > Prateek
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... Nick. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
