[PATCH v5 0/5] Update mdp clk to max supported value to support higher refresh rates

[PATCH v5 0/5] Update mdp clk to max supported value to support higher refresh rates

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during resume sequence.
- Add fixes tag.

Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)
- Add similar changes for sc7180, sdm845 which uses opp table for voting mdp clk.(Stephen Boyd)
- Drop patch: "drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table"

Changes in v4:
- Add similar change for sm8250.(Dmitry)

Changes in v5:
- Add change to set mdp clk to max frequency in opp table during mdp probe/bind.

Vinod Polimera (5):
  arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk
  arm64/dts/qcom/sc7180: remove assigned-clock-rate property for mdp clk
  arm64/dts/qcom/sdm845: remove assigned-clock-rate property for mdp clk
  arm64/dts/qcom/sm8250: remove assigned-clock-rate property for mdp clk
  drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table
    during probe

 arch/arm64/boot/dts/qcom/sc7180.dtsi    | 9 ++-------
 arch/arm64/boot/dts/qcom/sc7280.dtsi    | 9 ++-------
 arch/arm64/boot/dts/qcom/sdm845.dtsi    | 9 ++-------
 arch/arm64/boot/dts/qcom/sm8250.dtsi    | 9 ++-------
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
 5 files changed, 11 insertions(+), 28 deletions(-)

-- 
2.7.4

[PATCH v5 0/5] Update mdp clk to max supported value to support higher refresh rates

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during resume sequence.
- Add fixes tag.

Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)
- Add similar changes for sc7180, sdm845 which uses opp table for voting mdp clk.(Stephen Boyd)
- Drop patch: "drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table"

Changes in v4:
- Add similar change for sm8250.(Dmitry)

Changes in v5:
- Add change to set mdp clk to max frequency in opp table during mdp probe/bind.

Vinod Polimera (5):
  arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk
  arm64/dts/qcom/sc7180: remove assigned-clock-rate property for mdp clk
  arm64/dts/qcom/sdm845: remove assigned-clock-rate property for mdp clk
  arm64/dts/qcom/sm8250: remove assigned-clock-rate property for mdp clk
  drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table
    during probe

 arch/arm64/boot/dts/qcom/sc7180.dtsi    | 9 ++-------
 arch/arm64/boot/dts/qcom/sc7280.dtsi    | 9 ++-------
 arch/arm64/boot/dts/qcom/sdm845.dtsi    | 9 ++-------
 arch/arm64/boot/dts/qcom/sm8250.dtsi    | 9 ++-------
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
 5 files changed, 11 insertions(+), 28 deletions(-)

-- 
2.7.4

[PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during resume sequence.
- Add fixes tag.

Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)

Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index baf1653..408cf6c 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2856,9 +2856,6 @@
 				      "ahb",
 				      "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <300000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -2892,11 +2889,9 @@
 					      "lut",
 					      "core",
 					      "vsync";
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						<&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
 						<&dispcc DISP_CC_MDSS_AHB_CLK>;
-				assigned-clock-rates = <300000000>,
-							<19200000>,
+				assigned-clock-rates = <19200000>,
 							<19200000>;
 				operating-points-v2 = <&mdp_opp_table>;
 				power-domains = <&rpmhpd SC7280_CX>;
-- 
2.7.4

[PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during resume sequence.
- Add fixes tag.

Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)

Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index baf1653..408cf6c 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2856,9 +2856,6 @@
 				      "ahb",
 				      "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <300000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -2892,11 +2889,9 @@
 					      "lut",
 					      "core",
 					      "vsync";
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						<&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
 						<&dispcc DISP_CC_MDSS_AHB_CLK>;
-				assigned-clock-rates = <300000000>,
-							<19200000>,
+				assigned-clock-rates = <19200000>,
 							<19200000>;
 				operating-points-v2 = <&mdp_opp_table>;
 				power-domains = <&rpmhpd SC7280_CX>;
-- 
2.7.4

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Stephen Boyd]

Quoting Vinod Polimera (2022-03-08 08:54:56)
> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.

How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
is preventing the frequency from changing beyond the assigned value.

>
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated value during the usecase.
>
> Changes in v2:
> - Remove assigned-clock-rate property and set mdp clk during resume sequence.
> - Add fixes tag.
>
> Changes in v3:
> - Remove extra line after fixes tag.(Stephen Boyd)

This changelog should be removed.

>
> Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")

I thought folks were saying that this is bad to keep? I don't really
mind either way, but I guess it's better to drop the fixes tag because
this is largely a performance improvement?

> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Stephen Boyd]

Quoting Vinod Polimera (2022-03-08 08:54:56)
> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.

How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
is preventing the frequency from changing beyond the assigned value.

>
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated value during the usecase.
>
> Changes in v2:
> - Remove assigned-clock-rate property and set mdp clk during resume sequence.
> - Add fixes tag.
>
> Changes in v3:
> - Remove extra line after fixes tag.(Stephen Boyd)

This changelog should be removed.

>
> Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")

I thought folks were saying that this is bad to keep? I don't really
mind either way, but I guess it's better to drop the fixes tag because
this is largely a performance improvement?

> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>

RE: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Wednesday, March 9, 2022 1:36 AM
> To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> rate property for mdp clk
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Quoting Vinod Polimera (2022-03-08 08:54:56)
> > Kernel clock driver assumes that initial rate is the
> > max rate for that clock and was not allowing it to scale
> > beyond the assigned clock value.
> 
> How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> is preventing the frequency from changing beyond the assigned value.

Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that.
i am planning to fix it as below.
1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed.
3) no changes in dt are required. (we can drop all the posted ones)

Changes :
```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
 	}
 }
 
-static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
-{
-	struct dss_clk *core_clk = kms->perf.core_clk;
-
-	if (core_clk->max_rate && (rate > core_clk->max_rate))
-		rate = core_clk->max_rate;
-
-	core_clk->rate = rate;
-	return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
-}
-
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
 {
 	u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
 		trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
 
-		ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
+		ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
 		if (ret) {
 			DPU_ERROR("failed to set %s clock rate %llu\n",
 					kms->perf.core_clk->clk_name, clk_rate);
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -175,7 +175,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
 			continue;
 		mp->clk_config[i].rate = rate;
 		mp->clk_config[i].type = DSS_CLK_PCLK;
-		mp->clk_config[i].max_rate = rate;
+		mp->clk_config[i].max_rate = ULONG_MAX;
 	}
 
 	mp->num_clk = num_clk;
--```

