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