linux-kernel - Re: regulator voltage aggregation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C6AF4B4.4060004@codeaurora.org>
Date:	Tue, 17 Aug 2010 13:44:36 -0700
From:	Bobby Crabtree <bobbyc@...eaurora.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	lrg@...mlogic.co.uk, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: regulator voltage aggregation

Mark Brown wrote:
> 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.
> 
Aah. I get it now.

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

Got it.

Only remaining question I have is if the aggregation of
multiple consumer constraints should be the default (and only)
behavior. Or should we introduce a new flag to the
regulator_constraints structure that tells the core to aggregate
consumer voltages constraints?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/