[PATCH 0/2] mmc: mmci: Update regulator support

[PATCH 0/2] mmc: mmci: Update regulator support

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

In this patchset the mmci driver is converted to use the new
mmc_regulator_get_supply API for handling regulators and OCR
mask.

On top of that we are taking the first step of moving away
from using the platform callback, ios_handler, to be more
DT compliant.

Lee Jones (1):
  mmc: mmci: Move ios_handler functionality into the driver

Ulf Hansson (1):
  mmc: mmci: Convert to use mmc_regulator_get_supply

 drivers/mmc/host/mmci.c |   63 +++++++++++++++--------------------------------
 drivers/mmc/host/mmci.h |    1 -
 2 files changed, 20 insertions(+), 44 deletions(-)

-- 
1.7.10

[PATCH 0/2] mmc: mmci: Update regulator support

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

In this patchset the mmci driver is converted to use the new
mmc_regulator_get_supply API for handling regulators and OCR
mask.

On top of that we are taking the first step of moving away
from using the platform callback, ios_handler, to be more
DT compliant.

Lee Jones (1):
  mmc: mmci: Move ios_handler functionality into the driver

Ulf Hansson (1):
  mmc: mmci: Convert to use mmc_regulator_get_supply

 drivers/mmc/host/mmci.c |   63 +++++++++++++++--------------------------------
 drivers/mmc/host/mmci.h |    1 -
 2 files changed, 20 insertions(+), 44 deletions(-)

-- 
1.7.10

[PATCH 1/2] mmc: mmci: Convert to use mmc_regulator_get_supply

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

By using the mmc_regulator_get_supply API we are able to do some
cleanups of the regulator code. Additionally let the regulator
API handle the error printing.

Cc: Chris Ball <cjb@laptop.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |   54 ++++++++++-------------------------------------
 drivers/mmc/host/mmci.h |    1 -
 2 files changed, 11 insertions(+), 44 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index aa04b42..9da5f24 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1086,7 +1086,6 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	struct variant_data *variant = host->variant;
 	u32 pwr = 0;
 	unsigned long flags;
-	int ret;
 
 	pm_runtime_get_sync(mmc_dev(mmc));
 
