[RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[Dmitry Baryshkov]

Konrad brought up the topic of scaling the MX domain according to the
OPP changes. Here is my RFC for this functionality. I post it as an RFC
for two reasons:

1) I'm not sure that we should scale MX if we are not scaling main
voltage following the CPR3

2) With this patchset I'm getting the following huuuge backtrace from
lockdep, which I was not able to solve and which, I believe, is a false
positive. An independent opinion is appreciated.

======================================================
WARNING: possible circular locking dependency detected
6.3.0-rc2-00329-g761f7b50599b #348 Not tainted
------------------------------------------------------
ring2/111 is trying to acquire lock:
ffff00008ca79078 (&devfreq->lock){+.+.}-{3:3}, at: qos_min_notifier_call+0x28/0x88

but task is already holding lock:
ffff00008b7d64e8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0xa0

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #4 (&(c->notifiers)->rwsem){++++}-{3:3}:
       lock_acquire+0x68/0x84
       down_write+0x40/0xe4
       blocking_notifier_chain_register+0x30/0x8c
       freq_qos_add_notifier+0x68/0x7c
       dev_pm_qos_add_notifier+0xa0/0xf8
       devfreq_add_device.part.0+0x360/0x5c8
       devm_devfreq_add_device+0x74/0xe0
       msm_devfreq_init+0xa0/0x16c
       msm_gpu_init+0x2fc/0x588
       adreno_gpu_init+0x180/0x2c8
       a5xx_gpu_init+0x128/0x378
       adreno_bind+0x180/0x290
       component_bind_all+0x118/0x24c
       msm_drm_bind+0x1ac/0x66c
       try_to_bring_up_aggregate_device+0x168/0x1d4
       __component_add+0xa8/0x170
       component_add+0x14/0x20
       msm_hdmi_dev_probe+0x474/0x5bc
       platform_probe+0x68/0xd8
       really_probe+0x148/0x2b4
       __driver_probe_device+0x78/0xe0
       driver_probe_device+0xd8/0x160
       __device_attach_driver+0xb8/0x138
       bus_for_each_drv+0x84/0xe0
       __device_attach+0xa8/0x1b0
       device_initial_probe+0x14/0x20
       bus_probe_device+0xb0/0xb4
       deferred_probe_work_func+0x8c/0xc8
       process_one_work+0x288/0x6b0
       worker_thread+0x23c/0x440
       kthread+0x10c/0x110
       ret_from_fork+0x10/0x20

-> #3 (dev_pm_qos_mtx){+.+.}-{3:3}:
       lock_acquire+0x68/0x84
       __mutex_lock+0x84/0x400
       mutex_lock_nested+0x2c/0x38
       dev_pm_qos_add_notifier+0x38/0xf8
       genpd_add_device+0x150/0x340
       __genpd_dev_pm_attach+0xa4/0x264
       genpd_dev_pm_attach+0x60/0x70
       dev_pm_domain_attach+0x20/0x34
       platform_probe+0x50/0xd8
       really_probe+0x148/0x2b4
       __driver_probe_device+0x78/0xe0
       driver_probe_device+0xd8/0x160
       __device_attach_driver+0xb8/0x138
       bus_for_each_drv+0x84/0xe0
       __device_attach+0xa8/0x1b0
       device_initial_probe+0x14/0x20
       bus_probe_device+0xb0/0xb4
       deferred_probe_work_func+0x8c/0xc8
       process_one_work+0x288/0x6b0
       worker_thread+0x23c/0x440
       kthread+0x10c/0x110
       ret_from_fork+0x10/0x20

