| Message ID | 20250424-sm8750-display-dts-v1-1-6fb22ca95f38@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: dts: qcom: sm8750: Enable display | expand |
On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: > Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, > DisplayPort and Display Clock Controller. > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > --- [...] > + mdp_opp_table: opp-table { > + compatible = "operating-points-v2"; > + The computer tells me there's also a 156 MHz rate @ SVS_D1 Maybe Abhinav could chime in whether we should add it or not [...] > + mdss_dsi_opp_table: opp-table { > + compatible = "operating-points-v2"; > + Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd with the decimals Konrad
On 4/28/2025 2:31 PM, Konrad Dybcio wrote: > On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: >> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, >> DisplayPort and Display Clock Controller. >> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> >> --- > > [...] > >> + mdp_opp_table: opp-table { >> + compatible = "operating-points-v2"; >> + > > The computer tells me there's also a 156 MHz rate @ SVS_D1 > > Maybe Abhinav could chime in whether we should add it or not > Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for sm8650 and did not publish it in the dt. It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though LOW_SVS_D1 is present even on those. I think the reason could be that the displays being used on the reference boards will need a pixel clock of atleast >= low_svs and the MDP clock usually depends on the value of the DSI pixel clock (which has a fixed relationship to the byte clock) to maintain the data rate. So as a result perhaps even if we add it, for most displays this level will be unused. If we end up using displays which are so small that the pixel clock requirement will be even lower than low_svs, we can add those. OR as an alternative, we can leave this patch as it is and add the low_svs_d1 for all chipsets which support it together in another series that way it will have the full context of why we are adding it otherwise it will look odd again of why sm8550/sm8650 was left out but added in sm8750. > [...] > >> + mdss_dsi_opp_table: opp-table { >> + compatible = "operating-points-v2"; >> + > > Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd > with the decimals For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this voltage corner was somehow never used for DSI byte clock again I am thinking this is because for the display resolutions we use, we will always be >= low_svs so the low_svs_d1 will never hit even if we add it. > > Konrad >
On 4/30/25 1:07 AM, Abhinav Kumar wrote: > > > On 4/28/2025 2:31 PM, Konrad Dybcio wrote: >> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: >>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, >>> DisplayPort and Display Clock Controller. >>> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>> >>> --- >> >> [...] >> >>> + mdp_opp_table: opp-table { >>> + compatible = "operating-points-v2"; >>> + >> >> The computer tells me there's also a 156 MHz rate @ SVS_D1 >> >> Maybe Abhinav could chime in whether we should add it or not >> > > Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for sm8650 and did not publish it in the dt. > > It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though LOW_SVS_D1 is present even on those. > > I think the reason could be that the displays being used on the reference boards will need a pixel clock of atleast >= low_svs and the MDP clock usually depends on the value of the DSI pixel clock (which has a fixed relationship to the byte clock) to maintain the data rate. So as a result perhaps even if we add it, for most displays this level will be unused. > > If we end up using displays which are so small that the pixel clock requirement will be even lower than low_svs, we can add those. > > OR as an alternative, we can leave this patch as it is and add the low_svs_d1 for all chipsets which support it together in another series that way it will have the full context of why we are adding it otherwise it will look odd again of why sm8550/sm8650 was left out but added in sm8750. I would assume that with VRR even fancy panels at low refresh rate (in the 1-5 Hz range) may make use of this, so I would be happy to go with option 2 > >> [...] >> >>> + mdss_dsi_opp_table: opp-table { >>> + compatible = "operating-points-v2"; >>> + >> >> Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd >> with the decimals > > For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this voltage corner was somehow never used for DSI byte clock again I am thinking this is because for the display resolutions we use, we will always be >= low_svs so the low_svs_d1 will never hit even if we add it. Alright Konrad
On Tue, Apr 29, 2025 at 04:07:24PM -0700, Abhinav Kumar wrote: > > > On 4/28/2025 2:31 PM, Konrad Dybcio wrote: > > On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: > > > Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, > > > DisplayPort and Display Clock Controller. > > > > > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > > > --- > > > > [...] > > > > > + mdp_opp_table: opp-table { > > > + compatible = "operating-points-v2"; > > > + > > > > The computer tells me there's also a 156 MHz rate @ SVS_D1 > > > > Maybe Abhinav could chime in whether we should add it or not > > > > Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for > sm8650 and did not publish it in the dt. > > It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though > LOW_SVS_D1 is present even on those. > > I think the reason could be that the displays being used on the reference > boards will need a pixel clock of atleast >= low_svs and the MDP clock > usually depends on the value of the DSI pixel clock (which has a fixed > relationship to the byte clock) to maintain the data rate. So as a result > perhaps even if we add it, for most displays this level will be unused. > > If we end up using displays which are so small that the pixel clock > requirement will be even lower than low_svs, we can add those. > > OR as an alternative, we can leave this patch as it is and add the > low_svs_d1 for all chipsets which support it together in another series that > way it will have the full context of why we are adding it otherwise it will > look odd again of why sm8550/sm8650 was left out but added in sm8750. I think it's better to describe hardware accurately, even if the particular entry ends up being unused. I'd vote for this option. > > [...] > > > > > + mdss_dsi_opp_table: opp-table { > > > + compatible = "operating-points-v2"; > > > + > > > > Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd > > with the decimals > > For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this > voltage corner was somehow never used for DSI byte clock again I am thinking > this is because for the display resolutions we use, we will always be >= > low_svs so the low_svs_d1 will never hit even if we add it. Please add all voltage/frequency corners. Think about low-res DP or low-res, low-rate WB.
On 5/2/2025 10:51 PM, Dmitry Baryshkov wrote: > On Tue, Apr 29, 2025 at 04:07:24PM -0700, Abhinav Kumar wrote: >> >> >> On 4/28/2025 2:31 PM, Konrad Dybcio wrote: >>> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: >>>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, >>>> DisplayPort and Display Clock Controller. >>>> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> >>>> --- >>> >>> [...] >>> >>>> + mdp_opp_table: opp-table { >>>> + compatible = "operating-points-v2"; >>>> + >>> >>> The computer tells me there's also a 156 MHz rate @ SVS_D1 >>> >>> Maybe Abhinav could chime in whether we should add it or not >>> >> >> Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for >> sm8650 and did not publish it in the dt. >> >> It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though >> LOW_SVS_D1 is present even on those. >> >> I think the reason could be that the displays being used on the reference >> boards will need a pixel clock of atleast >= low_svs and the MDP clock >> usually depends on the value of the DSI pixel clock (which has a fixed >> relationship to the byte clock) to maintain the data rate. So as a result >> perhaps even if we add it, for most displays this level will be unused. >> >> If we end up using displays which are so small that the pixel clock >> requirement will be even lower than low_svs, we can add those. >> >> OR as an alternative, we can leave this patch as it is and add the >> low_svs_d1 for all chipsets which support it together in another series that >> way it will have the full context of why we are adding it otherwise it will >> look odd again of why sm8550/sm8650 was left out but added in sm8750. > > I think it's better to describe hardware accurately, even if the > particular entry ends up being unused. I'd vote for this option. > >>> [...] >>> >>>> + mdss_dsi_opp_table: opp-table { >>>> + compatible = "operating-points-v2"; >>>> + >>> >>> Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd >>> with the decimals >> >> For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this >> voltage corner was somehow never used for DSI byte clock again I am thinking >> this is because for the display resolutions we use, we will always be >= >> low_svs so the low_svs_d1 will never hit even if we add it. > > Please add all voltage/frequency corners. Think about low-res DP or > low-res, low-rate WB. > Sounds good, lets go ahead and add all the voltage/freq corners. Like I noted, even for sm8550/sm8650 the low_svs_d1 was missed out, so if we are adding it for sm8750 now in this series, a follow up patch should also be sent to add them for sm8550/sm8650 as well. That way we will fix them all up together and this does not come across as a discrepancy.
On Sat, 3 May 2025 at 22:59, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > > On 5/2/2025 10:51 PM, Dmitry Baryshkov wrote: > > On Tue, Apr 29, 2025 at 04:07:24PM -0700, Abhinav Kumar wrote: > >> > >> > >> On 4/28/2025 2:31 PM, Konrad Dybcio wrote: > >>> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: > >>>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, > >>>> DisplayPort and Display Clock Controller. > >>>> > >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >>>> > >>>> --- > >>> > >>> [...] > >>> > >>>> + mdp_opp_table: opp-table { > >>>> + compatible = "operating-points-v2"; > >>>> + > >>> > >>> The computer tells me there's also a 156 MHz rate @ SVS_D1 > >>> > >>> Maybe Abhinav could chime in whether we should add it or not > >>> > >> > >> Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for > >> sm8650 and did not publish it in the dt. > >> > >> It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though > >> LOW_SVS_D1 is present even on those. > >> > >> I think the reason could be that the displays being used on the reference > >> boards will need a pixel clock of atleast >= low_svs and the MDP clock > >> usually depends on the value of the DSI pixel clock (which has a fixed > >> relationship to the byte clock) to maintain the data rate. So as a result > >> perhaps even if we add it, for most displays this level will be unused. > >> > >> If we end up using displays which are so small that the pixel clock > >> requirement will be even lower than low_svs, we can add those. > >> > >> OR as an alternative, we can leave this patch as it is and add the > >> low_svs_d1 for all chipsets which support it together in another series that > >> way it will have the full context of why we are adding it otherwise it will > >> look odd again of why sm8550/sm8650 was left out but added in sm8750. > > > > I think it's better to describe hardware accurately, even if the > > particular entry ends up being unused. I'd vote for this option. > > > >>> [...] > >>> > >>>> + mdss_dsi_opp_table: opp-table { > >>>> + compatible = "operating-points-v2"; > >>>> + > >>> > >>> Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd > >>> with the decimals > >> > >> For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this > >> voltage corner was somehow never used for DSI byte clock again I am thinking > >> this is because for the display resolutions we use, we will always be >= > >> low_svs so the low_svs_d1 will never hit even if we add it. > > > > Please add all voltage/frequency corners. Think about low-res DP or > > low-res, low-rate WB. > > > > Sounds good, lets go ahead and add all the voltage/freq corners. > > Like I noted, even for sm8550/sm8650 the low_svs_d1 was missed out, so > if we are adding it for sm8750 now in this series, a follow up patch > should also be sent to add them for sm8550/sm8650 as well. That way we > will fix them all up together and this does not come across as a > discrepancy. Abhinav, if you know a missing piece, please send a patch, fixing it.
On 5/3/2025 2:01 PM, Dmitry Baryshkov wrote: > On Sat, 3 May 2025 at 22:59, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: >> >> >> >> On 5/2/2025 10:51 PM, Dmitry Baryshkov wrote: >>> On Tue, Apr 29, 2025 at 04:07:24PM -0700, Abhinav Kumar wrote: >>>> >>>> >>>> On 4/28/2025 2:31 PM, Konrad Dybcio wrote: >>>>> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: >>>>>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, >>>>>> DisplayPort and Display Clock Controller. >>>>>> >>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>>>> >>>>>> --- >>>>> >>>>> [...] >>>>> >>>>>> + mdp_opp_table: opp-table { >>>>>> + compatible = "operating-points-v2"; >>>>>> + >>>>> >>>>> The computer tells me there's also a 156 MHz rate @ SVS_D1 >>>>> >>>>> Maybe Abhinav could chime in whether we should add it or not >>>>> >>>> >>>> Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for >>>> sm8650 and did not publish it in the dt. >>>> >>>> It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though >>>> LOW_SVS_D1 is present even on those. >>>> >>>> I think the reason could be that the displays being used on the reference >>>> boards will need a pixel clock of atleast >= low_svs and the MDP clock >>>> usually depends on the value of the DSI pixel clock (which has a fixed >>>> relationship to the byte clock) to maintain the data rate. So as a result >>>> perhaps even if we add it, for most displays this level will be unused. >>>> >>>> If we end up using displays which are so small that the pixel clock >>>> requirement will be even lower than low_svs, we can add those. >>>> >>>> OR as an alternative, we can leave this patch as it is and add the >>>> low_svs_d1 for all chipsets which support it together in another series that >>>> way it will have the full context of why we are adding it otherwise it will >>>> look odd again of why sm8550/sm8650 was left out but added in sm8750. >>> >>> I think it's better to describe hardware accurately, even if the >>> particular entry ends up being unused. I'd vote for this option. >>> >>>>> [...] >>>>> >>>>>> + mdss_dsi_opp_table: opp-table { >>>>>> + compatible = "operating-points-v2"; >>>>>> + >>>>> >>>>> Similarly there's a 140.63 MHz rate at SVS_D1, but it seems odd >>>>> with the decimals >>>> >>>> For this one, yes its true that LOW_SVS_D1 is 140.63Mhz for sm8750 but this >>>> voltage corner was somehow never used for DSI byte clock again I am thinking >>>> this is because for the display resolutions we use, we will always be >= >>>> low_svs so the low_svs_d1 will never hit even if we add it. >>> >>> Please add all voltage/frequency corners. Think about low-res DP or >>> low-res, low-rate WB. >>> >> >> Sounds good, lets go ahead and add all the voltage/freq corners. >> >> Like I noted, even for sm8550/sm8650 the low_svs_d1 was missed out, so >> if we are adding it for sm8750 now in this series, a follow up patch >> should also be sent to add them for sm8550/sm8650 as well. That way we >> will fix them all up together and this does not come across as a >> discrepancy. > > Abhinav, if you know a missing piece, please send a patch, fixing it. > Sure, I will send something next week to fix up the sm8550/sm8650 dtsi to add the missing opp tables unless someone beats me to it.
On 30/04/2025 09:46, Konrad Dybcio wrote: > On 4/30/25 1:07 AM, Abhinav Kumar wrote: >> >> >> On 4/28/2025 2:31 PM, Konrad Dybcio wrote: >>> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: >>>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, >>>> DisplayPort and Display Clock Controller. >>>> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> >>>> --- >>> >>> [...] >>> >>>> + mdp_opp_table: opp-table { >>>> + compatible = "operating-points-v2"; >>>> + >>> >>> The computer tells me there's also a 156 MHz rate @ SVS_D1 >>> >>> Maybe Abhinav could chime in whether we should add it or not >>> >> >> Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for sm8650 and did not publish it in the dt. >> >> It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though LOW_SVS_D1 is present even on those. >> >> I think the reason could be that the displays being used on the reference boards will need a pixel clock of atleast >= low_svs and the MDP clock usually depends on the value of the DSI pixel clock (which has a fixed relationship to the byte clock) to maintain the data rate. So as a result perhaps even if we add it, for most displays this level will be unused. >> >> If we end up using displays which are so small that the pixel clock requirement will be even lower than low_svs, we can add those. >> >> OR as an alternative, we can leave this patch as it is and add the low_svs_d1 for all chipsets which support it together in another series that way it will have the full context of why we are adding it otherwise it will look odd again of why sm8550/sm8650 was left out but added in sm8750. > > I would assume that with VRR even fancy panels at low refresh rate (in > the 1-5 Hz range) may make use of this, so I would be happy to go with > option 2 Corner cases, at least high frequency, was omitted intentionally because for example NOM_L1 simply cause hardware reboot. Something else is missing in rpmh, but I don't mind documenting all of them. Best regards, Krzysztof
On 05/05/2025 08:49, Krzysztof Kozlowski wrote: > On 30/04/2025 09:46, Konrad Dybcio wrote: >> On 4/30/25 1:07 AM, Abhinav Kumar wrote: >>> >>> >>> On 4/28/2025 2:31 PM, Konrad Dybcio wrote: >>>> On 4/24/25 3:04 PM, Krzysztof Kozlowski wrote: >>>>> Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, >>>>> DisplayPort and Display Clock Controller. >>>>> >>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>>> >>>>> --- >>>> >>>> [...] >>>> >>>>> + mdp_opp_table: opp-table { >>>>> + compatible = "operating-points-v2"; >>>>> + >>>> >>>> The computer tells me there's also a 156 MHz rate @ SVS_D1 >>>> >>>> Maybe Abhinav could chime in whether we should add it or not >>>> >>> >>> Yes I also see a 156Mhz for LOW_SVS_D1 but we had a similar entry even for sm8650 and did not publish it in the dt. >>> >>> It was present till sm8450.dtsi but dropped in sm8550/sm8650 even though LOW_SVS_D1 is present even on those. >>> >>> I think the reason could be that the displays being used on the reference boards will need a pixel clock of atleast >= low_svs and the MDP clock usually depends on the value of the DSI pixel clock (which has a fixed relationship to the byte clock) to maintain the data rate. So as a result perhaps even if we add it, for most displays this level will be unused. >>> >>> If we end up using displays which are so small that the pixel clock requirement will be even lower than low_svs, we can add those. >>> >>> OR as an alternative, we can leave this patch as it is and add the low_svs_d1 for all chipsets which support it together in another series that way it will have the full context of why we are adding it otherwise it will look odd again of why sm8550/sm8650 was left out but added in sm8750. >> >> I would assume that with VRR even fancy panels at low refresh rate (in >> the 1-5 Hz range) may make use of this, so I would be happy to go with >> option 2 > > Corner cases, at least high frequency, was omitted intentionally because > for example NOM_L1 simply cause hardware reboot. Something else is > missing in rpmh, but I don't mind documenting all of them. Lower frequencies work, so I will include them. Best regards, Krzysztof
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi index 30ee98567b6078e8225142f2e13b25b5f35a3038..753b069cab1de636a3b1108747f300bec0f33980 100644 --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi @@ -3,7 +3,9 @@ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved. */ +#include <dt-bindings/clock/qcom,dsi-phy-28nm.h> #include <dt-bindings/clock/qcom,rpmh.h> +#include <dt-bindings/clock/qcom,sm8750-dispcc.h> #include <dt-bindings/clock/qcom,sm8750-gcc.h> #include <dt-bindings/clock/qcom,sm8750-tcsr.h> #include <dt-bindings/dma/qcom-gpi.h> @@ -2585,6 +2587,419 @@ data-pins { }; }; + mdss: display-subsystem@ae00000 { + compatible = "qcom,sm8750-mdss"; + reg = <0x0 0x0ae00000 0x0 0x1000>; + reg-names = "mdss"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + + resets = <&dispcc DISP_CC_MDSS_CORE_BCR>; + + interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>; + interconnect-names = "mdp0-mem", + "cpu-cfg"; + + power-domains = <&dispcc MDSS_GDSC>; + + iommus = <&apps_smmu 0x800 0x2>; + + interrupt-controller; + #interrupt-cells = <1>; + + #address-cells = <2>; + #size-cells = <2>; + ranges; + + status = "disabled"; + + mdss_mdp: display-controller@ae01000 { + compatible = "qcom,sm8750-dpu"; + reg = <0 0x0ae01000 0 0x93000>, + <0 0x0aeb0000 0 0x2008>; + reg-names = "mdp", + "vbif"; + + interrupts-extended = <&mdss 0>; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss_dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + + dpu_intf2_out: endpoint { + remote-endpoint = <&mdss_dsi1_in>; + }; + }; + + port@2 { + reg = <2>; + + dpu_intf0_out: endpoint { + remote-endpoint = <&mdss_dp0_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-207000000 { + opp-hz = /bits/ 64 <207000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-337000000 { + opp-hz = /bits/ 64 <337000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-417000000 { + opp-hz = /bits/ 64 <417000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-532000000 { + opp-hz = /bits/ 64 <532000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + + opp-575000000 { + opp-hz = /bits/ 64 <575000000>; + required-opps = <&rpmhpd_opp_nom_l1>; + }; + }; + }; + + mdss_dsi0: dsi@ae94000 { + compatible = "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0 0x0ae94000 0x0 0x400>; + reg-names = "dsi_ctrl"; + + interrupts-extended = <&mdss 4>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK>, + <&dispcc DISP_CC_MDSS_ESC0_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>, + <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>, + <&dispcc DISP_CC_ESYNC0_CLK>, + <&dispcc DISP_CC_OSC_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus", + "dsi_pll_pixel", + "dsi_pll_byte", + "esync", + "osc", + "byte_src", + "pixel_src"; + + operating-points-v2 = <&mdss_dsi_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&mdss_dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dsi0_out: endpoint { + }; + }; + }; + + mdss_dsi_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-187500000 { + opp-hz = /bits/ 64 <187500000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-358000000 { + opp-hz = /bits/ 64 <358000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + }; + }; + + mdss_dsi0_phy: phy@ae95000 { + compatible = "qcom,sm8750-dsi-phy-3nm"; + reg = <0x0 0x0ae95000 0x0 0x200>, + <0x0 0x0ae95200 0x0 0x280>, + <0x0 0x0ae95500 0x0 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&bi_tcxo_div2>; + clock-names = "iface", + "ref"; + + #clock-cells = <1>; + #phy-cells = <0>; + + status = "disabled"; + }; + + mdss_dsi1: dsi@ae96000 { + compatible = "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0 0x0ae96000 0x0 0x400>; + reg-names = "dsi_ctrl"; + + interrupts-extended = <&mdss 5>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>, + <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK1_CLK>, + <&dispcc DISP_CC_MDSS_ESC1_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>; + assigned-clock-parents = <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>, + <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>; + + operating-points-v2 = <&mdss_dsi_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&mdss_dsi1_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dsi1_in: endpoint { + remote-endpoint = <&dpu_intf2_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dsi1_out: endpoint { + }; + }; + }; + }; + + mdss_dsi1_phy: phy@ae97000 { + compatible = "qcom,sm8750-dsi-phy-3nm"; + reg = <0x0 0x0ae97000 0x0 0x200>, + <0x0 0x0ae97200 0x0 0x280>, + <0x0 0x0ae97500 0x0 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", + "ref"; + + #clock-cells = <1>; + #phy-cells = <0>; + + status = "disabled"; + }; + + mdss_dp0: displayport-controller@af54000 { + compatible = "qcom,sm8750-dp", "qcom,sm8650-dp"; + reg = <0x0 0xaf54000 0x0 0x104>, + <0x0 0xaf54200 0x0 0xc0>, + <0x0 0xaf55000 0x0 0x770>, + <0x0 0xaf56000 0x0 0x9c>, + <0x0 0xaf57000 0x0 0x9c>; + + interrupts-extended = <&mdss 12>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>, + <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>, + <&dispcc DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>, + <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK>; + clock-names = "core_iface", + "core_aux", + "ctrl_link", + "ctrl_link_iface", + "stream_pixel"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>, + <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>; + assigned-clock-parents = <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>, + <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>; + + operating-points-v2 = <&dp_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>; + phy-names = "dp"; + + #sound-dai-cells = <0>; + + status = "disabled"; + + dp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-192000000 { + opp-hz = /bits/ 64 <192000000>; + required-opps = <&rpmhpd_opp_low_svs_d1>; + }; + + opp-270000000 { + opp-hz = /bits/ 64 <270000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-540000000 { + opp-hz = /bits/ 64 <540000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-810000000 { + opp-hz = /bits/ 64 <810000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dp0_in: endpoint { + remote-endpoint = <&dpu_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dp0_out: endpoint { + }; + }; + }; + }; + }; + + dispcc: clock-controller@af00000 { + compatible = "qcom,sm8750-dispcc"; + reg = <0 0x0af00000 0 0x20000>; + + clocks = <&bi_tcxo_div2>, + <&bi_tcxo_ao_div2>, + <&gcc GCC_DISP_AHB_CLK>, + <&sleep_clk>, + <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>, + <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>, + <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>, + <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>, + <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>, + <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>, + <0>, /* dp1 */ + <0>, + <0>, /* dp2 */ + <0>, + <0>, /* dp3 */ + <0>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + required-opps = <&rpmhpd_opp_low_svs>; + + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + usb_1_hsphy: phy@88e3000 { compatible = "qcom,sm8750-m31-eusb2-phy"; reg = <0x0 0x88e3000 0x0 0x29c>;
Add device nodes for entire display: MDSS, DPU, DSI, DSI PHYs, DisplayPort and Display Clock Controller. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- Bindings (dtbs_check dependency): https://lore.kernel.org/r/20250311-b4-sm8750-display-v4-0-da6b3e959c76@linaro.org/ --- arch/arm64/boot/dts/qcom/sm8750.dtsi | 415 +++++++++++++++++++++++++++++++++++ 1 file changed, 415 insertions(+)