Re: [PATCH 0/3] mmc: Use runtime pm for blkdevice

Kevin Liu
2013-03-07T09:38:15Z

2013/3/7 Ulf Hansson <ulf.hansson@linaro.org>:
> On 7 March 2013 01:12, Kevin Liu <keyuan.liu@gmail.com> wrote:
>>> From: Ulf Hansson <ulf.hansson@stericsson.com<mailto:ulf.hansson@stericsson.com>>
>>> Date: Fri, Mar 1, 2013 at 8:47 PM
>>> Subject: [PATCH 0/3] mmc: Use runtime pm for blkdevice
>>> To: linux-mmc@vger.kernel.org<mailto:linux-mmc@vger.kernel.org>, Chris Ball <cjb@laptop.org<mailto:cjb@laptop.org>>
>>> Cc: Johan Rudholm <johan.rudholm@stericsson.com<mailto:johan.rudholm@stericsson.com>>, Ulf Hansson <ulf.hansson@linaro.org<mailto:ulf.hansson@linaro.org>>
>>>
>>>
>>> From: Ulf Hansson <ulf.hansson@linaro.org<mailto:ulf.hansson@linaro.org>>
>>>
>>> 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 save operation to after request inactivty for
>>> a certain time.
>>>
>>> To actually perform some power save operations the corresponding bus ops
>>> for mmc and sd shall be implemented. Typically it could make sense to do
>>> BKOPS for eMMC in here.
>>>
>>> Ulf Hansson (3):
>>> mmc: core: Remove power_restore bus_ops for mmc and sd
>>> mmc: core: Add bus_ops for runtime pm callbacks
>>> mmc: block: Enable runtime pm for mmc blkdevice
>>>
>> Ulf,
>>
>> sdhci.c has added pm_runtime which also protect between request and
>> task finish. And some sdhci.c based host drivers has provided
>> pm_runtime_suspend/resume functions like sdhci-pxav3.c. From the
>> powersave viewpoint, I think adding pm_runtime in driver level is
>> better than doing that on bus level since the control granularity is
>> even smaller. And adding pm_runtime in both block.c and sdhci.c will
>> call pm_runtime twice. How do you think?
>>
>> Thanks
>> Kevin
>
> Hi Kevin,
>
> Thanks for your response!
>
> It seems like we need some more clarification around this area.
> Runtime pm for a host device driver shall ultimately be responsible
> for taking care of runtime power management of the host device - only.
> It should not handle runtime power management of a block device, which
> in principle means BKOPS shall be handled in the blkdevice. At least
> this is my view.
>
> So, why is this? I will try to elaborate on the runtime pm support in
> host drivers here.
> The host device driver controls a MMC/SD/SDIO IP. This IP could very
> well reside (for some SoC) in what you call a power domain. In
> principle, once the IP needs to be used, a host driver has done a
> pm_runtime_get of it's device. This will mean a reference to the power
> domain has been fetched. Once the IP is not needed any more,
> pm_runtime_put is done and the reference to the power domain is
> released. Once no reference to the power domain exist the power domain
> can enter lower sleep states, which is preferred to happen as soon as
> possible and as long as possible - of course.
>
> Hope this gives a better understanding. :-)
>
Ulf,

Thanks for the explanations!
Then do you mean to start bkops when blkdev pm_runtime auto suspended
while stop bkops when blkdev pm_runtime resumed?
My only concern is that we have implemented pm_runtime for host device
and its pm_runtime functions will turn on/off bus clock when host dev
runtime resume/suspend. Let's see below sequence when an issue request
come:
1. blkdev pm_runtime resumed in mmc_blk_issue_rq.
2. blkdev issue request
3. host dev pm_runtime resumed in host->ops->request.
4. host finished the transfer and host dev pm_runtime suspended.
5. 3s later, blkdev pm_runtime suspended.
The bus clock will be turn off in step 4 by host dev
pm_runtime_suspend function. Then how can bkops run in step 5?

Kevin