linux-kernel - Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

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: <20150811151736.GO18282@x1>
Date:	Tue, 11 Aug 2015 16:17:36 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Rob Herring <robherring2@...il.com>,
	Nishanth Menon <nm@...com>, kernel@...inux.com,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	Rafael Wysocki <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sebastian Reichel <sre@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Arnd Bergmann <arnd.bergmann@...aro.org>,
	Ajit Pal Singh <ajitpal.singh@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 14:27, Lee Jones wrote:
> > Okay, so what you're saying is that you've already made the decision
> > to create a separate node for every OPP permutation,
> 
> Absolutely not.
> 
> > despite the fact
> > that I've told you this could lead to more nodes than anyone would
> > care to successfully write or maintain?
> 
> I have enough fear of yours and then I have to see you in another
> month as well. I wouldn't dare to disobey your command SIR :)

Funny guy! ;)

> > Perhaps an example might help explain the issue.
> > 
> > Using the current driver, we need to place the following in DT and the
> > driver does the rest:
> > 
> > opp-list {
> > 	opp1 {
> > 		opp-hz = <1500000000>;
> > 		st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>;
> > 		st,substrate = <0xff>;
> > 		st,cuts = <0xff>;
> > 	};
> > 	opp0 {
> > 		opp-hz = <1200000000>;
> > 		st,avs = <1110 1150 1100 1080 1040 1020 980 930>;
> > 		st,substrate = <0xff>;
> > 		st,cuts = <0x2>;
> > 	};
> > };
> 
> Nothing is fixed as of now but this is what I am thinking of:
> 
> 	cpu0_opp_table: opp_table0 {
> 		compatible = "operating-points-v2";
>                 opp-cuts = "10", "3c", "f0";
> 		supply-names = "vcc0", "vcc1", "vcc2";
> 		opp-shared;
> 
> 		opp00 {
> 			opp-hz = /bits/ 64 <1000000000>;
> 			clock-latency-ns = <300000>;
> 			opp-microvolt-10 = <970000>;
> 			opp-microvolt-3c = <950000>;
> 			opp-microvolt-f0 = <930000>;
> 		};
> 
> 		/* OR */
> 
> 		opp00 {
> 			opp-hz = /bits/ 64 <1000000000>;
> 			clock-latency-ns = <300000>;
>                         opp-microvolt = <970000>, <950000>, <930000>;
> 		};
>         };
> 
> And then the platform code needs to tell OPP layer:
> "Use OPPs for cut f0 for device X", and OPP layer will store that
> somewhere.
> 
> And then it will only initialize OPPs after matching this string with
> the values.
> 
> Out of the earlier two options, I may prefer the first one. As we will
> be soon adding support for multiple regulators, and a single regulator
> can have min/max/target values.. So, a single list will become too
> long.

This would work if we only had a single variable to contend with, but
what I showed you in my previous example is that we have 3 variables
to consider; cut (version), pcode and substrate.

Using the two (simple) examples I provided, how would your suggestion
look in our case?

> But, something like this should be generic enough to capture most of
> the cases.
> 
> @Stephen/Rob ??
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/