Re: [RFC] sdhci: use ios->clock to know when sdhci is idle

From: Pierre Tardy
Date: Mon Dec 27 2010 - 06:51:41 EST


On Thu, Dec 23, 2010 at 8:02 AM, Yuan, Hang <hang.yuan@xxxxxxxxx> wrote:
> Just have a question why not let sdio card driver call pm_runtime_get/put instead of host
> controller driver itself?
Because sdio card maintain its own power via runtime_pm, and sdhci
wants to manage its power more independantly, and go suspended more
often than the sdio card. A wifi sdio card would be active when
background scanning for network. During that time, the sdio bus is
completly inactive (for full-mac wifi device), and sdhci can go
suspended during that time.
Lowest SoC platform state can be achieved during that time.

> This patch may suspend host controller without cooperation of sdio card driver. But suspending
> host controller will change controller's registers and then impact sdio card. I think it's
> safer to suspend host controller according to sdio card driver's notification following runtime
> PM framework.
The sdhci must suspend itself without impacting the sdio card.

> Another question is why to call pm_runtime_get/put when ios-clock changes? Is it based on
> Linus Walleij's aggressive clock gating framework patch? Linus' patch doesn't gate SDIO cards.
runtime_suspend of sdhci should *not* gate the sdio card. It should
only gate the sdhci.
An sdio bus inactive does not mean that the sdio card is inactive.
(think wifi Idle, bluetooth idle, ethernet idle)

We need to suspend the sdhci as soon as the sdio bus is inactive,
which is what clock gating framework is trying to detect. It does not
do usage counting via runtime_pm because it is generic enough to allow
clock gating *and* power gating.

Regards,
Pierre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/