[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191204112749.jkwlyteal4hfvnhb@vireshk-i7>
Date: Wed, 4 Dec 2019 16:57:49 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: 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
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() ?
> >
> > - 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().
--
viresh
Powered by blists - more mailing lists