On Fri, Mar 9, 2012 at 12:01 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > A runtime suspend of a device (e.g. an MMC controller) belonging to > a power domain or, in a more complicated scenario, a runtime suspend > of another device in the same power domain, may cause power to be > removed from the entire domain. In that case, the amount of time > necessary to runtime-resume the given device (e.g. the MMC > controller) is often substantially greater than the time needed to > run its driver's runtime resume callback. That may hurt performance > in some situations, because user data may need to wait for the > device to become operational, so we should make it possible to > prevent that from happening. > > For this reason, introduce a new sysfs attribute for devices, > power/pm_qos_resume_latency_us, allowing user space to specify the > upper bound of the time necessary to bring the (runtime-suspended) > device up after the resume of it has been requested. However, make > that attribute appear only for the devices whose drivers declare > support for it by calling the (new) dev_pm_qos_expose_latency_limit() > helper function with the appropriate initial value of the attribute. > > Signed-off-by: Rafael J. Wysocki <rjw@xxxxxxx> > Reviewed-by: Kevin Hilman <khilman@xxxxxx> > Reviewed-by: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Acked-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Yours, Linus Walleij -- 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
