All of lore.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 15:42:57 +0100	[thread overview]
Message-ID: <20120420144256.GA6828@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJe_ZhdKtK8YKo1qc8g18XrdnrQRZw2aFSkW8x3koELU10EsHw@mail.gmail.com>

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

On Fri, Apr 20, 2012 at 07:18:15PM +0530, Jassi Brar wrote:
> On 20 April 2012 18:31, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > No.  You're failing to understand what dummy regulators are for.

> I think I do understand what dummy regulators are for and also that
> they are meant to go away some time in future.

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.

> >  To repeat yet again you're not supposed to actually use dummy regulators,
> > you're supposed to fully specify the regulators on your platform.

> I use dummy regulators for what they are meant for - until every platform
> completely define supplies for every consumer.
> We are not there yet, yet one 'ideal' consumer suffers because of that.

> If you ask me to go away and disable dummy and update all consumers
> and their platforms, then I say why not remove the concept of dummy
> altogether which only delays full compliance to the regulator api ?

The only reason dummy regulators are there is to provide a get out of
jail card to help keep systems booting when there's a problem with their
regulator setup.  Managing the introduction of regulator support to new
drivers is relatively hard, I don't see us getting it right first time
every time, so it's unlikely we'll ever be able to get rid of these
crutches.  It keeps people happy so even though the regulator setup is
generally trivial to fix when an issue crops up it's less hassle to have
the option.

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.  

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)
you're still stuck with guessing if the supply is missing because of
missing regulator setup or if the supply really is not physically
present.  If you really want to try to bodge in something for thingns
like this in the consumer probably a good solution is to do something
like have the driver check that it can get a sensible voltage back
though I'd be interested to see a driver that can usefully use it and a
system which did so.  Your example seemed pretty theoretical and it'd be
more usual to tie to a supply so I'd really like to look at some
concrete systems that do this.

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

  parent reply	other threads:[~2012-04-20 14:43 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 [this message]
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=20120420144256.GA6828@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 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.