All of lore.kernel.org
 help / color / mirror / Atom feed
* support for fixed 1.8V eMMC interface
@ 2016-04-27 11:44 Raul Benet
  2016-04-27 12:46 ` Ulf Hansson
  2016-04-28 12:15 ` Dong Aisheng
  0 siblings, 2 replies; 4+ messages in thread
From: Raul Benet @ 2016-04-27 11:44 UTC (permalink / raw)
  To: linux-mmc

Hi,

I am currently working on a design using i.MX6SL and Linux Kernel 3.14.52. Though I believe may question still applies to latest MMC code.
Our design uses an eMMC as boot device and main storage (ie: it contains u-boot, kernel, dtb and rootfs).

The eMMC I/O rail is fixed in hardware to 1.8Volts.
The Processor SDIO I/O rail is controlled by the MMC driver.

In 3.14.52, the MMC driver sets processor SDIO rail to 3v3 per default, and only when using HS DDR modes (which do not apply in our case) would it set it to 1.8V.

I have seen that starting on 3.16, the function power_up() in drivers/mmc/core/core.c attempts at setting the regulator to 3v3, failing that it tries 1v8, failing that it tries 1v2.

So I patched my kernel with that, and defined a fixed regulator with 1v8 in my dts, and set the vqmmc-supply to point to it.
But that doesn't work, because power_up() ultimately tries to call set_voltage() on the vqmmc regulator, which doesn't seem to exist for "regulator-fixed" type of regulators, and hence it fails in setting all the rails, which ultimately means that it sets it to 3v3 ('cause that is the default/initial value of the field in the ios struct)

So my question is: how am I supposed to setup the MMC driver in my scenario (I/O at 1.8V always) ?
(I know I can go and force the rail to 1.8V by hacking drivers/mmc/host/sdhci-esdhc-imx.c, but I would very much prefer to avoid that)

Thanks ,
Raul.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: support for fixed 1.8V eMMC interface
  2016-04-27 11:44 support for fixed 1.8V eMMC interface Raul Benet
@ 2016-04-27 12:46 ` Ulf Hansson
  2016-04-28 12:15 ` Dong Aisheng
  1 sibling, 0 replies; 4+ messages in thread
From: Ulf Hansson @ 2016-04-27 12:46 UTC (permalink / raw)
  To: Raul Benet; +Cc: linux-mmc

On 27 April 2016 at 13:44, Raul Benet <Raul.Benet@lightblueoptics.com> wrote:
> Hi,
>
> I am currently working on a design using i.MX6SL and Linux Kernel 3.14.52. Though I believe may question still applies to latest MMC code.
> Our design uses an eMMC as boot device and main storage (ie: it contains u-boot, kernel, dtb and rootfs).
>
> The eMMC I/O rail is fixed in hardware to 1.8Volts.
> The Processor SDIO I/O rail is controlled by the MMC driver.
>
> In 3.14.52, the MMC driver sets processor SDIO rail to 3v3 per default, and only when using HS DDR modes (which do not apply in our case) would it set it to 1.8V.
>
> I have seen that starting on 3.16, the function power_up() in drivers/mmc/core/core.c attempts at setting the regulator to 3v3, failing that it tries 1v8, failing that it tries 1v2.
>
> So I patched my kernel with that, and defined a fixed regulator with 1v8 in my dts, and set the vqmmc-supply to point to it.

That's great and exactly how you should do it!

> But that doesn't work, because power_up() ultimately tries to call set_voltage() on the vqmmc regulator, which doesn't seem to exist for "regulator-fixed" type of regulators, and hence it fails in setting all the rails, which ultimately means that it sets it to 3v3 ('cause that is the default/initial value of the field in the ios struct)

So mmc_power_up() invokes the mmc host ops
->start_signal_voltage_switch(). That doesn't use the vqmmc regulator
directly, as it is host dependent on how to deal with regulators.

>
> So my question is: how am I supposed to setup the MMC driver in my scenario (I/O at 1.8V always) ?
> (I know I can go and force the rail to 1.8V by hacking drivers/mmc/host/sdhci-esdhc-imx.c, but I would very much prefer to avoid that)

I think there are two options.

1. Make drivers/mmc/host/sdhci-esdhc-imx.c to check what voltages are
requested from the mmc core and deal with that depending on what the
regulator support.
2. Change the regulator API to accept that it can set a voltage on a
fixed regulator. Of course returning error if the voltage isn't
supported.

Kind regards
Uffe

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: support for fixed 1.8V eMMC interface
  2016-04-27 11:44 support for fixed 1.8V eMMC interface Raul Benet
  2016-04-27 12:46 ` Ulf Hansson
@ 2016-04-28 12:15 ` Dong Aisheng
  2016-04-29 13:24   ` Raul Benet
  1 sibling, 1 reply; 4+ messages in thread
From: Dong Aisheng @ 2016-04-28 12:15 UTC (permalink / raw)
  To: Raul Benet; +Cc: linux-mmc

On Wed, Apr 27, 2016 at 7:44 PM, Raul Benet
<Raul.Benet@lightblueoptics.com> wrote:
> Hi,
>
> I am currently working on a design using i.MX6SL and Linux Kernel 3.14.52. Though I believe may question still applies to latest MMC code.
> Our design uses an eMMC as boot device and main storage (ie: it contains u-boot, kernel, dtb and rootfs).
>
> The eMMC I/O rail is fixed in hardware to 1.8Volts.
> The Processor SDIO I/O rail is controlled by the MMC driver.
>
> In 3.14.52, the MMC driver sets processor SDIO rail to 3v3 per default, and only when using HS DDR modes (which do not apply in our case) would it set it to 1.8V.
>
> I have seen that starting on 3.16, the function power_up() in drivers/mmc/core/core.c attempts at setting the regulator to 3v3, failing that it tries 1v8, failing that it tries 1v2.
>
> So I patched my kernel with that, and defined a fixed regulator with 1v8 in my dts, and set the vqmmc-supply to point to it.
> But that doesn't work, because power_up() ultimately tries to call set_voltage() on the vqmmc regulator, which doesn't seem to exist for "regulator-fixed" type of regulators, and hence it fails in setting all the rails, which ultimately means that it sets it to 3v3 ('cause that is the default/initial value of the field in the ios struct)
>

It seems the 3.6 kernel you tried may still not support set voltage
for fixed regulator.
But i tried the latest kernel already supports it.

> So my question is: how am I supposed to setup the MMC driver in my scenario (I/O at 1.8V always) ?
> (I know I can go and force the rail to 1.8V by hacking drivers/mmc/host/sdhci-esdhc-imx.c, but I would very much prefer to avoid that)
>

Pls try the option 2 as Ulf pointed.

You can refer to this patch:
commit c00dc359e5e0b10de993651d8e73e60c41bf29cd
Author: Bjorn Andersson <bjorn@kryo.se>
Date:   Wed Feb 5 12:30:26 2014 -0800

    regulator: core: Allow regulator_set_voltage for fixed regulators

    Make it okay to call regulator_set_voltage on regulators with fixed
    voltage if the requested range overlaps the current/configured voltage.

    Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b38a6b669e8c..0cd1a3b8e589 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2395,6 +2395,7 @@ int regulator_set_voltage(struct regulator
*regulator, int min_uV, int max_uV)
        struct regulator_dev *rdev = regulator->rdev;
        int ret = 0;
        int old_min_uV, old_max_uV;
+       int current_uV;

        mutex_lock(&rdev->mutex);

@@ -2405,6 +2406,19 @@ int regulator_set_voltage(struct regulator
*regulator, int min_uV, int max_uV)
        if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
                goto out;

+       /* If we're trying to set a range that overlaps the current voltage,
+        * return succesfully even though the regulator does not support
+        * changing the voltage.
+        */
+       if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE)) {
+               current_uV = _regulator_get_voltage(rdev);
+               if (min_uV <= current_uV && current_uV <= max_uV) {
+                       regulator->min_uV = min_uV;
+                       regulator->max_uV = max_uV;
+                       goto out;
+               }
+       }
+
        /* sanity check */
        if (!rdev->desc->ops->set_voltage &&
            !rdev->desc->ops->set_voltage_sel) {

Regards
Dong Aisheng

> Thanks ,
> Raul.
>
>
> --
> 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

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* RE: support for fixed 1.8V eMMC interface
  2016-04-28 12:15 ` Dong Aisheng
@ 2016-04-29 13:24   ` Raul Benet
  0 siblings, 0 replies; 4+ messages in thread
From: Raul Benet @ 2016-04-29 13:24 UTC (permalink / raw)
  To: Dong Aisheng; +Cc: linux-mmc

Dong, Ulf,
Thanks for your advice.
I will pursue your suggestions.

Regards,
Raul Benet.

-----Original Message-----
From: Dong Aisheng [mailto:dongas86@gmail.com] 
Sent: 28 April 2016 13:15
To: Raul Benet <Raul.Benet@lightblueoptics.com>
Cc: linux-mmc@vger.kernel.org
Subject: Re: support for fixed 1.8V eMMC interface

On Wed, Apr 27, 2016 at 7:44 PM, Raul Benet <Raul.Benet@lightblueoptics.com> wrote:
> Hi,
>
> I am currently working on a design using i.MX6SL and Linux Kernel 3.14.52. Though I believe may question still applies to latest MMC code.
> Our design uses an eMMC as boot device and main storage (ie: it contains u-boot, kernel, dtb and rootfs).
>
> The eMMC I/O rail is fixed in hardware to 1.8Volts.
> The Processor SDIO I/O rail is controlled by the MMC driver.
>
> In 3.14.52, the MMC driver sets processor SDIO rail to 3v3 per default, and only when using HS DDR modes (which do not apply in our case) would it set it to 1.8V.
>
> I have seen that starting on 3.16, the function power_up() in drivers/mmc/core/core.c attempts at setting the regulator to 3v3, failing that it tries 1v8, failing that it tries 1v2.
>
> So I patched my kernel with that, and defined a fixed regulator with 1v8 in my dts, and set the vqmmc-supply to point to it.
> But that doesn't work, because power_up() ultimately tries to call 
> set_voltage() on the vqmmc regulator, which doesn't seem to exist for 
> "regulator-fixed" type of regulators, and hence it fails in setting 
> all the rails, which ultimately means that it sets it to 3v3 ('cause 
> that is the default/initial value of the field in the ios struct)
>

It seems the 3.6 kernel you tried may still not support set voltage for fixed regulator.
But i tried the latest kernel already supports it.

> So my question is: how am I supposed to setup the MMC driver in my scenario (I/O at 1.8V always) ?
> (I know I can go and force the rail to 1.8V by hacking 
> drivers/mmc/host/sdhci-esdhc-imx.c, but I would very much prefer to 
> avoid that)
>

Pls try the option 2 as Ulf pointed.

You can refer to this patch:
commit c00dc359e5e0b10de993651d8e73e60c41bf29cd
Author: Bjorn Andersson <bjorn@kryo.se>
Date:   Wed Feb 5 12:30:26 2014 -0800

    regulator: core: Allow regulator_set_voltage for fixed regulators

    Make it okay to call regulator_set_voltage on regulators with fixed
    voltage if the requested range overlaps the current/configured voltage.

    Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index b38a6b669e8c..0cd1a3b8e589 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2395,6 +2395,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
        struct regulator_dev *rdev = regulator->rdev;
        int ret = 0;
        int old_min_uV, old_max_uV;
+       int current_uV;

        mutex_lock(&rdev->mutex);

@@ -2405,6 +2406,19 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
        if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
                goto out;

+       /* If we're trying to set a range that overlaps the current voltage,
+        * return succesfully even though the regulator does not support
+        * changing the voltage.
+        */
+       if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE)) {
+               current_uV = _regulator_get_voltage(rdev);
+               if (min_uV <= current_uV && current_uV <= max_uV) {
+                       regulator->min_uV = min_uV;
+                       regulator->max_uV = max_uV;
+                       goto out;
+               }
+       }
+
        /* sanity check */
        if (!rdev->desc->ops->set_voltage &&
            !rdev->desc->ops->set_voltage_sel) {

Regards
Dong Aisheng

> Thanks ,
> Raul.
>
>
> --
> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-04-29 13:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-27 11:44 support for fixed 1.8V eMMC interface Raul Benet
2016-04-27 12:46 ` Ulf Hansson
2016-04-28 12:15 ` Dong Aisheng
2016-04-29 13:24   ` Raul Benet

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.