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