Linus Walleij wrote:
2011/10/24 Ulf Hansson <ulf.hansson@xxxxxxxxxxxxxx>:
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
--
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
