Re: [PATCH 0/3] MMC / PM: Make it possible to use PM QoS latency constraints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux