mmc: perform SDIO reset on power restore of host

On some boards card power is hard wired to the slot and active regardless of host controller state. When runtime PM suspends such a host, certain cards may keep their current configuration (e.g. bus width), now when runtime PM resumes the host, communication with the card will fail.
This was observed on AP4EVB with tmio_mmc and a b43 based SDIO card:
http://marc.info/?l=linux-mmc&m=128854536521274&w=2

This patch, fixes the problem by resetting the SDIO card on power restore.

---
 drivers/mmc/core/core.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

index 31ae07a..21cdee6 100644
@@ -1617,8 +1617,13 @@ int mmc_power_restore_host(struct mmc_host *host)
 	}
 
 	mmc_power_up(host);
-	ret = host->bus_ops->power_restore(host);
 
+	mmc_claim_host(host);
+	sdio_reset(host);
+	mmc_go_idle(host);
+	mmc_release_host(host);
+
+	ret = host->bus_ops->power_restore(host);
 	mmc_bus_put(host);
 
 	return ret;

1.7.2.3

...

Do you mean that your card is always powered on regardless of mmc_power_off() invocations ?

I always wondered why SDIO runtime PM didn't work with your card, so thanks for the follow up on this.

That said, if you card can't be powered down, then it shouldn't be MMC_CAP_POWER_OFF_CARD at all (which literally means that the card can be powered down).

And if it isn't MMC_CAP_POWER_OFF_CARD, then runtime PM will stay disabled for the card, so the problem you describe can't happen.

Thanks,
Ohad.

Hi Ohad,

Am 28.12.2010 13:45, schrieb Ohad Ben-Cohen:

Yes, it seems so.

Even if the card is kept powered, when mmc_power_off() is called, the host controller will stop the SD bus clock. So I believe at least some power is saved this way and MMC_CAP_POWER_OFF_CARD makes sense?

Thanks,
Arnd

Hi Arnd,

Ok, thanks for letting us know.

It bothered me that we didn't understand the issue you had, but now it seems that MMC_CAP_POWER_OFF_CARD is the right solution for you as well.

Well, with some SDIO cards, the host controller can use the recently added aggressive clock gating framework to stop the clock on inactivity, and not wait until the card is powered off.

Currently that clock gating framework is still disabled for SDIO cards, but this is just temporary until we sort out how to use it safely for SDIO as well.

For example, the wl1271 card has asynchronous interrupts (via external irq) so we can safely stop its clock on inactivity.

Do you know if that's possible with your card as well ?

Thanks,
Ohad.

Hi Ohad,

Am 28.12.2010 15:24, schrieb Ohad Ben-Cohen:

So you suggest to don't set MMC_CAP_POWER_OFF_CARD for the boards which keep the card powered, but instead wait for the clock gating framework?

I don't think so, the card is a normal SDIO card which plugs into a normal MMC/SD slot, no extra pins or such. However SDIO IRQs are available, but you don't mean that, do you?

Thanks,
Arnd

Hi Arnd,

Yes, if you can't power off your card, it doesn't make a lot of sense to set it MMC_CAP_POWER_OFF_CARD.

If the reason is to notify the host controller, via runtime PM, to disable the clock to the card, we need first to see that it works (have you tested it ? how ?): currently there are no host controllers which employ runtime PM. It looks like sdhci is about to, but it is still not clear how exactly - it is just being discussed.

Moreover, it seems that host controllers will ignore the card's runtime PM status, in order to allow them to independently manage their runtime PM status (and by that disable clocks more aggressively).

So I'd wait to see how those discussions evolve (or jump in and have my use case considered) but before that it won't make a lot of sense to add MMC_CAP_POWER_OFF_CARD for cards that are always powered on, because it is currently still not clear that it will yield any benefit.

Some cards do support asynchronous SDIO IRQs (do you know if yours too btw ?). How this is going to be safely employed is still in discussions...

Thanks,
Ohad.