Message ID | 20230624-sm6125-dpu-v1-0-1d5a638cebf2@somainline.org (mailing list archive) |
---|---|
Headers | show |
Series | drm/msm: Add SM6125 MDSS/DPU hardware and enable Sony Xperia 10 II panel | expand |
On 24.06.2023 02:40, Marijn Suijten wrote: > Bring up the SM6125 DPU now that all preliminary series (such as INTF > TE) have been merged (for me to test the hardware properly) We should not repeat the same mistake in the future.. Finding a balance between releasing early and releasing what we can declare working and tested code is hard, but we waaaaaaaay overstayed on this one.. Konrad , and most > other conflicting work (barring ongoing catalog *improvements*) has made > its way in as well or is still being discussed. > > The second part of the series complements that by immediately utilizing > this hardware in DT, and even enabling the MDSS/DSI nodes complete with > a 6.0" 1080x2520 panel for Sony's Seine PDX201 (Xperia 10 II). > > The last patch ("sm6125-seine: Configure MDSS, DSI and panel") depends > on (an impending v2 of) my Sony panel collection series [1]. > > [1]: https://lore.kernel.org/linux-arm-msm/20230521-drm-panels-sony-v1-0-541c341d6bee@somainline.org/ > > --- > Marijn Suijten (15): > arm64: dts: qcom: sm6125: Sort spmi_bus node numerically by reg > dt-bindings: clock: qcom,dispcc-sm6125: Remove unused GCC_DISP_AHB_CLK > dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock > dt-bindings: clock: qcom,dispcc-sm6125: Allow power-domains property > dt-bindings: display/msm: dsi-controller-main: Document SM6125 > dt-bindings: display/msm: sc7180-dpu: Describe SM6125 > dt-bindings: display/msm: Add SM6125 MDSS > drm/msm/dpu: Add SM6125 support > drm/msm/mdss: Add SM6125 support > dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant > drm/msm/dsi: Add 14nm phy configuration for SM6125 > arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock > arm64: dts: qcom: sm6125: Add dispcc node > arm64: dts: qcom: sm6125: Add display hardware nodes > arm64: dts: qcom: sm6125-seine: Configure MDSS, DSI and panel > > .../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +- > .../bindings/display/msm/dsi-controller-main.yaml | 2 + > .../bindings/display/msm/dsi-phy-14nm.yaml | 1 + > .../bindings/display/msm/qcom,sc7180-dpu.yaml | 1 + > .../bindings/display/msm/qcom,sm6125-mdss.yaml | 206 +++++++++++++++++ > .../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 +++++ > arch/arm64/boot/dts/qcom/sm6125.dtsi | 244 +++++++++++++++++++-- > .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 173 +++++++++++++++ > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 15 ++ > drivers/gpu/drm/msm/msm_mdss.c | 8 + > 15 files changed, 712 insertions(+), 25 deletions(-) > --- > base-commit: 8d2be868b42c08290509c60515865f4de24ea704 > change-id: 20230624-sm6125-dpu-aedc9637ee7b > > Best regards,
On 2023-06-24 03:42:46, Konrad Dybcio wrote: > On 24.06.2023 02:40, Marijn Suijten wrote: > > Bring up the SM6125 DPU now that all preliminary series (such as INTF > > TE) have been merged (for me to test the hardware properly) > We should not repeat the same mistake in the future.. Finding a > balance between releasing early and releasing what we can declare > working and tested code is hard, but we waaaaaaaay overstayed on > this one.. I don't understand what you mean by "mistake" at all. Yes the DPU catalog portion of this series sat in my local branch for a very long time. Yes it had to be rebased on top of conflicts many many times. However, that time has also been used to fix and extend DPU where necessary, instead of submitting a half-broken or half-incomplete catalog entry... Re "we overstayed": you could have asked to clean up and send my patch, so I don't take this as a mistake on my part as you are completely aware of my time schedule ;) > Konrad > , and most Also here, don't forget to re-quote my message if you break half-way in the line. > > other conflicting work (barring ongoing catalog *improvements*) has made > > its way in as well or is still being discussed. > > > > > The second part of the series complements that by immediately utilizing > > this hardware in DT, and even enabling the MDSS/DSI nodes complete with > > a 6.0" 1080x2520 panel for Sony's Seine PDX201 (Xperia 10 II). > > > > The last patch ("sm6125-seine: Configure MDSS, DSI and panel") depends > > on (an impending v2 of) my Sony panel collection series [1]. > > > > [1]: https://lore.kernel.org/linux-arm-msm/20230521-drm-panels-sony-v1-0-541c341d6bee@somainline.org/ > > > > --- > > Marijn Suijten (15): > > arm64: dts: qcom: sm6125: Sort spmi_bus node numerically by reg > > dt-bindings: clock: qcom,dispcc-sm6125: Remove unused GCC_DISP_AHB_CLK > > dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock > > dt-bindings: clock: qcom,dispcc-sm6125: Allow power-domains property > > dt-bindings: display/msm: dsi-controller-main: Document SM6125 > > dt-bindings: display/msm: sc7180-dpu: Describe SM6125 > > dt-bindings: display/msm: Add SM6125 MDSS > > drm/msm/dpu: Add SM6125 support > > drm/msm/mdss: Add SM6125 support > > dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant > > drm/msm/dsi: Add 14nm phy configuration for SM6125 > > arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock > > arm64: dts: qcom: sm6125: Add dispcc node > > arm64: dts: qcom: sm6125: Add display hardware nodes > > arm64: dts: qcom: sm6125-seine: Configure MDSS, DSI and panel > > > > .../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +- > > .../bindings/display/msm/dsi-controller-main.yaml | 2 + > > .../bindings/display/msm/dsi-phy-14nm.yaml | 1 + > > .../bindings/display/msm/qcom,sc7180-dpu.yaml | 1 + > > .../bindings/display/msm/qcom,sm6125-mdss.yaml | 206 +++++++++++++++++ > > .../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 +++++ > > arch/arm64/boot/dts/qcom/sm6125.dtsi | 244 +++++++++++++++++++-- > > .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 173 +++++++++++++++ > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 + > > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + > > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + > > drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 15 ++ > > drivers/gpu/drm/msm/msm_mdss.c | 8 + > > 15 files changed, 712 insertions(+), 25 deletions(-) > > --- > > base-commit: 8d2be868b42c08290509c60515865f4de24ea704 > > change-id: 20230624-sm6125-dpu-aedc9637ee7b > > > > Best regards,
On 25.06.2023 21:18, Marijn Suijten wrote: > On 2023-06-24 03:42:46, Konrad Dybcio wrote: >> On 24.06.2023 02:40, Marijn Suijten wrote: >>> Bring up the SM6125 DPU now that all preliminary series (such as INTF >>> TE) have been merged (for me to test the hardware properly) >> We should not repeat the same mistake in the future.. Finding a >> balance between releasing early and releasing what we can declare >> working and tested code is hard, but we waaaaaaaay overstayed on >> this one.. > > I don't understand what you mean by "mistake" at all. Yes the DPU > catalog portion of this series sat in my local branch for a very long > time. Yes it had to be rebased on top of conflicts many many times. > > However, that time has also been used to fix and extend DPU where > necessary, instead of submitting a half-broken or half-incomplete > catalog entry... > > Re "we overstayed": you could have asked to clean up and send my patch, > so I don't take this as a mistake on my part as you are completely aware > of my time schedule ;) I didn't mean to pick on you. I just wanted to emphasize that a more upstream-forward approach would have saved us quite some time on the rebasing and cleaning-up front. > >> Konrad >> , and most > > Also here, don't forget to re-quote my message if you break half-way in > the line. Ugh. All the time I've been doing this I thought thunderfox was smart enough to do it for me. Apparently not and you're the 1st one to point that out. Konrad > >>> other conflicting work (barring ongoing catalog *improvements*) has made >>> its way in as well or is still being discussed. >> >>> >>> The second part of the series complements that by immediately utilizing >>> this hardware in DT, and even enabling the MDSS/DSI nodes complete with >>> a 6.0" 1080x2520 panel for Sony's Seine PDX201 (Xperia 10 II). >>> >>> The last patch ("sm6125-seine: Configure MDSS, DSI and panel") depends >>> on (an impending v2 of) my Sony panel collection series [1]. >>> >>> [1]: https://lore.kernel.org/linux-arm-msm/20230521-drm-panels-sony-v1-0-541c341d6bee@somainline.org/ >>> >>> --- >>> Marijn Suijten (15): >>> arm64: dts: qcom: sm6125: Sort spmi_bus node numerically by reg >>> dt-bindings: clock: qcom,dispcc-sm6125: Remove unused GCC_DISP_AHB_CLK >>> dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock >>> dt-bindings: clock: qcom,dispcc-sm6125: Allow power-domains property >>> dt-bindings: display/msm: dsi-controller-main: Document SM6125 >>> dt-bindings: display/msm: sc7180-dpu: Describe SM6125 >>> dt-bindings: display/msm: Add SM6125 MDSS >>> drm/msm/dpu: Add SM6125 support >>> drm/msm/mdss: Add SM6125 support >>> dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant >>> drm/msm/dsi: Add 14nm phy configuration for SM6125 >>> arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock >>> arm64: dts: qcom: sm6125: Add dispcc node >>> arm64: dts: qcom: sm6125: Add display hardware nodes >>> arm64: dts: qcom: sm6125-seine: Configure MDSS, DSI and panel >>> >>> .../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +- >>> .../bindings/display/msm/dsi-controller-main.yaml | 2 + >>> .../bindings/display/msm/dsi-phy-14nm.yaml | 1 + >>> .../bindings/display/msm/qcom,sc7180-dpu.yaml | 1 + >>> .../bindings/display/msm/qcom,sm6125-mdss.yaml | 206 +++++++++++++++++ >>> .../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 +++++ >>> arch/arm64/boot/dts/qcom/sm6125.dtsi | 244 +++++++++++++++++++-- >>> .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 173 +++++++++++++++ >>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 + >>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 + >>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 + >>> drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + >>> drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + >>> drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 15 ++ >>> drivers/gpu/drm/msm/msm_mdss.c | 8 + >>> 15 files changed, 712 insertions(+), 25 deletions(-) >>> --- >>> base-commit: 8d2be868b42c08290509c60515865f4de24ea704 >>> change-id: 20230624-sm6125-dpu-aedc9637ee7b >>> >>> Best regards,
On 2023-06-26 11:41:39, Konrad Dybcio wrote: > On 25.06.2023 21:18, Marijn Suijten wrote: > > On 2023-06-24 03:42:46, Konrad Dybcio wrote: > >> On 24.06.2023 02:40, Marijn Suijten wrote: > >>> Bring up the SM6125 DPU now that all preliminary series (such as INTF > >>> TE) have been merged (for me to test the hardware properly) > >> We should not repeat the same mistake in the future.. Finding a > >> balance between releasing early and releasing what we can declare > >> working and tested code is hard, but we waaaaaaaay overstayed on > >> this one.. > > > > I don't understand what you mean by "mistake" at all. Yes the DPU > > catalog portion of this series sat in my local branch for a very long > > time. Yes it had to be rebased on top of conflicts many many times. > > > > However, that time has also been used to fix and extend DPU where > > necessary, instead of submitting a half-broken or half-incomplete > > catalog entry... > > > > Re "we overstayed": you could have asked to clean up and send my patch, > > so I don't take this as a mistake on my part as you are completely aware > > of my time schedule ;) > I didn't mean to pick on you. I just wanted to emphasize that a more > upstream-forward approach would have saved us quite some time on the > rebasing and cleaning-up front. That is how it comes across ;) - our dream is all about upstream-first but as you know this becomes a mess really quickly when things are blocked on dependencies and you're working on 5 different features and testing across ±8 different Sony platforms on ±14 different devices at once... all in a limited portion of free time. Fwiw cleaning-up would have had to happen either way, and would have taken the same amount of time regardless of whether this series is submitted now or two months ago. > >> Konrad > >> , and most > > > > Also here, don't forget to re-quote my message if you break half-way in > > the line. > Ugh. All the time I've been doing this I thought thunderfox was smart > enough to do it for me. Apparently not and you're the 1st one to point > that out. You're welcome! (Though I thought it should be visible in Thunderburd, unless you're not in plaintext mode? Does it still show the "this is quoted" line in front of the broken sentence?) - Marijn
On 26.06.2023 16:17, Marijn Suijten wrote: > On 2023-06-26 11:41:39, Konrad Dybcio wrote: >> On 25.06.2023 21:18, Marijn Suijten wrote: >>> On 2023-06-24 03:42:46, Konrad Dybcio wrote: >>>> On 24.06.2023 02:40, Marijn Suijten wrote: >>>>> Bring up the SM6125 DPU now that all preliminary series (such as INTF >>>>> TE) have been merged (for me to test the hardware properly) >>>> We should not repeat the same mistake in the future.. Finding a >>>> balance between releasing early and releasing what we can declare >>>> working and tested code is hard, but we waaaaaaaay overstayed on >>>> this one.. >>> >>> I don't understand what you mean by "mistake" at all. Yes the DPU >>> catalog portion of this series sat in my local branch for a very long >>> time. Yes it had to be rebased on top of conflicts many many times. >>> >>> However, that time has also been used to fix and extend DPU where >>> necessary, instead of submitting a half-broken or half-incomplete >>> catalog entry... >>> >>> Re "we overstayed": you could have asked to clean up and send my patch, >>> so I don't take this as a mistake on my part as you are completely aware >>> of my time schedule ;) >> I didn't mean to pick on you. I just wanted to emphasize that a more >> upstream-forward approach would have saved us quite some time on the >> rebasing and cleaning-up front. > > That is how it comes across ;) - our dream is all about upstream-first > but as you know this becomes a mess really quickly when things are > blocked on dependencies and you're working on 5 different features and > testing across ±8 different Sony platforms on ±14 different devices at > once... all in a limited portion of free time. > > Fwiw cleaning-up would have had to happen either way, and would have > taken the same amount of time regardless of whether this series is > submitted now or two months ago. > >>>> Konrad >>>> , and most >>> >>> Also here, don't forget to re-quote my message if you break half-way in >>> the line. >> Ugh. All the time I've been doing this I thought thunderfox was smart >> enough to do it for me. Apparently not and you're the 1st one to point >> that out. > > You're welcome! > (Though I thought it should be visible in Thunderburd, unless you're not > in plaintext mode? Does it still show the "this is quoted" line in > front of the broken sentence?) It doesn't, but the text stays blue (as if it was) Konrad > > - Marijn