On 14/10/2021 18.55, Ulf Hansson wrote:
Yes, this sounds like you should move away from modeling the memory part as a parent genpd for the CPUs' genpd. As Viresh pointed out, a devfreq driver seems like a better way to do this. As a matter of fact, there are already devfreq drivers that do this, unless I am mistaken. It looks like devfreq providers are listening to opp/cpufreq notifiers, as to get an indication of when it could make sense to change a performance state. In some cases the devfreq provider is also modeled as an interconnect provider, allowing consumers to specify memory bandwidth constraints, which may trigger a new performance state to be set for the memory controller. In the tegra case, the memory controller is modelled as an interconnect provider and the devfreq node is modelled as an interconnect-consumer of the memory controller. Perhaps this can work for apple SoCs too?
I was poking around and noticed the OPP core can already integrate with interconnect requirements, so perhaps the memory controller can be an interconnect provider, and the CPU nodes can directly reference it as a consumer? This seems like a more accurate model of what the hardware does, and I think I saw some devices doing this already.
(only problem is I have no idea of the actual bandwidth numbers involved here... I'll have to run some benchmarks to make sure this isn't just completely dummy data)
That said, perhaps as an option to move forward, we can try to get the cpufreq pieces solved first. Then as a step on top, add the performance scaling for the memory controller?
Sure; that's a pretty much independent part of this patchset, though I'm thinking I might as well try some things out for v2 anyway; if it looks like it'll take longer we can split it out and do just the cpufreq side.
-- Hector Martin (marcan@xxxxxxxxx) Public Key: https://mrcn.st/pub
