Messages in this thread | | | Date | Tue, 4 Aug 2020 16:08:57 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers |
| |
On 04-08-20, 11:29, Lukasz Luba wrote: > On 8/4/20 6:35 AM, Viresh Kumar wrote: > > IIUC, the only concern right now is to capture stats with fast switch ? Maybe we > > can do something else in that case and brainstorm a bit.. > > Correct, the fast switch is the only concern right now and not tracked. We > could fill in that information with statistics data from firmware > with a cpufreq driver help. > > I could make the if from patch 1/4 covering narrowed case, when > fast switch is present, check for drivers stats. > Something like: > -----------8<------------------------------------------------------------ > if (policy->fast_switch_enabled) > if (policy->has_driver_stats) > return cpufreq_stats_present_driver_data(policy, buf); > else > return 0; > -------------->8----------------------------------------------------------
I don't think doing it with help of firmware is the right thing to do here then. For another platform we may not have a firmware which can help us, we need something in the opp core itself for that. Lemme see if I can do something about it.
> > Why is firmware the governor here ? Aren't you talking about the simple fast > > switch case only ? > > I used a term 'governor' for the firmware because it makes the final > set for the frequency. It (FW) should respect the frequency value > set using the fast switch. I don't know how other firmware (e.g. Intel) > treats this fast switch value or if they even expose FW stats, though.
For Intel I think, Linux is one of the entities that vote for deciding the frequency of the CPUs and the firmware (after taking all such factors into account) chooses a frequency by its own, which must be >= the frequency requested by Linux.
> You can read about this statistics region in [1] at: > 4.5.5 Performance domain statistics shared memory region > > > > > Over that, I think this cpufreq stats information isn't parsed by any tool right > > now and tweaking it a bit won't hurt anyone (like if we start capturing things a > > bit differently). So we may not want to worry about breaking userspace ABI here, > > if what we are looking to do is the right thing to do. > > So, there is some hope... IMHO it would be better to have this cpufreq > stats in normal location, rather then in scmi debugfs.
I agree.
> > I am not sure what notifications are we talking about here. > > There is a notification mechanism described in the SCMI spec [1] at > 4.5.4 Notifications. > We were referring to that mechanism.
Ahh, I see. All I was thinking was about the cpufreq specific notifiers :)
-- viresh
| |