From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Maurus Cuelenaere <mcuelenaere@gmail.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 10:14:20 -0700 [thread overview]
Message-ID: <20100728171420.GA22544@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4C50638E.7010101@gmail.com>
On Wed, Jul 28, 2010 at 07:06:22PM +0200, Maurus Cuelenaere wrote:
> Op 28-07-10 17:41, Mark Brown schreef:
> >>> + 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.
It's unlikely to be a property of the regulator in general, it sounds
like it's a property of the MMC application somehow (most likely due to
very light loading). Possibly it should be platform configurable, but I
suspect in the MMC driver.
It'd be nice to know exactly what the delay is for...
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] sdhci-s3c: add regulator support
Date: Wed, 28 Jul 2010 10:14:20 -0700 [thread overview]
Message-ID: <20100728171420.GA22544@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4C50638E.7010101@gmail.com>
On Wed, Jul 28, 2010 at 07:06:22PM +0200, Maurus Cuelenaere wrote:
> Op 28-07-10 17:41, Mark Brown schreef:
> >>> + 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.
It's unlikely to be a property of the regulator in general, it sounds
like it's a property of the MMC application somehow (most likely due to
very light loading). Possibly it should be platform configurable, but I
suspect in the MMC driver.
It'd be nice to know exactly what the delay is for...
next prev parent reply other threads:[~2010-07-28 17:14 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
2010-07-28 17:06 ` Maurus Cuelenaere
2010-07-28 17:14 ` Mark Brown [this message]
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=20100728171420.GA22544@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=akpm@linux-foundation.org \
--cc=ben-linux@fluff.org \
--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 \
--cc=mcuelenaere@gmail.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.