-> #2 (gpd_list_lock){+.+.}-{3:3}:
       lock_acquire+0x68/0x84
       __mutex_lock+0x84/0x400
       mutex_lock_nested+0x2c/0x38
       __genpd_dev_pm_attach+0x78/0x264
       genpd_dev_pm_attach_by_id.part.0+0xa4/0x158
       genpd_dev_pm_attach_by_name+0x64/0x8c
       dev_pm_domain_attach_by_name+0x20/0x2c
       dev_pm_opp_set_config+0x3e4/0x688
       devm_pm_opp_set_config+0x18/0x70
       a5xx_gpu_init+0x1d8/0x378
       adreno_bind+0x180/0x290
       component_bind_all+0x118/0x24c
       msm_drm_bind+0x1ac/0x66c
       try_to_bring_up_aggregate_device+0x168/0x1d4
       __component_add+0xa8/0x170
       component_add+0x14/0x20
       msm_hdmi_dev_probe+0x474/0x5bc
       platform_probe+0x68/0xd8
       really_probe+0x148/0x2b4
       __driver_probe_device+0x78/0xe0
       driver_probe_device+0xd8/0x160
       __device_attach_driver+0xb8/0x138
       bus_for_each_drv+0x84/0xe0
       __device_attach+0xa8/0x1b0
       device_initial_probe+0x14/0x20
       bus_probe_device+0xb0/0xb4
       deferred_probe_work_func+0x8c/0xc8
       process_one_work+0x288/0x6b0
       worker_thread+0x23c/0x440
       kthread+0x10c/0x110
       ret_from_fork+0x10/0x20

-> #1 (&opp_table->genpd_virt_dev_lock){+.+.}-{3:3}:
       lock_acquire+0x68/0x84
       __mutex_lock+0x84/0x400
       mutex_lock_nested+0x2c/0x38
       _set_required_opps+0x64/0x180
       _set_opp+0x190/0x438
       dev_pm_opp_set_rate+0x18c/0x274
       msm_devfreq_target+0x19c/0x224
       devfreq_set_target+0x84/0x2f8
       devfreq_update_target+0xc4/0xec
       devfreq_monitor+0x38/0x1f0
       process_one_work+0x288/0x6b0
       worker_thread+0x74/0x440
       kthread+0x10c/0x110
       ret_from_fork+0x10/0x20

-> #0 (&devfreq->lock){+.+.}-{3:3}:
       __lock_acquire+0x138c/0x2218
       lock_acquire.part.0+0xc4/0x1fc
       lock_acquire+0x68/0x84
       __mutex_lock+0x84/0x400
       mutex_lock_nested+0x2c/0x38
       qos_min_notifier_call+0x28/0x88
       blocking_notifier_call_chain+0x6c/0xa0
       pm_qos_update_target+0xdc/0x24c
       freq_qos_apply+0x68/0x74
       apply_constraint+0x100/0x148
       __dev_pm_qos_update_request+0xb8/0x280
       dev_pm_qos_update_request+0x3c/0x64
       msm_devfreq_active+0xf8/0x194
       msm_gpu_submit+0x18c/0x1a8
       msm_job_run+0xbc/0x140
       drm_sched_main+0x190/0x510
       kthread+0x10c/0x110
       ret_from_fork+0x10/0x20

other info that might help us debug this:

Chain exists of:
  &devfreq->lock --> dev_pm_qos_mtx --> &(c->notifiers)->rwsem

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(c->notifiers)->rwsem);
                               lock(dev_pm_qos_mtx);
                               lock(&(c->notifiers)->rwsem);
  lock(&devfreq->lock);

 *** DEADLOCK ***

4 locks held by ring2/111:
 #0: ffff000087064170 (&gpu->lock){+.+.}-{3:3}, at: msm_job_run+0xb0/0x140
 #1: ffff000087064208 (&gpu->active_lock){+.+.}-{3:3}, at: msm_gpu_submit+0xdc/0x1a8
 #2: ffff80000a344bf8 (dev_pm_qos_mtx){+.+.}-{3:3}, at: dev_pm_qos_update_request+0x30/0x64
 #3: ffff00008b7d64e8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0xa0

