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?
--
Regards,
Sujit
--
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
