The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60 display, resulting in constant underrun.
Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to
fix this.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index a19c278ebec9..a2a6717c6c87 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -4417,6 +4417,11 @@ opp-506666667 {
opp-hz = /bits/ 64 <506666667>;
required-opps = <&rpmhpd_opp_nom>;
};
+
+ opp-608000000 {
+ opp-hz = /bits/ 64 <608000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ };
};
};
--
2.25.1On 2/22/24 00:19, Bjorn Andersson wrote: > The max frequency listed in the DPU opp-table is 506MHz, this is not > sufficient to drive a 4k@60 display, resulting in constant underrun. > > Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > fix this. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> The max frequency listed in the DPU opp-table is 506MHz, this is not
> sufficient to drive a 4k@60 display, resulting in constant underrun.
>
> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to
> fix this.
I think we might want to keep this disabled for ChromeOS devices. Doug?
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index a19c278ebec9..a2a6717c6c87 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -4417,6 +4417,11 @@ opp-506666667 {
> opp-hz = /bits/ 64 <506666667>;
> required-opps = <&rpmhpd_opp_nom>;
> };
> +
> + opp-608000000 {
> + opp-hz = /bits/ 64 <608000000>;
> + required-opps = <&rpmhpd_opp_turbo>;
> + };
> };
> };
>
>
> --
> 2.25.1
>
--
With best wishes
Dmitry
On 2/22/24 00:41, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >> >> The max frequency listed in the DPU opp-table is 506MHz, this is not >> sufficient to drive a 4k@60 display, resulting in constant underrun. >> >> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >> fix this. > > I think we might want to keep this disabled for ChromeOS devices. Doug? ChromeOS devices don't get a special SoC Konrad
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > On 2/22/24 00:41, Dmitry Baryshkov wrote: > > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > >> > >> The max frequency listed in the DPU opp-table is 506MHz, this is not > >> sufficient to drive a 4k@60 display, resulting in constant underrun. > >> > >> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > >> fix this. > > > > I think we might want to keep this disabled for ChromeOS devices. Doug? > > ChromeOS devices don't get a special SoC But they have the sc7280-chrome-common.dtsi, which might contain a corresponding /delete-node/ . -- With best wishes Dmitry
On 2/22/24 10:04, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 2/22/24 00:41, Dmitry Baryshkov wrote: >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >>>> >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. >>>> >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >>>> fix this. >>> >>> I think we might want to keep this disabled for ChromeOS devices. Doug? >> >> ChromeOS devices don't get a special SoC > > But they have the sc7280-chrome-common.dtsi, which might contain a > corresponding /delete-node/ . What does that change? The clock rates are bound to the SoC and the effective values are limited by link-frequencies or the panel driver. Konrad
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > >> > >> > >> > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > >>>> > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > >>>> > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > >>>> fix this. > >>> > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > >> > >> ChromeOS devices don't get a special SoC > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > corresponding /delete-node/ . > > What does that change? The clock rates are bound to the > SoC and the effective values are limited by link-frequencies > or the panel driver. Preventing the DPU from overheating? Or spending too much power? -- With best wishes Dmitry
On 2/22/2024 1:46 AM, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 2/22/24 10:04, Dmitry Baryshkov wrote: >>> On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >>>> >>>> >>>> >>>> On 2/22/24 00:41, Dmitry Baryshkov wrote: >>>>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >>>>>> >>>>>> The max frequency listed in the DPU opp-table is 506MHz, this is not >>>>>> sufficient to drive a 4k@60 display, resulting in constant underrun. >>>>>> >>>>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >>>>>> fix this. >>>>> >>>>> I think we might want to keep this disabled for ChromeOS devices. Doug? >>>> >>>> ChromeOS devices don't get a special SoC >>> >>> But they have the sc7280-chrome-common.dtsi, which might contain a >>> corresponding /delete-node/ . >> >> What does that change? The clock rates are bound to the >> SoC and the effective values are limited by link-frequencies >> or the panel driver. > > Preventing the DPU from overheating? Or spending too much power? > Running DPU clock in turbo is a requirement to support 4k@60 otherwise the pixel rate that high cannot be supported. sc7280 chrome devices already limit to HBR2 https://lore.kernel.org/all/20230329233416.27152-1-quic_abhinavk@quicinc.com/ So the DPU will not vote more than nominal. And like others wrote, limiting SOC frequencies is not the way and we should filter out required frequencies using link-frequencies. Hence fwiw, I am fine with this change. Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > >> > > >> > > >> > > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > >>>> > > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > > >>>> > > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > > >>>> fix this. > > >>> > > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > > >> > > >> ChromeOS devices don't get a special SoC > > > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > > corresponding /delete-node/ . > > > > What does that change? The clock rates are bound to the > > SoC and the effective values are limited by link-frequencies > > or the panel driver. > > Preventing the DPU from overheating? Or spending too much power? > Perhaps I'm misunderstanding the implementation then, are we always running at the max opp? I thought the opp was selected based on the current need for performance? Regards, Bjorn > -- > With best wishes > Dmitry
On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote: > > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > >> > > > >> > > > >> > > > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > > > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > >>>> > > > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > > > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > > > >>>> > > > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > > > >>>> fix this. > > > >>> > > > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > > > >> > > > >> ChromeOS devices don't get a special SoC > > > > > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > > > corresponding /delete-node/ . > > > > > > What does that change? The clock rates are bound to the > > > SoC and the effective values are limited by link-frequencies > > > or the panel driver. > > > > Preventing the DPU from overheating? Or spending too much power? > > > > Perhaps I'm misunderstanding the implementation then, are we always > running at the max opp? I thought the opp was selected based on the > current need for performance? Yes. My concern was whether the Chrome people purposely skipped this top/turbo freq for any reason. In such a case, surprising them by adding it to all platforms might be not the best idea. I hope Doug can comment here. -- With best wishes Dmitry
Hi, On Thu, Feb 22, 2024 at 9:32 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > > On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote: > > > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > > > > > > > > > On 2/22/24 10:04, Dmitry Baryshkov wrote: > > > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > >> > > > > >> > > > > >> > > > > >> On 2/22/24 00:41, Dmitry Baryshkov wrote: > > > > >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > > >>>> > > > > >>>> The max frequency listed in the DPU opp-table is 506MHz, this is not > > > > >>>> sufficient to drive a 4k@60 display, resulting in constant underrun. > > > > >>>> > > > > >>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to > > > > >>>> fix this. > > > > >>> > > > > >>> I think we might want to keep this disabled for ChromeOS devices. Doug? > > > > >> > > > > >> ChromeOS devices don't get a special SoC > > > > > > > > > > But they have the sc7280-chrome-common.dtsi, which might contain a > > > > > corresponding /delete-node/ . > > > > > > > > What does that change? The clock rates are bound to the > > > > SoC and the effective values are limited by link-frequencies > > > > or the panel driver. > > > > > > Preventing the DPU from overheating? Or spending too much power? > > > > > > > Perhaps I'm misunderstanding the implementation then, are we always > > running at the max opp? I thought the opp was selected based on the > > current need for performance? > > Yes. My concern was whether the Chrome people purposely skipped this > top/turbo freq for any reason. In such a case, surprising them by > adding it to all platforms might be not the best idea. I hope Doug can > comment here. Thanks for thinking of us! In this case, I think the only users left of the sc7280 Chrome devices are folks like Rob and then a few folks on Qualcomm's display team (like Abhinav), so if they're happy with the change then I have no objections. In any case, I'm not aware of any reason why this would have been skipped for Chrome. The Chrome devices were always intended to support 4K so I assume this was an oversight and nothing more. ...of course, as Abhinav points out Chrome devices are currently limited to HBR2 + 2 lanes DP so they can't go 4K60 anyway. In any case, in case it matters, feel free to have: Acked-by: Douglas Anderson <dianders@chromium.org>
On 2/22/24 10:46, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> >> On 2/22/24 10:04, Dmitry Baryshkov wrote: >>> On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >>>> >>>> >>>> >>>> On 2/22/24 00:41, Dmitry Baryshkov wrote: >>>>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: >>>>>> >>>>>> The max frequency listed in the DPU opp-table is 506MHz, this is not >>>>>> sufficient to drive a 4k@60 display, resulting in constant underrun. >>>>>> >>>>>> Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to >>>>>> fix this. >>>>> >>>>> I think we might want to keep this disabled for ChromeOS devices. Doug? >>>> >>>> ChromeOS devices don't get a special SoC >>> >>> But they have the sc7280-chrome-common.dtsi, which might contain a >>> corresponding /delete-node/ . >> >> What does that change? The clock rates are bound to the >> SoC and the effective values are limited by link-frequencies >> or the panel driver. > > Preventing the DPU from overheating? ????????????? > Or spending too much power? Would it not concern non-Chrome SC7280s too, then? Konrad
© 2016 - 2026 Red Hat, Inc.