On 4/25/2024 6:45 PM, Peter Wang (王信友) wrote:
On Wed, 2024-04-24 at 14:44 +0530, Ram Prakash Gupta wrote:
Hi Peter,
I tried different dvfs settings, none is helping including enlarged
polling period time, its degrading perf numbers as its taking longer
time to scale up when the load is high and clk is low.
I checked from power side on qualcomm boards, suspending with zero
request is not impacting power hence I am consider a vops to add
which
can help your use case too, I tested this vops and it works fine on
qualcomm boards.
here is a small snippet of a different approach using vops, which I
am
planning to push under a separate mail subject to remove this
deadlock
between mediatek and qualcomm, scaling config.
- if (sched_clk_scaling_suspend_work && !scale_up)
+ if (sched_clk_scaling_suspend_work &&
hba->clk_scaling.no_req_suspend)
+ queue_work(hba->clk_scaling.workq,
+ &hba->clk_scaling.suspend_work);
Hi Ram,
It is weird for me that if no_req_suspend is true, queue suspend work?
Dosen't "no_req_suspend" simply mean "do not suspend"?
Thanks
Peter
Hi Peter,
well I intended to shorthand the naming of macro for "no request
suspend", meaning suspend when there is no request, which I want to
control in the scaling logic.
I am open to suggestion on name of the variable if you suggest any other
meaningful name.
and earlier the logic was, scaling was getting suspended when there were
no request, that we would like to keep via vops for qcom board, rest
everyone can use the default existing logic.
Thanks,
Ram
+ else if (sched_clk_scaling_suspend_work && !scale_up)
Here no_req_suspend would be false by default, so would hit else if
case, which is desirable for mediatek boards. For qualcomm,
no_req_suspend would set it to true via vops. please let me know if
this
is ok for you.
Thanks,
Ram