@@ -1096,23 +1095,13 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 	switch (ios->power_mode) {
 	case MMC_POWER_OFF:
-		if (host->vcc)
-			ret = mmc_regulator_set_ocr(mmc, host->vcc, 0);
+		if (!IS_ERR(mmc->supply.vmmc))
+			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
 		break;
 	case MMC_POWER_UP:
-		if (host->vcc) {
-			ret = mmc_regulator_set_ocr(mmc, host->vcc, ios->vdd);
-			if (ret) {
-				dev_err(mmc_dev(mmc), "unable to set OCR\n");
-				/*
-				 * The .set_ios() function in the mmc_host_ops
-				 * struct return void, and failing to set the
-				 * power should be rare so we print an error
-				 * and return here.
-				 */
-				goto out;
-			}
-		}
+		if (!IS_ERR(mmc->supply.vmmc))
+			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
+
 		/*
 		 * The ST Micro variant doesn't have the PL180s MCI_PWR_UP
 		 * and instead uses MCI_PWR_ON so apply whatever value is
@@ -1161,7 +1150,6 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 	spin_unlock_irqrestore(&host->lock, flags);
 
- out:
 	pm_runtime_mark_last_busy(mmc_dev(mmc));
 	pm_runtime_put_autosuspend(mmc_dev(mmc));
 }
@@ -1384,29 +1372,13 @@ static int mmci_probe(struct amba_device *dev,
 	} else
 		dev_warn(&dev->dev, "could not get default pinstate\n");
 
-#ifdef CONFIG_REGULATOR
-	/* If we're using the regulator framework, try to fetch a regulator */
-	host->vcc = regulator_get(&dev->dev, "vmmc");
-	if (IS_ERR(host->vcc))
-		host->vcc = NULL;
-	else {
-		int mask = mmc_regulator_get_ocrmask(host->vcc);
-
-		if (mask < 0)
-			dev_err(&dev->dev, "error getting OCR mask (%d)\n",
-				mask);
-		else {
-			host->mmc->ocr_avail = (u32) mask;
-			if (plat->ocr_mask)
-				dev_warn(&dev->dev,
-				 "Provided ocr_mask/setpower will not be used "
-				 "(using regulator instead)\n");
-		}
-	}
-#endif
-	/* Fall back to platform data if no regulator is found */
-	if (host->vcc == NULL)
+	/* Get regulators and the supported OCR mask */
+	mmc_regulator_get_supply(mmc);
+	if (!mmc->ocr_avail)
 		mmc->ocr_avail = plat->ocr_mask;
+	else if (plat->ocr_mask)
+		dev_warn(mmc_dev(mmc), "Platform OCR mask is ignored\n");
+
 	mmc->caps = plat->capabilities;
 	mmc->caps2 = plat->capabilities2;
 
@@ -1585,10 +1557,6 @@ static int mmci_remove(struct amba_device *dev)
 		clk_disable_unprepare(host->clk);
 		clk_put(host->clk);
 
-		if (host->vcc)
-			mmc_regulator_set_ocr(mmc, host->vcc, 0);
-		regulator_put(host->vcc);
-
 		mmc_free_host(mmc);
 
 		amba_release_regions(dev);
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index d34d8c0..a22213e 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -193,7 +193,6 @@ struct mmci_host {
 	/* pio stuff */
 	struct sg_mapping_iter	sg_miter;
 	unsigned int		size;
-	struct regulator	*vcc;
 
 	/* pinctrl handles */
 	struct pinctrl		*pinctrl;
-- 
1.7.10

[PATCH 1/2] mmc: mmci: Convert to use mmc_regulator_get_supply

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

By using the mmc_regulator_get_supply API we are able to do some
cleanups of the regulator code. Additionally let the regulator
API handle the error printing.

Cc: Chris Ball <cjb@laptop.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |   54 ++++++++++-------------------------------------
 drivers/mmc/host/mmci.h |    1 -
 2 files changed, 11 insertions(+), 44 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index aa04b42..9da5f24 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1086,7 +1086,6 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	struct variant_data *variant = host->variant;
 	u32 pwr = 0;
 	unsigned long flags;
-	int ret;
 
 	pm_runtime_get_sync(mmc_dev(mmc));
 
@@ -1096,23 +1095,13 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 	switch (ios->power_mode) {
 	case MMC_POWER_OFF:
-		if (host->vcc)
-			ret = mmc_regulator_set_ocr(mmc, host->vcc, 0);
+		if (!IS_ERR(mmc->supply.vmmc))
+			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
 		break;
 	case MMC_POWER_UP:
-		if (host->vcc) {
-			ret = mmc_regulator_set_ocr(mmc, host->vcc, ios->vdd);
-			if (ret) {
-				dev_err(mmc_dev(mmc), "unable to set OCR\n");
-				/*
-				 * The .set_ios() function in the mmc_host_ops
-				 * struct return void, and failing to set the
-				 * power should be rare so we print an error
-				 * and return here.
-				 */
-				goto out;
-			}
-		}
+		if (!IS_ERR(mmc->supply.vmmc))
+			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
+
 		/*
 		 * The ST Micro variant doesn't have the PL180s MCI_PWR_UP
 		 * and instead uses MCI_PWR_ON so apply whatever value is
@@ -1161,7 +1150,6 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 	spin_unlock_irqrestore(&host->lock, flags);
 
- out:
 	pm_runtime_mark_last_busy(mmc_dev(mmc));
 	pm_runtime_put_autosuspend(mmc_dev(mmc));
 }
@@ -1384,29 +1372,13 @@ static int mmci_probe(struct amba_device *dev,
 	} else
 		dev_warn(&dev->dev, "could not get default pinstate\n");
 
-#ifdef CONFIG_REGULATOR
-	/* If we're using the regulator framework, try to fetch a regulator */
-	host->vcc = regulator_get(&dev->dev, "vmmc");
-	if (IS_ERR(host->vcc))
-		host->vcc = NULL;
-	else {
-		int mask = mmc_regulator_get_ocrmask(host->vcc);
-
-		if (mask < 0)
-			dev_err(&dev->dev, "error getting OCR mask (%d)\n",
-				mask);
-		else {
-			host->mmc->ocr_avail = (u32) mask;
-			if (plat->ocr_mask)
-				dev_warn(&dev->dev,
-				 "Provided ocr_mask/setpower will not be used "
-				 "(using regulator instead)\n");
-		}
-	}
-#endif
-	/* Fall back to platform data if no regulator is found */
-	if (host->vcc == NULL)
+	/* Get regulators and the supported OCR mask */
+	mmc_regulator_get_supply(mmc);
+	if (!mmc->ocr_avail)
 		mmc->ocr_avail = plat->ocr_mask;
+	else if (plat->ocr_mask)
+		dev_warn(mmc_dev(mmc), "Platform OCR mask is ignored\n");
+
 	mmc->caps = plat->capabilities;
 	mmc->caps2 = plat->capabilities2;
 
@@ -1585,10 +1557,6 @@ static int mmci_remove(struct amba_device *dev)
 		clk_disable_unprepare(host->clk);
 		clk_put(host->clk);
 
-		if (host->vcc)
-			mmc_regulator_set_ocr(mmc, host->vcc, 0);
-		regulator_put(host->vcc);
-
 		mmc_free_host(mmc);
 
 		amba_release_regions(dev);
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index d34d8c0..a22213e 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -193,7 +193,6 @@ struct mmci_host {
 	/* pio stuff */
 	struct sg_mapping_iter	sg_miter;
 	unsigned int		size;
-	struct regulator	*vcc;
 
 	/* pinctrl handles */
 	struct pinctrl		*pinctrl;
-- 
1.7.10

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Ulf Hansson]

From: Lee Jones <lee.jones@linaro.org>

There are currently two instances of the ios_handler being used.
Both of which mearly toy with some regulator settings. Now there
is a GPIO regulator API, we can use that instead, and lessen the
per platform burden. By doing this, we also become more Device
Tree compatible.

Cc: Chris Ball <cjb@laptop.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 9da5f24..e56655a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1097,6 +1097,11 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	case MMC_POWER_OFF:
 		if (!IS_ERR(mmc->supply.vmmc))
 			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
+		if (!IS_ERR(mmc->supply.vqmmc) &&
+		    regulator_is_enabled(mmc->supply.vqmmc))
+			regulator_disable(mmc->supply.vqmmc);
+
 		break;
 	case MMC_POWER_UP:
 		if (!IS_ERR(mmc->supply.vmmc))
@@ -1111,6 +1116,10 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 		break;
 	case MMC_POWER_ON:
+		if (!IS_ERR(mmc->supply.vqmmc) &&
+		    !regulator_is_enabled(mmc->supply.vqmmc))
+			regulator_enable(mmc->supply.vqmmc);
+
 		pwr |= MCI_PWR_ON;
 		break;
 	}
-- 
1.7.10

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Ulf Hansson]

From: Lee Jones <lee.jones@linaro.org>

There are currently two instances of the ios_handler being used.
Both of which mearly toy with some regulator settings. Now there
is a GPIO regulator API, we can use that instead, and lessen the
per platform burden. By doing this, we also become more Device
Tree compatible.

Cc: Chris Ball <cjb@laptop.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/mmci.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 9da5f24..e56655a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1097,6 +1097,11 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	case MMC_POWER_OFF:
 		if (!IS_ERR(mmc->supply.vmmc))
 			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
+		if (!IS_ERR(mmc->supply.vqmmc) &&
+		    regulator_is_enabled(mmc->supply.vqmmc))
+			regulator_disable(mmc->supply.vqmmc);
+
 		break;
 	case MMC_POWER_UP:
 		if (!IS_ERR(mmc->supply.vmmc))
@@ -1111,6 +1116,10 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 		break;
 	case MMC_POWER_ON:
+		if (!IS_ERR(mmc->supply.vqmmc) &&
+		    !regulator_is_enabled(mmc->supply.vqmmc))
+			regulator_enable(mmc->supply.vqmmc);
+
 		pwr |= MCI_PWR_ON;
 		break;
 	}
