On 15 March 2013 05:18, Sujit Reddy Thumma <sthu...@codeaurora.org> wrote: > On 3/8/2013 8:44 AM, Ulf Hansson wrote: >> >> On 7 March 2013 22:14, Kevin Liu <keyuan....@gmail.com> wrote: >>> >>> 2013/3/7 Kevin Liu <keyuan....@gmail.com>: >>>> >>>> 2013/3/7 Ulf Hansson <ulf.hans...@linaro.org>: >>>>> >>>>> On 7 March 2013 01:12, Kevin Liu <keyuan....@gmail.com> wrote: >>>>>>> >>>>>>> From: Ulf Hansson >>>>>>> <ulf.hans...@stericsson.com<mailto:ulf.hans...@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 <c...@laptop.org<mailto:c...@laptop.org>> >>>>>>> Cc: Johan Rudholm >>>>>>> <johan.rudh...@stericsson.com<mailto:johan.rudh...@stericsson.com>>, Ulf >>>>>>> Hansson <ulf.hans...@linaro.org<mailto:ulf.hans...@linaro.org>> >>>>>>> >>>>>>> >>>>>>> From: Ulf Hansson >>>>>>> <ulf.hans...@linaro.org<mailto:ulf.hans...@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? >>>> >>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
