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 19:15:57 +0100	[thread overview]
Message-ID: <20100817181557.GA5755@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4C6ACF92.7050506@codeaurora.org>

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...

> 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.

> 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.

> 2. Add a flag to the regulation_constraints structure and reuse the
> existing regulator_set_voltage API.

> struct regulation_constraints {
>         ...
>         unsigned aggregate_uV:1;
>         ...
> };

> Does this sound like a reasonable feature? And if so, are there any
> preferences as to how the feature is implemented and exposed?

If we were going to add something for this it should be a capability,
however I don't think there's any need to add anything to the API since
this is the only sane interpretation of allowing voltage changes on a
regulator with more than one consumer.

  reply	other threads:[~2010-08-17 18:15 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 [this message]
2010-08-17 19:33   ` Bobby Crabtree
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=20100817181557.GA5755@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