Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed

["Rafael J. Wysocki" <rjw@sisk.pl>]

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@gmx.de>
> > 
> > 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