-----Messaggio originale-----
Da: sibis=codeaurora.org@mg.codeaurora.org
[off-list ref] Per conto di Sibi Sankar
Inviato: giovedì 3 settembre 2020 09:13
A: Viresh Kumar [off-list ref]
Cc: ansuelsmth@gmail.com; vincent.guittot@linaro.org;
saravanak@google.com; 'Sudeep Holla' [off-list ref]; 'Rafael J.
Wysocki' [off-list ref]; 'Rob Herring' [off-list ref]; linux-
pm@vger.kernel.org; devicetree@vger.kernel.org; linux-
kernel@vger.kernel.org
Oggetto: Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

On 2020-09-03 12:23, Viresh Kumar wrote:

quoted

On 31-08-20, 09:41, ansuelsmth@gmail.com wrote:

quoted

On 31-08-20, Sibi wrote:

quoted

On 2020-08-24 16:10, Viresh Kumar wrote:

quoted

+Vincent/Saravana/Sibi

On 21-08-20, 16:00, Ansuel Smith wrote:

quoted

This adds Krait Cache scaling support using the cpufreq notifier.
I have some doubt about where this should be actually placed (clk

or

quoted

quoted

quoted

quoted

quoted

cpufreq)?
Also the original idea was to create a dedicated cpufreq driver

(like

quoted

quoted

quoted

quoted

quoted

it's done in
the codeaurora qcom repo) by copying the cpufreq-dt driver and

adding

quoted

quoted

quoted

quoted

quoted

the cache
scaling logic but i still don't know what is better. Have a very
similar driver or
add a dedicated driver only for the cache using the cpufreq

notifier

quoted

quoted

quoted

quoted

quoted

and do the
scale on every freq transition.
Thanks to everyone who will review or answer these questions.

Saravana was doing something with devfreq to solve such issues if I
wasn't mistaken.

Sibi ?

IIRC the final plan was to create a devfreq device
and devfreq-cpufreq based governor to scale them, this
way one can switch to a different governor if required.

So in this case I should convert this patch to a devfreq driver-

I think this should happen nevertheless. You are doing DVFS for a
device which isn't a CPU and devfreq looks to be the right place of
doing so.

quoted

Isn't overkill to use a governor for such a task?
(3 range based on the cpufreq?)

I am not sure about the governor part here, maybe it won't be required
?

Yeah I don't see it being needed in ^^
case as well. I just mentioned them as
an advantage in case you wanted to switch
to a different governor in the future.

https://lore.kernel.org/lkml/d0bc8877-6d41-f54e-1c4c-
2fadbb9dcd0b@samsung.com/

A devfreq governor tracking cpufreq was
generally accepted but using a cpufreq
notifier to achieve that was discouraged.

I read the patch discussion and it looks like at the very end they
lost interest in pushing it. That would very fit what I need here so
I'm asking how should I proceed? Keep the cpufreq notifier?
Introduce a dedicated governor? Ask them to resume the pushing or
try to include the changes to the passive governor by myself? 

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.