From: Maurus Cuelenaere <mcuelenaere@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>,
"kgene.kim@samsung.com" <kgene.kim@samsung.com>,
"ben-linux@fluff.org" <ben-linux@fluff.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 4/4] sdhci-s3c: add regulator support
Date: Wed, 28 Jul 2010 19:06:22 +0200 [thread overview]
Message-ID: <4C50638E.7010101@gmail.com> (raw)
In-Reply-To: <3482ADFC-0FFB-47AE-B809-C88AC8B92C7F@opensource.wolfsonmicro.com>
Op 28-07-10 17:41, Mark Brown schreef:
> On 28 Jul 2010, at 07:48, Maurus Cuelenaere <mcuelenaere@gmail.com> wrote:
>>> + struct sdhci_s3c *sc = sdhci_priv(host);
>>> +
>>> + if (sc->vmmc) {
>>> + int ret = regulator_disable(sc->vmmc);
>>> + if (ret)
>>> + return ret;
>>> + mdelay(2);
>> Shouldn't these delays be handled in the regulator framework itself?
> A 2ms delay on power down seems suspicious for a regulator. I'm not sure why this is required but if it is I suspect it's due to a large cap on the regulator output and light load rather than something that's always true for whatever regulator is providing the supply.
I wasn't suggesting to do the delay in the framework *itself*, rather in the
regulator driver and/or the board platform code which needs this delay.
--
Maurus Cuelenaere
WARNING: multiple messages have this Message-ID (diff)
From: mcuelenaere@gmail.com (Maurus Cuelenaere)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] sdhci-s3c: add regulator support
Date: Wed, 28 Jul 2010 19:06:22 +0200 [thread overview]
Message-ID: <4C50638E.7010101@gmail.com> (raw)
In-Reply-To: <3482ADFC-0FFB-47AE-B809-C88AC8B92C7F@opensource.wolfsonmicro.com>
Op 28-07-10 17:41, Mark Brown schreef:
> On 28 Jul 2010, at 07:48, Maurus Cuelenaere <mcuelenaere@gmail.com> wrote:
>>> + struct sdhci_s3c *sc = sdhci_priv(host);
>>> +
>>> + if (sc->vmmc) {
>>> + int ret = regulator_disable(sc->vmmc);
>>> + if (ret)
>>> + return ret;
>>> + mdelay(2);
>> Shouldn't these delays be handled in the regulator framework itself?
> A 2ms delay on power down seems suspicious for a regulator. I'm not sure why this is required but if it is I suspect it's due to a large cap on the regulator output and light load rather than something that's always true for whatever regulator is providing the supply.
I wasn't suggesting to do the delay in the framework *itself*, rather in the
regulator driver and/or the board platform code which needs this delay.
--
Maurus Cuelenaere
next prev parent reply other threads:[~2010-07-28 17:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 14:19 [PATCH] SDHCI-S3C updates Marek Szyprowski
2010-07-28 14:19 ` Marek Szyprowski
2010-07-28 14:19 ` [PATCHv2 1/4] sdhci-s3c: add support for the non standard minimal clock value Marek Szyprowski
2010-07-28 14:19 ` Marek Szyprowski
2010-07-28 16:48 ` Ben Dooks
2010-07-28 16:48 ` Ben Dooks
2010-07-29 5:30 ` Marek Szyprowski
2010-07-29 5:30 ` Marek Szyprowski
2010-07-28 14:19 ` [PATCH 2/4] sdhci-s3c: enable SDHCI_QUIRK_NO_HISPD_BIT quirk Marek Szyprowski
2010-07-28 14:19 ` Marek Szyprowski
2010-07-28 14:19 ` [PATCHv5 3/4] sdhci-s3c: add support for new card detection methods (driver part) Marek Szyprowski
2010-07-28 14:19 ` Marek Szyprowski
2010-07-28 14:39 ` Maurus Cuelenaere
2010-07-28 14:39 ` Maurus Cuelenaere
2010-07-29 5:22 ` Marek Szyprowski
2010-07-29 5:22 ` Marek Szyprowski
2010-07-28 17:03 ` Ben Dooks
2010-07-28 17:03 ` Ben Dooks
2010-07-29 5:40 ` Marek Szyprowski
2010-07-29 5:40 ` Marek Szyprowski
2010-07-28 14:19 ` [PATCH 4/4] sdhci-s3c: add regulator support Marek Szyprowski
2010-07-28 14:19 ` Marek Szyprowski
2010-07-28 14:48 ` Maurus Cuelenaere
2010-07-28 14:48 ` Maurus Cuelenaere
2010-07-28 15:41 ` Mark Brown
2010-07-28 15:41 ` Mark Brown
2010-07-28 17:06 ` Maurus Cuelenaere [this message]
2010-07-28 17:06 ` Maurus Cuelenaere
2010-07-28 17:14 ` Mark Brown
2010-07-28 17:14 ` Mark Brown
2010-07-29 5:28 ` Marek Szyprowski
2010-07-29 5:28 ` Marek Szyprowski
2010-07-28 17:39 ` Mark Brown
2010-07-28 17:39 ` Mark Brown
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=4C50638E.7010101@gmail.com \
--to=mcuelenaere@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ben-linux@fluff.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
/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.