Messages in this thread | | | Subject | Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers | From | Lukasz Luba <> | Date | Tue, 4 Aug 2020 11:44:10 +0100 |
| |
On 8/4/20 11:38 AM, Viresh Kumar wrote: > 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.
OK, great, I will wait then with this patch series v2 which would change into debugfs scmi only. Could you please add me on CC, I am very interested in.
> >>> 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 :) >
| |