Thanks,
Vinod.

> 
> >
> > Drop the assigned clock rate property and vote on the mdp clock as per
> > calculated value during the usecase.
> >
> > Changes in v2:
> > - Remove assigned-clock-rate property and set mdp clk during resume
> sequence.
> > - Add fixes tag.
> >
> > Changes in v3:
> > - Remove extra line after fixes tag.(Stephen Boyd)
> 
> This changelog should be removed.
> 
> >
> > Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> 
> I thought folks were saying that this is bad to keep? I don't really
> mind either way, but I guess it's better to drop the fixes tag because
> this is largely a performance improvement?
> 
> > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > Reviewed-by: Stephen Boyd <swboyd@chromium.org>

RE: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Wednesday, March 9, 2022 1:36 AM
> To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> rate property for mdp clk
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Quoting Vinod Polimera (2022-03-08 08:54:56)
> > Kernel clock driver assumes that initial rate is the
> > max rate for that clock and was not allowing it to scale
> > beyond the assigned clock value.
> 
> How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> is preventing the frequency from changing beyond the assigned value.

Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that.
i am planning to fix it as below.
1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed.
3) no changes in dt are required. (we can drop all the posted ones)

Changes :
```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
 	}
 }
 
-static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
-{
-	struct dss_clk *core_clk = kms->perf.core_clk;
-
-	if (core_clk->max_rate && (rate > core_clk->max_rate))
-		rate = core_clk->max_rate;
-
-	core_clk->rate = rate;
-	return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
-}
-
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
 {
 	u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
 		trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
 
-		ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
+		ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
 		if (ret) {
 			DPU_ERROR("failed to set %s clock rate %llu\n",
 					kms->perf.core_clk->clk_name, clk_rate);
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -175,7 +175,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
 			continue;
 		mp->clk_config[i].rate = rate;
 		mp->clk_config[i].type = DSS_CLK_PCLK;
-		mp->clk_config[i].max_rate = rate;
+		mp->clk_config[i].max_rate = ULONG_MAX;
 	}
 
 	mp->num_clk = num_clk;
--```

Thanks,
Vinod.

> 
> >
> > Drop the assigned clock rate property and vote on the mdp clock as per
> > calculated value during the usecase.
> >
> > Changes in v2:
> > - Remove assigned-clock-rate property and set mdp clk during resume
> sequence.
> > - Add fixes tag.
> >
> > Changes in v3:
> > - Remove extra line after fixes tag.(Stephen Boyd)
> 
> This changelog should be removed.
> 
> >
> > Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> 
> I thought folks were saying that this is bad to keep? I don't really
> mind either way, but I guess it's better to drop the fixes tag because
> this is largely a performance improvement?
> 
> > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > Reviewed-by: Stephen Boyd <swboyd@chromium.org>

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Dmitry Baryshkov]

On Fri, 11 Mar 2022 at 11:06, Vinod Polimera <vpolimer@qti.qualcomm.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Stephen Boyd <swboyd@chromium.org>
> > Sent: Wednesday, March 9, 2022 1:36 AM
> > To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> > dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> > rate property for mdp clk
> >
> > WARNING: This email originated from outside of Qualcomm. Please be wary
> > of any links or attachments, and do not enable macros.
> >
> > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > Kernel clock driver assumes that initial rate is the
> > > max rate for that clock and was not allowing it to scale
> > > beyond the assigned clock value.
> >
> > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > is preventing the frequency from changing beyond the assigned value.
>
> Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that.
> i am planning to fix it as below.
> 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> 2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed.
> 3) no changes in dt are required. (we can drop all the posted ones)

Why? They made perfect sense. The dts assignments should be replaced
by the opp setting in the bind function, as this would also set the
performance point of the respective power domain.

