[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b886c49e4bdab4054d08f10b0d8fa763@codeaurora.org>
Date: Sat, 01 Feb 2020 17:51:59 +0530
From: Sibi Sankar <sibis@...eaurora.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Matthias Kaehlcke <mka@...omium.org>, viresh.kumar@...aro.org,
sboyd@...nel.org, georgi.djakov@...aro.org, saravanak@...gle.com,
nm@...com, bjorn.andersson@...aro.org, agross@...nel.org,
david.brown@...aro.org, robh+dt@...nel.org, mark.rutland@....com,
rjw@...ysocki.net, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, dianders@...omium.org,
vincent.guittot@...aro.org, amit.kucheria@...aro.org,
ulf.hansson@...aro.org, linux-kernel-owner@...r.kernel.org
Subject: Re: [RFC v3 02/10] cpufreq: blacklist SDM845 in cpufreq-dt-platdev
Hey Sudeep,
Thanks for the review!
On 2020-01-30 17:10, Sudeep Holla wrote:
> On Tue, Jan 28, 2020 at 12:44:23PM -0800, Matthias Kaehlcke wrote:
>> On Tue, Jan 28, 2020 at 01:33:42AM +0530, Sibi Sankar wrote:
>> > Add SDM845 to cpufreq-dt-platdev blacklist.
>>
>> nit: you could mention that cpufreq is handled by the
>> 'qcom-cpufreq-hw' driver.
>>
>
> IIUC, these platforms get the OPP table from the firmware and there
> shouldn't
> be OPP entries in the DT. If not, why not fix that to avoid more
> confusion.
> Can we make cpu0_node_has_opp_v2_prop return false in short.
The entire point of the series is to
define a way of identifying required
opp-kBps values for L3/DDR at different
cpu frequencies. The required-opps is
chosen as the way of showcasing the
dependencies. Hence the need to for a
superset cpu opp-table consisting of
all possible cpu freq values supported
by the family of SoCs and enabling only
the opps that are supported by the board
from the values read back from firmware.
>
> --
> Regards,
> Sudeep
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists