lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 18 May 2015 11:23:42 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Mark Brown <broonie@...nel.org>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Johan Rudholm <johan.rudholm@...s.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Tim Kryger <tim.kryger@...il.com>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Andrew Gabbasov <andrew_gabbasov@...tor.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] RFC: mmc: core: Increase delay for voltage to stabilize
 from 3.3V to 1.8V

On 12 May 2015 at 23:46, Doug Anderson <dianders@...omium.org> wrote:
> 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@...omium.org>

Thanks, applied.

Kind regards
Uffe

> ---
>  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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