On 02/05/13 14:35, Ulf Hansson wrote:
> On 2 May 2013 12:38, Adrian Hunter wrote:
>> On 16/04/13 13:00, Ulf Hansson wrote:
>>> Aggressive power management is suitable when saving power is
>>> essential. At request inactivity timeout, aka pm runtime
>>> autosuspend timeout, the card will be suspend
On 02/05/13 14:09, Ulf Hansson wrote:
> On 2 May 2013 11:57, Asutosh Das wrote:
>> On 5/2/2013 3:22 PM, Ulf Hansson wrote:
>>>
>>> On 2 May 2013 10:58, Adrian Hunter wrote:
On 16/04/13 13:00, Ulf Hansson wrote:
>
> From: Ulf Hansson
>
> Once the mmc blkdevice is being p
From: Ulf Hansson
SDIO is the only protocol that uses runtime pm for the card device
right now. To provide the option for sd and mmc to use runtime pm as
well the bus_ops callback are extended with two new functions. One for
runtime_suspend and one for runtime_resume.
This patch will also implem
From: Ulf Hansson
Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inactivity occurs for a certain time. Right now the
selected timeout value is set to 3 s. Obviously this value will likely
need to
From: Ulf Hansson
Move mmc suspend specific operations to be executed from the .suspend
callback in the mmc bus_ops. This simplifies the mmc_suspend_host
function which is supposed to handle nothing but common suspend tasks.
Since eMMC can be considered non-removable there are no need to check
f
From: Ulf Hansson
Aggressive power management is suitable when saving power is
essential. At request inactivity timeout, aka pm runtime
autosuspend timeout, the card will be suspended.
Once a new request arrives, the card will be re-initalized and
thus the first request will suffer from a latenc
From: Ulf Hansson
SDIO has been using runtime pm for a while to handle runtime power save
operations. This patchset is enabling the option to make the sd/mmc
blockdevices to use runtime pm as well.
The runtime pm implementation for the block device will make use of
autosuspend to defer power sav
On 2 May 2013 12:38, Adrian Hunter wrote:
> On 16/04/13 13:00, Ulf Hansson wrote:
>> Aggressive power management is suitable when saving power is
>> essential. At request inactivity timeout, aka pm runtime
>> autosuspend timeout, the card will be suspended.
>>
>> Once a new request arrives, the ca
On 2 May 2013 11:57, Asutosh Das wrote:
> On 5/2/2013 3:22 PM, Ulf Hansson wrote:
>>
>> On 2 May 2013 10:58, Adrian Hunter wrote:
>>>
>>> On 16/04/13 13:00, Ulf Hansson wrote:
From: Ulf Hansson
Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using
On 16/04/13 13:00, Ulf Hansson wrote:
> Aggressive power management is suitable when saving power is
> essential. At request inactivity timeout, aka pm runtime
> autosuspend timeout, the card will be suspended.
>
> Once a new request arrives, the card will be re-initalized and
> thus the first req
On 5/2/2013 3:22 PM, Ulf Hansson wrote:
On 2 May 2013 10:58, Adrian Hunter wrote:
On 16/04/13 13:00, Ulf Hansson wrote:
From: Ulf Hansson
Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inact
On 2 May 2013 10:58, Adrian Hunter wrote:
> On 16/04/13 13:00, Ulf Hansson wrote:
>> From: Ulf Hansson
>>
>> Once the mmc blkdevice is being probed, runtime pm will be enabled.
>> By using runtime autosuspend, the power save operations can be done
>> when request inactivity occurs for a certain t
On 16/04/13 13:00, Ulf Hansson wrote:
> From: Ulf Hansson
>
> Once the mmc blkdevice is being probed, runtime pm will be enabled.
> By using runtime autosuspend, the power save operations can be done
> when request inactivity occurs for a certain time. Right now the
> selected timeout value is se
13 matches
Mail list logo