stack backtrace:
CPU: 0 PID: 111 Comm: ring2 Not tainted 6.3.0-rc2-00329-g761f7b50599b #348
Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
Call trace:
 dump_backtrace+0xa0/0xfc
 show_stack+0x18/0x24
 dump_stack_lvl+0x60/0xac
 dump_stack+0x18/0x24
 print_circular_bug+0x24c/0x2f8
 check_noncircular+0x134/0x148
 __lock_acquire+0x138c/0x2218
 lock_acquire.part.0+0xc4/0x1fc
 lock_acquire+0x68/0x84
 __mutex_lock+0x84/0x400
 mutex_lock_nested+0x2c/0x38
 qos_min_notifier_call+0x28/0x88
 blocking_notifier_call_chain+0x6c/0xa0
 pm_qos_update_target+0xdc/0x24c
 freq_qos_apply+0x68/0x74
 apply_constraint+0x100/0x148
 __dev_pm_qos_update_request+0xb8/0x280
 dev_pm_qos_update_request+0x3c/0x64
 msm_devfreq_active+0xf8/0x194
 msm_gpu_submit+0x18c/0x1a8
 msm_job_run+0xbc/0x140
 drm_sched_main+0x190/0x510
 kthread+0x10c/0x110
 ret_from_fork+0x10/0x20
Rendered 979 frames in 2.001978 sec (489.016434 fps)

Dmitry Baryshkov (3):
  dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
  drm/msm/a5xx: scale MX domain following the frequncy changes
  arm64: dts: qcom: specify power domains for the GPU

 .../devicetree/bindings/display/msm/gpu.yaml  |  9 +++-
 arch/arm64/boot/dts/qcom/msm8996.dtsi         | 14 ++++-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c         | 52 +++++++++++++++++++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h         |  3 ++
 4 files changed, 76 insertions(+), 2 deletions(-)

-- 
2.39.2

[RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx

[Dmitry Baryshkov]

Some a5xx Adreno devices might need additional power domains to handle
voltage scaling. While we do not (yet) have support for CPR3 providing
voltage scaling, allow specifying MX domain to scale the memory cell
voltage.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 Documentation/devicetree/bindings/display/msm/gpu.yaml | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index d4191cca71fb..4dc1f6b2cdbf 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -78,7 +78,14 @@ properties:
     type: object
 
   power-domains:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
+
+  power-domain-names:
+    items:
+      - const: gx
+      - const: mx
+    minItems: 1
 
   zap-shader:
     type: object
-- 
2.39.2

[RFC PATCH 2/3] drm/msm/a5xx: scale MX domain following the frequncy changes

[Dmitry Baryshkov]

For some a5xx Adrenos we have to specify both GX and MX power domains.
GX is used to power up the GPU clocks and logic. MX is used for scaling
voltage of memory cells.

In case the DT specifies several (GX, MX) power domains, none will be
bound by the core. We have to manage GX manually. Also make sure that
the MX domain is resumed and scaled to the proper performance state
following the desired frequency.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 52 +++++++++++++++++++++++++++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  3 ++
 2 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 0372f8908202..36b3d11dd5b0 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -8,6 +8,7 @@
 #include <linux/firmware/qcom/qcom_scm.h>
 #include <linux/pm_opp.h>
 #include <linux/nvmem-consumer.h>
+#include <linux/pm_domain.h>
 #include <linux/slab.h>
 #include "msm_gem.h"
 #include "msm_mmu.h"
@@ -1053,6 +1054,13 @@ static void a5xx_destroy(struct msm_gpu *gpu)
 	}
 
 	adreno_gpu_cleanup(adreno_gpu);
+
+	if (a5xx_gpu->mx_link)
+		device_link_del(a5xx_gpu->mx_link);
+
+	if (a5xx_gpu->gxpd)
+		dev_pm_domain_detach(a5xx_gpu->gxpd, true);
+
 	kfree(a5xx_gpu);
 }
 
@@ -1339,8 +1347,15 @@ static void a5xx_dump(struct msm_gpu *gpu)
 static int a5xx_pm_resume(struct msm_gpu *gpu)
 {
 	struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+	struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
 	int ret;
 
+	if (a5xx_gpu->gxpd) {
+		ret = pm_runtime_resume_and_get(a5xx_gpu->gxpd);
+		if (ret < 0)
+			return ret;
+	}
+
 	/* Turn on the core power */
 	ret = msm_gpu_pm_resume(gpu);
 	if (ret)
@@ -1414,6 +1429,9 @@ static int a5xx_pm_suspend(struct msm_gpu *gpu)
 	if (ret)
 		return ret;
 
+	if (a5xx_gpu->gxpd)
+		pm_runtime_put(a5xx_gpu->gxpd);
+
 	if (a5xx_gpu->has_whereami)
 		for (i = 0; i < gpu->nr_rings; i++)
 			a5xx_gpu->shadow[i] = 0;
@@ -1762,6 +1780,40 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 
 	a5xx_gpu->lm_leakage = 0x4E001A;
 
+	/*
+	 * If the device has several power domain (gx and mx), none are attached by the core.
+	 */
+	if (!pdev->dev.pm_domain) {
+		struct device **opp_virt_dev;
+		struct device *pd;
+
+		/* FIXME: add cpr once it is supported */
+		static const char *genpd_names[] = { "mx", NULL };
+
+		pd = dev_pm_domain_attach_by_name(&pdev->dev, "gx");
+		if (IS_ERR(pd))
+			return ERR_CAST(pd);
+
+		/* GX is required for GPU to function */
+		if (pd == NULL)
+			return ERR_PTR(-EINVAL);
+
+		a5xx_gpu->gxpd = pd;
+
+		ret = devm_pm_opp_attach_genpd(&pdev->dev, genpd_names, &opp_virt_dev);
+		if (ret) {
+			dev_pm_domain_detach(a5xx_gpu->gxpd, true);
+			return ERR_PTR(ret);
+		}
+
+		a5xx_gpu->mx_link = device_link_add(&pdev->dev, opp_virt_dev[0],
+						    DL_FLAG_RPM_ACTIVE |
+						    DL_FLAG_PM_RUNTIME |
+						    DL_FLAG_STATELESS);
+		if (!a5xx_gpu->mx_link)
+			return ERR_PTR(-ENODEV);
+	}
+
 	check_speed_bin(&pdev->dev);
 
 	nr_rings = 4;
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index c7187bcc5e90..36e910397c14 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -44,6 +44,9 @@ struct a5xx_gpu {
 
 	/* True if the microcode supports the WHERE_AM_I opcode */
 	bool has_whereami;
+
+	struct device *gxpd;
+	struct device_link *mx_link;
 };
 
 #define to_a5xx_gpu(x) container_of(x, struct a5xx_gpu, base)
-- 
2.39.2

[RFC PATCH 3/3] arm64: dts: qcom: specify power domains for the GPU

[Dmitry Baryshkov]

The GPU on msm8996 is powered on by several power domains. Add
configuration for the GFX CPR and MX domains.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 905678e7175d..ff4fb30f9075 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -521,6 +521,10 @@ rpmpd_opp5: opp5 {
 					rpmpd_opp6: opp6 {
 						opp-level = <6>;
 					};
+
+					rpmpd_opp7: opp7 {
+						opp-level = <7>;
+					};
 				};
 			};
 		};
@@ -1228,7 +1232,8 @@ gpu: gpu@b00000 {
 			interconnects = <&bimc MASTER_GRAPHICS_3D &bimc SLAVE_EBI_CH0>;
 			interconnect-names = "gfx-mem";
 
-			power-domains = <&mmcc GPU_GX_GDSC>;
+			power-domains = <&mmcc GPU_GX_GDSC>, <&rpmpd MSM8996_VDDMX>;
+			power-domain-names = "gx", "mx";
 			iommus = <&adreno_smmu 0>;
 
 			nvmem-cells = <&speedbin_efuse>;
@@ -1251,30 +1256,37 @@ gpu_opp_table: opp-table {
 				opp-624000000 {
 					opp-hz = /bits/ 64 <624000000>;
 					opp-supported-hw = <0x09>;
+					required-opps = <&rpmpd_opp7>;
 				};
 				opp-560000000 {
 					opp-hz = /bits/ 64 <560000000>;
 					opp-supported-hw = <0x0d>;
+					required-opps = <&rpmpd_opp7>;
 				};
 				opp-510000000 {
 					opp-hz = /bits/ 64 <510000000>;
 					opp-supported-hw = <0xff>;
+					required-opps = <&rpmpd_opp5>;
 				};
 				opp-401800000 {
 					opp-hz = /bits/ 64 <401800000>;
 					opp-supported-hw = <0xff>;
+					required-opps = <&rpmpd_opp5>;
 				};
 				opp-315000000 {
 					opp-hz = /bits/ 64 <315000000>;
 					opp-supported-hw = <0xff>;
+					required-opps = <&rpmpd_opp4>;
 				};
 				opp-214000000 {
 					opp-hz = /bits/ 64 <214000000>;
 					opp-supported-hw = <0xff>;
+					required-opps = <&rpmpd_opp4>;
 				};
 				opp-133000000 {
 					opp-hz = /bits/ 64 <133000000>;
 					opp-supported-hw = <0xff>;
+					required-opps = <&rpmpd_opp4>;
 				};
 			};
 
-- 
2.39.2

Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[Konrad Dybcio]

On 30.03.2023 00:24, Dmitry Baryshkov wrote:
> Konrad brought up the topic of scaling the MX domain according to the
> OPP changes. Here is my RFC for this functionality. I post it as an RFC
> for two reasons:
> 
> 1) I'm not sure that we should scale MX if we are not scaling main
> voltage following the CPR3
It should be ok, however..
> 
[...]

