public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 14:01:34 +0100	[thread overview]
Message-ID: <20120420130134.GA5957@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJe_ZhdKv_7fTj9ZhJE0JzmuhxEZn-JmSbHu615YMXoWZUei9A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

On Fri, Apr 20, 2012 at 05:59:42PM +0530, Jassi Brar wrote:

> That's what I have been trying to fix. My example might be fictitious but
> I have a real scenario with omap_hsmmc (I was avoiding getting into that).

> The dummy not just provide a place holder data structure for missing definition
> of an available supply, but it also masks the fact that there might indeed be no
> supply at all on the given machine.

> As I said, atm the only option for a consumer is to know it via PD/DT.

No.  You're failing to understand what dummy regulators are for.  To
repeat yet again you're not supposed to actually use dummy regulators,
you're supposed to fully specify the regulators on your platform.  As
I've said several times now dummy regulators are just a crutch to hold
systems together, if they're not working out the solution is to turn
them off and even if they are working out turning them off is still the
best thing to do.  The problems you are seeing are exactly why this is
the case.

> The benefit is magnified by the fact that, for a given circuit, at
> least theoretically,
> there is no limit to the number/combination of supplies that could be controlled
> by inserting a regulator. And that could lead to a very noisy PD/DT.

No, any given circuit is going to have a very clear set of things that
can be controlled by a regulator, and most chips have a fixed set of
supplies they always need so it's very simple from their point of view.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-04-20 13:01 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 [this message]
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
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=20120420130134.GA5957@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