On 2018-07-31 01:00, Rafael J. Wysocki wrote:
On Mon, Jul 30, 2018 at 8:58 PM, <skannan@xxxxxxxxxxxxxx> wrote:
On 2018-07-29 03:52, Rafael J. Wysocki wrote:
On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan
<skannan@xxxxxxxxxxxxxx>
wrote:
Many CPU architectures have caches that can scale independent of the
CPUs.
Frequency scaling of the caches is necessary to make sure the cache
is
not
a performance bottleneck that leads to poor performance and power.
The
same
idea applies for RAM/DDR.
To achieve this, this patch adds a generic devfreq governor that can
listen
to the frequency transitions of each CPU frequency domain and then
adjusts
the frequency of the cache (or any devfreq device) based on the
frequency
of the CPUs.
To decide the frequency of the device, the governor does one of the
following:
* Uses a CPU frequency to device frequency mapping table
- Either one mapping table used for all CPU freq policies
(typically
used
for system with homogeneous cores/clusters that have the same
OPPs.
- One mapping table per CPU freq policy (typically used for ASMP
systems
with heterogeneous CPUs with different OPPs)
OR
* Scales the device frequency in proportion to the CPU frequency.
So, if
the CPUs are running at their max frequency, the device runs at
its max
frequency. If the CPUs are running at their min frequency, the
device
runs at its min frequency. And interpolated for frequencies in
between.
While not having looked at the details of the patch yet, I would
change the name of the feature to "Generic cpufreq transition
governor" to make it somewhat less ambiguous.
In my opinion it makes it look MORE like this is a cpufreq governor.
How
about the following?
PM / devfreq: Generic cpufreq to devfreq mapping governor
Seem a lot more clear to me.
Well, it's not just mapping, but also it triggers on cpufreq
transitions AFAICS.
Right, but I'm not sure that's the most important aspect of this
governor.
Which makes me wonder if the approach here is the right one at all.
Shouldn't the cpufreq driver be hooked up to the related HW through
the OPP framework and sharing access with devfreq rather?
Not sure what you mean here. This devfreq governor is orthogonal to what
the cpufreq driver does with its HW. This is just trying to scale L3 or
DDR or whatever other device based on current CPU frequency. Not all
CPUfreq drivers support OPP. And even if they do, I don't see how it's
relevant here.
Thanks,
Saravana
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
