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

[Paul Walmsley]

On Sat, 4 Feb 2012, Russell King - ARM Linux wrote:

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

There is indeed an argument here.  The decision of how to act in this 
situation needs to be up to the user of the serial port.

The default behavior needs to be what you state: to not lose characters.  
And indeed that is what it is in v3.3: the UART will not enter idle when 
the PM runtime autosuspend timeout is -1.  

But in cases where there is a protocol that can handle retries, the system 
integrator may well prefer the large power savings available by letting 
the chip enter device idle, and take the added delay in the retransmission 
process.

As in many power management situations, the choice needs to be up to the 
user of the serial port or the system administrator, with the default 
mode being to not lose data.  We must not remove that choice from them, 
otherwise they will just hack it in later.


- Paul