Messages in this thread | | | Date | Wed, 5 Aug 2020 13:36:43 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers |
| |
On Tue, Aug 04, 2020 at 10:19:23AM -0700, Florian Fainelli wrote: > > > On 7/31/2020 8:56 AM, Sudeep Holla wrote: > > On Thu, Jul 30, 2020 at 10:36:51AM +0100, Lukasz Luba wrote: > >> > >> In this case I think we would have to create debugfs. > >> Sudeep do you think these debugfs should be exposed from the protocol > >> layer: > >> drivers/firmware/arm_scmi/perf.c > > > > I prefer above over cpufreq as we can support for all the devices not > > just cpus which avoids adding similar support elsewhere(mostly devfreq) > > > >> or maybe from the cpufreq scmi driver? I would probably be safer to have > >> it in the cpufreq driver because we have scmi_handle there. > >> > > > > Cristian was thinking if we can consolidate all such debugfs under one > > device may be and that should eliminate your handle restriction. I would > > like to see how that works out in implementation but I don't have any > > better suggestion ATM. > > debugfs is not enabled in production kernels, and especially not with > Android kernels, so sticking those in sysfs like the existing cpufreq > subsystem statistics may be a better choice.
Fair enough. I was suggesting that only if we can't push this into existing sysfs support. If we can, then we need not worry about it. If not, I don't want a user ABI just for SCMI for this firmware stats, I would rather keep it in debugfs for debug purposes. This will be useless once we start seeing AMU in the hardware and hence I was pushing for debugfs.
-- Regards, Sudeep
| |