-- 
1.7.10

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Fri, Dec 14, 2012 at 03:30:29PM +0100, Ulf Hansson wrote:
> From: Lee Jones <lee.jones@linaro.org>
> 
> There are currently two instances of the ios_handler being used.
> Both of which mearly toy with some regulator settings. Now there
> is a GPIO regulator API, we can use that instead, and lessen the
> per platform burden. By doing this, we also become more Device
> Tree compatible.

Err, why is this needed?  What's wrong with using the 'vmmc' for this?

>From what I read in the mmc core, vmmc handling via mmc_regulator_set_ocr()
can cope with GPIO-based regulators, and if you have a single GPIO signal
then you have a single supply (it's either on or off).  So what's wrong
with using the existing regulator hooks for this which are already there?

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Fri, Dec 14, 2012 at 03:30:29PM +0100, Ulf Hansson wrote:
> From: Lee Jones <lee.jones@linaro.org>
> 
> There are currently two instances of the ios_handler being used.
> Both of which mearly toy with some regulator settings. Now there
> is a GPIO regulator API, we can use that instead, and lessen the
> per platform burden. By doing this, we also become more Device
> Tree compatible.

Err, why is this needed?  What's wrong with using the 'vmmc' for this?

>From what I read in the mmc core, vmmc handling via mmc_regulator_set_ocr()
can cope with GPIO-based regulators, and if you have a single GPIO signal
then you have a single supply (it's either on or off).  So what's wrong
with using the existing regulator hooks for this which are already there?

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Ulf Hansson]

[-- Attachment #1.1: Type: text/plain, Size: 1205 bytes --]

On Friday, 14 December 2012, Russell King - ARM Linux <
linux@arm.linux.org.uk> wrote:
> On Fri, Dec 14, 2012 at 03:30:29PM +0100, Ulf Hansson wrote:
>> From: Lee Jones <lee.jones@linaro.org>
>>
>> There are currently two instances of the ios_handler being used.
>> Both of which mearly toy with some regulator settings. Now there
>> is a GPIO regulator API, we can use that instead, and lessen the
>> per platform burden. By doing this, we also become more Device
>> Tree compatible.
>
> Err, why is this needed?  What's wrong with using the 'vmmc' for this?

This is not for power to the card, but for the I/O voltage. Before this was
controlled by the ios_handler.

>
> From what I read in the mmc core, vmmc handling via
mmc_regulator_set_ocr()
> can cope with GPIO-based regulators, and if you have a single GPIO signal
> then you have a single supply (it's either on or off).  So what's wrong
> with using the existing regulator hooks for this which are already there?

Kind regards
Ulf Hansson

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

[-- Attachment #1.2: Type: text/html, Size: 1619 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Ulf Hansson]

On Friday, 14 December 2012, Russell King - ARM Linux <
linux@arm.linux.org.uk> wrote:
> On Fri, Dec 14, 2012 at 03:30:29PM +0100, Ulf Hansson wrote:
>> From: Lee Jones <lee.jones@linaro.org>
>>
>> There are currently two instances of the ios_handler being used.
>> Both of which mearly toy with some regulator settings. Now there
>> is a GPIO regulator API, we can use that instead, and lessen the
>> per platform burden. By doing this, we also become more Device
>> Tree compatible.
>
> Err, why is this needed?  What's wrong with using the 'vmmc' for this?

This is not for power to the card, but for the I/O voltage. Before this was
controlled by the ios_handler.

>
> From what I read in the mmc core, vmmc handling via
mmc_regulator_set_ocr()
> can cope with GPIO-based regulators, and if you have a single GPIO signal
> then you have a single supply (it's either on or off).  So what's wrong
> with using the existing regulator hooks for this which are already there?

Kind regards
Ulf Hansson

> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121214/abf80c4c/attachment-0001.html>

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Fri, 14 Dec 2012, Russell King - ARM Linux wrote:

> On Fri, Dec 14, 2012 at 03:30:29PM +0100, Ulf Hansson wrote:
> > From: Lee Jones <lee.jones@linaro.org>
> > 
> > There are currently two instances of the ios_handler being used.
> > Both of which mearly toy with some regulator settings. Now there
> > is a GPIO regulator API, we can use that instead, and lessen the
> > per platform burden. By doing this, we also become more Device
> > Tree compatible.
> 
> Err, why is this needed?  What's wrong with using the 'vmmc' for this?

It's a different regulator. The core knows about 'vmmc', which is the
primary one, then there is a regulator called 'vqmmc' which is for I/O
voltage. Until now this was done in a very platform specific way.
Normally by doing gpio_set's. Now there is a regulator API which can
deal with GPIO controlled regulators and there is provision for it in
MMC core also, so it's time to move it to the driver.

> From what I read in the mmc core, vmmc handling via mmc_regulator_set_ocr()
> can cope with GPIO-based regulators, and if you have a single GPIO signal
> then you have a single supply (it's either on or off).  So what's wrong
> with using the existing regulator hooks for this which are already there?

In our case it's not a 'fixed' regulator (i.e. on/off). The new GPIO
regulator API can also control voltage selection using GPIOs too.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Fri, 14 Dec 2012, Russell King - ARM Linux wrote:

> On Fri, Dec 14, 2012 at 03:30:29PM +0100, Ulf Hansson wrote:
> > From: Lee Jones <lee.jones@linaro.org>
> > 
> > There are currently two instances of the ios_handler being used.
> > Both of which mearly toy with some regulator settings. Now there
> > is a GPIO regulator API, we can use that instead, and lessen the
> > per platform burden. By doing this, we also become more Device
> > Tree compatible.
> 
> Err, why is this needed?  What's wrong with using the 'vmmc' for this?

It's a different regulator. The core knows about 'vmmc', which is the
primary one, then there is a regulator called 'vqmmc' which is for I/O
voltage. Until now this was done in a very platform specific way.
Normally by doing gpio_set's. Now there is a regulator API which can
deal with GPIO controlled regulators and there is provision for it in
MMC core also, so it's time to move it to the driver.

> From what I read in the mmc core, vmmc handling via mmc_regulator_set_ocr()
> can cope with GPIO-based regulators, and if you have a single GPIO signal
> then you have a single supply (it's either on or off).  So what's wrong
> with using the existing regulator hooks for this which are already there?

In our case it's not a 'fixed' regulator (i.e. on/off). The new GPIO
regulator API can also control voltage selection using GPIOs too.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

> From: Lee Jones <lee.jones@linaro.org>
> 
> There are currently two instances of the ios_handler being used.
> Both of which mearly toy with some regulator settings. Now there
> is a GPIO regulator API, we can use that instead, and lessen the
> per platform burden. By doing this, we also become more Device
> Tree compatible.

Russell,

Why is this patch in your tree with Ulf as the Author?

> Cc: Chris Ball <cjb@laptop.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>  drivers/mmc/host/mmci.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 9da5f24..e56655a 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1097,6 +1097,11 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  	case MMC_POWER_OFF:
>  		if (!IS_ERR(mmc->supply.vmmc))
>  			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> +		if (!IS_ERR(mmc->supply.vqmmc) &&
> +		    regulator_is_enabled(mmc->supply.vqmmc))
> +			regulator_disable(mmc->supply.vqmmc);
> +
>  		break;
>  	case MMC_POWER_UP:
>  		if (!IS_ERR(mmc->supply.vmmc))
> @@ -1111,6 +1116,10 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  
>  		break;
>  	case MMC_POWER_ON:
> +		if (!IS_ERR(mmc->supply.vqmmc) &&
> +		    !regulator_is_enabled(mmc->supply.vqmmc))
> +			regulator_enable(mmc->supply.vqmmc);
> +
>  		pwr |= MCI_PWR_ON;
>  		break;
>  	}

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

> From: Lee Jones <lee.jones@linaro.org>
> 
> There are currently two instances of the ios_handler being used.
> Both of which mearly toy with some regulator settings. Now there
> is a GPIO regulator API, we can use that instead, and lessen the
> per platform burden. By doing this, we also become more Device
> Tree compatible.

Russell,

Why is this patch in your tree with Ulf as the Author?

> Cc: Chris Ball <cjb@laptop.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>  drivers/mmc/host/mmci.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 9da5f24..e56655a 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1097,6 +1097,11 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  	case MMC_POWER_OFF:
>  		if (!IS_ERR(mmc->supply.vmmc))
>  			mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> +		if (!IS_ERR(mmc->supply.vqmmc) &&
> +		    regulator_is_enabled(mmc->supply.vqmmc))
> +			regulator_disable(mmc->supply.vqmmc);
> +
>  		break;
>  	case MMC_POWER_UP:
>  		if (!IS_ERR(mmc->supply.vmmc))
> @@ -1111,6 +1116,10 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  
>  		break;
>  	case MMC_POWER_ON:
> +		if (!IS_ERR(mmc->supply.vqmmc) &&
> +		    !regulator_is_enabled(mmc->supply.vqmmc))
> +			regulator_enable(mmc->supply.vqmmc);
> +
>  		pwr |= MCI_PWR_ON;
>  		break;
>  	}

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Linus Walleij]

On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:

>> From: Lee Jones <lee.jones@linaro.org>
>>
>> There are currently two instances of the ios_handler being used.
>> Both of which mearly toy with some regulator settings. Now there
>> is a GPIO regulator API, we can use that instead, and lessen the
>> per platform burden. By doing this, we also become more Device
>> Tree compatible.
>
> Russell,
>
> Why is this patch in your tree with Ulf as the Author?

This is because of the way Russell's patch tracker works, it sets
Author: to the name of the person using the patch tracker and
discards the From: field in the beginning of the patch which
git am will conversely respect.

If you need authorship preserved each author need to submit the
patch to the patch tracker individually, as author.

Yours,
Linus Walleij

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Linus Walleij]

On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:

>> From: Lee Jones <lee.jones@linaro.org>
>>
>> There are currently two instances of the ios_handler being used.
>> Both of which mearly toy with some regulator settings. Now there
>> is a GPIO regulator API, we can use that instead, and lessen the
>> per platform burden. By doing this, we also become more Device
>> Tree compatible.
>
> Russell,
>
> Why is this patch in your tree with Ulf as the Author?

This is because of the way Russell's patch tracker works, it sets
Author: to the name of the person using the patch tracker and
discards the From: field in the beginning of the patch which
git am will conversely respect.

If you need authorship preserved each author need to submit the
patch to the patch tracker individually, as author.

Yours,
Linus Walleij

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> 
> >> From: Lee Jones <lee.jones@linaro.org>
> >>
> >> There are currently two instances of the ios_handler being used.
> >> Both of which mearly toy with some regulator settings. Now there
> >> is a GPIO regulator API, we can use that instead, and lessen the
> >> per platform burden. By doing this, we also become more Device
> >> Tree compatible.
> >
> > Russell,
> >
> > Why is this patch in your tree with Ulf as the Author?
> 
> This is because of the way Russell's patch tracker works, it sets
> Author: to the name of the person using the patch tracker and
> discards the From: field in the beginning of the patch which
> git am will conversely respect.

Actually, the reverse.  It does now respect the From: line, but the
From: line will be ignored for all notifications about the patch
because the patch system was never built to parse the actual comments
when sending out the email notifications.

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> 
> >> From: Lee Jones <lee.jones@linaro.org>
> >>
> >> There are currently two instances of the ios_handler being used.
> >> Both of which mearly toy with some regulator settings. Now there
> >> is a GPIO regulator API, we can use that instead, and lessen the
> >> per platform burden. By doing this, we also become more Device
> >> Tree compatible.
> >
> > Russell,
> >
> > Why is this patch in your tree with Ulf as the Author?
> 
> This is because of the way Russell's patch tracker works, it sets
> Author: to the name of the person using the patch tracker and
> discards the From: field in the beginning of the patch which
> git am will conversely respect.

Actually, the reverse.  It does now respect the From: line, but the
From: line will be ignored for all notifications about the patch
because the patch system was never built to parse the actual comments
when sending out the email notifications.

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Linus Walleij]

On Tue, Jan 22, 2013 at 11:06 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> Actually, the reverse.  It does now respect the From: line, but the
> From: line will be ignored for all notifications about the patch
> because the patch system was never built to parse the actual comments
> when sending out the email notifications.

Yay! Thanks Russell.

Yours,
Linus Walleij

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Linus Walleij]

On Tue, Jan 22, 2013 at 11:06 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> Actually, the reverse.  It does now respect the From: line, but the
> From: line will be ignored for all notifications about the patch
> because the patch system was never built to parse the actual comments
> when sending out the email notifications.

Yay! Thanks Russell.

Yours,
Linus Walleij

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:

> On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > 
> > >> From: Lee Jones <lee.jones@linaro.org>
> > >>
> > >> There are currently two instances of the ios_handler being used.
> > >> Both of which mearly toy with some regulator settings. Now there
> > >> is a GPIO regulator API, we can use that instead, and lessen the
> > >> per platform burden. By doing this, we also become more Device
> > >> Tree compatible.
> > >
> > > Russell,
> > >
> > > Why is this patch in your tree with Ulf as the Author?
> > 
> > This is because of the way Russell's patch tracker works, it sets
> > Author: to the name of the person using the patch tracker and
> > discards the From: field in the beginning of the patch which
> > git am will conversely respect.
> 
> Actually, the reverse.  It does now respect the From: line, but the
> From: line will be ignored for all notifications about the patch
> because the patch system was never built to parse the actual comments
> when sending out the email notifications.

So what do I have to do to reaffirm myself as the author?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:

> On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > 
> > >> From: Lee Jones <lee.jones@linaro.org>
> > >>
> > >> There are currently two instances of the ios_handler being used.
> > >> Both of which mearly toy with some regulator settings. Now there
> > >> is a GPIO regulator API, we can use that instead, and lessen the
> > >> per platform burden. By doing this, we also become more Device
> > >> Tree compatible.
> > >
> > > Russell,
> > >
> > > Why is this patch in your tree with Ulf as the Author?
> > 
> > This is because of the way Russell's patch tracker works, it sets
> > Author: to the name of the person using the patch tracker and
> > discards the From: field in the beginning of the patch which
> > git am will conversely respect.
> 
> Actually, the reverse.  It does now respect the From: line, but the
> From: line will be ignored for all notifications about the patch
> because the patch system was never built to parse the actual comments
> when sending out the email notifications.

So what do I have to do to reaffirm myself as the author?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Tue, Jan 22, 2013 at 10:20:10AM +0000, Lee Jones wrote:
> On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > 
> > > >> From: Lee Jones <lee.jones@linaro.org>
> > > >>
> > > >> There are currently two instances of the ios_handler being used.
> > > >> Both of which mearly toy with some regulator settings. Now there
> > > >> is a GPIO regulator API, we can use that instead, and lessen the
> > > >> per platform burden. By doing this, we also become more Device
> > > >> Tree compatible.
> > > >
> > > > Russell,
> > > >
> > > > Why is this patch in your tree with Ulf as the Author?
> > > 
> > > This is because of the way Russell's patch tracker works, it sets
> > > Author: to the name of the person using the patch tracker and
> > > discards the From: field in the beginning of the patch which
> > > git am will conversely respect.
> > 
> > Actually, the reverse.  It does now respect the From: line, but the
> > From: line will be ignored for all notifications about the patch
> > because the patch system was never built to parse the actual comments
> > when sending out the email notifications.
> 
> So what do I have to do to reaffirm myself as the author?

I'd need to recommit the patch with the right information, which isn't
that easy to do.

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Tue, Jan 22, 2013 at 10:20:10AM +0000, Lee Jones wrote:
> On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > 
> > > >> From: Lee Jones <lee.jones@linaro.org>
> > > >>
> > > >> There are currently two instances of the ios_handler being used.
> > > >> Both of which mearly toy with some regulator settings. Now there
> > > >> is a GPIO regulator API, we can use that instead, and lessen the
> > > >> per platform burden. By doing this, we also become more Device
> > > >> Tree compatible.
> > > >
> > > > Russell,
> > > >
> > > > Why is this patch in your tree with Ulf as the Author?
> > > 
> > > This is because of the way Russell's patch tracker works, it sets
> > > Author: to the name of the person using the patch tracker and
> > > discards the From: field in the beginning of the patch which
> > > git am will conversely respect.
> > 
> > Actually, the reverse.  It does now respect the From: line, but the
> > From: line will be ignored for all notifications about the patch
> > because the patch system was never built to parse the actual comments
> > when sending out the email notifications.
> 
> So what do I have to do to reaffirm myself as the author?

I'd need to recommit the patch with the right information, which isn't
that easy to do.

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:

> On Tue, Jan 22, 2013 at 10:20:10AM +0000, Lee Jones wrote:
> > On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > > > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > 
> > > > >> From: Lee Jones <lee.jones@linaro.org>
> > > > >>
> > > > >> There are currently two instances of the ios_handler being used.
> > > > >> Both of which mearly toy with some regulator settings. Now there
> > > > >> is a GPIO regulator API, we can use that instead, and lessen the
> > > > >> per platform burden. By doing this, we also become more Device
> > > > >> Tree compatible.
> > > > >
> > > > > Russell,
> > > > >
> > > > > Why is this patch in your tree with Ulf as the Author?
> > > > 
> > > > This is because of the way Russell's patch tracker works, it sets
> > > > Author: to the name of the person using the patch tracker and
> > > > discards the From: field in the beginning of the patch which
> > > > git am will conversely respect.
> > > 
> > > Actually, the reverse.  It does now respect the From: line, but the
> > > From: line will be ignored for all notifications about the patch
> > > because the patch system was never built to parse the actual comments
> > > when sending out the email notifications.
> > 
> > So what do I have to do to reaffirm myself as the author?
> 
> I'd need to recommit the patch with the right information, which isn't
> that easy to do.

Are you saying that you won't do it? :)

Is there anything I can do to make the process easier?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:

> On Tue, Jan 22, 2013 at 10:20:10AM +0000, Lee Jones wrote:
> > On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > > > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > 
> > > > >> From: Lee Jones <lee.jones@linaro.org>
> > > > >>
> > > > >> There are currently two instances of the ios_handler being used.
> > > > >> Both of which mearly toy with some regulator settings. Now there
> > > > >> is a GPIO regulator API, we can use that instead, and lessen the
> > > > >> per platform burden. By doing this, we also become more Device
> > > > >> Tree compatible.
> > > > >
> > > > > Russell,
> > > > >
> > > > > Why is this patch in your tree with Ulf as the Author?
> > > > 
> > > > This is because of the way Russell's patch tracker works, it sets
> > > > Author: to the name of the person using the patch tracker and
> > > > discards the From: field in the beginning of the patch which
> > > > git am will conversely respect.
> > > 
> > > Actually, the reverse.  It does now respect the From: line, but the
> > > From: line will be ignored for all notifications about the patch
> > > because the patch system was never built to parse the actual comments
> > > when sending out the email notifications.
> > 
> > So what do I have to do to reaffirm myself as the author?
> 
> I'd need to recommit the patch with the right information, which isn't
> that easy to do.

Are you saying that you won't do it? :)

Is there anything I can do to make the process easier?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Tue, 22 Jan 2013, Lee Jones wrote:

> On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 22, 2013 at 10:20:10AM +0000, Lee Jones wrote:
> > > On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> > > 
> > > > On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > > > > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > 
> > > > > >> From: Lee Jones <lee.jones@linaro.org>
> > > > > >>
> > > > > >> There are currently two instances of the ios_handler being used.
> > > > > >> Both of which mearly toy with some regulator settings. Now there
> > > > > >> is a GPIO regulator API, we can use that instead, and lessen the
> > > > > >> per platform burden. By doing this, we also become more Device
> > > > > >> Tree compatible.
> > > > > >
> > > > > > Russell,
> > > > > >
> > > > > > Why is this patch in your tree with Ulf as the Author?
> > > > > 
> > > > > This is because of the way Russell's patch tracker works, it sets
> > > > > Author: to the name of the person using the patch tracker and
> > > > > discards the From: field in the beginning of the patch which
> > > > > git am will conversely respect.
> > > > 
> > > > Actually, the reverse.  It does now respect the From: line, but the
> > > > From: line will be ignored for all notifications about the patch
> > > > because the patch system was never built to parse the actual comments
> > > > when sending out the email notifications.
> > > 
> > > So what do I have to do to reaffirm myself as the author?
> > 
> > I'd need to recommit the patch with the right information, which isn't
> > that easy to do.
> 
> Are you saying that you won't do it? :)
> 
> Is there anything I can do to make the process easier?

Thinking about this a little more. Is it easier to remove it from your
tree altogether? Only I have a small "ARM: ux500: " patch-set which
directly relies on this patch. I could take it in via ARM-SoC without
any fear of ordering issues.

The alternative is for me to wait until this hits Mainline, or for you
to take in the remainder of the patch-set via your patch tracker. The
first option would be my preference.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Tue, 22 Jan 2013, Lee Jones wrote:

> On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 22, 2013 at 10:20:10AM +0000, Lee Jones wrote:
> > > On Tue, 22 Jan 2013, Russell King - ARM Linux wrote:
> > > 
> > > > On Tue, Jan 22, 2013 at 10:53:42AM +0100, Linus Walleij wrote:
> > > > > On Tue, Jan 22, 2013 at 10:00 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > 
> > > > > >> From: Lee Jones <lee.jones@linaro.org>
> > > > > >>
> > > > > >> There are currently two instances of the ios_handler being used.
> > > > > >> Both of which mearly toy with some regulator settings. Now there
> > > > > >> is a GPIO regulator API, we can use that instead, and lessen the
> > > > > >> per platform burden. By doing this, we also become more Device
> > > > > >> Tree compatible.
> > > > > >
> > > > > > Russell,
> > > > > >
> > > > > > Why is this patch in your tree with Ulf as the Author?
> > > > > 
> > > > > This is because of the way Russell's patch tracker works, it sets
> > > > > Author: to the name of the person using the patch tracker and
> > > > > discards the From: field in the beginning of the patch which
> > > > > git am will conversely respect.
> > > > 
> > > > Actually, the reverse.  It does now respect the From: line, but the
> > > > From: line will be ignored for all notifications about the patch
> > > > because the patch system was never built to parse the actual comments
> > > > when sending out the email notifications.
> > > 
> > > So what do I have to do to reaffirm myself as the author?
> > 
> > I'd need to recommit the patch with the right information, which isn't
> > that easy to do.
> 
> Are you saying that you won't do it? :)
> 
> Is there anything I can do to make the process easier?

Thinking about this a little more. Is it easier to remove it from your
tree altogether? Only I have a small "ARM: ux500: " patch-set which
directly relies on this patch. I could take it in via ARM-SoC without
any fear of ordering issues.

The alternative is for me to wait until this hits Mainline, or for you
to take in the remainder of the patch-set via your patch tracker. The
first option would be my preference.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
> On Tue, 22 Jan 2013, Lee Jones wrote:
> > Are you saying that you won't do it? :)
> > 
> > Is there anything I can do to make the process easier?
> 
> Thinking about this a little more. Is it easier to remove it from your
> tree altogether? Only I have a small "ARM: ux500: " patch-set which
> directly relies on this patch. I could take it in via ARM-SoC without
> any fear of ordering issues.

Thankfully, the patch doesn't conflict with any of the others I have, so
we can do that (and it's actually easier to do that.)

Done.

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Russell King - ARM Linux]

On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
> On Tue, 22 Jan 2013, Lee Jones wrote:
> > Are you saying that you won't do it? :)
> > 
> > Is there anything I can do to make the process easier?
> 
> Thinking about this a little more. Is it easier to remove it from your
> tree altogether? Only I have a small "ARM: ux500: " patch-set which
> directly relies on this patch. I could take it in via ARM-SoC without
> any fear of ordering issues.

Thankfully, the patch doesn't conflict with any of the others I have, so
we can do that (and it's actually easier to do that.)

Done.

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Wed, 23 Jan 2013, Russell King - ARM Linux wrote:

> On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
> > On Tue, 22 Jan 2013, Lee Jones wrote:
> > > Are you saying that you won't do it? :)
> > > 
> > > Is there anything I can do to make the process easier?
> > 
> > Thinking about this a little more. Is it easier to remove it from your
> > tree altogether? Only I have a small "ARM: ux500: " patch-set which
> > directly relies on this patch. I could take it in via ARM-SoC without
> > any fear of ordering issues.
> 
> Thankfully, the patch doesn't conflict with any of the others I have, so
> we can do that (and it's actually easier to do that.)
> 
> Done.

Brilliant, that's 2 birds with one stone. I'll queue it up for ARM-SoC.

Thanks Russell.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Lee Jones]

On Wed, 23 Jan 2013, Russell King - ARM Linux wrote:

> On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
> > On Tue, 22 Jan 2013, Lee Jones wrote:
> > > Are you saying that you won't do it? :)
> > > 
> > > Is there anything I can do to make the process easier?
> > 
> > Thinking about this a little more. Is it easier to remove it from your
> > tree altogether? Only I have a small "ARM: ux500: " patch-set which
> > directly relies on this patch. I could take it in via ARM-SoC without
> > any fear of ordering issues.
> 
> Thankfully, the patch doesn't conflict with any of the others I have, so
> we can do that (and it's actually easier to do that.)
> 
> Done.

Brilliant, that's 2 birds with one stone. I'll queue it up for ARM-SoC.

Thanks Russell.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Ulf Hansson]

On 23 January 2013 12:18, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 23 Jan 2013, Russell King - ARM Linux wrote:
>
>> On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
>> > On Tue, 22 Jan 2013, Lee Jones wrote:
>> > > Are you saying that you won't do it? :)
>> > >
>> > > Is there anything I can do to make the process easier?
>> >
>> > Thinking about this a little more. Is it easier to remove it from your
>> > tree altogether? Only I have a small "ARM: ux500: " patch-set which
>> > directly relies on this patch. I could take it in via ARM-SoC without
>> > any fear of ordering issues.
>>
>> Thankfully, the patch doesn't conflict with any of the others I have, so
>> we can do that (and it's actually easier to do that.)
>>
>> Done.
>
> Brilliant, that's 2 birds with one stone. I'll queue it up for ARM-SoC.
>
> Thanks Russell.
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

As long as it goes in for 3.9 I am happy. I am also depending on this
to add the UHS support for SD-cards for mmci. :-)

Kind regards
Ulf Hansson

[PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver

[Ulf Hansson]

On 23 January 2013 12:18, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 23 Jan 2013, Russell King - ARM Linux wrote:
>
>> On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
>> > On Tue, 22 Jan 2013, Lee Jones wrote:
>> > > Are you saying that you won't do it? :)
>> > >
>> > > Is there anything I can do to make the process easier?
>> >
>> > Thinking about this a little more. Is it easier to remove it from your
>> > tree altogether? Only I have a small "ARM: ux500: " patch-set which
>> > directly relies on this patch. I could take it in via ARM-SoC without
>> > any fear of ordering issues.
>>
>> Thankfully, the patch doesn't conflict with any of the others I have, so
>> we can do that (and it's actually easier to do that.)
>>
>> Done.
>
> Brilliant, that's 2 birds with one stone. I'll queue it up for ARM-SoC.
>
> Thanks Russell.
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

As long as it goes in for 3.9 I am happy. I am also depending on this
to add the UHS support for SD-cards for mmci. :-)

Kind regards
Ulf Hansson