| Message ID | 20230118082048.2198715-1-dmitry.baryshkov@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] arm64: dts: qcom: add device tree for DB845c working in dual DSI mode | expand |
On Wed, Jan 18, 2023 at 08:47:53PM +0200, Dmitry Baryshkov wrote: > 18 января 2023 г. 19:32:42 GMT+02:00, Bjorn Andersson <andersson@kernel.org> пишет: > >On Wed, Jan 18, 2023 at 10:20:48AM +0200, Dmitry Baryshkov wrote: > >> While we are testing the DB845c working in dual DSI mode (which is > >> required for the 4k support), create a separate device tree using this > >> configuration. > >> > > > >I don't think it's right to change the DTB on your device depending on > >your TV's ability to do 4k or not... > > > >I ran into this problem when playing around with 4k-support on the RB3 > >as well a while back. I was not able to figure out a way to run the > >lt9611 off two inputs for the lower resolutions and ended never posted > >anything because I couldn't come up with any good solution. > > > This is implemented with the latest lt9611 patchset, referenced in the patch annotation. > > I posted this as an RFC with the separate dts to let people test dual DSI, DPU wide planes, etc. and to compare that with plain old single link DSI/lt9611. > > > > > > >Would it be possible somehow to describe the two ports in DT, but have > >the display driver use one or both depending on the number of inputs > >needed by the lt9611? > > This would be very problemsome. Even switching the number of lanes > goes against the standard and is not supported by Linux kernel. > Supporting switching the host off and on would be a real troublle. > Does this imply that switching resolution in runtime is not possible for any of these DSI->HDMI/DP/eDP bridges? The immediate worry is that we need 4k and non-4k variants of every mezzanine (unless we start doing overlays). But beyond that I still don't like the fact that you need to change firmware depending on which monitor/TV you're going to connect the board to. (And with the current boot.img-based design, this is overly cumbersome) Regards, Bjorn > Hopefully, this is is not necessary. > > > > >Regards, > >Bjorn > > > >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > >> --- > >> > >> Dependencies to be able to verify the 4k@30 mode: > >> [1] https://lore.kernel.org/linux-arm-msm/20221229191856.3508092-1-dmitry.baryshkov@linaro.org/ > >> [2] https://lore.kernel.org/dri-devel/20230118081658.2198520-1-dmitry.baryshkov@linaro.org/ > >> > >> --- > >> arch/arm64/boot/dts/qcom/Makefile | 1 + > >> .../boot/dts/qcom/sdm845-db845c-dual-dsi.dts | 48 +++++++++++++++++++ > >> 2 files changed, 49 insertions(+) > >> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts > >> > >> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile > >> index 3e79496292e7..dc55c3b989a4 100644 > >> --- a/arch/arm64/boot/dts/qcom/Makefile > >> +++ b/arch/arm64/boot/dts/qcom/Makefile > >> @@ -139,6 +139,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb > >> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb > >> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb > >> dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb > >> +dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-dual-dsi.dtb > >> dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtb > >> dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyln.dtb > >> dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyp.dtb > >> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts b/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts > >> new file mode 100644 > >> index 000000000000..4a366dedc841 > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts > >> @@ -0,0 +1,48 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * Copyright (c) 2023, Linaro Ltd. > >> + */ > >> + > >> +#include "sdm845-db845c.dts" > >> + > >> +&dsi0 { > >> + qcom,dual-dsi-mode; > >> + qcom,master-dsi; > >> +}; > >> + > >> +&dsi1 { > >> + vdda-supply = <&vreg_l26a_1p2>; > >> + > >> + qcom,dual-dsi-mode; > >> + > >> + /* DSI1 is slave, so use DSI0 clocks */ > >> + assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; > >> + > >> + status = "okay"; > >> + > >> + ports { > >> + port@1 { > >> + endpoint { > >> + remote-endpoint = <<9611_b>; > >> + data-lanes = <0 1 2 3>; > >> + }; > >> + }; > >> + }; > >> +}; > >> + > >> +&dsi1_phy { > >> + vdds-supply = <&vreg_l1a_0p875>; > >> + status = "okay"; > >> +}; > >> + > >> +<9611_codec { > >> + ports { > >> + port@1 { > >> + reg = <1>; > >> + > >> + lt9611_b: endpoint { > >> + remote-endpoint = <&dsi1_out>; > >> + }; > >> + }; > >> + }; > >> +}; > >> -- > >> 2.39.0 > >> >
On 07/04/2023 19:48, Bjorn Andersson wrote: > On Wed, Jan 18, 2023 at 08:47:53PM +0200, Dmitry Baryshkov wrote: >> 18 января 2023 г. 19:32:42 GMT+02:00, Bjorn Andersson <andersson@kernel.org> пишет: >>> On Wed, Jan 18, 2023 at 10:20:48AM +0200, Dmitry Baryshkov wrote: >>>> While we are testing the DB845c working in dual DSI mode (which is >>>> required for the 4k support), create a separate device tree using this >>>> configuration. >>>> >>> >>> I don't think it's right to change the DTB on your device depending on >>> your TV's ability to do 4k or not... >>> >>> I ran into this problem when playing around with 4k-support on the RB3 >>> as well a while back. I was not able to figure out a way to run the >>> lt9611 off two inputs for the lower resolutions and ended never posted >>> anything because I couldn't come up with any good solution. >> >> >> This is implemented with the latest lt9611 patchset, referenced in the patch annotation. >> >> I posted this as an RFC with the separate dts to let people test dual DSI, DPU wide planes, etc. and to compare that with plain old single link DSI/lt9611. >> >>> >>> >>> Would it be possible somehow to describe the two ports in DT, but have >>> the display driver use one or both depending on the number of inputs >>> needed by the lt9611? >> >> This would be very problemsome. Even switching the number of lanes >> goes against the standard and is not supported by Linux kernel. >> Supporting switching the host off and on would be a real troublle. >> > > Does this imply that switching resolution in runtime is not possible for > any of these DSI->HDMI/DP/eDP bridges? > > The immediate worry is that we need 4k and non-4k variants of every > mezzanine (unless we start doing overlays). But beyond that I still > don't like the fact that you need to change firmware depending on which > monitor/TV you're going to connect the board to. (And with the current > boot.img-based design, this is overly cumbersome) No. With the latest lt9611 driver and with the current msm/msm-next it should not be necessary to have a separate dtsi. I submitted this patch as an RFC to let people compare 2xDSI vs single-link cases. Currently I'm happy with the way it works, so I can probably send this as a patch to main sdm845-db845c.dtb. As a background info: - lt9611 driver can utilize either one or two DSI links - drm/msm can output 4k over two DSI links in bonded mode. - drm/msm will still utilize two DSI links for smaller resolutions (switching between single and bonded DSI modes doesn't seem practical). - If just one DSI link is supplied, 1080p is the maximum resolution that can be supported. > Regards, > Bjorn > >> Hopefully, this is is not necessary. >> >>> >>> Regards, >>> Bjorn >>> >>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >>>> --- >>>> >>>> Dependencies to be able to verify the 4k@30 mode: >>>> [1] https://lore.kernel.org/linux-arm-msm/20221229191856.3508092-1-dmitry.baryshkov@linaro.org/ >>>> [2] https://lore.kernel.org/dri-devel/20230118081658.2198520-1-dmitry.baryshkov@linaro.org/ >>>> >>>> --- >>>> arch/arm64/boot/dts/qcom/Makefile | 1 + >>>> .../boot/dts/qcom/sdm845-db845c-dual-dsi.dts | 48 +++++++++++++++++++ >>>> 2 files changed, 49 insertions(+) >>>> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts >>>> >>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile >>>> index 3e79496292e7..dc55c3b989a4 100644 >>>> --- a/arch/arm64/boot/dts/qcom/Makefile >>>> +++ b/arch/arm64/boot/dts/qcom/Makefile >>>> @@ -139,6 +139,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb >>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb >>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb >>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb >>>> +dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-dual-dsi.dtb >>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtb >>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyln.dtb >>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyp.dtb >>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts b/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts >>>> new file mode 100644 >>>> index 000000000000..4a366dedc841 >>>> --- /dev/null >>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts >>>> @@ -0,0 +1,48 @@ >>>> +// SPDX-License-Identifier: GPL-2.0 >>>> +/* >>>> + * Copyright (c) 2023, Linaro Ltd. >>>> + */ >>>> + >>>> +#include "sdm845-db845c.dts" >>>> + >>>> +&dsi0 { >>>> + qcom,dual-dsi-mode; >>>> + qcom,master-dsi; >>>> +}; >>>> + >>>> +&dsi1 { >>>> + vdda-supply = <&vreg_l26a_1p2>; >>>> + >>>> + qcom,dual-dsi-mode; >>>> + >>>> + /* DSI1 is slave, so use DSI0 clocks */ >>>> + assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; >>>> + >>>> + status = "okay"; >>>> + >>>> + ports { >>>> + port@1 { >>>> + endpoint { >>>> + remote-endpoint = <<9611_b>; >>>> + data-lanes = <0 1 2 3>; >>>> + }; >>>> + }; >>>> + }; >>>> +}; >>>> + >>>> +&dsi1_phy { >>>> + vdds-supply = <&vreg_l1a_0p875>; >>>> + status = "okay"; >>>> +}; >>>> + >>>> +<9611_codec { >>>> + ports { >>>> + port@1 { >>>> + reg = <1>; >>>> + >>>> + lt9611_b: endpoint { >>>> + remote-endpoint = <&dsi1_out>; >>>> + }; >>>> + }; >>>> + }; >>>> +}; >>>> -- >>>> 2.39.0 >>>> >>
On Fri, Apr 07, 2023 at 08:09:23PM +0300, Dmitry Baryshkov wrote: > On 07/04/2023 19:48, Bjorn Andersson wrote: > > On Wed, Jan 18, 2023 at 08:47:53PM +0200, Dmitry Baryshkov wrote: > > > 18 января 2023 г. 19:32:42 GMT+02:00, Bjorn Andersson <andersson@kernel.org> пишет: > > > > On Wed, Jan 18, 2023 at 10:20:48AM +0200, Dmitry Baryshkov wrote: > > > > > While we are testing the DB845c working in dual DSI mode (which is > > > > > required for the 4k support), create a separate device tree using this > > > > > configuration. > > > > > > > > > > > > > I don't think it's right to change the DTB on your device depending on > > > > your TV's ability to do 4k or not... > > > > > > > > I ran into this problem when playing around with 4k-support on the RB3 > > > > as well a while back. I was not able to figure out a way to run the > > > > lt9611 off two inputs for the lower resolutions and ended never posted > > > > anything because I couldn't come up with any good solution. > > > > > > > > > This is implemented with the latest lt9611 patchset, referenced in the patch annotation. > > > > > > I posted this as an RFC with the separate dts to let people test dual DSI, DPU wide planes, etc. and to compare that with plain old single link DSI/lt9611. > > > > > > > > > > > > > > > Would it be possible somehow to describe the two ports in DT, but have > > > > the display driver use one or both depending on the number of inputs > > > > needed by the lt9611? > > > > > > This would be very problemsome. Even switching the number of lanes > > > goes against the standard and is not supported by Linux kernel. > > > Supporting switching the host off and on would be a real troublle. > > > > > > > Does this imply that switching resolution in runtime is not possible for > > any of these DSI->HDMI/DP/eDP bridges? > > > > The immediate worry is that we need 4k and non-4k variants of every > > mezzanine (unless we start doing overlays). But beyond that I still > > don't like the fact that you need to change firmware depending on which > > monitor/TV you're going to connect the board to. (And with the current > > boot.img-based design, this is overly cumbersome) > No. With the latest lt9611 driver and with the current msm/msm-next it > should not be necessary to have a separate dtsi. I submitted this patch as > an RFC to let people compare 2xDSI vs single-link cases. Currently I'm happy > with the way it works, so I can probably send this as a patch to main > sdm845-db845c.dtb. > > As a background info: > - lt9611 driver can utilize either one or two DSI links > - drm/msm can output 4k over two DSI links in bonded mode. > - drm/msm will still utilize two DSI links for smaller resolutions > (switching between single and bonded DSI modes doesn't seem practical). > - If just one DSI link is supplied, 1080p is the maximum resolution that can > be supported. > Sorry, I missed your reply earlier. If we can run the lower resolutions off two bonded DSI I think we should make that the default configuration - it's just that when I tried it a few years ago I had problems getting a working output... But much has changed since then. There is a dip switch to allow one of the DSI links to be passed onto one of the HS-connectors, but for anyone to use that they would need a mezzaine dts anyways, so they can unbond the DSIs there. Regards, Bjorn
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile index 3e79496292e7..dc55c3b989a4 100644 --- a/arch/arm64/boot/dts/qcom/Makefile +++ b/arch/arm64/boot/dts/qcom/Makefile @@ -139,6 +139,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb +dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-dual-dsi.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c-navigation-mezzanine.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyln.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-lg-judyp.dtb diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts b/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts new file mode 100644 index 000000000000..4a366dedc841 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts @@ -0,0 +1,48 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2023, Linaro Ltd. + */ + +#include "sdm845-db845c.dts" + +&dsi0 { + qcom,dual-dsi-mode; + qcom,master-dsi; +}; + +&dsi1 { + vdda-supply = <&vreg_l26a_1p2>; + + qcom,dual-dsi-mode; + + /* DSI1 is slave, so use DSI0 clocks */ + assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; + + status = "okay"; + + ports { + port@1 { + endpoint { + remote-endpoint = <<9611_b>; + data-lanes = <0 1 2 3>; + }; + }; + }; +}; + +&dsi1_phy { + vdds-supply = <&vreg_l1a_0p875>; + status = "okay"; +}; + +<9611_codec { + ports { + port@1 { + reg = <1>; + + lt9611_b: endpoint { + remote-endpoint = <&dsi1_out>; + }; + }; + }; +};
While we are testing the DB845c working in dual DSI mode (which is required for the 4k support), create a separate device tree using this configuration. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Dependencies to be able to verify the 4k@30 mode: [1] https://lore.kernel.org/linux-arm-msm/20221229191856.3508092-1-dmitry.baryshkov@linaro.org/ [2] https://lore.kernel.org/dri-devel/20230118081658.2198520-1-dmitry.baryshkov@linaro.org/ --- arch/arm64/boot/dts/qcom/Makefile | 1 + .../boot/dts/qcom/sdm845-db845c-dual-dsi.dts | 48 +++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sdm845-db845c-dual-dsi.dts