mmc: mmci: Update regulator support
Subsystems (2)
cover mmc: mmci: Update regulator support
From: Ulf Hansson <[email protected]>
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(-)
Signature · 1 line
1.7.10
PATCH 1/2 mmc: mmci: Convert to use mmc_regulator_get_supply
From: Ulf Hansson <[email protected]>
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.
--- drivers/mmc/host/mmci.c | 54 ++++++++++------------------------------------- drivers/mmc/host/mmci.h | 1 - 2 files changed, 11 insertions(+), 44 deletions(-)
drivers/mmc/host/mmci.c +11 -43
@@ -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);
drivers/mmc/host/mmci.h +0 -1
@@ -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;
Signature · 1 line
1.7.10
PATCH v2 2/2 mmc: mmci: Move ios_handler functionality into the driver
In reply to Ulf HanssonFrom: Lee Jones <[email protected]>
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.
--- drivers/mmc/host/mmci.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/mmc/host/mmci.c +9 -0
@@ -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 ; }
Signature · 1 line
1.7.10
PATCH v2 2/2 mmc: mmci: Move ios_handler functionality into the driver
Quoted 7 lines · Ulf Hansson
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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?
Quoted 1 line
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
Quoted 10 lines · Russell King - ARM Linux
Quoted 7 lines · Ulf Hansson
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.
Quoted 2 lines
From what I read in the mmc core, vmmc handling via
mmc_regulator_set_ocr()
Quoted 3 lines
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
Quoted 5 lines
--
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>
PATCH v2 2/2 mmc: mmci: Move ios_handler functionality into the driver
In reply to Russell King - ARM LinuxQuoted 10 lines · Russell King - ARM Linux
Quoted 7 lines · Ulf Hansson
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.
Quoted 4 lines
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.
Signature · 4 lines
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
In reply to Ulf HanssonQuoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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?
Quoted 35 lines
Cc Chris Ball <[email protected]>Cc Russell King <[email protected]>Signed-off-by Lee Jones <[email protected]>Signed-off-by Ulf Hansson <[email protected]>--- drivers/mmc/host/mmci.c | 9 +++++++++ 1 file changed, 9 insertions(+)drivers/mmc/host/mmci.c +9
-0@@ -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 ; }
Signature · 4 lines
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
Quoted 11 lines · Lee Jones
Quoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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
Quoted 10 lines · Linus Walleij
Quoted 8 lines · Lee Jones
Quoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 4 lines · Russell King - ARM Linux
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
In reply to Russell King - ARM LinuxQuoted 20 lines · Russell King - ARM Linux
Quoted 10 lines · Linus Walleij
Quoted 8 lines · Lee Jones
Quoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.Quoted 8 lines
Quoted 3 lines
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.
Quoted 4 lines
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?
Signature · 4 lines
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
Quoted 22 lines · Lee Jones
Quoted 20 lines · Russell King - ARM Linux
Quoted 18 lines · Linus Walleij
Quoted 11 lines · Lee Jones
Quoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.
Quoted 6 lines
Quoted 4 lines
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
Quoted 28 lines · Russell King - ARM Linux
Quoted 27 lines · Lee Jones
Quoted 24 lines · Russell King - ARM Linux
Quoted 10 lines · Linus Walleij
Quoted 8 lines · Lee Jones
Quoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.Quoted 8 lines
Quoted 3 lines
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.
Quoted 4 lines
Quoted 1 line
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?
Signature · 4 lines
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
Quoted 30 lines · Lee Jones
Quoted 28 lines · Russell King - ARM Linux
Quoted 27 lines · Lee Jones
Quoted 24 lines · Russell King - ARM Linux
Quoted 10 lines · Linus Walleij
Quoted 8 lines · Lee Jones
Quoted 7 lines
From: Lee Jones <[email protected]>
There are currently two instances of the
ios_handlerbeing 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.Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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.
Signature · 4 lines
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
Quoted 9 lines · Lee Jones
Quoted 3 lines · Lee Jones
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
Quoted 11 lines · Russell King - ARM Linux
Quoted 9 lines · Lee Jones
Quoted 3 lines · Lee Jones
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.
Quoted 4 lines
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.
Signature · 4 lines
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
Quoted 20 lines · Lee Jones
Quoted 11 lines · Russell King - ARM Linux
Quoted 9 lines · Lee Jones
Quoted 3 lines · Lee Jones
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.
Quoted 4 lines
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.
Quoted 7 lines
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