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

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

 



On 15 March 2013 05:18, Sujit Reddy Thumma <sthumma@xxxxxxxxxxxxxx> wrote:
> On 3/8/2013 8:44 AM, Ulf Hansson wrote:
>>
>> On 7 March 2013 22:14, Kevin Liu <keyuan.liu@xxxxxxxxx> wrote:
>>>
>>> 2013/3/7 Kevin Liu <keyuan.liu@xxxxxxxxx>:
>>>>
>>>> 2013/3/7 Ulf Hansson <ulf.hansson@xxxxxxxxxx>:
>>>>>
>>>>> On 7 March 2013 01:12, Kevin Liu <keyuan.liu@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>> From: Ulf Hansson
>>>>>>> <ulf.hansson@xxxxxxxxxxxxxx<mailto:ulf.hansson@xxxxxxxxxxxxxx>>
>>>>>>> Date: Fri, Mar 1, 2013 at 8:47 PM
>>>>>>> Subject: [PATCH 0/3] mmc: Use runtime pm for blkdevice
>>>>>>> To: linux-mmc@xxxxxxxxxxxxxxx<mailto:linux-mmc@xxxxxxxxxxxxxxx>,
>>>>>>> Chris Ball <cjb@xxxxxxxxxx<mailto:cjb@xxxxxxxxxx>>
>>>>>>> Cc: Johan Rudholm
>>>>>>> <johan.rudholm@xxxxxxxxxxxxxx<mailto:johan.rudholm@xxxxxxxxxxxxxx>>, Ulf
>>>>>>> Hansson <ulf.hansson@xxxxxxxxxx<mailto:ulf.hansson@xxxxxxxxxx>>
>>>>>>>
>>>>>>>
>>>>>>> From: Ulf Hansson
>>>>>>> <ulf.hansson@xxxxxxxxxx<mailto:ulf.hansson@xxxxxxxxxx>>
>>>>>>>
>>>>>>> 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?
>>>>
>>> My question is host dev will stop bus clock by pm_runtime_suspend once
>>> the request transfer is finished. But bkops on emmc chip should still
>>> need the bus clock after bkops started. How to handle this?
>>
>>
>> According the eMMC spec I can't see any requirement that the bus clock
>> needs to be on while a BKOPS is running. Moreover it is clearly stated
>> it is allowed to gate the bus clock for a device which indicates busy.
>> So, I can't see that this is needed.
>>
>
> What if host is aggressive and wants to keep eMMC in sleep-mode and turn off
> VCC regulator during runtime power management? I believe that eMMC card
> needs VCC supply as well in addition to VCCQ to carry out BKOPS. Do you
> think that the block device also needs to take a reference for VCC regulator
> while BKOPS is started in runtime suspend of block device?

What you are thinking of would be exactly the same scenario as doing
"mmc_suspend_host" from a host runtime suspend callback, which have
been discussed here earlier. Right now, no up-streamed host driver is
doing this and I would guess it would never happen either. Anyway,
still worth to consider somehow.

Please have a look at below thread to find the answers to your questions:
http://thread.gmane.org/gmane.linux.kernel.mmc/19444/focus=19443


>
>
> --
> Regards,
> Sujit

Kind regards
Ulf Hansson
--
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