On Thu, 26 Feb 2009 13:48:30 -0800
David Brownell <[email protected]> wrote:
> From: David Brownell <[email protected]>
>
> Add optional glue between MMC and regulator stacks, using a new
> regulator interface to learn what voltages are available.
>
> This is intended to be selected and driven by MMC host adapters.
> It only handles reusable parts of the regulator-to-MMC glue; the
> adapter drivers will have access to details that affect how this
> is used. Examples include when to use multiple voltage rails or
> configure (internal or external) level shifters.
>
> Signed-off-by: David Brownell <[email protected]>
> ---
> Changes from previous version: adapter must select this, and
> callers now pass in the regulator. mmc_regulator_set_ocr()
> is still not tested, mmc_regulator_get_ocrmask() passed sanity
> testing.
>
> Pierre: Mark may have a need for this soonish. The omap_hsmmc
> code will want it at some point.
>
I have no insight into the regulator stuff, so I'm going to have to
trust you on this. :)
Some nitpicking though:
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -14,3 +14,10 @@ config MMC_UNSAFE_RESUME
> This option is usually just for embedded systems which use
> a MMC/SD card for rootfs. Most people should say N here.
>
> +config MMC_REGULATOR
> + bool
> + depends on REGULATOR
> + help
> + Select this if your MMC host adapter driver wants helper
> + utilities for accessing power rails.
> +
Is there a need for a special Kconfig for this? Can't we just build
these two whenever REGULATOR is defined? Or always, provided the
regulator API is present even when the code isn't.
> +/**
> + * mmc_regulator_set_ocr - set regulator to match host->ios voltage
> + * @host: mmc host whose supply voltage will be changed
> + * @supply: regulator to use
> + *
> + * MMC host drivers may use this to enable or disable a regulator using
> + * a particular supply voltage. This would normally be called from the
> + * set_ios() method.
> + */
> +int mmc_regulator_set_ocr(struct mmc_host *host, struct regulator *supply)
> +{
Why not pass the vdd directly? Saves a few dereferences if nothing else.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Monday 02 March 2009, Pierre Ossman wrote:
> On Thu, 26 Feb 2009 13:48:30 -0800
> David Brownell <[email protected]> wrote:
>
> > From: David Brownell <[email protected]>
> >
> > Add optional glue between MMC and regulator stacks, using a new
> > regulator interface to learn what voltages are available.
> >
> > This is intended to be selected and driven by MMC host adapters.
> > It only handles reusable parts of the regulator-to-MMC glue; the
> > adapter drivers will have access to details that affect how this
> > is used. Examples include when to use multiple voltage rails or
> > configure (internal or external) level shifters.
> >
> > Signed-off-by: David Brownell <[email protected]>
> > ---
> > Changes from previous version: adapter must select this, and
> > callers now pass in the regulator. mmc_regulator_set_ocr()
> > is still not tested, mmc_regulator_get_ocrmask() passed sanity
> > testing.
> >
> > Pierre: Mark may have a need for this soonish. The omap_hsmmc
> > code will want it at some point.
> >
>
> I have no insight into the regulator stuff, so I'm going to have to
> trust you on this. :)
Works for me. ;)
> Some nitpicking though:
>
> > --- a/drivers/mmc/core/Kconfig
> > +++ b/drivers/mmc/core/Kconfig
> > @@ -14,3 +14,10 @@ config MMC_UNSAFE_RESUME
> > This option is usually just for embedded systems which use
> > a MMC/SD card for rootfs. Most people should say N here.
> >
> > +config MMC_REGULATOR
> > + bool
> > + depends on REGULATOR
> > + help
> > + Select this if your MMC host adapter driver wants helper
> > + utilities for accessing power rails.
> > +
>
> Is there a need for a special Kconfig for this? Can't we just build
> these two whenever REGULATOR is defined? Or always, provided the
> regulator API is present even when the code isn't.
The first patch had a "default y" there, nobody commented.
I'll simplify that, and use #ifdef CONFIG_REGULATOR instead.
> > +/**
> > + * mmc_regulator_set_ocr - set regulator to match host->ios voltage
> > + * @host: mmc host whose supply voltage will be changed
> > + * @supply: regulator to use
> > + *
> > + * MMC host drivers may use this to enable or disable a regulator using
> > + * a particular supply voltage. This would normally be called from the
> > + * set_ios() method.
> > + */
> > +int mmc_regulator_set_ocr(struct mmc_host *host, struct regulator *supply)
> > +{
>
> Why not pass the vdd directly? Saves a few dereferences if nothing else.
This call syntax is simpler, which is usually a win.
Passing a third parameter would create fault paths
of the "pass *wrong* parameter" flavor.
In terms of object code, when I've looked at such things
the dereferences generally cost the same as a ref to a
parameter, but passing an extra parameter isn't free.
- Dave
On Mon, 2 Mar 2009 13:27:13 -0800
David Brownell <[email protected]> wrote:
> On Monday 02 March 2009, Pierre Ossman wrote:
> > On Thu, 26 Feb 2009 13:48:30 -0800
> > David Brownell <[email protected]> wrote:
> >
> > > + */
> > > +int mmc_regulator_set_ocr(struct mmc_host *host, struct regulator *supply)
> > > +{
> >
> > Why not pass the vdd directly? Saves a few dereferences if nothing else.
>
> This call syntax is simpler, which is usually a win.
> Passing a third parameter would create fault paths
> of the "pass *wrong* parameter" flavor.
>
> In terms of object code, when I've looked at such things
> the dereferences generally cost the same as a ref to a
> parameter, but passing an extra parameter isn't free.
>
I couldn't see host being used in there, so I was thinking more of a
replacement, not an addition.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Monday 02 March 2009, Pierre Ossman wrote:
> > > > +int mmc_regulator_set_ocr(struct mmc_host *host, struct regulator *supply)
> > > > +{
> > >
> > > Why not pass the vdd directly? Saves a few dereferences if nothing else.
> >
> > This call syntax is simpler, which is usually a win.
> > Passing a third parameter would create fault paths
> > of the "pass *wrong* parameter" flavor.
> >
> > In terms of object code, when I've looked at such things
> > the dereferences generally cost the same as a ref to a
> > parameter, but passing an extra parameter isn't free.
> >
>
> I couldn't see host being used in there, so I was thinking more of a
> replacement, not an addition.
Oh, I see. That'd make sense. Just pass host->ios.vdd.
From: David Brownell <[email protected]>
Glue between MMC and regulator stacks ... compiles, and
mmc_regulator_get_ocrmask() passed sanity testing.
These calls are intended to be used by MMC host adapters
using at least one regulator per host. Examples include
slots with regulators supporting multiple voltages and
ones using multiple voltage rails (e.g. DAT4..DAT7 using a
separate supply, or a split rail chip like certain SDIO
WLAN or eMMC solutions).
Signed-off-by: David Brownell <[email protected]>
---
Changes from previous version: automagically available if the
regulator calls are available; callers now pass in host->ios.vdd.
mmc_regulator_set_ocr() still untested.
drivers/mmc/core/core.c | 86 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mmc/host.h | 5 ++
2 files changed, 91 insertions(+)
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -21,6 +21,7 @@
#include <linux/leds.h>
#include <linux/scatterlist.h>
#include <linux/log2.h>
+#include <linux/regulator/consumer.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
@@ -523,6 +524,91 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min,
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_REGULATOR
+
+/**
+ * mmc_regulator_get_ocrmask - return mask of supported voltages
+ * @host: mmc host whose supply will be consulted
+ * @supply: regulator to use
+ *
+ * This returns either a negative errno, or a mask of voltages that
+ * can be provided to MMC/SD/SDIO devices using the specified voltage
+ * regulator. This would normally be called before registering the
+ * MMC host adapter.
+ */
+int mmc_regulator_get_ocrmask(struct mmc_host *host, struct regulator *supply)
+{
+ int result = 0;
+ int count;
+ int i;
+
+ count = regulator_count_voltages(supply);
+ if (count < 0)
+ return count;
+
+ for (i = 0; i < count; i++) {
+ int vdd_uV;
+ int vdd_mV;
+
+ vdd_uV = regulator_list_voltage(supply, i);
+ if (vdd_uV <= 0)
+ continue;
+
+ vdd_mV = vdd_uV / 1000;
+ result |= mmc_vddrange_to_ocrmask(vdd_mV, vdd_mV);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_get_ocrmask);
+
+/**
+ * mmc_regulator_set_ocr - set regulator to match host->ios voltage
+ * @vdd_bit: zero for power off, else a bit number (host->ios.vdd)
+ * @supply: regulator to use
+ *
+ * Returns zero on success, else negative errno.
+ *
+ * MMC host drivers may use this to enable or disable a regulator using
+ * a particular supply voltage. This would normally be called from the
+ * set_ios() method.
+ */
+int mmc_regulator_set_ocr(unsigned short vdd_bit, struct regulator *supply)
+{
+ int result = 0;
+ int min_mV, max_mV;
+ int enabled;
+
+ enabled = regulator_is_enabled(supply);
+ if (enabled < 0)
+ return enabled;
+
+ if (vdd_bit) {
+ int tmp;
+
+ tmp = vdd_bit - ilog2(MMC_VDD_165_195);
+ if (tmp == 0) {
+ min_mV = 1650;
+ max_mV = 1950;
+ } else {
+ min_mV = 2000 + tmp * 100;
+ max_mV = min_mV + 100;
+ }
+
+ result = regulator_set_voltage(supply,
+ min_mV * 1000, max_mV * 1000);
+ if (result == 0 && !enabled)
+ result = regulator_enable(supply);
+ } else if (enabled) {
+ result = regulator_disable(supply);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_set_ocr);
+
+#endif
+
/*
* Mask off any voltages we don't support and select
* the lowest voltage
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -192,5 +192,10 @@ static inline void mmc_signal_sdio_irq(s
wake_up_process(host->sdio_irq_thread);
}
+struct regulator;
+
+int mmc_regulator_get_ocrmask(struct mmc_host *host, struct regulator *supply);
+int mmc_regulator_set_ocr(unsigned short vdd_bit, struct regulator *supply);
+
#endif
On Tue, 3 Mar 2009 19:18:06 -0800
David Brownell <[email protected]> wrote:
> From: David Brownell <[email protected]>
>
> Glue between MMC and regulator stacks ... compiles, and
> mmc_regulator_get_ocrmask() passed sanity testing.
>
> These calls are intended to be used by MMC host adapters
> using at least one regulator per host. Examples include
> slots with regulators supporting multiple voltages and
> ones using multiple voltage rails (e.g. DAT4..DAT7 using a
> separate supply, or a split rail chip like certain SDIO
> WLAN or eMMC solutions).
>
> Signed-off-by: David Brownell <[email protected]>
> ---
> Changes from previous version: automagically available if the
> regulator calls are available; callers now pass in host->ios.vdd.
> mmc_regulator_set_ocr() still untested.
>
Looks good. Now what should I do with it? Merge it in the next window
good enough?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Sunday 08 March 2009, Pierre Ossman wrote:
> Looks good. Now what should I do with it? Merge it in the next window
> good enough?
Well, after testing the previously-untested call ... here's
another update.
Since these depend on new calls in the regulator framework,
it can't merge until after they merge (in the next window).
Least hassle for you would be if this merges through the
regulator framework (with your ack), I suspect.
- Dave
======== CUT HERE
From: David Brownell <[email protected]>
Glue between MMC and regulator stacks ... verified with
some OMAP3 boards using adjustable and configured-as-fixed
regulators on several MMC controllers.
These calls are intended to be used by MMC host adapters
using at least one regulator per host. Examples include
slots with regulators supporting multiple voltages and
ones using multiple voltage rails (e.g. DAT4..DAT7 using a
separate supply, or a split rail chip like certain SDIO
WLAN or eMMC solutions).
Signed-off-by: David Brownell <[email protected]>
---
Changes since previous version: simplified set_ocr() calling
convention, fixed an off-by-100mA error in that code, and don't
set voltage on regulators that don't need (and may disallow) it.
drivers/mmc/core/core.c | 100 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mmc/host.h | 5 ++
2 files changed, 105 insertions(+)
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -21,6 +21,7 @@
#include <linux/leds.h>
#include <linux/scatterlist.h>
#include <linux/log2.h>
+#include <linux/regulator/consumer.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
@@ -523,6 +524,105 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min,
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_REGULATOR
+
+/**
+ * mmc_regulator_get_ocrmask - return mask of supported voltages
+ * @supply: regulator to use
+ *
+ * This returns either a negative errno, or a mask of voltages that
+ * can be provided to MMC/SD/SDIO devices using the specified voltage
+ * regulator. This would normally be called before registering the
+ * MMC host adapter.
+ */
+int mmc_regulator_get_ocrmask(struct regulator *supply)
+{
+ int result = 0;
+ int count;
+ int i;
+
+ count = regulator_count_voltages(supply);
+ if (count < 0)
+ return count;
+
+ for (i = 0; i < count; i++) {
+ int vdd_uV;
+ int vdd_mV;
+
+ vdd_uV = regulator_list_voltage(supply, i);
+ if (vdd_uV <= 0)
+ continue;
+
+ vdd_mV = vdd_uV / 1000;
+ result |= mmc_vddrange_to_ocrmask(vdd_mV, vdd_mV);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_get_ocrmask);
+
+/**
+ * mmc_regulator_set_ocr - set regulator to match host->ios voltage
+ * @vdd_bit: zero for power off, else a bit number (host->ios.vdd)
+ * @supply: regulator to use
+ *
+ * Returns zero on success, else negative errno.
+ *
+ * MMC host drivers may use this to enable or disable a regulator using
+ * a particular supply voltage. This would normally be called from the
+ * set_ios() method.
+ */
+int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit)
+{
+ int result = 0;
+ int min_uV, max_uV;
+ int enabled;
+
+ enabled = regulator_is_enabled(supply);
+ if (enabled < 0)
+ return enabled;
+
+ if (vdd_bit) {
+ int tmp;
+ int voltage;
+
+ /* REVISIT mmc_vddrange_to_ocrmask() may have set some
+ * bits this regulator doesn't quite support ... don't
+ * be too picky, most cards and regulators are OK with
+ * a 0.1V range goof (it's a small error percentage).
+ */
+ tmp = vdd_bit - ilog2(MMC_VDD_165_195);
+ if (tmp == 0) {
+ min_uV = 1650 * 1000;
+ max_uV = 1950 * 1000;
+ } else {
+ min_uV = 1900 * 1000 + tmp * 100 * 1000;
+ max_uV = min_uV + 100 * 1000;
+ }
+
+ /* avoid needless changes to this voltage; the regulator
+ * might not allow this operation
+ */
+ voltage = regulator_get_voltage(supply);
+ if (voltage < 0)
+ result = voltage;
+ else if (voltage < min_uV || voltage > max_uV)
+ result = regulator_set_voltage(supply, min_uV, max_uV);
+ else
+ result = 0;
+
+ if (result == 0 && !enabled)
+ result = regulator_enable(supply);
+ } else if (enabled) {
+ result = regulator_disable(supply);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_set_ocr);
+
+#endif
+
/*
* Mask off any voltages we don't support and select
* the lowest voltage
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -192,5 +192,10 @@ static inline void mmc_signal_sdio_irq(s
wake_up_process(host->sdio_irq_thread);
}
+struct regulator;
+
+int mmc_regulator_get_ocrmask(struct regulator *supply);
+int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit);
+
#endif
On Sun, 8 Mar 2009 12:34:25 -0800
David Brownell <[email protected]> wrote:
> On Sunday 08 March 2009, Pierre Ossman wrote:
> > Looks good. Now what should I do with it? Merge it in the next window
> > good enough?
>
> Well, after testing the previously-untested call ... here's
> another update.
>
> Since these depend on new calls in the regulator framework,
> it can't merge until after they merge (in the next window).
> Least hassle for you would be if this merges through the
> regulator framework (with your ack), I suspect.
>
> - Dave
>
>
> ======== CUT HERE
> From: David Brownell <[email protected]>
>
> Glue between MMC and regulator stacks ... verified with
> some OMAP3 boards using adjustable and configured-as-fixed
> regulators on several MMC controllers.
>
> These calls are intended to be used by MMC host adapters
> using at least one regulator per host. Examples include
> slots with regulators supporting multiple voltages and
> ones using multiple voltage rails (e.g. DAT4..DAT7 using a
> separate supply, or a split rail chip like certain SDIO
> WLAN or eMMC solutions).
>
> Signed-off-by: David Brownell <[email protected]>
> ---
Acked-by: Pierre Ossman <[email protected]>
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Sun, 2009-03-08 at 22:49 +0100, Pierre Ossman wrote:
> On Sun, 8 Mar 2009 12:34:25 -0800
> David Brownell <[email protected]> wrote:
>
> > On Sunday 08 March 2009, Pierre Ossman wrote:
> > > Looks good. Now what should I do with it? Merge it in the next window
> > > good enough?
> >
> > Well, after testing the previously-untested call ... here's
> > another update.
> >
> > Since these depend on new calls in the regulator framework,
> > it can't merge until after they merge (in the next window).
> > Least hassle for you would be if this merges through the
> > regulator framework (with your ack), I suspect.
> >
> > - Dave
> >
> >
> > ======== CUT HERE
> > From: David Brownell <[email protected]>
> >
> > Glue between MMC and regulator stacks ... verified with
> > some OMAP3 boards using adjustable and configured-as-fixed
> > regulators on several MMC controllers.
> >
> > These calls are intended to be used by MMC host adapters
> > using at least one regulator per host. Examples include
> > slots with regulators supporting multiple voltages and
> > ones using multiple voltage rails (e.g. DAT4..DAT7 using a
> > separate supply, or a split rail chip like certain SDIO
> > WLAN or eMMC solutions).
> >
> > Signed-off-by: David Brownell <[email protected]>
> > ---
>
> Acked-by: Pierre Ossman <[email protected]>
>
Applied.
Thanks
Liam
On Monday 09 March 2009, Liam Girdwood wrote:
> > > From: David Brownell <[email protected]>
> > >
> > > Glue between MMC and regulator stacks ... verified with
> > > some OMAP3 boards using adjustable and configured-as-fixed
> > > regulators on several MMC controllers.
> > >
> > > ...
> >
> > Acked-by: Pierre Ossman <[email protected]>
> >
>
> Applied.
... actually you applied an old version, not the one that
was verified, with mmc_regulator_set_ocr() fixes and with
Pierre's ACK. The comment is in your GIT tree is wrong,
for starters...
Please use this one instead.
- Dave
========== CUT HERE
From: David Brownell <[email protected]>
Glue between MMC and regulator stacks ... verified with
some OMAP3 boards using adjustable and configured-as-fixed
regulators on several MMC controllers.
These calls are intended to be used by MMC host adapters
using at least one regulator per host. Examples include
slots with regulators supporting multiple voltages and
ones using multiple voltage rails (e.g. DAT4..DAT7 using a
separate supply, or a split rail chip like certain SDIO
WLAN or eMMC solutions).
Signed-off-by: David Brownell <[email protected]>
Acked-by: Pierre Ossman <[email protected]>
---
Changes since previous version: simplified set_ocr() calling
convention, fixed an off-by-100mA error in that code, and don't
set voltage on regulators that don't need (and may disallow) it.
drivers/mmc/core/core.c | 100 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mmc/host.h | 5 ++
2 files changed, 105 insertions(+)
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -21,6 +21,7 @@
#include <linux/leds.h>
#include <linux/scatterlist.h>
#include <linux/log2.h>
+#include <linux/regulator/consumer.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
@@ -523,6 +524,105 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min,
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_REGULATOR
+
+/**
+ * mmc_regulator_get_ocrmask - return mask of supported voltages
+ * @supply: regulator to use
+ *
+ * This returns either a negative errno, or a mask of voltages that
+ * can be provided to MMC/SD/SDIO devices using the specified voltage
+ * regulator. This would normally be called before registering the
+ * MMC host adapter.
+ */
+int mmc_regulator_get_ocrmask(struct regulator *supply)
+{
+ int result = 0;
+ int count;
+ int i;
+
+ count = regulator_count_voltages(supply);
+ if (count < 0)
+ return count;
+
+ for (i = 0; i < count; i++) {
+ int vdd_uV;
+ int vdd_mV;
+
+ vdd_uV = regulator_list_voltage(supply, i);
+ if (vdd_uV <= 0)
+ continue;
+
+ vdd_mV = vdd_uV / 1000;
+ result |= mmc_vddrange_to_ocrmask(vdd_mV, vdd_mV);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_get_ocrmask);
+
+/**
+ * mmc_regulator_set_ocr - set regulator to match host->ios voltage
+ * @vdd_bit: zero for power off, else a bit number (host->ios.vdd)
+ * @supply: regulator to use
+ *
+ * Returns zero on success, else negative errno.
+ *
+ * MMC host drivers may use this to enable or disable a regulator using
+ * a particular supply voltage. This would normally be called from the
+ * set_ios() method.
+ */
+int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit)
+{
+ int result = 0;
+ int min_uV, max_uV;
+ int enabled;
+
+ enabled = regulator_is_enabled(supply);
+ if (enabled < 0)
+ return enabled;
+
+ if (vdd_bit) {
+ int tmp;
+ int voltage;
+
+ /* REVISIT mmc_vddrange_to_ocrmask() may have set some
+ * bits this regulator doesn't quite support ... don't
+ * be too picky, most cards and regulators are OK with
+ * a 0.1V range goof (it's a small error percentage).
+ */
+ tmp = vdd_bit - ilog2(MMC_VDD_165_195);
+ if (tmp == 0) {
+ min_uV = 1650 * 1000;
+ max_uV = 1950 * 1000;
+ } else {
+ min_uV = 1900 * 1000 + tmp * 100 * 1000;
+ max_uV = min_uV + 100 * 1000;
+ }
+
+ /* avoid needless changes to this voltage; the regulator
+ * might not allow this operation
+ */
+ voltage = regulator_get_voltage(supply);
+ if (voltage < 0)
+ result = voltage;
+ else if (voltage < min_uV || voltage > max_uV)
+ result = regulator_set_voltage(supply, min_uV, max_uV);
+ else
+ result = 0;
+
+ if (result == 0 && !enabled)
+ result = regulator_enable(supply);
+ } else if (enabled) {
+ result = regulator_disable(supply);
+ }
+
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_set_ocr);
+
+#endif
+
/*
* Mask off any voltages we don't support and select
* the lowest voltage
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -192,5 +192,10 @@ static inline void mmc_signal_sdio_irq(s
wake_up_process(host->sdio_irq_thread);
}
+struct regulator;
+
+int mmc_regulator_get_ocrmask(struct regulator *supply);
+int mmc_regulator_set_ocr(struct regulator *supply, unsigned short vdd_bit);
+
#endif
On Wed, 2009-03-11 at 03:30 -0800, David Brownell wrote:
> On Monday 09 March 2009, Liam Girdwood wrote:
> > > > From: David Brownell <[email protected]>
> > > >
> > > > Glue between MMC and regulator stacks ... verified with
> > > > some OMAP3 boards using adjustable and configured-as-fixed
> > > > regulators on several MMC controllers.
> > > >
> > > > ...
> > >
> > > Acked-by: Pierre Ossman <[email protected]>
> > >
> >
> > Applied.
>
> ... actually you applied an old version, not the one that
> was verified, with mmc_regulator_set_ocr() fixes and with
> Pierre's ACK. The comment is in your GIT tree is wrong,
> for starters...
>
> Please use this one instead.
I've removed the old patch now and applied the correct one. In the
future could you start a new thread or change the thread subject a
little (i.e. patch V2) when a patch changes during discussion. This
should avoid similar confusion in the future.
Thanks
Liam