On Fri, 18 Jan 2019 at 02:44, Al Grant Al.Grant@arm.com wrote:
Hi,
One of the top questions that comes up on CoreSight is how it interacts with CPU power saving, and I'd like to get a handle on where we are with this. This will help us understand if any more work needs to be done.
I'd suggest three levels of support:
- transparent: use of CoreSight has no effect on CPU power saving - if an idle
CPU would have been powered down it's still powered down. Any increased power draw from CoreSight comes from debug/trace blocks being powered up as necessary, not from keeping entire CPUs powered up.
Yes, that is the ideal scenario and also how Juno is currently working. It uses the TRCPDRC:PU bit and requires FW and PMIC support. To the best of my knowledge it is the only platform that works this way. It is hard to implement because it requires involvement from different teams (kernel, FW, PMIC) and the HW needs to have been designed properly.
Seeing the improbability to get all this right on all platform, three years ago I set out to fix the solution in the kernel by using the genPD subsystem. That was swiftly refused by the Juno maintainers, leaving only the above as an option.
- automatic wakelock: use of CoreSight has the effect of disabling powering
off of idle CPUs, so there may be a significant increase in power consumption, but it's done automatically and works out of the box. CoreSight itself is fully functional irrespective of how the system is configured.
This is functionality that I will not accept upstream and will have to be carried (and maintained) out of tree by ARM. To me it is better to spend time and efforts on making things right using either the FW/PMIC mechanic or genPD.
- invasive: power saving must be disabled manually - i.e. you have to get a
manual (and possibly device-specific) recipe from somewhere. If you don't then things will break (loss of trace at best, crash at worst).
That is how all platforms (except Juno) currently work. CPUidle needs to be manually disabled at compilation time or at runtime via sysfs.
I would hope that perf (all modes) is transparent, and direct use of sysfs is at worst a wakelock... but where are we now? Are there still boards that need manual recipes with the current kernel - either with perf or with sysfs?
I think the first thing that needs to be worked on is the integration of CPUs with genPD so that CPU power domains can be controlled by genPD rather than CPUidle. That way power management can be done by the kernel rather than in FW. I'm being told the functionality is now supported in genPD but I wouldn't bet a penny that it is adequate for CS or that it does exactly what we want.
Second is properly handling CPUhotplug operation when perf or sysfs sessions are ongoing.
Mathieu
Thanks,
Al _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight