On Tue, Aug 04, 2020 at 10:19:23AM -0700, Florian Fainelli wrote:

On 7/31/2020 8:56 AM, Sudeep Holla wrote:

quoted

On Thu, Jul 30, 2020 at 10:36:51AM +0100, Lukasz Luba wrote:

quoted

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)

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel