public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Sujit Reddy Thumma <sthumma@codeaurora.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Liu <keyuan.liu@gmail.com>,
	Ulf Hansson <ulf.hansson@stericsson.com>,
	linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>,
	Johan Rudholm <johan.rudholm@stericsson.com>
Subject: Re: [PATCH 0/3] mmc: Use runtime pm for blkdevice
Date: Wed, 20 Mar 2013 21:14:03 +0530	[thread overview]
Message-ID: <5149D943.8030903@codeaurora.org> (raw)
In-Reply-To: <CAPDyKFr0UT1aPxhg69hicC6xBHoMPwfNVP688gjoJQMZrPspzw@mail.gmail.com>

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

If any driver wants to implement this then the runtime PM code would be 
refactored again. So I guess we might want to think about this now itself?

What about SD cards? For SD cards the runtime PM is not doing any 
advantage but instead waste cpu cycles with a timer interrupt and 
running noop runtime PM callbacks? I guess allowing to power off cards 
in such cases would have decent power savings.

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

Thanks a lot. I have missed this discussion :(
I have some comments on the possible solutions:

"In mmc bus_ops runtime callback, do a pm_runtime_get_sync("host plf
device"), and vice verse in the runtime resume callback. This will
prevent the host driver from entering runtime power save sate while
for example doing BKOPS, thus preventing your host driver from doing
mmc_suspend_host while BKOPS is running"

[Sujit] In addition, probably we can allow host to turn off the clocks 
while carrying out BKOPS. But, how can we know whether card is done with 
BKOPS and is idle so that we can call mmc_suspend_host()?

"Move mmc_suspend|resume_host from your host runtime callbacks, into
the bus_ops runtime callbacks. Typically, when no BKOPS is needed
mmc_suspend_host can be done."

[Sujit] Doesn't it look like we are establishing parent child 
relationship here? If the card has nothing to do, suspend the host?


-- 
Regards,
Sujit

  reply	other threads:[~2013-03-20 15:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ED64882F200EF5419CDAC2E6B5C4B3A2097FC4412E@SC-VEXCH1.marvell.com>
     [not found] ` <25B60CDC2F704E4E9D88FFD52780CB4C0BDE9E0DE9@SC-VEXCH1.marvell.com>
2013-03-06 17:12   ` FW: [PATCH 0/3] mmc: Use runtime pm for blkdevice Kevin Liu
2013-03-07  3:41     ` Ulf Hansson
2013-03-07  9:38       ` Kevin Liu
2013-03-07 14:14         ` Kevin Liu
2013-03-08  3:14           ` Ulf Hansson
2013-03-08  4:38             ` Kevin Liu
2013-03-15  4:18             ` Sujit Reddy Thumma
2013-03-15  8:50               ` Ulf Hansson
2013-03-20 15:44                 ` Sujit Reddy Thumma [this message]
2013-03-20 21:58                   ` Ulf Hansson
2013-03-20 22:04                     ` Ulf Hansson
2013-03-27 18:25                     ` Sujit Reddy Thumma
     [not found] <25B60CDC2F704E4E9D88FFD52780CB4C0BDED3BFE1@SC-VEXCH1.marvell.com>
2013-03-28  1:43 ` Kevin Liu
2013-03-28 21:05   ` merez
2013-04-02 10:45     ` Ulf Hansson
2013-04-03 10:51       ` Maya Erez
2013-03-01 12:47 Ulf Hansson
2013-03-02 20:00 ` Maya Erez
2013-03-27 13:31 ` Chris Ball
2013-03-27 13:40 ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5149D943.8030903@codeaurora.org \
    --to=sthumma@codeaurora.org \
    --cc=cjb@laptop.org \
    --cc=johan.rudholm@stericsson.com \
    --cc=keyuan.liu@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=ulf.hansson@stericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox