| Message ID | 1355495429-12510-3-git-send-email-ulf.hansson@stericsson.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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?
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 >
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.
> 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; > }
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
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.
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
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?
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.
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?
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.
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.
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.
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
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; }