Messages in this thread | | | Subject | Re: [TEGRA194_CPUFREQ Patch 2/3] cpufreq: Add Tegra194 cpufreq driver | From | sumitg <> | Date | Wed, 4 Dec 2019 16:25:57 +0530 |
| |
Hi Viresh,
On 04/12/19 11:10 AM, Viresh Kumar wrote: > Hi Sumit, > > On 03-12-19, 23:02, Sumit Gupta wrote: >> Add support for CPU frequency scaling on Tegra194. The frequency >> of each core can be adjusted by writing a clock divisor value to >> an MSR on the core. The range of valid divisors is queried from >> the BPMP. >> >> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> >> Signed-off-by: Sumit Gupta <sumitg@nvidia.com> >> --- >> drivers/cpufreq/Kconfig.arm | 6 + >> drivers/cpufreq/Makefile | 1 + >> drivers/cpufreq/tegra194-cpufreq.c | 423 +++++++++++++++++++++++++++++++++++++ >> 3 files changed, 430 insertions(+) >> create mode 100644 drivers/cpufreq/tegra194-cpufreq.c > Overall these are the things that you are doing here in the driver: > > - open coded clk_{get|set}_rate(), why can't you implement a clock > driver for the CPU and use the clk framework? You may not need the > (hacky) work-queue usage then probably.
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".
> > - 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.
> > - And then you can reuse the cpufreq-dt driver for your platform as > well, as is the case for few other tegra platforms. >
| |