2013/3/8 Ulf Hansson <[email protected]>: > On 7 March 2013 22:14, Kevin Liu <[email protected]> wrote: >> 2013/3/7 Kevin Liu <[email protected]>: >>> 2013/3/7 Ulf Hansson <[email protected]>: >>>> On 7 March 2013 01:12, Kevin Liu <[email protected]> wrote: >>>>>> From: Ulf Hansson >>>>>> <[email protected]<mailto:[email protected]>> >>>>>> Date: Fri, Mar 1, 2013 at 8:47 PM >>>>>> Subject: [PATCH 0/3] mmc: Use runtime pm for blkdevice >>>>>> To: [email protected]<mailto:[email protected]>, Chris >>>>>> Ball <[email protected]<mailto:[email protected]>> >>>>>> Cc: Johan Rudholm >>>>>> <[email protected]<mailto:[email protected]>>, Ulf >>>>>> Hansson <[email protected]<mailto:[email protected]>> >>>>>> >>>>>> >>>>>> From: Ulf Hansson <[email protected]<mailto:[email protected]>> >>>>>> >>>>>> 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. >
Got it. Thanks! > Kind regards > Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
