| Message ID | 20240626103033.2332-2-quic_rampraka@quicinc.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Suspend clk scaling when there is no request | expand |
On Wed, Jun 26, 2024 at 04:00:32PM GMT, Ram Prakash Gupta wrote: > Currently ufs clk scaling is getting suspended only when the > clks are scaled down, but next when high load is generated its > adding a huge amount of latency in scaling up the clk and complete > the request post that. > > Now if the scaling is suspended in its existing state, and when high > load is generated it is helping improve the random performance KPI by > 28%. So suspending the scaling when there is no request. And the clk > would be put in low scaled state when the actual request load is low. > > Making this change as optional for other vendor by having the check > enabled using vops as for some vendor suspending without bringing the > clk in low scaled state might have impact on power consumption on the > SoC. > > Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> > --- > drivers/ufs/core/ufshcd.c | 3 ++- > include/ufs/ufshcd.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c > index 1b65e6ae4137..0dc9928ae18d 100644 > --- a/drivers/ufs/core/ufshcd.c > +++ b/drivers/ufs/core/ufshcd.c > @@ -1560,7 +1560,8 @@ static int ufshcd_devfreq_target(struct device *dev, > ktime_to_us(ktime_sub(ktime_get(), start)), ret); > > out: > - if (sched_clk_scaling_suspend_work && !scale_up) > + if (sched_clk_scaling_suspend_work && (!scale_up || > + hba->clk_scaling.suspend_on_no_request)) Really a nit: moving !scale_up to the next line would make easier to read. > queue_work(hba->clk_scaling.workq, > &hba->clk_scaling.suspend_work); > > diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h > index bad88bd91995..c14607f2890b 100644 > --- a/include/ufs/ufshcd.h > +++ b/include/ufs/ufshcd.h > @@ -457,6 +457,7 @@ struct ufs_clk_scaling { > bool is_initialized; > bool is_busy_started; > bool is_suspended; > + bool suspend_on_no_request; > }; > > #define UFS_EVENT_HIST_LENGTH 8 > -- > 2.17.1 >
On 6/26/2024 11:14 PM, Dmitry Baryshkov wrote: > On Wed, Jun 26, 2024 at 04:00:32PM GMT, Ram Prakash Gupta wrote: >> Currently ufs clk scaling is getting suspended only when the >> clks are scaled down, but next when high load is generated its >> adding a huge amount of latency in scaling up the clk and complete >> the request post that. >> >> Now if the scaling is suspended in its existing state, and when high >> load is generated it is helping improve the random performance KPI by >> 28%. So suspending the scaling when there is no request. And the clk >> would be put in low scaled state when the actual request load is low. >> >> Making this change as optional for other vendor by having the check >> enabled using vops as for some vendor suspending without bringing the >> clk in low scaled state might have impact on power consumption on the >> SoC. >> >> Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> >> --- >> drivers/ufs/core/ufshcd.c | 3 ++- >> include/ufs/ufshcd.h | 1 + >> 2 files changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c >> index 1b65e6ae4137..0dc9928ae18d 100644 >> --- a/drivers/ufs/core/ufshcd.c >> +++ b/drivers/ufs/core/ufshcd.c >> @@ -1560,7 +1560,8 @@ static int ufshcd_devfreq_target(struct device *dev, >> ktime_to_us(ktime_sub(ktime_get(), start)), ret); >> >> out: >> - if (sched_clk_scaling_suspend_work && !scale_up) >> + if (sched_clk_scaling_suspend_work && (!scale_up || >> + hba->clk_scaling.suspend_on_no_request)) > > Really a nit: moving !scale_up to the next line would make easier to > read. > thanks will take care in next patchset. >> queue_work(hba->clk_scaling.workq, >> &hba->clk_scaling.suspend_work); >> >> diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h >> index bad88bd91995..c14607f2890b 100644 >> --- a/include/ufs/ufshcd.h >> +++ b/include/ufs/ufshcd.h >> @@ -457,6 +457,7 @@ struct ufs_clk_scaling { >> bool is_initialized; >> bool is_busy_started; >> bool is_suspended; >> + bool suspend_on_no_request; >> }; >> >> #define UFS_EVENT_HIST_LENGTH 8 >> -- >> 2.17.1 >> >
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 1b65e6ae4137..0dc9928ae18d 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -1560,7 +1560,8 @@ static int ufshcd_devfreq_target(struct device *dev, ktime_to_us(ktime_sub(ktime_get(), start)), ret); out: - if (sched_clk_scaling_suspend_work && !scale_up) + if (sched_clk_scaling_suspend_work && (!scale_up || + hba->clk_scaling.suspend_on_no_request)) queue_work(hba->clk_scaling.workq, &hba->clk_scaling.suspend_work); diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h index bad88bd91995..c14607f2890b 100644 --- a/include/ufs/ufshcd.h +++ b/include/ufs/ufshcd.h @@ -457,6 +457,7 @@ struct ufs_clk_scaling { bool is_initialized; bool is_busy_started; bool is_suspended; + bool suspend_on_no_request; }; #define UFS_EVENT_HIST_LENGTH 8
Currently ufs clk scaling is getting suspended only when the clks are scaled down, but next when high load is generated its adding a huge amount of latency in scaling up the clk and complete the request post that. Now if the scaling is suspended in its existing state, and when high load is generated it is helping improve the random performance KPI by 28%. So suspending the scaling when there is no request. And the clk would be put in low scaled state when the actual request load is low. Making this change as optional for other vendor by having the check enabled using vops as for some vendor suspending without bringing the clk in low scaled state might have impact on power consumption on the SoC. Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com> --- drivers/ufs/core/ufshcd.c | 3 ++- include/ufs/ufshcd.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-)