> Dmitry Baryshkov (3):
>   dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
>   drm/msm/a5xx: scale MX domain following the frequncy changes
This is a stopgap solution, CPR is a child of MX.

Konrad
>   arm64: dts: qcom: specify power domains for the GPU
> 
>  .../devicetree/bindings/display/msm/gpu.yaml  |  9 +++-
>  arch/arm64/boot/dts/qcom/msm8996.dtsi         | 14 ++++-
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c         | 52 +++++++++++++++++++
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.h         |  3 ++
>  4 files changed, 76 insertions(+), 2 deletions(-)
> 

Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[Dmitry Baryshkov]

On 30/03/2023 14:06, Konrad Dybcio wrote:
> 
> 
> On 30.03.2023 00:24, Dmitry Baryshkov wrote:
>> Konrad brought up the topic of scaling the MX domain according to the
>> OPP changes. Here is my RFC for this functionality. I post it as an RFC
>> for two reasons:
>>
>> 1) I'm not sure that we should scale MX if we are not scaling main
>> voltage following the CPR3
> It should be ok, however..
>>
> [...]
> 
>> Dmitry Baryshkov (3):
>>    dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
>>    drm/msm/a5xx: scale MX domain following the frequncy changes
> This is a stopgap solution, CPR is a child of MX.

Not so sure here. Vendor kernel scales voltages and MX levels 
separately. Moreover, please correct me if I'm wrong here, the kernel 
doesn't scale VDD_GFX directly. It programs GPMU's voltage table and 
then GPMU handles voltage scaling according to performance levels being 
set. MX is handled in parallel to switching GPMU's level.

I have implemented this voltage scaling locally, just need to run more 
tests before posting (and unfortunately it depends either on CPR3+GFX or 
on programming the voltages manually).

> 
> Konrad
>>    arm64: dts: qcom: specify power domains for the GPU
>>
>>   .../devicetree/bindings/display/msm/gpu.yaml  |  9 +++-
>>   arch/arm64/boot/dts/qcom/msm8996.dtsi         | 14 ++++-
>>   drivers/gpu/drm/msm/adreno/a5xx_gpu.c         | 52 +++++++++++++++++++
>>   drivers/gpu/drm/msm/adreno/a5xx_gpu.h         |  3 ++
>>   4 files changed, 76 insertions(+), 2 deletions(-)
>>

-- 
With best wishes
Dmitry

Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[Konrad Dybcio]

On 30.03.2023 13:15, Dmitry Baryshkov wrote:
> On 30/03/2023 14:06, Konrad Dybcio wrote:
>>
>>
>> On 30.03.2023 00:24, Dmitry Baryshkov wrote:
>>> Konrad brought up the topic of scaling the MX domain according to the
>>> OPP changes. Here is my RFC for this functionality. I post it as an RFC
>>> for two reasons:
>>>
>>> 1) I'm not sure that we should scale MX if we are not scaling main
>>> voltage following the CPR3
>> It should be ok, however..
>>>
>> [...]
>>
>>> Dmitry Baryshkov (3):
>>>    dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
>>>    drm/msm/a5xx: scale MX domain following the frequncy changes
>> This is a stopgap solution, CPR is a child of MX.
> 
> Not so sure here. Vendor kernel scales voltages and MX levels separately. Moreover, please correct me if I'm wrong here, the kernel doesn't scale VDD_GFX directly. It programs GPMU's voltage table and then GPMU handles voltage scaling according to performance levels being set. MX is handled in parallel to switching GPMU's level.
> 
> I have implemented this voltage scaling locally, just need to run more tests before posting (and unfortunately it depends either on CPR3+GFX or on programming the voltages manually).
Oh no.. I forgot about the ugly goblin that we call GPMU.. I'll have
to dig into it further. Thanks for reminding me..

Konrad
> 
>>
>> Konrad
>>>    arm64: dts: qcom: specify power domains for the GPU
>>>
>>>   .../devicetree/bindings/display/msm/gpu.yaml  |  9 +++-
>>>   arch/arm64/boot/dts/qcom/msm8996.dtsi         | 14 ++++-
>>>   drivers/gpu/drm/msm/adreno/a5xx_gpu.c         | 52 +++++++++++++++++++
>>>   drivers/gpu/drm/msm/adreno/a5xx_gpu.h         |  3 ++
>>>   4 files changed, 76 insertions(+), 2 deletions(-)
>>>
> 

Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes

[Dmitry Baryshkov]

On Thu, 30 Mar 2023 at 14:16, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>
>
>
> On 30.03.2023 13:15, Dmitry Baryshkov wrote:
> > On 30/03/2023 14:06, Konrad Dybcio wrote:
> >>
> >>
> >> On 30.03.2023 00:24, Dmitry Baryshkov wrote:
> >>> Konrad brought up the topic of scaling the MX domain according to the
> >>> OPP changes. Here is my RFC for this functionality. I post it as an RFC
> >>> for two reasons:
> >>>
> >>> 1) I'm not sure that we should scale MX if we are not scaling main
> >>> voltage following the CPR3
> >> It should be ok, however..
> >>>
> >> [...]
> >>
> >>> Dmitry Baryshkov (3):
> >>>    dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
> >>>    drm/msm/a5xx: scale MX domain following the frequncy changes
> >> This is a stopgap solution, CPR is a child of MX.
> >
> > Not so sure here. Vendor kernel scales voltages and MX levels separately. Moreover, please correct me if I'm wrong here, the kernel doesn't scale VDD_GFX directly. It programs GPMU's voltage table and then GPMU handles voltage scaling according to performance levels being set. MX is handled in parallel to switching GPMU's level.
> >
> > I have implemented this voltage scaling locally, just need to run more tests before posting (and unfortunately it depends either on CPR3+GFX or on programming the voltages manually).
> Oh no.. I forgot about the ugly goblin that we call GPMU.. I'll have
> to dig into it further. Thanks for reminding me..

Let me send the fixed voltage table programming (probably on Friday).

>
> Konrad
> >
> >>
> >> Konrad
> >>>    arm64: dts: qcom: specify power domains for the GPU
> >>>
> >>>   .../devicetree/bindings/display/msm/gpu.yaml  |  9 +++-
> >>>   arch/arm64/boot/dts/qcom/msm8996.dtsi         | 14 ++++-
> >>>   drivers/gpu/drm/msm/adreno/a5xx_gpu.c         | 52 +++++++++++++++++++
> >>>   drivers/gpu/drm/msm/adreno/a5xx_gpu.h         |  3 ++
> >>>   4 files changed, 76 insertions(+), 2 deletions(-)
> >>>
> >



-- 
With best wishes
Dmitry

Re: [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx

[Krzysztof Kozlowski]

On 30/03/2023 00:24, Dmitry Baryshkov wrote:
> Some a5xx Adreno devices might need additional power domains to handle
> voltage scaling. While we do not (yet) have support for CPR3 providing
> voltage scaling, allow specifying MX domain to scale the memory cell
> voltage.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof