From: ulf.hansson@stericsson.com (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: mmci: Improve runtime PM support
Date: Tue, 25 Oct 2011 09:39:12 +0200 [thread overview]
Message-ID: <4EA667A0.9070808@stericsson.com> (raw)
In-Reply-To: <CAKnu2MppySzpE5SxtqW_yV7KNEWw+tQ658i0pyfoUiwQCL2CGA@mail.gmail.com>
Linus Walleij wrote:
> 2011/10/24 Ulf Hansson <ulf.hansson@stericsson.com>:
>
>> Could we assume that all boards which utilizes the ARM PL180 are using the
>> MMCIPWR register to control power the card? Or should we add a new amba mmci
>> platform member so this is configurable for each board?
>
> I think we should take entire variants, like currently U300 and Ux500.
> In those designs the MMCIPWR signal is left dangling on the chip,
> so no-one electronics designer can use that signal for anything even
> if s/he would have wanted to.
>
>> An option could also be if we might want to simplify code to just skip the
>> entire runtime_suspend|idle|resume function (ie stubb it or something) for
>> these kind of boards?
>
> I think the clk_disable()/clk_enable() pair in runtime suspend/resume
> is still valuable for all other variants too. That has nothing to do with
> MMCIPWR.
>
>> By the way, there is also another option. In the runtime_suspend function
>> for ARM PL180 block we can use mmc_power_save_host (and then also
>> disable vcore etc) and vice verse in runtime_resume with
>> mmc_power_restore_host.
>
> This is what the OMAP driver does right?
Nope.
Right now I think it is only SDIO function drivers through pm_runtime
that can trigger the use of these functions though the bus registered
runtime functions.
>
>> Of course, these kind of operations takes quite some time to execute and
>> therefore we use a much bigger timeout than 50 ms (for example 10 s
>> instead) for ARM PL180.
>
> Can we do both?
That is possible! But I think we need confirmation from Russell first.
Using mmc_power_save_host/mmc_power_restore_host could be a way forward
for ARM PL180, but you should note that initializing a card after it has
been fully powered down, can for really crappy SD-cards take up to 1 s.
Normally this time is 100-400 ms.
This initialization time will then be the latency for the first
read/write after the runtime timeout has expired. There is always a cost
in "performance" when doing power save it seems. :-)
>
> 1) Break out mmci_state_save_restore() from the runtime PM hooks.
>
> 2) I.e. have a short time-out that will runtime-suspend the external
> regulator variants quickly with finer granularity.
>
> 3) Have a long time-out that will runtime-suspend the MMCIPWR
> variants using mmc_power_save_host() with a longer delay?
> Since mmc_power_save_host() calls .set_ios() to really shut
> down the power to the card we should be on the safe side.
>
> Looks like a nice silver bullet to me :-)
>
> I volunteer to test the long time-out code path on the Integrator
> PB1176 to verify this works.
>
> Yours,
> Linus Walleij
>
next prev parent reply other threads:[~2011-10-25 7:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-21 15:25 [PATCH] mmc: mmci: Improve runtime PM support Ulf Hansson
2011-10-21 17:36 ` Russell King - ARM Linux
[not found] ` <CAKnu2MrOriMzJH9NcwUivWa0cinASa6wrRf4a69si4WUs-aTrQ@mail.gmail.com>
2011-10-23 0:31 ` Sebastian Rasmussen
2011-10-24 8:05 ` Ulf Hansson
2011-10-24 9:04 ` Russell King - ARM Linux
2011-10-24 9:36 ` Ulf Hansson
2011-10-24 9:42 ` Russell King - ARM Linux
2011-10-24 10:06 ` Ulf Hansson
2011-10-24 10:14 ` Russell King - ARM Linux
2011-10-24 11:48 ` Ulf Hansson
2011-10-24 12:18 ` Linus Walleij
2011-10-24 15:25 ` Ulf Hansson
2011-10-24 15:34 ` Ulf Hansson
2011-10-25 7:12 ` Linus Walleij
2011-10-25 7:39 ` Ulf Hansson [this message]
2011-10-24 9:11 ` Sebastian Rasmussen
2011-10-24 9:14 ` Linus Walleij
2011-10-24 9:36 ` Russell King - ARM Linux
2011-10-24 9:54 ` Linus Walleij
2011-10-24 9:56 ` Russell King - ARM Linux
2011-10-24 10:17 ` Ulf Hansson
2011-10-24 11:49 ` Linus Walleij
2011-10-25 8:05 ` Adrian Hunter
2011-10-25 8:53 ` Linus Walleij
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=4EA667A0.9070808@stericsson.com \
--to=ulf.hansson@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).