Re: [PATCH 1/1] Revert "scsi: ufs: core: Only suspend clock scaling if scaling down"

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

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



> +       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