Re: [PATCH] mmc: mmci: Improve runtime PM support

[Ulf Hansson <ulf.hansson@stericsson.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
>