>
> Changes :
> ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
>         }
>  }
>
> -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> -{
> -       struct dss_clk *core_clk = kms->perf.core_clk;
> -
> -       if (core_clk->max_rate && (rate > core_clk->max_rate))
> -               rate = core_clk->max_rate;
> -
> -       core_clk->rate = rate;
> -       return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> -}
> -
>  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
>  {
>         u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>
>                 trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
>
> -               ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> +               ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
>                 if (ret) {
>                         DPU_ERROR("failed to set %s clock rate %llu\n",
>                                         kms->perf.core_clk->clk_name, clk_rate);
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c

This file has been removed in msm/next

> @@ -175,7 +175,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
>                         continue;
>                 mp->clk_config[i].rate = rate;
>                 mp->clk_config[i].type = DSS_CLK_PCLK;
> -               mp->clk_config[i].max_rate = rate;
> +               mp->clk_config[i].max_rate = ULONG_MAX;
>         }
>
>         mp->num_clk = num_clk;
> --```
>
> Thanks,
> Vinod.
>
> >
> > >
> > > Drop the assigned clock rate property and vote on the mdp clock as per
> > > calculated value during the usecase.
> > >
> > > Changes in v2:
> > > - Remove assigned-clock-rate property and set mdp clk during resume
> > sequence.
> > > - Add fixes tag.
> > >
> > > Changes in v3:
> > > - Remove extra line after fixes tag.(Stephen Boyd)
> >
> > This changelog should be removed.
> >
> > >
> > > Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> >
> > I thought folks were saying that this is bad to keep? I don't really
> > mind either way, but I guess it's better to drop the fixes tag because
> > this is largely a performance improvement?
> >
> > > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > > Reviewed-by: Stephen Boyd <swboyd@chromium.org>



-- 
With best wishes
Dmitry

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Dmitry Baryshkov]

On Fri, 11 Mar 2022 at 11:06, Vinod Polimera <vpolimer@qti.qualcomm.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Stephen Boyd <swboyd@chromium.org>
> > Sent: Wednesday, March 9, 2022 1:36 AM
> > To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> > dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> > rate property for mdp clk
> >
> > WARNING: This email originated from outside of Qualcomm. Please be wary
> > of any links or attachments, and do not enable macros.
> >
> > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > Kernel clock driver assumes that initial rate is the
> > > max rate for that clock and was not allowing it to scale
> > > beyond the assigned clock value.
> >
> > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > is preventing the frequency from changing beyond the assigned value.
>
> Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that.
> i am planning to fix it as below.
> 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> 2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed.
> 3) no changes in dt are required. (we can drop all the posted ones)

Why? They made perfect sense. The dts assignments should be replaced
by the opp setting in the bind function, as this would also set the
performance point of the respective power domain.

>
> Changes :
> ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
>         }
>  }
>
> -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> -{
> -       struct dss_clk *core_clk = kms->perf.core_clk;
> -
> -       if (core_clk->max_rate && (rate > core_clk->max_rate))
> -               rate = core_clk->max_rate;
> -
> -       core_clk->rate = rate;
> -       return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> -}
> -
>  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
>  {
>         u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>
>                 trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
>
> -               ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> +               ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
>                 if (ret) {
>                         DPU_ERROR("failed to set %s clock rate %llu\n",
>                                         kms->perf.core_clk->clk_name, clk_rate);
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c

This file has been removed in msm/next

> @@ -175,7 +175,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
>                         continue;
>                 mp->clk_config[i].rate = rate;
>                 mp->clk_config[i].type = DSS_CLK_PCLK;
> -               mp->clk_config[i].max_rate = rate;
> +               mp->clk_config[i].max_rate = ULONG_MAX;
>         }
>
>         mp->num_clk = num_clk;
> --```
>
> Thanks,
> Vinod.
>
> >
> > >
> > > Drop the assigned clock rate property and vote on the mdp clock as per
> > > calculated value during the usecase.
> > >
> > > Changes in v2:
> > > - Remove assigned-clock-rate property and set mdp clk during resume
> > sequence.
> > > - Add fixes tag.
> > >
> > > Changes in v3:
> > > - Remove extra line after fixes tag.(Stephen Boyd)
> >
> > This changelog should be removed.
> >
> > >
> > > Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> >
> > I thought folks were saying that this is bad to keep? I don't really
> > mind either way, but I guess it's better to drop the fixes tag because
> > this is largely a performance improvement?
> >
> > > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > > Reviewed-by: Stephen Boyd <swboyd@chromium.org>



-- 
With best wishes
Dmitry

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Doug Anderson]

Hi,

On Fri, Mar 11, 2022 at 1:22 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Fri, 11 Mar 2022 at 11:06, Vinod Polimera <vpolimer@qti.qualcomm.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Stephen Boyd <swboyd@chromium.org>
> > > Sent: Wednesday, March 9, 2022 1:36 AM
> > > To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> > > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> > > dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> > > rate property for mdp clk
> > >
> > > WARNING: This email originated from outside of Qualcomm. Please be wary
> > > of any links or attachments, and do not enable macros.
> > >
> > > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > > Kernel clock driver assumes that initial rate is the
> > > > max rate for that clock and was not allowing it to scale
> > > > beyond the assigned clock value.
> > >
> > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > > is preventing the frequency from changing beyond the assigned value.
> >
> > Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that.
> > i am planning to fix it as below.
> > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> > 2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed.
> > 3) no changes in dt are required. (we can drop all the posted ones)
>
> Why? They made perfect sense. The dts assignments should be replaced
> by the opp setting in the bind function, as this would also set the
> performance point of the respective power domain.

Right. You should still _post_ the dts patches. It's nice to avoid
unneeded "assigned-clocks" in the dts. The patch description should
just be clear that it relies on the driver patch and shouldn't land /
be backported without the driver patch.


> > Changes :
> > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
> >         }
> >  }
> >
> > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> > -{
> > -       struct dss_clk *core_clk = kms->perf.core_clk;
> > -
> > -       if (core_clk->max_rate && (rate > core_clk->max_rate))
> > -               rate = core_clk->max_rate;
> > -
> > -       core_clk->rate = rate;
> > -       return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> > -}
> > -
> >  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> >  {
> >         u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
> >
> >                 trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
> >
> > -               ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> > +               ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
> >                 if (ret) {
> >                         DPU_ERROR("failed to set %s clock rate %llu\n",
> >                                         kms->perf.core_clk->clk_name, clk_rate);
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
>
> This file has been removed in msm/next

To echo Dmitry, please make sure that your patch applies to msm-next,
As I understand it, that means the branch msm-next on:

https://gitlab.freedesktop.org/drm/msm.git

-Doug

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Doug Anderson]

Hi,

On Fri, Mar 11, 2022 at 1:22 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Fri, 11 Mar 2022 at 11:06, Vinod Polimera <vpolimer@qti.qualcomm.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Stephen Boyd <swboyd@chromium.org>
> > > Sent: Wednesday, March 9, 2022 1:36 AM
> > > To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> > > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> > > dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> > > rate property for mdp clk
> > >
> > > WARNING: This email originated from outside of Qualcomm. Please be wary
> > > of any links or attachments, and do not enable macros.
> > >
> > > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > > Kernel clock driver assumes that initial rate is the
> > > > max rate for that clock and was not allowing it to scale
> > > > beyond the assigned clock value.
> > >
> > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and
> > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > > is preventing the frequency from changing beyond the assigned value.
> >
> > Folowing the comment of Stephen, i have checked a bit more. it appears that clock driver is not setting the max clock from assgined clocks, dpu driver is doing that.
> > i am planning to fix it as below.
> > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> > 2) remove unnecessary checks in the core_perf library. If rate doesn't match with the entries in the opp table, it will throw error, hence furthur checks are not needed.
> > 3) no changes in dt are required. (we can drop all the posted ones)
>
> Why? They made perfect sense. The dts assignments should be replaced
> by the opp setting in the bind function, as this would also set the
> performance point of the respective power domain.

Right. You should still _post_ the dts patches. It's nice to avoid
unneeded "assigned-clocks" in the dts. The patch description should
just be clear that it relies on the driver patch and shouldn't land /
be backported without the driver patch.


