On Tuesday, December 13, 2011, Guennadi Liakhovetski wrote: > Hi Ulf > > On Tue, 13 Dec 2011, Ulf Hansson wrote: > > > Guennadi Liakhovetski wrote: > > > Some MMC hosts implement a fine-grained runtime PM, whereby they > > > runtime-suspend and -resume the host interface on each transfer. This can > > > negatively affect performance, if the user was trying to transfer data > > > blocks back-to-back. This patch adds a PM QoS constraint to avoid such a > > > throughput reduction. This constraint prevents runtime-suspending the > > > device, if the expected wakeup latency is larger than 100us. > > > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@xxxxxx> > > > > I think host drivers can use autosuspend with some ms delay for this instead. > > This will mean that requests coming in bursts will not be affected (well only > > the first request in the burst will suffer from the runtime resume latency). > > I think, Rafael is the best person to explain, why exactly this is not > desired. In short, this is the wrong location to make such decisions and > to define these criteria. The only thing, that the driver may be aware of > is how quickly it wants to be able to wake up, if it got suspended. And > it's already the PM subsystem, that has to decide, whether it can satisfy > this requirement or not. Rafael will correct me, if my explanation is > wrong. It is correct. More specifically, the problem is, for example, that there may be two different low-power states of the system that may be entered when the device is suspended, one of which is relatively shallow, but having a low exit latency, while the other one is deep with a correspondingly longer exit latency. This happens when the device is a member of a power domain that may be turned off entirely when it is suspended under certain conditions and at the same time the device's individual clock may be turned off and on almost instantaneously. In that case there's no reason to avoid suspending the device whenever possible, allowing its clock to be turned off to save energy, but there may be a good reason to avoid turning off the power domain due to latency constraints. No amount of playing with autosuspends is going to help here, unless the driver is aware of the exact system hardware configuration it is in, which is rather impractical if you think of universal drivers (such that may be used with different platforms, for example). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
