[PATCH v2] drm/lima: add governor data with pre-defined thresholds

[PATCH v2] drm/lima: add governor data with pre-defined thresholds

[Christian Hewitt]

This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real-world performance. The upthreshold value has
been set to ramp GPU frequency to max freq faster (compared to panfrost)
to compensate for the lower overall performance of utgard devices.

[0] https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.luba@arm.com/

Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
Change since v1: increased upthreshold from 20 to 30, with a soft
dependency on Lukasz delayed timer patch [0]

[0] https://lore.kernel.org/lkml/20210127105121.20345-1-lukasz.luba@arm.com/

 drivers/gpu/drm/lima/lima_devfreq.c | 10 +++++++++-
 drivers/gpu/drm/lima/lima_devfreq.h |  2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/lima/lima_devfreq.c b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..c9854315a0b5 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -163,8 +163,16 @@ int lima_devfreq_init(struct lima_device *ldev)
 	lima_devfreq_profile.initial_freq = cur_freq;
 	dev_pm_opp_put(opp);
 
+	/*
+	 * Setup default thresholds for the simple_ondemand governor.
+	 * The values are chosen based on experiments.
+	 */
+	ldevfreq->gov_data.upthreshold = 30;
+	ldevfreq->gov_data.downdifferential = 5;
+
 	devfreq = devm_devfreq_add_device(dev, &lima_devfreq_profile,
-					  DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+					  DEVFREQ_GOV_SIMPLE_ONDEMAND,
+					  &ldevfreq->gov_data);
 	if (IS_ERR(devfreq)) {
 		dev_err(dev, "Couldn't initialize GPU devfreq\n");
 		ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..b0c7c736e81a 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -4,6 +4,7 @@
 #ifndef __LIMA_DEVFREQ_H__
 #define __LIMA_DEVFREQ_H__
 
+#include <linux/devfreq.h>
 #include <linux/spinlock.h>
 #include <linux/ktime.h>
 
@@ -18,6 +19,7 @@ struct lima_devfreq {
 	struct opp_table *clkname_opp_table;
 	struct opp_table *regulators_opp_table;
 	struct thermal_cooling_device *cooling;
+	struct devfreq_simple_ondemand_data gov_data;
 
 	ktime_t busy_time;
 	ktime_t idle_time;
-- 
2.17.1

Re: [PATCH v2] drm/lima: add governor data with pre-defined thresholds

[Lukasz Luba]

On 1/27/21 7:40 PM, Christian Hewitt wrote:
> This patch adapts the panfrost pre-defined thresholds change [0] to the
> lima driver to improve real-world performance. The upthreshold value has
> been set to ramp GPU frequency to max freq faster (compared to panfrost)
> to compensate for the lower overall performance of utgard devices.
> 
> [0] https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.luba@arm.com/
> 
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> Change since v1: increased upthreshold from 20 to 30, with a soft
> dependency on Lukasz delayed timer patch [0]
> 
> [0] https://lore.kernel.org/lkml/20210127105121.20345-1-lukasz.luba@arm.com/
> 
>   drivers/gpu/drm/lima/lima_devfreq.c | 10 +++++++++-
>   drivers/gpu/drm/lima/lima_devfreq.h |  2 ++
>   2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c b/drivers/gpu/drm/lima/lima_devfreq.c
> index 5686ad4aaf7c..c9854315a0b5 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.c
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -163,8 +163,16 @@ int lima_devfreq_init(struct lima_device *ldev)
>   	lima_devfreq_profile.initial_freq = cur_freq;
>   	dev_pm_opp_put(opp);
>   
> +	/*
> +	 * Setup default thresholds for the simple_ondemand governor.
> +	 * The values are chosen based on experiments.
> +	 */
> +	ldevfreq->gov_data.upthreshold = 30;
> +	ldevfreq->gov_data.downdifferential = 5;
> +
>   	devfreq = devm_devfreq_add_device(dev, &lima_devfreq_profile,
> -					  DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
> +					  DEVFREQ_GOV_SIMPLE_ONDEMAND,
> +					  &ldevfreq->gov_data);
>   	if (IS_ERR(devfreq)) {
>   		dev_err(dev, "Couldn't initialize GPU devfreq\n");
>   		ret = PTR_ERR(devfreq);
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.h b/drivers/gpu/drm/lima/lima_devfreq.h
> index 2d9b3008ce77..b0c7c736e81a 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.h
> +++ b/drivers/gpu/drm/lima/lima_devfreq.h
> @@ -4,6 +4,7 @@
>   #ifndef __LIMA_DEVFREQ_H__
>   #define __LIMA_DEVFREQ_H__
>   
> +#include <linux/devfreq.h>
>   #include <linux/spinlock.h>
>   #include <linux/ktime.h>
>   
> @@ -18,6 +19,7 @@ struct lima_devfreq {
>   	struct opp_table *clkname_opp_table;
>   	struct opp_table *regulators_opp_table;
>   	struct thermal_cooling_device *cooling;
> +	struct devfreq_simple_ondemand_data gov_data;
>   
>   	ktime_t busy_time;
>   	ktime_t idle_time;
> 

It looks good.

Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>

Regards,
Lukasz

Re: [PATCH v2] drm/lima: add governor data with pre-defined thresholds

[Qiang Yu]

This patch gets minor improvement on glmark2 (160->162).

Seems there's no way for user to change this value, do we?
Or there's work pending to expose it to sysfs?

Regards,
Qiang

On Thu, Jan 28, 2021 at 3:40 AM Christian Hewitt
<christianshewitt@gmail.com> wrote:
>
> This patch adapts the panfrost pre-defined thresholds change [0] to the
> lima driver to improve real-world performance. The upthreshold value has
> been set to ramp GPU frequency to max freq faster (compared to panfrost)
> to compensate for the lower overall performance of utgard devices.
>
> [0] https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.luba@arm.com/
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> Change since v1: increased upthreshold from 20 to 30, with a soft
> dependency on Lukasz delayed timer patch [0]
>
> [0] https://lore.kernel.org/lkml/20210127105121.20345-1-lukasz.luba@arm.com/
>
>  drivers/gpu/drm/lima/lima_devfreq.c | 10 +++++++++-
>  drivers/gpu/drm/lima/lima_devfreq.h |  2 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c b/drivers/gpu/drm/lima/lima_devfreq.c
> index 5686ad4aaf7c..c9854315a0b5 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.c
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -163,8 +163,16 @@ int lima_devfreq_init(struct lima_device *ldev)
>         lima_devfreq_profile.initial_freq = cur_freq;
>         dev_pm_opp_put(opp);
>
> +       /*
> +        * Setup default thresholds for the simple_ondemand governor.
> +        * The values are chosen based on experiments.
> +        */
> +       ldevfreq->gov_data.upthreshold = 30;
> +       ldevfreq->gov_data.downdifferential = 5;
> +
>         devfreq = devm_devfreq_add_device(dev, &lima_devfreq_profile,
> -                                         DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
> +                                         DEVFREQ_GOV_SIMPLE_ONDEMAND,
> +                                         &ldevfreq->gov_data);
>         if (IS_ERR(devfreq)) {
>                 dev_err(dev, "Couldn't initialize GPU devfreq\n");
>                 ret = PTR_ERR(devfreq);
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.h b/drivers/gpu/drm/lima/lima_devfreq.h
> index 2d9b3008ce77..b0c7c736e81a 100644
> --- a/drivers/gpu/drm/lima/lima_devfreq.h
> +++ b/drivers/gpu/drm/lima/lima_devfreq.h
> @@ -4,6 +4,7 @@
>  #ifndef __LIMA_DEVFREQ_H__
>  #define __LIMA_DEVFREQ_H__
>
> +#include <linux/devfreq.h>
>  #include <linux/spinlock.h>
>  #include <linux/ktime.h>
>
> @@ -18,6 +19,7 @@ struct lima_devfreq {
>         struct opp_table *clkname_opp_table;
>         struct opp_table *regulators_opp_table;
>         struct thermal_cooling_device *cooling;
> +       struct devfreq_simple_ondemand_data gov_data;
>
>         ktime_t busy_time;
>         ktime_t idle_time;
> --
> 2.17.1
>

Re: [PATCH v2] drm/lima: add governor data with pre-defined thresholds

[Lukasz Luba]

On 1/30/21 1:57 PM, Qiang Yu wrote:
> This patch gets minor improvement on glmark2 (160->162).

It has bigger impact when the load is changing and the frequency
is stuck to min w/o this patch.

> 
> Seems there's no way for user to change this value, do we?
> Or there's work pending to expose it to sysfs?

True there is no user sysfs. I've proposed a patch to export these via
sysfs. Chanwoo is going to work on it. When it will land mainline, it's
probably a few months. So for now, the fix makes sense.

Regards,
Lukasz

Re: [PATCH v2] drm/lima: add governor data with pre-defined thresholds

[Qiang Yu]

OK, I see. Patch is also:
Reviewed-by: Qiang Yu <yuq825@gmail.com>

Regards,
Qiang

On Mon, Feb 1, 2021 at 5:59 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
>
>
> On 1/30/21 1:57 PM, Qiang Yu wrote:
> > This patch gets minor improvement on glmark2 (160->162).
>
> It has bigger impact when the load is changing and the frequency
> is stuck to min w/o this patch.
>
> >
> > Seems there's no way for user to change this value, do we?
> > Or there's work pending to expose it to sysfs?
>
> True there is no user sysfs. I've proposed a patch to export these via
> sysfs. Chanwoo is going to work on it. When it will land mainline, it's
> probably a few months. So for now, the fix makes sense.
>
> Regards,
> Lukasz
>

Re: [PATCH v2] drm/lima: add governor data with pre-defined thresholds

[Qiang Yu]

Applied to drm-misc-next.

Regards,
Qiang

On Tue, Feb 2, 2021 at 9:04 AM Qiang Yu <yuq825@gmail.com> wrote:
>
> OK, I see. Patch is also:
> Reviewed-by: Qiang Yu <yuq825@gmail.com>
>
> Regards,
> Qiang
>
> On Mon, Feb 1, 2021 at 5:59 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
> >
> >
> >
> > On 1/30/21 1:57 PM, Qiang Yu wrote:
> > > This patch gets minor improvement on glmark2 (160->162).
> >
> > It has bigger impact when the load is changing and the frequency
> > is stuck to min w/o this patch.
> >
> > >
> > > Seems there's no way for user to change this value, do we?
> > > Or there's work pending to expose it to sysfs?
> >
> > True there is no user sysfs. I've proposed a patch to export these via
> > sysfs. Chanwoo is going to work on it. When it will land mainline, it's
> > probably a few months. So for now, the fix makes sense.
> >
> > Regards,
> > Lukasz
> >