On Wednesday, March 07, 2012, Adrian Hunter wrote: > On 06/03/12 23:14, Rafael J. Wysocki wrote: > > On Tuesday, March 06, 2012, Guennadi Liakhovetski wrote: > >> On Tue, 6 Mar 2012, Adrian Hunter wrote: > >> > >>> On 04/03/12 02:01, Rafael J. Wysocki wrote: > >>>> Hi all, > >>>> > >>>> The goal of this patchset is to allow user space to control the > >>>> responsiveness of the MMC stack related to runtime power management. > >>> > >>> I wonder why this is build into mmc and not just a generic runtime pm > >>> facility. e.g. > > > > Because of the user space interface (it doesn't necessarily make sense > > for all devices) and to allow drivers to opt-in (if they don't, the > > interface > > won't be created), which is not possible at the core level (we don't know in > > advance what drivers will handle the given devices and if they will support > > PM QoS). > > Even "opt-in" is undesirable, because it is really up to userspace not the > driver. > > > > >>> /* Set maximum resume latency target to 100ms */ > >>> pm_runtime_set_max_latency(dev, 100); > >>> > >>> And then runtime pm will create sysfs attributes etc > >> > >> +1. Having to do essentially exactly the same for each driver subsystem > >> seems counterproductive. > > > > Other subsystems need not do that in the same way. > > Maybe this needs to be re-thought. Userspace needs a simple, consistent and > understandable set of pm controls across the entire kernel, not piecemeal > across different subsystems.
Well, that's my opinion too, but other people don't seem to agree with it. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
