LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Liam Girdwood <lg@opensource.wolfsonmicro.com>
Cc: linux-arm-kernel@lists.arm.linux.org.uk,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface
Date: Mon, 10 Mar 2008 18:00:25 -0800	[thread overview]
Message-ID: <200803101900.25430.david-b@pacbell.net> (raw)
In-Reply-To: <1205061053.13653.114.camel@localhost.localdomain>

On Sunday 09 March 2008, Liam Girdwood wrote:
> 
> > > +int regulator_set_voltage(struct regulator *regulator, int uV);
> > 
> > You described a mode where consumers could set ranges that
> > might overlap (e.g. 1.6 to 1.9V, 1.8 to 2.0) and the result
> > would be some compatible result.  But I don't see how that
> > could be achieved, since that's the only call to provide
> > a consumer's constraints.
> 
> In this example the power domain constraint (not consumer constraint)
> would be 1.6 - > 2.0 V. 

I was actually thinking of a chip I've used which has four
prgrammable regulators:

  * Three are similar ... they can supply 2.5V, 2.75V, or
    3.0V; plus a regulator-specific fourth setting of either
    3.3V, 1.8V, or adjusted by board-specific feedback.

  * The fourth has eight settings (from 0.85V up to 1.6V).

Those are the hard power domain constraints for the chip.

But any given board (set of "consumers") needs to be able to
provide additional constraints.


> i.e. this range is safe for all consumers on 
> this domain as all can operate at 2.0V and some can operate as low as
> 1.6V.

You've declared similar hidden assumptions in response to some
of my other questions.  Such hidden assumptions are not helpful.
Best to document them, if they survive discussion ...

One assumption is that consumers can't make constraints.  That's
because of a second one, that somehow board designers can and will
ensure they don't need to.

I don't buy that.  If the designer ensured that there would be
no need for such constraints, then why even have a set_voltage()
request?  That adds a constraint ... but it's an inflexible one.


But maybe the broader issue is:  just what model are you using
for customization here?  At what points are constraints specific
to a chip, board, or external connection applied?


My assumption is that the regulators themselves should know
only about their hard constraints ... most often specific to
the chip (this regulator is optimized for these voltages),
but sometimes specific to a given board's wiring (e.g. the
resistor ladder for a given voltage feedback channel).

And then additional constraints could come from consumers,
which would basically be of two types:  (a) board setup code,
and (b) drivers that cope with various situations, some of
which are externally imposed.  Those drivers would tend to
need just on/off controls for power domains they manage,
but in some cases (like the MMC example I mentioned) would
need more capability than that.


> The actual regulator output will be determined by consumer voltage
> requests. e.g. On power domain A, consumer x sets 1.8V and consumer y
> sets 1.9V, hence regulator output will be 1.9V. (as y needs 1.9 to
> operate, but x can operate at 1.8 - 2.0)

So when consumer X tunes everything to run in a low power mode
(using 1.6V as a better example), consumer Y can come along and
change things (to 2.0V ... 25% higher voltage, a "huge" delta)?

How would consume X know that it's got to re-adjust things, and
shift out of a low power operational mode?  Or prevent the need
to do that?  (Or vice versa.  Y could come first, preventing X
from entering a low power mode ... though maybe X could still
run in a high power mode.)


> > Presumably one configures a voltage then enables it?  How
> > does one turn a voltage supply on or off?  I'm guessing
> > that zero volts doesn't equate to "off"...
> 
> Some regulators cant go down as far as 0V ;)

For the ones that can, shouldn't that be equivalent to disabling
the regulator?  And for ones that can't, doesn't that mean
that regulator can not be enabled or disabled??

This "interface" definition is at best vague about quite a
lot of issues like these.

 
> We have regulator_enable() and regulator
> regulator output.
> 
> e.g. set voltage -> enable -> do some stuff -> disable. 

Would it be allowable to enable -> set voltage too?

Oh ... and if the regulator doesn't have a setting for
the specific voltage requested, is it allowed to choose
something "close"?  (How close is close enough?)  Or must
it instead fail?

- Dave


  parent reply	other threads:[~2008-03-11  2:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06 18:10 Liam Girdwood
2008-03-08  3:43 ` David Brownell
2008-03-09 11:10   ` Liam Girdwood
2008-03-11  0:39     ` David Brownell
2008-03-11 10:20       ` Liam Girdwood
2008-03-11 21:36         ` David Brownell
2008-03-11 22:25           ` David Brownell
2008-03-12  0:00             ` Mark Brown
2008-03-12  7:31               ` David Brownell
2008-03-12 13:02                 ` Mark Brown
2008-03-12 21:52                   ` David Brownell
2008-03-12 23:26                     ` ian
2008-03-13  4:39                       ` David Brownell
2008-03-12 23:57                     ` Mark Brown
2008-03-13  5:08                       ` David Brownell
2008-03-13 12:00                         ` Mark Brown
2008-03-11  2:00     ` David Brownell [this message]
2008-03-11 15:19       ` Liam Girdwood
2008-03-12  6:29         ` David Brownell

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=200803101900.25430.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=lg@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).