Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist
From: Hector Martin
Date: Thu Oct 14 2021 - 07:44:06 EST
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