| Message ID | 20240221-rb3gen2-dp-connector-v1-0-dc0964ef7d96@quicinc.com |
|---|---|
| Headers | show |
| Series | arm64: dts: qcom: qcs6490-rb3gen2: Enable two displays | expand |
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 >
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > Define firmware paths and enable the ADSP and CDSP remoteprocs. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > index 32313f47602a..ab498494caea 100644 > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > @@ -451,6 +451,16 @@ &qupv3_id_0 { > status = "okay"; > }; > > +&remoteproc_adsp { > + firmware-name = "qcom/qcs6490/rb3gen2/adsp.mbn"; This should be either firmware-name = "qcom/qcs6490/adsp.mbn"; or firmware-name = "qcom/qcs6490/Vendor/rb3gen2/adsp.mbn"; > + status = "okay"; > +}; > + > +&remoteproc_cdsp { > + firmware-name = "qcom/qcs6490/rb3gen2/cdsp.mbn"; > + status = "okay"; > +}; > + > &tlmm { > gpio-reserved-ranges = <32 2>, /* ADSP */ > <48 4>; /* NFC */ > > -- > 2.25.1 >
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > Enable the SC7280 display and gpu clock controllers to enable display > support on the QCS6490 RB3gen2. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > arch/arm64/configs/defconfig | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > The RB3Gen2 board comes with a mini DP connector, describe this, enable > MDSS, DP controller and the PHY that drives this. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > index ac4579119d3b..32313f47602a 100644 > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > @@ -430,6 +430,23 @@ &gcc { > <GCC_WPSS_RSCP_CLK>; > }; > > +&mdss { > + status = "okay"; > +}; > + > +&mdss_edp { > + status = "okay"; > +}; > + > +&mdss_edp_out { > + data-lanes = <0 1 2 3>; > + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>; > +}; Please add a corresponding dp-connector device and link it to the mdss_edp_out. > + > +&mdss_edp_phy { > + status = "okay"; > +}; > + > &qupv3_id_0 { > status = "okay"; > }; > @@ -470,3 +487,9 @@ &usb_1_qmpphy { > &wifi { > memory-region = <&wlan_fw_mem>; > }; > + > +/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */ > + > +&edp_hot_plug_det { > + bias-disable; > +}; > > -- > 2.25.1 > -- With best wishes Dmitry
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > With the ADSP remoteproc loaded pmic_glink can be introduced and wired > up to provide role and orientation switching signals. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 48 +++++++++++++++++++++++++++- > 1 file changed, 47 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > index ab498494caea..079bf43b14cc 100644 > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > @@ -121,6 +121,41 @@ debug_vm_mem: debug-vm@d0600000 { > }; > }; > > + pmic-glink { > + compatible = "qcom,qcm6490-pmic-glink", "qcom,pmic-glink"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + connector@0 { > + compatible = "usb-c-connector"; > + reg = <0>; > + power-role = "dual"; > + data-role = "dual"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + > + pmic_glink_hs_in: endpoint { > + remote-endpoint = <&usb_1_dwc3_hs>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + > + pmic_glink_ss_in: endpoint { > + remote-endpoint = <&usb_1_dwc3_ss>; This should be connected to the QMP PHY rather than to the USB host. Also it might be better to squash this patch with the patch 8. Or at least to get redriver into the picture in this patch (and keep only display-related parts in that patch). > + }; > + }; > + }; > + }; > + }; > + > vph_pwr: vph-pwr-regulator { > compatible = "regulator-fixed"; > regulator-name = "vph_pwr"; > @@ -476,7 +511,16 @@ &usb_1 { > }; > > &usb_1_dwc3 { > - dr_mode = "peripheral"; > + dr_mode = "otg"; > + usb-role-switch; > +}; > + > +&usb_1_dwc3_hs { > + remote-endpoint = <&pmic_glink_hs_in>; > +}; > + > +&usb_1_dwc3_ss { > + remote-endpoint = <&pmic_glink_ss_in>; > }; > > &usb_1_hsphy { > @@ -491,6 +535,8 @@ &usb_1_qmpphy { > vdda-phy-supply = <&vreg_l6b_1p2>; > vdda-pll-supply = <&vreg_l1b_0p912>; > > + orientation-switch; > + > status = "okay"; > }; > > > -- > 2.25.1 > -- With best wishes Dmitry
On Thu, Feb 22, 2024 at 01:50:12AM +0200, Dmitry Baryshkov wrote: > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson <quic_bjorande@quicinc.com> wrote: > > > > With the ADSP remoteproc loaded pmic_glink can be introduced and wired > > up to provide role and orientation switching signals. > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > > --- > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 48 +++++++++++++++++++++++++++- > > 1 file changed, 47 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > > index ab498494caea..079bf43b14cc 100644 > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > > @@ -121,6 +121,41 @@ debug_vm_mem: debug-vm@d0600000 { > > }; > > }; > > > > + pmic-glink { > > + compatible = "qcom,qcm6490-pmic-glink", "qcom,pmic-glink"; > > + > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + connector@0 { > > + compatible = "usb-c-connector"; > > + reg = <0>; > > + power-role = "dual"; > > + data-role = "dual"; > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { > > + reg = <0>; > > + > > + pmic_glink_hs_in: endpoint { > > + remote-endpoint = <&usb_1_dwc3_hs>; > > + }; > > + }; > > + > > + port@1 { > > + reg = <1>; > > + > > + pmic_glink_ss_in: endpoint { > > + remote-endpoint = <&usb_1_dwc3_ss>; > > This should be connected to the QMP PHY rather than to the USB host. > Ahh, you're right, otherwise the orientation-switch below isn't of much use. > Also it might be better to squash this patch with the patch 8. Or at > least to get redriver into the picture in this patch (and keep only > display-related parts in that patch). > The idea was to only bring in the pmic-glink here and then do the plumbing between all the components separately, but I guess the orientation-switch in the redriver means that it should go here as well... I'll shuffle this into something that makes sense. Thanks, Bjorn > > > + }; > > + }; > > + }; > > + }; > > + }; > > + > > vph_pwr: vph-pwr-regulator { > > compatible = "regulator-fixed"; > > regulator-name = "vph_pwr"; > > @@ -476,7 +511,16 @@ &usb_1 { > > }; > > > > &usb_1_dwc3 { > > - dr_mode = "peripheral"; > > + dr_mode = "otg"; > > + usb-role-switch; > > +}; > > + > > +&usb_1_dwc3_hs { > > + remote-endpoint = <&pmic_glink_hs_in>; > > +}; > > + > > +&usb_1_dwc3_ss { > > + remote-endpoint = <&pmic_glink_ss_in>; > > }; > > > > &usb_1_hsphy { > > @@ -491,6 +535,8 @@ &usb_1_qmpphy { > > vdda-phy-supply = <&vreg_l6b_1p2>; > > vdda-pll-supply = <&vreg_l1b_0p912>; > > > > + orientation-switch; > > + > > status = "okay"; > > }; > > > > > > -- > > 2.25.1 > > > > > -- > With best wishes > Dmitry
On 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 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/ .
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?
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
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 2/22/2024 4:49 AM, Bjorn Andersson wrote: > With the ADSP remoteproc loaded pmic_glink can be introduced and wired > up to provide role and orientation switching signals. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 48 +++++++++++++++++++++++++++- > 1 file changed, 47 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > index ab498494caea..079bf43b14cc 100644 > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts > @@ -121,6 +121,41 @@ debug_vm_mem: debug-vm@d0600000 { > }; > }; > > + pmic-glink { > + compatible = "qcom,qcm6490-pmic-glink", "qcom,pmic-glink"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + connector@0 { > + compatible = "usb-c-connector"; > + reg = <0>; > + power-role = "dual"; > + data-role = "dual"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + > + pmic_glink_hs_in: endpoint { > + remote-endpoint = <&usb_1_dwc3_hs>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + > + pmic_glink_ss_in: endpoint { > + remote-endpoint = <&usb_1_dwc3_ss>; > + }; > + }; For the role switching part: Tested-By: Krishna Kurapati PSSNV <quic_kriskura@quicinc.com> Regards, Krishna,
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.
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>
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>
RB3Gen2 is capable of producing DisplayPort output on a dedicated mini-DP connector and USB Type-C. Utilize Abel's work for DP vs eDP selection to allow configuring both controllers in DP-mode, then enable the two output paths. Tested by driving fbcon to 4k@60 + 4k@30 concurrently. Depends on https://lore.kernel.org/linux-arm-msm/20240220-x1e80100-display-v4-0-971afd9de861@linaro.org/ Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> --- Bjorn Andersson (9): drm/msm/dp: Add DP support to combo instance in SC7280 arm64: dts: qcom: sc7280: Make eDP/DP controller default DP arm64: dts: qcom: sc7280: Enable MDP turbo mode arm64: dts: qcom: qcs6490-rb3gen2: Add DP output arm64: dts: qcom: qcs6490-rb3gen2: Enable adsp and cdsp arm64: dts: qcom: qcs6490-rb3gen2: Enable USB role switching arm64: dts: qcom: qcs6490-rb3gen2: Introduce USB redriver arm64: dts: qcom: qcs6490-rb3gen2: Enable USB Type-C display arm64: defconfig: Enable sc7280 display and gpu clock controllers arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 154 ++++++++++++++++++++++++++- arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 2 + arch/arm64/boot/dts/qcom/sc7280.dtsi | 7 +- arch/arm64/configs/defconfig | 2 + drivers/gpu/drm/msm/dp/dp_display.c | 9 +- 5 files changed, 170 insertions(+), 4 deletions(-) --- base-commit: aba508318eec7acad2373296279d6447fd35f83f change-id: 20240209-rb3gen2-dp-connector-bddfb892ff20 Best regards,