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]

Date:	Tue, 17 Aug 2010 12:33:33 -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 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.

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