Messages in this thread | | | Date | Wed, 7 Jun 2023 10:58:56 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH] arm64: Provide an AMU-based version of arch_freq_get_on_cpu |
| |
On Tue, Jun 06, 2023 at 04:57:54PM +0100, Beata Michalska wrote: > With the Frequency Invariance Engine (FIE) being already wired up with > sched tick and making use of relevant (core counter and constant > counter) AMU counters, getting the current frequency for a given CPU > on supported platforms, can be achieved by utilizing the frequency scale > factor which reflects an average CPU frequency for the last tick period > length. > > With that at hand, arch_freq_get_on_cpu dedicated implementation > gets enrolled into cpuinfo_cur_freq policy sysfs attribute handler, > which is expected to represent the current frequency of a given CPU, > as obtained by the hardware. This is exactly the type of feedback that > cycle counters provide. > > In order to avoid calling arch_freq_get_on_cpu from the scaling_cur_freq > attribute handler for platforms that do provide cpuinfo_cur_freq, and > yet keeping things intact for those platform that do not, its use gets > conditioned on the presence of cpufreq_driver (*get) callback (which also > seems to be the case for creating cpuinfo_cur_freq attribute). >
LGTM,
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
However I fail to understand if both the changes are dependent ? Can this be split into 2 patches ? I fail to see the dependency, what am I missing ? Even if there is some dependency to get arch value (arch_freq_get_on_cpu() from show_cpuinfo_cur_freq()), you can push that change first followed by the arm64 change as 2 different change.
-- Regards, Sudeep
| |