> > Changes :
> > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
> >         }
> >  }
> >
> > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> > -{
> > -       struct dss_clk *core_clk = kms->perf.core_clk;
> > -
> > -       if (core_clk->max_rate && (rate > core_clk->max_rate))
> > -               rate = core_clk->max_rate;
> > -
> > -       core_clk->rate = rate;
> > -       return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> > -}
> > -
> >  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> >  {
> >         u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
> >
> >                 trace_dpu_core_perf_update_clk(kms->dev, stop_req, clk_rate);
> >
> > -               ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> > +               ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
> >                 if (ret) {
> >                         DPU_ERROR("failed to set %s clock rate %llu\n",
> >                                         kms->perf.core_clk->clk_name, clk_rate);
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
>
> This file has been removed in msm/next

To echo Dmitry, please make sure that your patch applies to msm-next,
As I understand it, that means the branch msm-next on:

https://gitlab.freedesktop.org/drm/msm.git

-Doug

RE: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Monday, March 14, 2022 7:28 PM
> To: dmitry.baryshkov@linaro.org
> Cc: Vinod Polimera <vpolimer@qti.qualcomm.com>; Stephen Boyd
> <swboyd@chromium.org>; quic_vpolimer <quic_vpolimer@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org; robdclark@gmail.com; quic_kalyant
> <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> rate property for mdp clk
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Fri, Mar 11, 2022 at 1:22 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Fri, 11 Mar 2022 at 11:06, Vinod Polimera
> <vpolimer@qti.qualcomm.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Stephen Boyd <swboyd@chromium.org>
> > > > Sent: Wednesday, March 9, 2022 1:36 AM
> > > > To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> > > > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> > > > dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> > > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-
> clock-
> > > > rate property for mdp clk
> > > >
> > > > WARNING: This email originated from outside of Qualcomm. Please be
> wary
> > > > of any links or attachments, and do not enable macros.
> > > >
> > > > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > > > Kernel clock driver assumes that initial rate is the
> > > > > max rate for that clock and was not allowing it to scale
> > > > > beyond the assigned clock value.
> > > >
> > > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies
> and
> > > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > > > is preventing the frequency from changing beyond the assigned value.
> > >
> > > Folowing the comment of Stephen, i have checked a bit more. it appears
> that clock driver is not setting the max clock from assgined clocks, dpu driver
> is doing that.
> > > i am planning to fix it as below.
> > > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> > > 2) remove unnecessary checks in the core_perf library. If rate doesn't
> match with the entries in the opp table, it will throw error, hence furthur
> checks are not needed.
> > > 3) no changes in dt are required. (we can drop all the posted ones)
> >
> > Why? They made perfect sense. The dts assignments should be replaced
> > by the opp setting in the bind function, as this would also set the
> > performance point of the respective power domain.
> 
> Right. You should still _post_ the dts patches. It's nice to avoid
> unneeded "assigned-clocks" in the dts. The patch description should
> just be clear that it relies on the driver patch and shouldn't land /
> be backported without the driver patch.
> 
> 
- I have checked the latest  msm/next based on your comment and found that disp_io_util file
Is removed. From the latest origin, I have made changes to earlier patch series to address the comments.

> > > Changes :
> > > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct
> drm_crtc *crtc)
> > >         }
> > >  }
> > >
> > > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64
> rate)
> > > -{
> > > -       struct dss_clk *core_clk = kms->perf.core_clk;
> > > -
> > > -       if (core_clk->max_rate && (rate > core_clk->max_rate))
> > > -               rate = core_clk->max_rate;
> > > -
> > > -       core_clk->rate = rate;
> > > -       return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> > > -}
> > > -
> > >  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> > >  {
> > >         u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> > > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc
> *crtc,
> > >
> > >                 trace_dpu_core_perf_update_clk(kms->dev, stop_req,
> clk_rate);
> > >
> > > -               ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> > > +               ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
> > >                 if (ret) {
> > >                         DPU_ERROR("failed to set %s clock rate %llu\n",
> > >                                         kms->perf.core_clk->clk_name, clk_rate);
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >
> > This file has been removed in msm/next
> 
> To echo Dmitry, please make sure that your patch applies to msm-next,
> As I understand it, that means the branch msm-next on:
> 
> https://gitlab.freedesktop.org/drm/msm.git
> 
> -Doug

RE: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Monday, March 14, 2022 7:28 PM
> To: dmitry.baryshkov@linaro.org
> Cc: Vinod Polimera <vpolimer@qti.qualcomm.com>; Stephen Boyd
> <swboyd@chromium.org>; quic_vpolimer <quic_vpolimer@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org; robdclark@gmail.com; quic_kalyant
> <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-
> rate property for mdp clk
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Fri, Mar 11, 2022 at 1:22 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Fri, 11 Mar 2022 at 11:06, Vinod Polimera
> <vpolimer@qti.qualcomm.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Stephen Boyd <swboyd@chromium.org>
> > > > Sent: Wednesday, March 9, 2022 1:36 AM
> > > > To: quic_vpolimer <quic_vpolimer@quicinc.com>;
> > > > devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > > freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org; robdclark@gmail.com;
> > > > dianders@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> > > > Subject: Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-
> clock-
> > > > rate property for mdp clk
> > > >
> > > > WARNING: This email originated from outside of Qualcomm. Please be
> wary
> > > > of any links or attachments, and do not enable macros.
> > > >
> > > > Quoting Vinod Polimera (2022-03-08 08:54:56)
> > > > > Kernel clock driver assumes that initial rate is the
> > > > > max rate for that clock and was not allowing it to scale
> > > > > beyond the assigned clock value.
> > > >
> > > > How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies
> and
> > > > clk_rcg2_shared_ops so it doesn't look like anything in the clk driver
> > > > is preventing the frequency from changing beyond the assigned value.
> > >
> > > Folowing the comment of Stephen, i have checked a bit more. it appears
> that clock driver is not setting the max clock from assgined clocks, dpu driver
> is doing that.
> > > i am planning to fix it as below.
> > > 1) assign ULONG_MAX to max_rate while initializing clock in dpu driver.
> > > 2) remove unnecessary checks in the core_perf library. If rate doesn't
> match with the entries in the opp table, it will throw error, hence furthur
> checks are not needed.
> > > 3) no changes in dt are required. (we can drop all the posted ones)
> >
> > Why? They made perfect sense. The dts assignments should be replaced
> > by the opp setting in the bind function, as this would also set the
> > performance point of the respective power domain.
> 
> Right. You should still _post_ the dts patches. It's nice to avoid
> unneeded "assigned-clocks" in the dts. The patch description should
> just be clear that it relies on the driver patch and shouldn't land /
> be backported without the driver patch.
> 
> 
- I have checked the latest  msm/next based on your comment and found that disp_io_util file
Is removed. From the latest origin, I have made changes to earlier patch series to address the comments.

