[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210616080310.vhvauvo5y6m2sekz@vireshk-i7>
Date: Wed, 16 Jun 2021 13:33:10 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Dmitry Osipenko <digetx@...il.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
vincent.guittot@...aro.org,
Thara Gopinath <thara.gopinath@...aro.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Zhang Rui <rui.zhang@...el.com>,
Amit Kucheria <amitk@...nel.org>,
Andreas Westman Dorcsak <hedmoo@...oo.com>,
Maxim Schwalm <maxim.schwalm@...il.com>,
Svyatoslav Ryhel <clamor95@...il.com>,
Ihor Didenko <tailormoon@...bler.ru>,
Ion Agorria <ion@...rria.com>,
Matt Merhar <mattmerhar@...tonmail.com>,
Peter Geis <pgwipeout@...il.com>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 4/7] thermal/drivers/tegra: Add driver for Tegra30
thermal sensor
+Vincent.
On 15-06-21, 22:32, Dmitry Osipenko wrote:
> IIUC, the cpufreq already should be prepared for the case where firmware
> may override frequency. Viresh, could you please clarify what are the
> possible implications of the frequency overriding?
The only implication is software would think hardware is running at
some other frequency, while it is not. Not sure if something may break
as a result of this.
The scheduler's view of CPUs will not be same though, i.e. scheduler
will see capacity as X, while in reality it has changed to Y.
--
viresh
Powered by blists - more mailing lists