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

On Sat, Feb 04, 2012 at 09:49:57AM -0700, Paul Walmsley wrote:

quoted

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.

Rubbish.  Let's say I hook an OMAP platform up to a GPS, and the system
integrator has decided to set the idle timeout on all UARTs to .5 sec.
The GPS transmits data every second.  Yes, it effectively retries each
second, but there's no way to receive its complete transmission _ever_.

No, that is not an example of a protocol with a retry.  That is an example 
of a protocol that has no provision for reliable data delivery.  Sending a 
new data string one second later is not a retry.

In such situations, the system integrator would just use the UART in the 
default (lossless) mode.  And if they don't, they'll have to deal with the 
consequences that they chose.  Those of us who ship battery-powered Linux 
devices are indeed capable of making this choice.

One could argue that the PM runtime autosuspend timeout is not the 
appropriate place to change this setting, and that it should be somewhere 
else.  That's fine.  But that's a separate issue from removing the 
functionality completely.


- Paul