On Sat, 4 Feb 2012, Russell King - ARM Linux wrote: > On Sat, Feb 04, 2012 at 09:49:57AM -0700, Paul Walmsley wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
