[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201009111711.5sl7m24engcwiqii@vireshk-i7>
Date: Fri, 9 Oct 2020 16:47:11 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Nicola Mazzucato <nicola.mazzucato@....com>
Cc: Ionela Voinescu <ionela.voinescu@....com>,
devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
vireshk@...nel.org, daniel.lezcano@...aro.org, rjw@...ysocki.net,
linux-kernel@...r.kernel.org, robh+dt@...nel.org,
sudeep.holla@....com, chris.redpath@....com,
morten.rasmussen@....com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for
cpu-perf-dependencies
On 09-10-20, 12:10, Nicola Mazzucato wrote:
> I thought about it and looked for other platforms' DT to see if can reuse
> existing opp information. Unfortunately I don't think it is optimal. The reason
> being that, because cpus have the same opp table it does not necessarily mean
> that they share a clock wire. It just tells us that they have the same
> capabilities (literally just tells us they have the same V/f op points).
No.
> Unless I am missing something?
Yes.
Here are the different scenarios which can happen.
- Two CPUs have separate OPP tables, even if they are exact copy of
each other, these CPUs don't share a clock line, but just v/f points
as you said.
- Two CPUs use the same OPP table, i.e. both point to it, but
"opp-shared" property is missing. This is same as above case. They
just share the v/f points and this is the preferred way instead of
duplicate OPP tables.
- Case two with "opp-shared" property present in the OPP table. The
CPUs share clock-lines.
And this is exactly how we find out today if CPUs share a policy or
not.
--
viresh
Powered by blists - more mailing lists