public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bobby Crabtree <bobbyc@codeaurora.org>,
	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:22:51 +0100	[thread overview]
Message-ID: <20100817182250.GB5755@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20100817192806.09744719@lxorguk.ukuu.org.uk>

On Tue, Aug 17, 2010 at 07:28:06PM +0100, Alan Cox wrote:
> O> int regulator_set_optimum_voltage(struct regulator *regulator,
> >                 int min_uV, int max_uV);

> Pedantic hat on - how can it be optimum if its a range ? (and an
> adjective but that is really pedantic) ;))

> Surely it's not the optimal value, it's the range at which it works at
> all you are defining (between off, and escaping smoke).

> set_voltage_range() sounds rather more natural to me.

The regulator API always specifies voltages in ranges, picking the
lowest possible voltage from the range.

One reason for this is that it allows us to finesse the mismatches
between the fixed steps that regulators offer and the requirements of
consumers - we don't needlessly fail to set a voltage due to a few
milivolts difference that the consumer doesn't care about.  The other
reason is that it maps very well onto a lot of applications which do
have fairly wide acceptable ranges.  For things like DVFS lowering the
frequency will typically reduce the minimum voltage required by the
device but will not affect the maximum voltage it can tolerate so we
allow the driver to specify the full range it can operate at and then
deliver the maximum power saving we can within the constraints of the
system.

      reply	other threads:[~2010-08-17 18:22 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
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 [this message]

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=20100817182250.GB5755@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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