[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c26ed467-0e30-900b-4e69-762ee83e8377@gmail.com>
Date: Thu, 5 Dec 2019 15:55:45 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: sumitg <sumitg@...dia.com>, rjw@...ysocki.net,
catalin.marinas@....com, will@...nel.org, thierry.reding@...il.com,
jonathanh@...dia.com, talho@...dia.com, linux-pm@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, bbasu@...dia.com,
mperttunen@...dia.com
Subject: Re: [TEGRA194_CPUFREQ Patch 2/3] cpufreq: Add Tegra194 cpufreq driver
05.12.2019 05:51, Viresh Kumar пишет:
> On 04-12-19, 16:57, Dmitry Osipenko wrote:
>> 04.12.2019 14:27, Viresh Kumar пишет:
>>> On 04-12-19, 16:25, sumitg wrote:
>>>> In T194, CCPLEX doesn't have access to set clocks and the
>>>>
>>>> clk_{get|set}_rate() functions set clocks by hook to BPMP R5.
>>>>
>>>> CPU freq can be directly set by CCPLEX using MSR(NVFREQ_REQ_EL1).
>>>>
>>>> As DVFS run's on BPMP, another MSR (NVFREQ_FEEDBACK_EL1) is
>>>>
>>>> used to read the counters and calculate "actual" cpu freq at CCPLEX.
>>>>
>>>> So, "cpuinfo_cur_freq" node gives the actual cpu frequency and not
>>>>
>>>> given by node "scaling_cur_freq".
>>>
>>> Right, but why can't this be hidden in the CPU's clk driver instead,
>>> so cpufreq driver can just do clk_get_rate() and clk_set_rate() ?
>>
>> What about to make use of dev_pm_opp_register_set_opp_helper()?
>
> It has a different purpose where we have to play with different
> regulators. And that won't help with clk_get_rate() anyway.
Indeed that won't help with the clk.
Powered by blists - more mailing lists