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, 29 Nov 2016 17:08:04 -0800
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Kevin Hilman <khilman@...libre.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Nayak Rajendra <rnayak@...eaurora.org>
Subject: Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state
 binding

On 11/29, Viresh Kumar wrote:
> On 28-11-16, 10:27, Stephen Boyd wrote:
> > On 11/23/2016 08:40 PM, Viresh Kumar wrote:
> > > But even in these cases we wouldn't be using the voltage values within the
> > > kernel as we will be giving only a performance state to the M3 core, right?
> > 
> > Nope. In these cases we need to set a certain voltage and we do that by
> > requesting it via the M3 core.
> 
> Don't we need something like this then ?

Perhaps. One question is if we consider a shared regulator as a
regulator in the kernel, or if we want to hide the regulator
behind some other API that aggregates the users of the voltage. I
don't see how to draw the line clearly between a regulator and a
power domain that modifies a regulator underneath. It seems like
everything that's using a regulator on the SoC could be using a
power domain instead and then we could be aggregating the voltage
requirements outside of the regulator APIs.

The only other way I can think of doing it is by having the
voltages in the OPP tables for each device. That gets sort of
messy though because all the devices calling
regulator_set_voltage() have to set the min voltage to be their
required voltage and the max to be the global max voltage on the
system. Otherwise a higher voltage may not be used while it may
be required. Of course, we could encode that as the last value in
the triplet and everything works.

> 
> 	parent: power-controller@...40000 {
> 		compatible = "foo,power-controller";
> 		reg = <0x12340000 0x1000>;
> 		#power-domain-cells = <0>;
> 		domain-performance-states = <&perf_state0>;
> 	};
> 
> 	perf_state0: performance_states {
> 		pstate1: pstate@1 {
> 			index = <1>;
> 			/* Optional */
> 			microvolt = <970000 975000 985000>;
> 		};
> 		pstate2: pstate@2 {
> 			index = <2>;
> 			/* Optional */
> 			microvolt = <970000 975000 985000>;
> 		};
> 		pstate3: pstate@3 {
> 			index = <3>;
> 			/* Optional */
> 			microvolt = <970000 975000 985000>;
> 		};
> 	}
> 
> 	cpus {
> 		cpu@0 {
> 			...
> 			power-domain = <&parent>;
> 			operating-points-v2 = <&cpu0_opp_table>;
> 		};
> 	};
> 
> 	cpu0_opp_table: opp_table0 {
> 		compatible = "operating-points-v2";
> 		opp-shared;
> 
> 		opp@...0000000 {
> 			opp-hz = /bits/ 64 <1000000000>;
> 			domain-performance-state = <&pstate1>;

What do we do if the device is part of multiple domains? For
example it may be part of two power domains for different pieces
of the silicon within one device, and we may want to
independently control those domains depending on the clock
frequency.

> 		};
> 		opp@...0000000 {
> 			opp-hz = /bits/ 64 <1100000000>;
> 			domain-performance-state = <&pstate2>;
> 		};
> 		opp@...0000000 {
> 			opp-hz = /bits/ 64 <1200000000>;
> 			domain-performance-state = <&pstate3>;
> 		};

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