* [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
2023-03-29 22:24 [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Dmitry Baryshkov
@ 2023-03-29 22:24 ` Dmitry Baryshkov
2023-03-31 8:40 ` Krzysztof Kozlowski
2023-03-29 22:24 ` [RFC PATCH 2/3] drm/msm/a5xx: scale MX domain following the frequncy changes Dmitry Baryshkov
` (2 subsequent siblings)
3 siblings, 1 reply; 9+ messages in thread
From: Dmitry Baryshkov @ 2023-03-29 22:24 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Clark, Sean Paul,
Abhinav Kumar, Rob Herring, Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx
2023-03-29 22:24 ` [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx Dmitry Baryshkov
@ 2023-03-31 8:40 ` Krzysztof Kozlowski
0 siblings, 0 replies; 9+ messages in thread
From: Krzysztof Kozlowski @ 2023-03-31 8:40 UTC (permalink / raw)
To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Sean Paul, Abhinav Kumar, Rob Herring,
Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC PATCH 2/3] drm/msm/a5xx: scale MX domain following the frequncy changes
2023-03-29 22:24 [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Dmitry Baryshkov
2023-03-29 22:24 ` [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx Dmitry Baryshkov
@ 2023-03-29 22:24 ` Dmitry Baryshkov
2023-03-29 22:25 ` [RFC PATCH 3/3] arm64: dts: qcom: specify power domains for the GPU Dmitry Baryshkov
2023-03-30 11:06 ` [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Konrad Dybcio
3 siblings, 0 replies; 9+ messages in thread
From: Dmitry Baryshkov @ 2023-03-29 22:24 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Clark, Sean Paul,
Abhinav Kumar, Rob Herring, Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [RFC PATCH 3/3] arm64: dts: qcom: specify power domains for the GPU
2023-03-29 22:24 [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Dmitry Baryshkov
2023-03-29 22:24 ` [RFC PATCH 1/3] dt-bindings: display/msm/gpu: allow specifying MX domain A5xx Dmitry Baryshkov
2023-03-29 22:24 ` [RFC PATCH 2/3] drm/msm/a5xx: scale MX domain following the frequncy changes Dmitry Baryshkov
@ 2023-03-29 22:25 ` Dmitry Baryshkov
2023-03-30 11:06 ` [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Konrad Dybcio
3 siblings, 0 replies; 9+ messages in thread
From: Dmitry Baryshkov @ 2023-03-29 22:25 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Clark, Sean Paul,
Abhinav Kumar, Rob Herring, Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes
2023-03-29 22:24 [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Dmitry Baryshkov
` (2 preceding siblings ...)
2023-03-29 22:25 ` [RFC PATCH 3/3] arm64: dts: qcom: specify power domains for the GPU Dmitry Baryshkov
@ 2023-03-30 11:06 ` Konrad Dybcio
2023-03-30 11:15 ` Dmitry Baryshkov
3 siblings, 1 reply; 9+ messages in thread
From: Konrad Dybcio @ 2023-03-30 11:06 UTC (permalink / raw)
To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Clark,
Sean Paul, Abhinav Kumar, Rob Herring, Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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(-)
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes
2023-03-30 11:06 ` [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes Konrad Dybcio
@ 2023-03-30 11:15 ` Dmitry Baryshkov
2023-03-30 11:16 ` Konrad Dybcio
0 siblings, 1 reply; 9+ messages in thread
From: Dmitry Baryshkov @ 2023-03-30 11:15 UTC (permalink / raw)
To: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Clark, Sean Paul,
Abhinav Kumar, Rob Herring, Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes
2023-03-30 11:15 ` Dmitry Baryshkov
@ 2023-03-30 11:16 ` Konrad Dybcio
2023-03-30 11:30 ` Dmitry Baryshkov
0 siblings, 1 reply; 9+ messages in thread
From: Konrad Dybcio @ 2023-03-30 11:16 UTC (permalink / raw)
To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Clark,
Sean Paul, Abhinav Kumar, Rob Herring, Krzysztof Kozlowski
Cc: Stephen Boyd, David Airlie, Daniel Vetter, linux-arm-msm,
devicetree, dri-devel, freedreno
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(-)
>>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC PATCH 0/3] drm/msm/a5xx: scale MX following the frequency changes
2023-03-30 11:16 ` Konrad Dybcio
@ 2023-03-30 11:30 ` Dmitry Baryshkov
0 siblings, 0 replies; 9+ messages in thread
From: Dmitry Baryshkov @ 2023-03-30 11:30 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andy Gross, Bjorn Andersson, Rob Clark, Sean Paul, Abhinav Kumar,
Rob Herring, Krzysztof Kozlowski, Stephen Boyd, David Airlie,
Daniel Vetter, linux-arm-msm, devicetree, dri-devel, freedreno
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
^ permalink raw reply [flat|nested] 9+ messages in thread