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: <20150811142812.GJ5509@linux>
Date:	Tue, 11 Aug 2015 19:58:12 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Lee Jones <lee.jones@...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 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 :)

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

But, something like this should be generic enough to capture most of
the cases.

@Stephen/Rob ??

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