From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
Cc: linux-kernel@vger.kernel.org, lrg@ti.com
Subject: Re: [PATCH] regulator: Provide a check for dummy regulator
Date: Fri, 20 Apr 2012 19:48:07 +0100 [thread overview]
Message-ID: <20120420184806.GA3092@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJe_ZhdzuHo8P5WHguKMaikht8aN4RU-j_Q9FB+xOSw=roFZ=w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3105 bytes --]
On Fri, Apr 20, 2012 at 11:55:22PM +0530, Jassi Brar wrote:
> On 20 April 2012 20:12, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > No, they're here to stay - people will always be bringing up new boards
> > after all - but they're not supposed to be used on platforms.
> "some time in future" means utopia.... whenever that be. The longer that is
> to more important is it for dummy support to be 'complete'.
Well, for any given board it's very quick to resolve. It's just that
from time to time people will break things and then they'll get annoyed
(and probably spend forever complaining on the lists rather than the
brief time taken to make the patch).
> > In any case, as I've said it's not the fact that you've got a dummy
> > supply that's an issue for most of the cases you mention - it's the fact
> > that the supply is always on.
> I am not sure anymore you read my posts :(
> I am more bothered by the case where the supply is always off i.e,
> physically absent.
It's not what you first mentioned... In any case, the solution is very
clear - just do proper regulator support and turn off dummy regulators
and everything is fine.
> > Even in the case where a supply might genuinely be missing (which are
> > very unusual, it's more effort in silicon to cope with missing supplies)
> It's not that unusual. See vcc_aux at line 150 of omap_hsmmc.c
No, really - that's exceptionally unusual and quite honestly given the
"discussion" surrounding the addition of the regulator support there I'm
not convinced that anything the driver is doing here is sane; the whole
stuff with regulator_get_exclusive() never made any sense for MMC in the
first place (and has now been removed).
> See how dummy fools the driver throughout into stuff like toggling vcc
> even for platforms that don't really provide vcc_aux.
> In practice, see how dummy affects (negatively because of unnecessary
> toggles) the vcc too. Not every platform with omap_hsmmc might afford
> having dummy disabled (I don't know all to tell for sure).
The fix here is in the boards, not with the dummy code. Open coding
handling of this sort of stuff in individual consumers is just insane,
and you're always going to run into the situation where you don't know
if the dummy regulator is there because the board setup is incomplete or
because someone left the option turned on when it shouldn't be.
What you want here is something like regulator_get_real_no_really()
which never returns a dummy regulator but the whole thing is just adding
fragility onto bodge. I'm not overly concerned if systems don't run as
efficiently as they might when using dummy regulators because (like I
say) they're just a crutch to keep systems running.
Note also that the performance improvement stuff I sent the other day
will help here, the bounces will be very cheap now.
I'd much rather remove the feature than start going down this rabbit
hole, it's just going to be a world of pain and fragility. But then a
whole different bunch of people will complain.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-04-20 18:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 9:51 [PATCH] regulator: Provide a check for dummy regulator Jassi Brar
2012-04-19 12:42 ` Mark Brown
2012-04-19 14:05 ` Jassi Brar
2012-04-19 16:29 ` Mark Brown
2012-04-20 7:32 ` Jassi Brar
2012-04-20 11:46 ` Mark Brown
2012-04-20 12:29 ` Jassi Brar
2012-04-20 13:01 ` Mark Brown
2012-04-20 13:48 ` Jassi Brar
2012-04-20 14:13 ` Jassi Brar
2012-04-20 14:42 ` Mark Brown
2012-04-20 18:25 ` Jassi Brar
2012-04-20 18:48 ` Mark Brown [this message]
2012-04-20 19:11 ` Jassi Brar
2012-04-20 22:04 ` 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=20120420184806.GA3092@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=jaswinder.singh@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox