* [PATCH V2 0/2] Suspend clk scaling when there is no request
@ 2024-06-27 8:37 Ram Prakash Gupta
2024-06-27 8:37 ` [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on " Ram Prakash Gupta
` (5 more replies)
0 siblings, 6 replies; 10+ messages in thread
From: Ram Prakash Gupta @ 2024-06-27 8:37 UTC (permalink / raw)
To: James E.J. Bottomley, Martin K. Petersen, Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, Bart Van Assche, linux-scsi,
linux-kernel, linux-arm-msm, quic_cang, quic_nguyenb,
quic_rampraka, quic_pragalla, quic_nitirawa
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.
Changes since V1:
- Address minor review comment.
Ram Prakash Gupta (2):
scsi: ufs: Suspend clk scaling on no request
scsi: ufs: qcom: Enable suspending clk scaling on no request
drivers/ufs/core/ufshcd.c | 3 ++-
drivers/ufs/host/ufs-qcom.c | 2 ++
include/ufs/ufshcd.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on no request
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
@ 2024-06-27 8:37 ` Ram Prakash Gupta
2024-06-27 16:35 ` Bart Van Assche
2024-06-27 8:37 ` [PATCH v2 2/2] scsi: ufs: qcom: Enable suspending " Ram Prakash Gupta
` (4 subsequent siblings)
5 siblings, 1 reply; 10+ messages in thread
From: Ram Prakash Gupta @ 2024-06-27 8:37 UTC (permalink / raw)
To: James E.J. Bottomley, Martin K. Petersen, Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, Bart Van Assche, linux-scsi,
linux-kernel, linux-arm-msm, quic_cang, quic_nguyenb,
quic_rampraka, quic_pragalla, quic_nitirawa
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..9f935e5c60e8 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
--
2.17.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v2 2/2] scsi: ufs: qcom: Enable suspending clk scaling on no request
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
2024-06-27 8:37 ` [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on " Ram Prakash Gupta
@ 2024-06-27 8:37 ` Ram Prakash Gupta
2024-06-27 16:36 ` [PATCH V2 0/2] Suspend clk scaling when there is " Bart Van Assche
` (3 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: Ram Prakash Gupta @ 2024-06-27 8:37 UTC (permalink / raw)
To: James E.J. Bottomley, Martin K. Petersen, Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, Bart Van Assche, linux-scsi,
linux-kernel, linux-arm-msm, quic_cang, quic_nguyenb,
quic_rampraka, quic_pragalla, quic_nitirawa
Enable suspending clk scaling on no request for Qualcomm SoC.
Signed-off-by: Ram Prakash Gupta <quic_rampraka@quicinc.com>
---
drivers/ufs/host/ufs-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index cca190d1c577..9041ffab152c 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -1548,6 +1548,8 @@ static void ufs_qcom_config_scaling_param(struct ufs_hba *hba,
p->timer = DEVFREQ_TIMER_DELAYED;
d->upthreshold = 70;
d->downdifferential = 5;
+
+ hba->clk_scaling.suspend_on_no_request = true;
}
#else
static void ufs_qcom_config_scaling_param(struct ufs_hba *hba,
--
2.17.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on no request
2024-06-27 8:37 ` [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on " Ram Prakash Gupta
@ 2024-06-27 16:35 ` Bart Van Assche
2024-06-27 16:59 ` Ram Prakash Gupta
0 siblings, 1 reply; 10+ messages in thread
From: Bart Van Assche @ 2024-06-27 16:35 UTC (permalink / raw)
To: Ram Prakash Gupta, James E.J. Bottomley, Martin K. Petersen,
Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, linux-scsi, linux-kernel, linux-arm-msm,
quic_cang, quic_nguyenb, quic_pragalla, quic_nitirawa
On 6/27/24 1:37 AM, Ram Prakash Gupta wrote:
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 1b65e6ae4137..9f935e5c60e8 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
Who are the other vendors that support clock scaling? I'm asking because
I don't think that the behavior change introduced by this patch should
depend on the SoC vendor.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 0/2] Suspend clk scaling when there is no request
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
2024-06-27 8:37 ` [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on " Ram Prakash Gupta
2024-06-27 8:37 ` [PATCH v2 2/2] scsi: ufs: qcom: Enable suspending " Ram Prakash Gupta
@ 2024-06-27 16:36 ` Bart Van Assche
2024-06-27 17:06 ` Ram Prakash Gupta
2024-06-28 19:34 ` Bart Van Assche
` (2 subsequent siblings)
5 siblings, 1 reply; 10+ messages in thread
From: Bart Van Assche @ 2024-06-27 16:36 UTC (permalink / raw)
To: Ram Prakash Gupta, James E.J. Bottomley, Martin K. Petersen,
Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, linux-scsi, linux-kernel, linux-arm-msm,
quic_cang, quic_nguyenb, quic_pragalla, quic_nitirawa
On 6/27/24 1:37 AM, Ram Prakash Gupta wrote:
> Changes since V1:
> - Address minor review comment.
This is too vague. Please be more specific in patch changelogs.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on no request
2024-06-27 16:35 ` Bart Van Assche
@ 2024-06-27 16:59 ` Ram Prakash Gupta
0 siblings, 0 replies; 10+ messages in thread
From: Ram Prakash Gupta @ 2024-06-27 16:59 UTC (permalink / raw)
To: Bart Van Assche, James E.J. Bottomley, Martin K. Petersen,
Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, linux-scsi, linux-kernel, linux-arm-msm,
quic_cang, quic_nguyenb, quic_pragalla, quic_nitirawa
On 6/27/2024 10:05 PM, Bart Van Assche wrote:
> On 6/27/24 1:37 AM, Ram Prakash Gupta wrote:
>> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
>> index 1b65e6ae4137..9f935e5c60e8 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
>
> Who are the other vendors that support clock scaling? I'm asking because
> I don't think that the behavior change introduced by this patch should
> depend on the SoC vendor.
>
> Thanks,
>
> Bart.
Hi Bart,
I guess, Mediatek is one vendor who is having this feature in use as I
see some fixes coming from Peter with respect to clk scaling, where some
power regression on mediatek chipsets were addressed.
Please check below link for background of this change and reason to keep
it vendor specific.
https://www.spinics.net/lists/linux-scsi/msg193591.html
Thanks,
Ram
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 0/2] Suspend clk scaling when there is no request
2024-06-27 16:36 ` [PATCH V2 0/2] Suspend clk scaling when there is " Bart Van Assche
@ 2024-06-27 17:06 ` Ram Prakash Gupta
0 siblings, 0 replies; 10+ messages in thread
From: Ram Prakash Gupta @ 2024-06-27 17:06 UTC (permalink / raw)
To: Bart Van Assche, James E.J. Bottomley, Martin K. Petersen,
Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, linux-scsi, linux-kernel, linux-arm-msm,
quic_cang, quic_nguyenb, quic_pragalla, quic_nitirawa
On 6/27/2024 10:06 PM, Bart Van Assche wrote:
> On 6/27/24 1:37 AM, Ram Prakash Gupta wrote:
>> Changes since V1:
>> - Address minor review comment.
>
> This is too vague. Please be more specific in patch changelogs.
>
> Thanks,
>
> Bart.
>
My Bad - will update it properly if next patchset is required.
By the way here I addressed code review comment from Dmitry.
https://www.spinics.net/lists/kernel/msg5268621.html
Thanks,
Ram
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 0/2] Suspend clk scaling when there is no request
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
` (2 preceding siblings ...)
2024-06-27 16:36 ` [PATCH V2 0/2] Suspend clk scaling when there is " Bart Van Assche
@ 2024-06-28 19:34 ` Bart Van Assche
2024-07-05 2:48 ` Martin K. Petersen
2024-07-11 3:08 ` Martin K. Petersen
5 siblings, 0 replies; 10+ messages in thread
From: Bart Van Assche @ 2024-06-28 19:34 UTC (permalink / raw)
To: Ram Prakash Gupta, James E.J. Bottomley, Martin K. Petersen,
Manivannan Sadhasivam
Cc: Alim Akhtar, Avri Altman, linux-scsi, linux-kernel, linux-arm-msm,
quic_cang, quic_nguyenb, quic_pragalla, quic_nitirawa
On 6/27/24 1:37 AM, 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.
For both patches:
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 0/2] Suspend clk scaling when there is no request
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
` (3 preceding siblings ...)
2024-06-28 19:34 ` Bart Van Assche
@ 2024-07-05 2:48 ` Martin K. Petersen
2024-07-11 3:08 ` Martin K. Petersen
5 siblings, 0 replies; 10+ messages in thread
From: Martin K. Petersen @ 2024-07-05 2:48 UTC (permalink / raw)
To: Ram Prakash Gupta
Cc: James E.J. Bottomley, Martin K. Petersen, Manivannan Sadhasivam,
Alim Akhtar, Avri Altman, Bart Van Assche, linux-scsi,
linux-kernel, linux-arm-msm, quic_cang, quic_nguyenb,
quic_pragalla, quic_nitirawa
Ram,
> 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.
Applied to 6.11/scsi-staging, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH V2 0/2] Suspend clk scaling when there is no request
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
` (4 preceding siblings ...)
2024-07-05 2:48 ` Martin K. Petersen
@ 2024-07-11 3:08 ` Martin K. Petersen
5 siblings, 0 replies; 10+ messages in thread
From: Martin K. Petersen @ 2024-07-11 3:08 UTC (permalink / raw)
To: James E.J. Bottomley, Manivannan Sadhasivam, Ram Prakash Gupta
Cc: Martin K . Petersen, Alim Akhtar, Avri Altman, Bart Van Assche,
linux-scsi, linux-kernel, linux-arm-msm, quic_cang, quic_nguyenb,
quic_pragalla, quic_nitirawa
On Thu, 27 Jun 2024 14:07:54 +0530, 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.
>
> [...]
Applied to 6.11/scsi-queue, thanks!
[1/2] scsi: ufs: Suspend clk scaling on no request
https://git.kernel.org/mkp/scsi/c/50183ac2cfb5
[2/2] scsi: ufs: qcom: Enable suspending clk scaling on no request
https://git.kernel.org/mkp/scsi/c/ed7dac86f140
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-07-11 3:09 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-27 8:37 [PATCH V2 0/2] Suspend clk scaling when there is no request Ram Prakash Gupta
2024-06-27 8:37 ` [PATCH v2 1/2] scsi: ufs: Suspend clk scaling on " Ram Prakash Gupta
2024-06-27 16:35 ` Bart Van Assche
2024-06-27 16:59 ` Ram Prakash Gupta
2024-06-27 8:37 ` [PATCH v2 2/2] scsi: ufs: qcom: Enable suspending " Ram Prakash Gupta
2024-06-27 16:36 ` [PATCH V2 0/2] Suspend clk scaling when there is " Bart Van Assche
2024-06-27 17:06 ` Ram Prakash Gupta
2024-06-28 19:34 ` Bart Van Assche
2024-07-05 2:48 ` Martin K. Petersen
2024-07-11 3:08 ` Martin K. Petersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox