linux-kernel - Re: [PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP

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: <20130501164905.GA21171@kahuna>
Date:	Wed, 1 May 2013 11:49:05 -0500
From:	Nishanth Menon <nm@...com>
To:	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Shawn Guo <shawn.guo@...aro.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 1/2] PM / OPP: add support to specify phandle of another
 node for OPP

On 17:28-20130501, Sudeep KarkadaNagesha wrote:
> On 01/05/13 15:41, Nishanth Menon wrote:
> > On 12:11-20130501, Sudeep.KarkadaNagesha@....com wrote:
> >> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@....com>
> >>
> >> If more than one similar devices share the same OPPs, currently we
> >> need to replicate the OPP entries in all the nodes.
> > Nice, thanks.
> >>
> >> Few drivers like cpufreq depend on physical cpu0 node to specify the
> > cpufreq-cpu0?
> Yes when I originally wrote this patch cpufreq-cpu0 was using cpu0 node.
> But later sometimes it was changed to parse all the nodes.
giving an explicit example like cpufreq-cpu0 might be helpful - but we
may have more cases like this else where with co-processors (devfreq
world).
[...]
> >> +a SoC or in a single cluster on a SoC, then we need to avoid replicating the
> >> +OPPs in all the nodes. We can specify the phandle of the node with which the
> >> +current node shares the operating points instead.
> >> +
> >> +Examples:
> >> +Consider an SMP with 4 CPUs all sharing the same OPPs.
> > We might want to descr
> I could not get what exactly you mean by 'descr', do you mean more
> descriptive ? If so, what exactly you would like to add ?
Arrgh.. Typical of me to forget my reply thread and leave it dangling
when someone interrupts me :( Sigh.. Apologies about that.

I intended the following:
An example of bL might be 4 A15s and 3 a7s? A15s have different
frequencies Vs A7s?
The example below could easily be covered by cpufreq-cpu0 - so an actual
usage illustrated will help.
> 
> >> +
> >> +cpu0: cpu@0 {
> >> +	compatible = "arm,cortex-a9";
> >> +	reg = <0>;
> >> +	next-level-cache = <&L2>;
> >> +	operating-points = <
> >> +		/* kHz    uV */
> >> +		792000  1100000
> >> +		396000  950000
> >> +		198000  850000
> >> +	>;
> >> +};
> >> +
> >> +cpu1: cpu@1 {
> >> +	compatible = "arm,cortex-a9";
> >> +	reg = <1>;
> >> +	next-level-cache = <&L2>;
> >> +	operating-points = <&cpu0>;
> >> +};
[...]
> 
> >>  {
> >> +	struct device_opp *dev_opp = NULL;
> > dev_opp is not used until patch #2 - please introduce it in that patch.
> Correct it was meant to be in patch#2, will move in next version
I'd hold on to the rev 2 until we are clear that we have precedence for
allowing parameters to have two different formats.

I might optionally go with introducing a new parameter to indicate
phandle lists similar to pinctrl.. Just a thought. There may be other
usage for the same in addition to resolving the scenario you mention.
Trivial example:
cpu0 can take three different operating-point sets ->
default - 300MHz, 600MHz, 800MHz
regular performance - 300MHz, 600MHz, 800MHz, 1GHz
performance - 300MHz, 600MHz, 800MHz, 1GHz, 1.7GHz

Choice is made which set it picks up.
making operating-points as a phandle by itself is questionable as it
does not really represent an hardware device - but options for
operation.

-- 
Regards,
Nishanth Menon
--
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/