[PATCH] mmc: mmci: Improve runtime PM support

[Linus Walleij]

2011/10/24 Ulf Hansson <ulf.hansson at 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?

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

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