On Fri, May 09, 2014 at 06:05:56PM +0100, Sudeep Holla wrote:
On 09/05/14 17:40, Mark Brown wrote:
From: Mark Brown broonie@linaro.org
The big.LITTLE cpufreq driver is useful on arm64 big.LITTLE systems even without IKS support since it implements support for clusters with shared clocks (a common big.LITTLE configuration). In order to allow it to be built provide the non-IKS stubs for arm64, enabling cpufreq with all the cores available.
I am in process of using this driver for ARM64 and hit the same issue. I don't like this approach at all. I too did similar changes/hacks which are good for quick testing but not for upstream.
I'm not a big fan of this either, but then as I indicated on the cpufreq bit of the series I'm not a massive fan of the way this is handled in the first place on either ARM or ARMv8. This at least gives us parity between the two architectures (modulo IKS implementation) which is progress especially given the fact that much of the work done on this stuff is being done on 32 bit due to hardware availability.
Given that the code isn't invasive I think the expediency tradeoff is OK for mainline, it's easy enough to get rid of when we come up with something better but in the meaintine it helps actual systems work better in mainline - if we didn't have the ARM implementation already I think it'd be different but we do.
Perfect can be the enemy of good (or at least adequate), one of the problems I'm seeing right now with convincing people to work with mainline is that people are missing lots of important functionality when they look at mainline.
I would like to move all the switcher code out of the driver as extension. Also the core driver should be made to work with any multi-clsuter platform not just big-little(bL). bL is one of them and bL switcher support should an extension of it.
The main reason for this is I see some non-bL multi-cluster platform support getting added, this driver should ideally support that.
It is not entirely clear to me what you mean by "this driver" or "the core driver" in all the above, sorry.
Personally the solution I'd rather see is cpufreq-cpu0 extended to handle shared clocks which would remove the need to use the big.LITTLE driver on systems not doing IKS. It isn't at all clear to me that cpufreq should understand clusters (or much of anything other than clocks) in the non-IKS case, the sharing of clocks between cores is not directly connected to their clustering. Clustering is important to the scheduler and an understanding of the power and clock sharing constraints that come along with clusters is going to be required there as part of energy aware scheduling but I'm not seeing any obvious reason for the frequency scaling driver to know about this, even with cpufreq governors it's mostly the clock sharing.
For IKS where we're pairing the CPUs up and telling the kernel that switching between the physical clusters is part of scaling the "frequency" of the virtual cluster presented to the rest of the system things are of course different and cpufreq does need to understand the physical clusters.
Having multiple generic frequency scaling drivers feels wrong; there's going to be code duplication between them and it doesn't seem like there should be anything going on that we can't automatically figure out at runtime.