[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201012041951.4qytnhuqvvzjionh@vireshk-i7>
Date: Mon, 12 Oct 2020 09:49:51 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Nicola Mazzucato <nicola.mazzucato@....com>
Cc: Rob Herring <robh@...nel.org>,
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, 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, 16:28, Nicola Mazzucato wrote:
> @Viresh
> I am sorry I misread your reply earlier thus I did not pay attention on that
> property.
> And yes, it is exactly as how you have described :)
> In the case 1 (different opps, different clk) and case 2 (same opps, different
> clk) we provide v/f points. In case 3, we add 'opp-shared' property in opp table
> to tell that the cpus with this opp table share a clock line.
>
> Here are my thoughts on this 3rd case:
> - the information of 'share the same clock line' comes correctly from DT as it's
> purely a hw description. The same applies for cpu-perf-dependencies.
> - because the opp table can come from any firmware, we won't have any opp table
> in DT, thus we won't be able to take advantage of 'opp-shared' I am afraid.
I wonder if we should use an empty OPP table just for parsing this
information.
--
viresh
Powered by blists - more mailing lists