public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Bobby Crabtree <bobbyc@codeaurora.org>
Cc: lrg@slimlogic.co.uk, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: regulator voltage aggregation
Date: Tue, 17 Aug 2010 20:50:08 +0100	[thread overview]
Message-ID: <20100817195008.GC5755@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4C6AE40D.7090206@codeaurora.org>

On Tue, Aug 17, 2010 at 12:33:33PM -0700, Bobby Crabtree wrote:
> Mark Brown wrote:

> > It's unlikely that the highest voltage would ever be the best choice...

> We do need the highest voltage. Let's say we have two consumers
> (A and B). Both require 1.3V for "normal" operations. Then let's
> say that consumer A can save power by reducing the voltage to 1.1V
> (but it doesn't require 1.1V). If the core were to immediately apply
> 1.1V, then the 1.3V requirement of consumer B would not be satisfied.

That's not the highest voltage, that's the minimum voltage that
satisfies all the requests that the consumers have made.  The consumer
which requires 1.1V will have requested 1.1V up to, say, 3.3V.  The
consumer that requested 1.3V will have requested, say, 1.3-1.8V and
let's say the machine constraints will allow at least these ranges.
1.3V is the lowest voltage that hits all the constraints, but it's still
lower than any of the maxima.  When you've got multiple things
specifying a voltage constraint you need to apply the most restrictive
combination of constraints but it still makes sense to pick the minimum
voltage we can deliver from the range that's left after doing that.

> > This was actually a feature of the regulator API when originally
> > proposed, it got dropped for ease of review but there's some remanants
> > of this in the code so it shouldn't be hard to resurrect.  Whenever a
> > voltage was set the code stored the range on the consumer then iterated
> > over all consumers applying their ranges plus the machine constraints
> > rather than just using the immediate value.

> I noticed some of the remnants. But I'm not sure I follow what you
> are saying. What range would the core actually propagate to the
> driver? The minimum min_uV and the maximum max_uV? We need the core
> to propagate the maximum min_uV and the maximum max_uV.

No, it'd be the maximum min_uV and the minimum max_uV - this is already
happening when the constraints from the machine are applied, it'd just
be applying a wider set of constraints.  In principle all we need to do
is remember the voltage constraints that individual consumers set and
then iterate over all the enabled consumers when one of them changes its
range (or is enabled/disabled) instead of just taking the immediate
values from the consumer.

  reply	other threads:[~2010-08-17 19:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17 18:06 regulator voltage aggregation Bobby Crabtree
2010-08-17 18:15 ` Mark Brown
2010-08-17 19:33   ` Bobby Crabtree
2010-08-17 19:50     ` Mark Brown [this message]
2010-08-17 20:44       ` Bobby Crabtree
2010-08-17 21:03         ` Mark Brown
2010-08-17 18:28 ` Alan Cox
2010-08-17 18:22   ` 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=20100817195008.GC5755@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=bobbyc@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    /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