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 believe that runtime resume callback should ofcourse be optimized so they are executed as fast as possible. But moreover, if they take more 100us, is that really a reason for not executing them at all?
Br Ulf Hansson -- 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
