| Message ID | 1311215673-2489-2-git-send-email-zhangfei.gao@marvell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 21 July 2011 03:34, Zhangfei Gao <zhangfei.gao@marvell.com> wrote: > sdio client may be required power on/off dynamically. > With regulator vsdio, sdio client power on/off could be executed by mmc_power_up/down I think you can/should do this with vmmc. When the device gets powered down (e.g. in runtime suspend), the voltage should be cut, so it should be possible to use the existing regulator. I also looked at doing this before, when it looked like we would have to manipulate a GPIO reset line for SD8686. I decided that the current vmmc implementation in sdhci wasn't quite complete enough, but it wouldn't be much effort to correct this. Daniel
On Fri, Jul 22, 2011 at 2:50 PM, Daniel Drake <dsd@laptop.org> wrote: > On 21 July 2011 03:34, Zhangfei Gao <zhangfei.gao@marvell.com> wrote: >> sdio client may be required power on/off dynamically. >> With regulator vsdio, sdio client power on/off could be executed by mmc_power_up/down > > I think you can/should do this with vmmc. When the device gets powered > down (e.g. in runtime suspend), the voltage should be cut, so it > should be possible to use the existing regulator. Have considered re-use vmmc before, Consider dynamically power control only required for sdio, so use vsdio to exclude potential issue to sd/mmc. Anyway, will try re-use vmmc. > > I also looked at doing this before, when it looked like we would have > to manipulate a GPIO reset line for SD8686. I decided that the current > vmmc implementation in sdhci wasn't quite complete enough, but it > wouldn't be much effort to correct this. > > Daniel > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Could we have an architecture discussion about how this is supposed to be done and a picture please ! (a pointer to good working code would be nice) On brownstone the SDIO 8787 power is supplied by a ldo which is dedicated to the internal SDIO chip. The Power GPIO (PDn) is an on/off switch for the 8787. It does not affect the power from the ldo. What is the responsibility of the 8787 SDIO driver for power management ? It is obviously called at probe / init time. Is it supposed to turn on power ? I realize that it may not be aware of what device to power on? Does it register a call back ? Is it responsible for turning itself on/off at suspend/resume time? Thought about open time but the firmware needs to be loaded before the device can respond. Is firmware loading done at the right place ? Should it be done at open and NOT at probe? That way the driver could look present and open might handle firmware loading and power control. What is the responsibilty of MMC layer. Obviously it needs to supply power to the device on the bus. Is there supposed to be a callback in the board file that handles these specifics ? Would this call back then call then set the ldo on and turn on the 8787 ? regards, Philip On Jul 21, 2011, at 11:50 PM, Daniel Drake wrote: > On 21 July 2011 03:34, Zhangfei Gao <zhangfei.gao@marvell.com> wrote: >> sdio client may be required power on/off dynamically. >> With regulator vsdio, sdio client power on/off could be executed by mmc_power_up/down > > I think you can/should do this with vmmc. When the device gets powered > down (e.g. in runtime suspend), the voltage should be cut, so it > should be possible to use the existing regulator. > > I also looked at doing this before, when it looked like we would have > to manipulate a GPIO reset line for SD8686. I decided that the current > vmmc implementation in sdhci wasn't quite complete enough, but it > wouldn't be much effort to correct this. > > Daniel > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 790f959..61fff10 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1295,6 +1295,18 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) sdhci_set_clock(host, ios->clock); + if (host->vsdio) { + if (ios->power_mode != host->power_mode_old) { + if (ios->power_mode == MMC_POWER_OFF) + regulator_disable(host->vsdio); + + if (ios->power_mode == MMC_POWER_UP) + regulator_enable(host->vsdio); + } + + host->power_mode_old = ios->power_mode; + } + if (ios->power_mode == MMC_POWER_OFF) sdhci_set_power(host, -1); else @@ -2751,6 +2763,13 @@ int sdhci_add_host(struct sdhci_host *host) regulator_enable(host->vmmc); } + host->vsdio = regulator_get(mmc_dev(mmc), "vsdio"); + if (IS_ERR(host->vsdio)) + host->vsdio = NULL; + else + printk(KERN_INFO "%s: vsdio regulator found\n", + mmc_hostname(mmc)); + sdhci_init(host, 0); #ifdef CONFIG_MMC_DEBUG @@ -2842,6 +2861,11 @@ void sdhci_remove_host(struct sdhci_host *host, int dead) regulator_put(host->vmmc); } + if (host->vsdio) { + regulator_disable(host->vsdio); + regulator_put(host->vsdio); + } + kfree(host->adma_desc); kfree(host->align_buffer); diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h index 13c13f8..bea07c7 100644 --- a/include/linux/mmc/sdhci.h +++ b/include/linux/mmc/sdhci.h @@ -94,6 +94,8 @@ struct sdhci_host { const struct sdhci_ops *ops; /* Low level hw interface */ struct regulator *vmmc; /* Power regulator */ + struct regulator *vsdio; /* sdio Power regulator */ + unsigned char power_mode_old; /* power supply mode */ /* Internal data */ struct mmc_host *mmc; /* MMC structure */
sdio client may be required power on/off dynamically. With regulator vsdio, sdio client power on/off could be executed by mmc_power_up/down CC: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Zhangfei Gao <zhangfei.gao@marvell.com> --- drivers/mmc/host/sdhci.c | 24 ++++++++++++++++++++++++ include/linux/mmc/sdhci.h | 2 ++ 2 files changed, 26 insertions(+), 0 deletions(-)