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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 13 May 2015 15:06:47 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Doug Anderson <dianders@...omium.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 13 May 2015 at 13:09, Mark Brown <broonie@...nel.org> wrote:
> On Tue, May 12, 2015 at 02:46:11PM -0700, Doug Anderson 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.
>
> What a LDO is doing is basically just charging up a capacitor - the
> regulation consists of monitoring the voltage on the capacitor and
> opening a transistor to charge the capacitor when the voltage droops too
> much.
>
>> 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.
>
> Right, and this is probably going beyond the delays that the regulator
> API is handling since it's not something the regulator hardware is
> actively managing.

Thanks for elaborating from the regulator perspective. So may I apply
your ack for this one?

Kind regards
Uffe
--
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