diff mbox

mmc: sdio add regulator vsdio

Message ID 1311215673-2489-2-git-send-email-zhangfei.gao@marvell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Zhangfei Gao July 21, 2011, 2:34 a.m. UTC
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(-)

Comments

Daniel Drake July 22, 2011, 6:50 a.m. UTC | #1
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
Zhangfei Gao July 22, 2011, 7:25 a.m. UTC | #2
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
>
--
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
Philip Rakity July 22, 2011, 4:05 p.m. UTC | #3
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

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

Patch

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 */