[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0b634341-ea2b-e9cd-4986-dc9a01c839bb@gmail.com>
Date: Wed, 4 Dec 2019 16:57:53 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>, sumitg <sumitg@...dia.com>
Cc: 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
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()?
>>> - populating cpufreq table, you can probably add OPPs instead using
>>> the same mechanism
>>
>> We are reading available frequencies from BPMP to populate
>>
>> cpufreq table and not using static opp table.
>
> Right and lot of other platforms read it from firmware (I believe BBMP
> is a firmware here), and create OPPs at runtime. Look at this for
> example:
>
> drivers/cpufreq/qcom-cpufreq-hw.c
>
> and search for dev_pm_opp_add().
>
Powered by blists - more mailing lists