Hi all, On Thursday, March 08, 2012, Rafael J. Wysocki wrote: > On Sunday, March 04, 2012, Rafael J. Wysocki wrote: > > On Sunday, March 04, 2012, Rafael J. Wysocki wrote: > > > > > > The goal of this patchset is to allow user space to control the > > > responsiveness of the MMC stack related to runtime power management. > > > > > > Namely, on systems that contain power domains, the time necessary > > > to bring an MMC host up after it has been runtime-suspended may > > > depend not only on the MMC core and host driver, but also on the platform > > > and other devices in the same power domain(s) that contain(s) the MMC > > > host. Although that obviously may influence the MMC performance, > > > currently, there is no way to control it through the MMC subsystem. > > > Moreover, the only available way to control it at all is by using PM QoS > > > latency requests, so it is necessary to add some kind of support for that > > > to MMC. > > > > > > Patch [1/3] adds PM QoS-related fields to struct mmc_host and introduces > > > a new sysfs attribute for MMC hosts, pm_latency_limit_ms, allowing user > > > space to influence the MMC host's runtime PM via PM QoS. Whether or not > > > this attribute will be created (and PM QoS will be used for the given host) > > > depends on the host driver, so host drivers that don't (plan) to support > > > PM QoS don't need to do anything about that. > > > > > > Patches [2/3] and [3/3] add the corresponding host driver bits to the > > > tmio_mmc and sh_mmcif drivers, respectively. > > > > After posting the patches I noticed that the changelog of patch [1/3] and > > the documentation of the new sysfs attribute were not 100% accurate, because > > the PM QoS request really applies to the time between a resume request and > > the moment the device is operational again and not the time from runtime > > suspend (the latter would imply some kind of autoresume mechanism, which isn't > > there). > > > > I also thought it would be cleaner to allocate the val and attr fields along > > with the request, because in the previous version of the patchset they weren't > > used when req was NULL, resulting in (a little) wasted memory. > > > > Updated patches follow. > > Taking the feedback so far into account, I decided to move the exposing of the > PM QoS latency limit from the MMC layer to the PM core sysfs code, so that > every driver (not only MMC host drivers) can use it. > > New patches follow, details are in the changelogs: > > [1/3] - Make it possible to expose PM QoS latency constraints > [2/3] - Make tmio_mmc use the new interface. > [3/3] - Make sh_mmcif use the new interface. Taking the latest feedback into account I reworked patch [1/3] in the following way: - The new attribute is now called pm_qos_resume_latency_us. - It depends on CONFIG_PM_RUNTIME and the documentation says it doesn't has an effect on system-wide suspend/resume. - The new attribute is hidden automatically by dev_pm_qos_constraints_destroy() if still exposed at this point, so the drivers that exposed it don't have to hide it explicitly on removal (although they still can do that). However, I still think that it is appropriate for the MMC drivers to hide it on _their_ removal, because otherwise the device would be left with the meaningless attribute after that point. So, I haven't modified patches [2-3/3], but they follow for completness. I've added the Reviewed-by tags from Kevin and Mark to patch [1/3], becuase the changes made generally follow their suggestions. 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
