[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFpkLhC7k+HNCYV_U7M6B615o4RgFktJ1wCXd_SxT0xiQg@mail.gmail.com>
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