patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Russell King - ARM Linux]

On Sat, Feb 04, 2012 at 06:00:56PM +0200, Grazvydas Ignotas wrote:
> It's case 1. What I wanted to say is that first char is most often
> nicely dropped and does not get into the terminal, so I can just type
> the command after it. But in some cases terminal gets corrupted char
> instead, so I must then first get rid of it somehow to successfully
> send a command, which is annoying a bit. I thought that maybe there is
> code somewhere that gets rid of first bad char received and maybe it
> can be tuned, but judging on further discussions it's all done by
> hardware?

If it's the case that the UART bitclock is derived from a PLL which is
shutdown while idle, then no matter which way you look at it - if the
port is open, and therefore the port is expecting to transfer data,
the port must _never_ be allowed to go into any low power state, period.

If it does, then the PLL stops, and it takes time for the PLL to re-lock.
That time will cause a character to be dropped, which is exactly what
people are reporting in this thread.

Moreover, if that then means that the OMAP CPU cores can't be put into a
low power state, then that's the hit that _has_ to be taken because of
the design of the hardware.

It is entirely unacceptable to drop characters on a serial port through
the use of PM.  Many serial protocols just will not cope with that kind
of behaviour - yes, serial protocols may have retry built-in, but will
they retry _before_ the port re-idles and the PLL shuts down?  Can you
be sure?

If you can't, then you can't do PM in this area while the port is open.
Runtime power management is _supposed_ to be transparent.  If it isn't,
it's a bug plain and simple, which blocks the ability for the device to
even _use_ runtime power management.

There's no absolutely argument here.  OMAP's hardware auto idle on the
UART which results in characters being dropped is quite clearly broken.

So, what I suggest is reverting back to standard FIFO thresholds, and
then doing the PM in software: if the kernel transmit buffer holds
characters, or the device FIFO contains characters, PM on the transmit
side must be denied.  If the port is _open_, PM on the receive side
must be denied.  If you don't have a distinction between the transmit
and receive sides, then that becomes a very simple rule: if the port is
open, runtime PM of the serial port is denied and the port must remain
active all the time that it's open.  It's that simple, no ifs or buts.

Anything else, which results in characters lost, is buggy.