All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Mark Brown <broonie@kernel.org>,
	linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Doug Anderson <dianders@chromium.org>,
	johan.rudholm@axis.com, adrian.hunter@intel.com,
	tim.kryger@gmail.com, javier.martinez@collabora.co.uk,
	andrew_gabbasov@mentor.com, s.hauer@pengutronix.de,
	linux-kernel@vger.kernel.org
Subject: [PATCH] RFC: mmc: core: Increase delay for voltage to stabilize from 3.3V to 1.8V
Date: Tue, 12 May 2015 14:46:11 -0700	[thread overview]
Message-ID: <1431467171-12937-1-git-send-email-dianders@chromium.org> (raw)

Since the regulator used for the SDMMC IO voltage is not expected to
draw a lot of current, most systems will probably use an inexpensive
LDO for it.  LDO regulators apparently have the feature that they
don't actively drive the voltage down--they wait for other components
in the system to drag the voltage down.  Thus they will transition
faster under heavy loads and slower under light loads.

During an SDMMC voltage change from 3.3V to 1.8V, we are almost
certainly under a light load.  To be specific:
* The regulator is hooked through pulls to CMD0-3 and DAT.  Probably
  the CMD pulls are something like 47K and the DAT is something like
  10K.
* The card is supposed to be driving DAT0-3 low during voltage change
  which will draw _some_ current, but not a lot.
* The regulator is also provided to the SDMMC host controller, but the
  SDMMC host controller is in open drain mode during the voltage
  change and so shouldn't be drawing much current.

In order to keep the SDMMC host working properly (or for noise
reasons), there might also be a capacitor attached to the SDMMC IO
regulator.  This also will have the effect of slowing down transitions
of the regulator, especially under light loads.

>From experimental evidence, we've seen the voltage change fail if the
card doesn't detect that the voltage fell to less than about 2.3V when
we turn on the clock.  On one device (that admittedly had a 47K CMD
pullup instead of a 10K CMD pullup) we saw that the voltage was just
about 2.3V after 5ms and thus the voltage change would sometimes fail.
Doubling the delay gave margin and made the voltage change work 100%
of the time, despite the slightly weaker CMD pull.

At the moment submitting this as an RFC patch since my problem _could_
be fixed by increasing the pull strength (or using a smaller
capacitor).  However being a little bit more lenient to strange
hardware could also be a good thing.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 drivers/mmc/core/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 92e7671..a7e6110 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1551,8 +1551,8 @@ int mmc_set_signal_voltage(struct mmc_host *host, int signal_voltage, u32 ocr)
 		goto power_cycle;
 	}
 
-	/* Keep clock gated for at least 5 ms */
-	mmc_delay(5);
+	/* Keep clock gated for at least 10 ms, though spec only says 5 ms */
+	mmc_delay(10);
 	host->ios.clock = clock;
 	mmc_set_ios(host);
 
-- 
2.2.0.rc0.207.ga3a616c


WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RFC: mmc: core: Increase delay for voltage to stabilize from 3.3V to 1.8V
Date: Tue, 12 May 2015 14:46:11 -0700	[thread overview]
Message-ID: <1431467171-12937-1-git-send-email-dianders@chromium.org> (raw)

Since the regulator used for the SDMMC IO voltage is not expected to
draw a lot of current, most systems will probably use an inexpensive
LDO for it.  LDO regulators apparently have the feature that they
don't actively drive the voltage down--they wait for other components
in the system to drag the voltage down.  Thus they will transition
faster under heavy loads and slower under light loads.

During an SDMMC voltage change from 3.3V to 1.8V, we are almost
certainly under a light load.  To be specific:
* The regulator is hooked through pulls to CMD0-3 and DAT.  Probably
  the CMD pulls are something like 47K and the DAT is something like
  10K.
* The card is supposed to be driving DAT0-3 low during voltage change
  which will draw _some_ current, but not a lot.
* The regulator is also provided to the SDMMC host controller, but the
  SDMMC host controller is in open drain mode during the voltage
  change and so shouldn't be drawing much current.

In order to keep the SDMMC host working properly (or for noise
reasons), there might also be a capacitor attached to the SDMMC IO
regulator.  This also will have the effect of slowing down transitions
of the regulator, especially under light loads.

>From experimental evidence, we've seen the voltage change fail if the
card doesn't detect that the voltage fell to less than about 2.3V when
we turn on the clock.  On one device (that admittedly had a 47K CMD
pullup instead of a 10K CMD pullup) we saw that the voltage was just
about 2.3V after 5ms and thus the voltage change would sometimes fail.
Doubling the delay gave margin and made the voltage change work 100%
of the time, despite the slightly weaker CMD pull.

At the moment submitting this as an RFC patch since my problem _could_
be fixed by increasing the pull strength (or using a smaller
capacitor).  However being a little bit more lenient to strange
hardware could also be a good thing.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 drivers/mmc/core/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 92e7671..a7e6110 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1551,8 +1551,8 @@ int mmc_set_signal_voltage(struct mmc_host *host, int signal_voltage, u32 ocr)
 		goto power_cycle;
 	}
 
-	/* Keep clock gated for at least 5 ms */
-	mmc_delay(5);
+	/* Keep clock gated for at least 10 ms, though spec only says 5 ms */
+	mmc_delay(10);
 	host->ios.clock = clock;
 	mmc_set_ios(host);
 
-- 
2.2.0.rc0.207.ga3a616c

             reply	other threads:[~2015-05-12 21:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 21:46 Doug Anderson [this message]
2015-05-12 21:46 ` [PATCH] RFC: mmc: core: Increase delay for voltage to stabilize from 3.3V to 1.8V Doug Anderson
2015-05-13 11:09 ` Mark Brown
2015-05-13 11:09   ` Mark Brown
2015-05-13 13:06   ` Ulf Hansson
2015-05-13 13:06     ` Ulf Hansson
2015-05-13 13:06     ` Ulf Hansson
2015-05-13 15:32     ` Mark Brown
2015-05-13 15:32       ` Mark Brown
2015-05-13 15:32       ` Mark Brown
2015-05-15 17:34 ` Doug Anderson
2015-05-15 17:34   ` Doug Anderson
2015-05-15 17:34   ` Doug Anderson
2015-05-18  9:23 ` Ulf Hansson
2015-05-18  9:23   ` Ulf Hansson
2015-05-18  9:23   ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1431467171-12937-1-git-send-email-dianders@chromium.org \
    --to=dianders@chromium.org \
    --cc=adrian.hunter@intel.com \
    --cc=andrew_gabbasov@mentor.com \
    --cc=broonie@kernel.org \
    --cc=javier.martinez@collabora.co.uk \
    --cc=johan.rudholm@axis.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=tim.kryger@gmail.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.