> > > Changes :
> > > ```--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > @@ -284,17 +284,6 @@ void dpu_core_perf_crtc_release_bw(struct
> drm_crtc *crtc)
> > >         }
> > >  }
> > >
> > > -static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64
> rate)
> > > -{
> > > -       struct dss_clk *core_clk = kms->perf.core_clk;
> > > -
> > > -       if (core_clk->max_rate && (rate > core_clk->max_rate))
> > > -               rate = core_clk->max_rate;
> > > -
> > > -       core_clk->rate = rate;
> > > -       return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
> > > -}
> > > -
> > >  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> > >  {
> > >         u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> > > @@ -405,7 +394,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc
> *crtc,
> > >
> > >                 trace_dpu_core_perf_update_clk(kms->dev, stop_req,
> clk_rate);
> > >
> > > -               ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
> > > +               ret = dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate);
> > >                 if (ret) {
> > >                         DPU_ERROR("failed to set %s clock rate %llu\n",
> > >                                         kms->perf.core_clk->clk_name, clk_rate);
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >
> > This file has been removed in msm/next
> 
> To echo Dmitry, please make sure that your patch applies to msm-next,
> As I understand it, that means the branch msm-next on:
> 
> https://gitlab.freedesktop.org/drm/msm.git
> 
> -Doug

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Bjorn Andersson]

On Tue 08 Mar 10:54 CST 2022, Vinod Polimera wrote:

Please run:

  git log --oneline --no-decorate -- arch/arm64/boot/dts/qcom/sc7280.dtsi

and make sure your $subject is prefixed according to all other
sc7280-specific changes.

> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.
> 
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated value during the usecase.
> 
> Changes in v2:
> - Remove assigned-clock-rate property and set mdp clk during resume sequence.
> - Add fixes tag.
> 
> Changes in v3:
> - Remove extra line after fixes tag.(Stephen Boyd)

It's only in drivers/drm that the changelog goes in the commit message,
so please move this below the ---.

Thanks,
Bjorn

> 
> Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> ---
>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index baf1653..408cf6c 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -2856,9 +2856,6 @@
>  				      "ahb",
>  				      "core";
>  
> -			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
> -			assigned-clock-rates = <300000000>;
> -
>  			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
>  			interrupt-controller;
>  			#interrupt-cells = <1>;
> @@ -2892,11 +2889,9 @@
>  					      "lut",
>  					      "core",
>  					      "vsync";
> -				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
> -						<&dispcc DISP_CC_MDSS_VSYNC_CLK>,
> +				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
>  						<&dispcc DISP_CC_MDSS_AHB_CLK>;
> -				assigned-clock-rates = <300000000>,
> -							<19200000>,
> +				assigned-clock-rates = <19200000>,
>  							<19200000>;
>  				operating-points-v2 = <&mdp_opp_table>;
>  				power-domains = <&rpmhpd SC7280_CX>;
> -- 
> 2.7.4
> 

Re: [PATCH v5 1/5] arm64/dts/qcom/sc7280: remove assigned-clock-rate property for mdp clk

[Bjorn Andersson]

On Tue 08 Mar 10:54 CST 2022, Vinod Polimera wrote:

Please run:

  git log --oneline --no-decorate -- arch/arm64/boot/dts/qcom/sc7280.dtsi

and make sure your $subject is prefixed according to all other
sc7280-specific changes.

> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.
> 
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated value during the usecase.
> 
> Changes in v2:
> - Remove assigned-clock-rate property and set mdp clk during resume sequence.
> - Add fixes tag.
> 
> Changes in v3:
> - Remove extra line after fixes tag.(Stephen Boyd)

It's only in drivers/drm that the changelog goes in the commit message,
so please move this below the ---.

Thanks,
Bjorn

> 
> Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> ---
>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index baf1653..408cf6c 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -2856,9 +2856,6 @@
>  				      "ahb",
>  				      "core";
>  
> -			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
> -			assigned-clock-rates = <300000000>;
> -
>  			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
>  			interrupt-controller;
>  			#interrupt-cells = <1>;
> @@ -2892,11 +2889,9 @@
>  					      "lut",
>  					      "core",
>  					      "vsync";
> -				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
> -						<&dispcc DISP_CC_MDSS_VSYNC_CLK>,
> +				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
>  						<&dispcc DISP_CC_MDSS_AHB_CLK>;
> -				assigned-clock-rates = <300000000>,
> -							<19200000>,
> +				assigned-clock-rates = <19200000>,
>  							<19200000>;
>  				operating-points-v2 = <&mdp_opp_table>;
>  				power-domains = <&rpmhpd SC7280_CX>;
> -- 
> 2.7.4
> 

[PATCH v5 2/5] arm64/dts/qcom/sc7180: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Fixes: a3db7ad1af("arm64: dts: qcom: sc7180: add display dt nodes")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index e1c46b8..eaab746 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2900,9 +2900,6 @@
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 			clock-names = "iface", "ahb", "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <300000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -2932,12 +2929,10 @@
 					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
 				clock-names = "bus", "iface", "rot", "lut", "core",
 					      "vsync";
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						  <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
 						  <&dispcc DISP_CC_MDSS_ROT_CLK>,
 						  <&dispcc DISP_CC_MDSS_AHB_CLK>;
-				assigned-clock-rates = <300000000>,
-						       <19200000>,
+				assigned-clock-rates = <19200000>,
 						       <19200000>,
 						       <19200000>;
 				operating-points-v2 = <&mdp_opp_table>;
-- 
2.7.4

[PATCH v5 2/5] arm64/dts/qcom/sc7180: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Fixes: a3db7ad1af("arm64: dts: qcom: sc7180: add display dt nodes")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index e1c46b8..eaab746 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2900,9 +2900,6 @@
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 			clock-names = "iface", "ahb", "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <300000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -2932,12 +2929,10 @@
 					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
 				clock-names = "bus", "iface", "rot", "lut", "core",
 					      "vsync";
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						  <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
 						  <&dispcc DISP_CC_MDSS_ROT_CLK>,
 						  <&dispcc DISP_CC_MDSS_AHB_CLK>;
-				assigned-clock-rates = <300000000>,
-						       <19200000>,
+				assigned-clock-rates = <19200000>,
 						       <19200000>,
 						       <19200000>;
 				operating-points-v2 = <&mdp_opp_table>;
-- 
2.7.4

[PATCH v5 3/5] arm64/dts/qcom/sdm845: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Fixes: 08c2a076d1("arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0d6286d..80dc486 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4181,9 +4181,6 @@
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 			clock-names = "iface", "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <300000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -4214,10 +4211,8 @@
 					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
 				clock-names = "gcc-bus", "iface", "bus", "core", "vsync";
 
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						  <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
-				assigned-clock-rates = <300000000>,
-						       <19200000>;
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+				assigned-clock-rates = <19200000>;
 				operating-points-v2 = <&mdp_opp_table>;
 				power-domains = <&rpmhpd SDM845_CX>;
 
-- 
2.7.4

[PATCH v5 3/5] arm64/dts/qcom/sdm845: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Fixes: 08c2a076d1("arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0d6286d..80dc486 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4181,9 +4181,6 @@
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 			clock-names = "iface", "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <300000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -4214,10 +4211,8 @@
 					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
 				clock-names = "gcc-bus", "iface", "bus", "core", "vsync";
 
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						  <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
-				assigned-clock-rates = <300000000>,
-						       <19200000>;
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+				assigned-clock-rates = <19200000>;
 				operating-points-v2 = <&mdp_opp_table>;
 				power-domains = <&rpmhpd SDM845_CX>;
 
-- 
2.7.4

[PATCH v5 4/5] arm64/dts/qcom/sm8250: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Fixes: 7c1dffd471("arm64: dts: qcom: sm8250.dtsi: add display system nodes")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index fdaf303..2105eb7 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -3164,9 +3164,6 @@
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 			clock-names = "iface", "bus", "nrt_bus", "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <460000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -3191,10 +3188,8 @@
 					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
 				clock-names = "iface", "bus", "core", "vsync";
 
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						  <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
-				assigned-clock-rates = <460000000>,
-						       <19200000>;
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+				assigned-clock-rates = <19200000>;
 
 				operating-points-v2 = <&mdp_opp_table>;
 				power-domains = <&rpmhpd SM8250_MMCX>;
-- 
2.7.4

[PATCH v5 4/5] arm64/dts/qcom/sm8250: remove assigned-clock-rate property for mdp clk

[Vinod Polimera]

Kernel clock driver assumes that initial rate is the
max rate for that clock and was not allowing it to scale
beyond the assigned clock value.

Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.

Fixes: 7c1dffd471("arm64: dts: qcom: sm8250.dtsi: add display system nodes")
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index fdaf303..2105eb7 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -3164,9 +3164,6 @@
 				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
 			clock-names = "iface", "bus", "nrt_bus", "core";
 
-			assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
-			assigned-clock-rates = <460000000>;
-
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-controller;
 			#interrupt-cells = <1>;
@@ -3191,10 +3188,8 @@
 					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
 				clock-names = "iface", "bus", "core", "vsync";
 
-				assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
-						  <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
-				assigned-clock-rates = <460000000>,
-						       <19200000>;
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+				assigned-clock-rates = <19200000>;
 
 				operating-points-v2 = <&mdp_opp_table>;
 				power-domains = <&rpmhpd SM8250_MMCX>;
-- 
2.7.4

[PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Vinod Polimera]

use max clock during probe/bind sequence from the opp table.
The clock will be scaled down when framework sends an update.

Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index d550f90..d9922b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
 	struct dpu_kms *dpu_kms;
 	struct dss_module_power *mp;
 	int ret = 0;
+	unsigned long max_freq = ULONG_MAX;
 
 	dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
 	if (!dpu_kms)
@@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 	}
 
+	dev_pm_opp_find_freq_floor(dev, &max_freq);
+	dev_pm_opp_set_rate(dev, max_freq);
 	platform_set_drvdata(pdev, dpu_kms);
 
 	ret = msm_kms_init(&dpu_kms->base, &kms_funcs);
-- 
2.7.4

[PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Vinod Polimera]

use max clock during probe/bind sequence from the opp table.
The clock will be scaled down when framework sends an update.

Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index d550f90..d9922b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
 	struct dpu_kms *dpu_kms;
 	struct dss_module_power *mp;
 	int ret = 0;
+	unsigned long max_freq = ULONG_MAX;
 
 	dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
 	if (!dpu_kms)
@@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
 		return ret;
 	}
 
+	dev_pm_opp_find_freq_floor(dev, &max_freq);
+	dev_pm_opp_set_rate(dev, max_freq);
 	platform_set_drvdata(pdev, dpu_kms);
 
 	ret = msm_kms_init(&dpu_kms->base, &kms_funcs);
-- 
2.7.4

Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Dmitry Baryshkov]

On Tue, 8 Mar 2022 at 19:55, Vinod Polimera <quic_vpolimer@quicinc.com> wrote:
>
> use max clock during probe/bind sequence from the opp table.
> The clock will be scaled down when framework sends an update.
>
> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index d550f90..d9922b9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
>         struct dpu_kms *dpu_kms;
>         struct dss_module_power *mp;
>         int ret = 0;
> +       unsigned long max_freq = ULONG_MAX;
>
>         dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
>         if (!dpu_kms)
> @@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
>                 return ret;
>         }
>
> +       dev_pm_opp_find_freq_floor(dev, &max_freq);

You leak a reference to the opp here. The function returns a value,
which should be dev_pm_opp_put().
Moreover judging from the dev_pm_opp_set_rate() code I think you don't
have to find an exact frequency, as it will call
clk_round_rate()/_find_freq_ceil() anyway.
Could you please check that it works?

> +       dev_pm_opp_set_rate(dev, max_freq);
>         platform_set_drvdata(pdev, dpu_kms);
>
>         ret = msm_kms_init(&dpu_kms->base, &kms_funcs);
> --
> 2.7.4
>


-- 
With best wishes
Dmitry

Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Dmitry Baryshkov]

On Tue, 8 Mar 2022 at 19:55, Vinod Polimera <quic_vpolimer@quicinc.com> wrote:
>
> use max clock during probe/bind sequence from the opp table.
> The clock will be scaled down when framework sends an update.
>
> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index d550f90..d9922b9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
>         struct dpu_kms *dpu_kms;
>         struct dss_module_power *mp;
>         int ret = 0;
> +       unsigned long max_freq = ULONG_MAX;
>
>         dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
>         if (!dpu_kms)
> @@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct device *master, void *data)
>                 return ret;
>         }
>
> +       dev_pm_opp_find_freq_floor(dev, &max_freq);

You leak a reference to the opp here. The function returns a value,
which should be dev_pm_opp_put().
Moreover judging from the dev_pm_opp_set_rate() code I think you don't
have to find an exact frequency, as it will call
clk_round_rate()/_find_freq_ceil() anyway.
Could you please check that it works?

> +       dev_pm_opp_set_rate(dev, max_freq);
>         platform_set_drvdata(pdev, dpu_kms);
>
>         ret = msm_kms_init(&dpu_kms->base, &kms_funcs);
> --
> 2.7.4
>


-- 
With best wishes
Dmitry

RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Vinod Polimera]

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Sent: Tuesday, March 8, 2022 10:40 PM
> To: quic_vpolimer <quic_vpolimer@quicinc.com>
> Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
> freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; robdclark@gmail.com; dianders@chromium.org;
> swboyd@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the
> maximum frequency in opp table during probe
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> On Tue, 8 Mar 2022 at 19:55, Vinod Polimera <quic_vpolimer@quicinc.com>
> wrote:
> >
> > use max clock during probe/bind sequence from the opp table.
> > The clock will be scaled down when framework sends an update.
> >
> > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index d550f90..d9922b9 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct
> device *master, void *data)
> >         struct dpu_kms *dpu_kms;
> >         struct dss_module_power *mp;
> >         int ret = 0;
> > +       unsigned long max_freq = ULONG_MAX;
> >
> >         dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms),
> GFP_KERNEL);
> >         if (!dpu_kms)
> > @@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct
> device *master, void *data)
> >                 return ret;
> >         }
> >
> > +       dev_pm_opp_find_freq_floor(dev, &max_freq);
> 
> You leak a reference to the opp here. The function returns a value,
> which should be dev_pm_opp_put().
> Moreover judging from the dev_pm_opp_set_rate() code I think you don't
> have to find an exact frequency, as it will call
> clk_round_rate()/_find_freq_ceil() anyway.
> Could you please check that it works?

clk_round_rate  will get the max frequency in freq_table in clk driver and if that frequency is missing in opp
table it will throw error. So, It will be optimal to get max freq in opp table and set it based on that freq.
> 
> > +       dev_pm_opp_set_rate(dev, max_freq);
> >         platform_set_drvdata(pdev, dpu_kms);
> >
> >         ret = msm_kms_init(&dpu_kms->base, &kms_funcs);
> > --
> > 2.7.4
> >
> 
> 
> --
> With best wishes
> Dmitry

RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Vinod Polimera]

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Sent: Tuesday, March 8, 2022 10:40 PM
> To: quic_vpolimer <quic_vpolimer@quicinc.com>
> Cc: dri-devel@lists.freedesktop.org; linux-arm-msm@vger.kernel.org;
> freedreno@lists.freedesktop.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; robdclark@gmail.com; dianders@chromium.org;
> swboyd@chromium.org; quic_kalyant <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the
> maximum frequency in opp table during probe
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> On Tue, 8 Mar 2022 at 19:55, Vinod Polimera <quic_vpolimer@quicinc.com>
> wrote:
> >
> > use max clock during probe/bind sequence from the opp table.
> > The clock will be scaled down when framework sends an update.
> >
> > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index d550f90..d9922b9 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > @@ -1221,6 +1221,7 @@ static int dpu_bind(struct device *dev, struct
> device *master, void *data)
> >         struct dpu_kms *dpu_kms;
> >         struct dss_module_power *mp;
> >         int ret = 0;
> > +       unsigned long max_freq = ULONG_MAX;
> >
> >         dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms),
> GFP_KERNEL);
> >         if (!dpu_kms)
> > @@ -1243,6 +1244,8 @@ static int dpu_bind(struct device *dev, struct
> device *master, void *data)
> >                 return ret;
> >         }
> >
> > +       dev_pm_opp_find_freq_floor(dev, &max_freq);
> 
> You leak a reference to the opp here. The function returns a value,
> which should be dev_pm_opp_put().
> Moreover judging from the dev_pm_opp_set_rate() code I think you don't
> have to find an exact frequency, as it will call
> clk_round_rate()/_find_freq_ceil() anyway.
> Could you please check that it works?

clk_round_rate  will get the max frequency in freq_table in clk driver and if that frequency is missing in opp
table it will throw error. So, It will be optimal to get max freq in opp table and set it based on that freq.
> 
> > +       dev_pm_opp_set_rate(dev, max_freq);
> >         platform_set_drvdata(pdev, dpu_kms);
> >
> >         ret = msm_kms_init(&dpu_kms->base, &kms_funcs);
> > --
> > 2.7.4
> >
> 
> 
> --
> With best wishes
> Dmitry

Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Doug Anderson]

Hi,

On Tue, Mar 8, 2022 at 8:55 AM Vinod Polimera <quic_vpolimer@quicinc.com> wrote:
>
> use max clock during probe/bind sequence from the opp table.
> The clock will be scaled down when framework sends an update.
>
> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
>  1 file changed, 3 insertions(+)

In addition to Dmitry's requests, can you also make this patch #1 in
the series since the DTS stuff really ought to come _after_ this one.

...and actually, thinking about it further:

1. If we land this fix, we actually don't _need_ the dts patches,
right? Sure, the clock rate will get assigned before probe but then
we'll change it right away in probe, right?

2. If we land the dts patches _before_ the driver patch then it will
be a regression, right?

3. The dts patches and driver patch will probably land through
separate trees. The driver patch will go through the MSM DRM tree and
the device tree patches through the Qualcomm armsoc tree, right?


Assuming that the above is right, we should:

1. Put the driver patch first.

2. Remove the "Fixes" tag on the dts patches. I guess in theory we
could have a FIxes tag on this patch?

3. Note in the dts patches commit messages that they depend on the driver patch.

4. Delay the dts patches until the driver change has made it to mainline.

Does that sound reasonable?

Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Doug Anderson]

Hi,

On Tue, Mar 8, 2022 at 8:55 AM Vinod Polimera <quic_vpolimer@quicinc.com> wrote:
>
> use max clock during probe/bind sequence from the opp table.
> The clock will be scaled down when framework sends an update.
>
> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
>  1 file changed, 3 insertions(+)

In addition to Dmitry's requests, can you also make this patch #1 in
the series since the DTS stuff really ought to come _after_ this one.

...and actually, thinking about it further:

1. If we land this fix, we actually don't _need_ the dts patches,
right? Sure, the clock rate will get assigned before probe but then
we'll change it right away in probe, right?

2. If we land the dts patches _before_ the driver patch then it will
be a regression, right?

3. The dts patches and driver patch will probably land through
separate trees. The driver patch will go through the MSM DRM tree and
the device tree patches through the Qualcomm armsoc tree, right?


Assuming that the above is right, we should:

1. Put the driver patch first.

2. Remove the "Fixes" tag on the dts patches. I guess in theory we
could have a FIxes tag on this patch?

3. Note in the dts patches commit messages that they depend on the driver patch.

4. Delay the dts patches until the driver change has made it to mainline.

Does that sound reasonable?

RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Vinod Polimera]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Thursday, March 10, 2022 12:55 AM
> To: quic_vpolimer <quic_vpolimer@quicinc.com>
> Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob
> Clark <robdclark@gmail.com>; Stephen Boyd <swboyd@chromium.org>;
> quic_kalyant <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the
> maximum frequency in opp table during probe
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Tue, Mar 8, 2022 at 8:55 AM Vinod Polimera
> <quic_vpolimer@quicinc.com> wrote:
> >
> > use max clock during probe/bind sequence from the opp table.
> > The clock will be scaled down when framework sends an update.
> >
> > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
> >  1 file changed, 3 insertions(+)
> 
> In addition to Dmitry's requests, can you also make this patch #1 in
> the series since the DTS stuff really ought to come _after_ this one.
> 
> ...and actually, thinking about it further:
> 
> 1. If we land this fix, we actually don't _need_ the dts patches,
> right? Sure, the clock rate will get assigned before probe but then
> we'll change it right away in probe, right?
> 
> 2. If we land the dts patches _before_ the driver patch then it will
> be a regression, right?
> 
> 3. The dts patches and driver patch will probably land through
> separate trees. The driver patch will go through the MSM DRM tree and
> the device tree patches through the Qualcomm armsoc tree, right?
> 
> 
> Assuming that the above is right, we should:
> 
> 1. Put the driver patch first.
> 
Moved driver patch first.

> 2. Remove the "Fixes" tag on the dts patches. I guess in theory we
> could have a FIxes tag on this patch?
> 
- Removed fixed tag on dt patches and added on driver patch.

> 3. Note in the dts patches commit messages that they depend on the driver
> patch.
> 
- Added dependency patch on driver patch for dt patch.

> 4. Delay the dts patches until the driver change has made it to mainline.
> 
> Does that sound reasonable?

RE: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the maximum frequency in opp table during probe

[Vinod Polimera]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Thursday, March 10, 2022 12:55 AM
> To: quic_vpolimer <quic_vpolimer@quicinc.com>
> Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob
> Clark <robdclark@gmail.com>; Stephen Boyd <swboyd@chromium.org>;
> quic_kalyant <quic_kalyant@quicinc.com>
> Subject: Re: [PATCH v5 5/5] drm/msm/disp/dpu1: set mdp clk to the
> maximum frequency in opp table during probe
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Tue, Mar 8, 2022 at 8:55 AM Vinod Polimera
> <quic_vpolimer@quicinc.com> wrote:
> >
> > use max clock during probe/bind sequence from the opp table.
> > The clock will be scaled down when framework sends an update.
> >
> > Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
> >  1 file changed, 3 insertions(+)
> 
> In addition to Dmitry's requests, can you also make this patch #1 in
> the series since the DTS stuff really ought to come _after_ this one.
> 
> ...and actually, thinking about it further:
> 
> 1. If we land this fix, we actually don't _need_ the dts patches,
> right? Sure, the clock rate will get assigned before probe but then
> we'll change it right away in probe, right?
> 
> 2. If we land the dts patches _before_ the driver patch then it will
> be a regression, right?
> 
> 3. The dts patches and driver patch will probably land through
> separate trees. The driver patch will go through the MSM DRM tree and
> the device tree patches through the Qualcomm armsoc tree, right?
> 
> 
> Assuming that the above is right, we should:
> 
> 1. Put the driver patch first.
> 
Moved driver patch first.

> 2. Remove the "Fixes" tag on the dts patches. I guess in theory we
> could have a FIxes tag on this patch?
> 
- Removed fixed tag on dt patches and added on driver patch.

> 3. Note in the dts patches commit messages that they depend on the driver
> patch.
> 
- Added dependency patch on driver patch for dt patch.

> 4. Delay the dts patches until the driver change has made it to mainline.
> 
> Does that sound reasonable?