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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox