From: Bobby Crabtree <bobbyc@codeaurora.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
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 12:33:33 -0700 [thread overview]
Message-ID: <4C6AE40D.7090206@codeaurora.org> (raw)
In-Reply-To: <20100817181557.GA5755@opensource.wolfsonmicro.com>
Mark Brown wrote:
> On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote:
>> I'm looking to upstream a new feature in which the regulator core
>> aggregates voltage requests from multiple consumers and applies the best
>> fitting voltage (e.g. max voltage) to a shared supply. The core would
>
> 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.
>> recompute the best fitting voltage when a consumer requests a voltage
>> change or requests to enable/disable the regulator (similar logic to
>> DRMS).
>
>> The reason we need this feature is for power savings. It would allow two
>> or more consumers to "vote" on a voltage that's lower than the normal
>> operating voltage.
>
> 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.
>> 1. Introduce a new API:
>
>> int regulator_set_optimum_voltage(struct regulator *regulator,
>> int min_uV, int max_uV);
>
> Why would you want to do this? This is just the same arguments as the
> standard regulator_set_voltage() call and if we're ever setting anything
> other than the optimal voltage we probably ought to just stop doing
> that.
>
"Optimum" was a bad choice of words. Seems that a new API isn't
preferred, so let's scrap this option.
next prev parent reply other threads:[~2010-08-17 19:33 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 [this message]
2010-08-17 19:50 ` Mark Brown
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=4C6AE40D.7090206@codeaurora.org \
--to=bobbyc@codeaurora.org \
--cc=broonie@opensource.wolfsonmicro.com \
--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 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.