mbox series

[v12,00/18] drm: Add Samsung MIPI DSIM bridge

Message ID 20230126144427.607098-1-jagan@amarulasolutions.com
Headers show
Series drm: Add Samsung MIPI DSIM bridge | expand

Message

Jagan Teki Jan. 26, 2023, 2:44 p.m. UTC
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.

Patch 0001 - 0004: adding devm_drm_of_dsi_get_bridge

Patch 0005 - 0006: optional PHY, PMS_P offset

Patch 0007       : introduce hw_type

Patch 0008	 : fixing host init

Patch 0009	 : atomic_check

Patch 0010	 : input_bus_flags

Patch 0011	 : atomic_get_input_bus_fmts

Patch 0012 - 0013: component vs bridge

Patch 0014	 : DSIM bridge

Patch 0015 - 0016: i.MX8M Mini/Nano

Patch 0017 - 0018: i.MX8M Plus

Changes for v12:
- collect RB from Marek V
- add te_irq_handler hook
- fix comments from Marek V
- update atomic_get_input_bus_fmts logic

Changes for v11:
- collect RB from Frieder Schrempf
- collect ACK from Rob
- collect ACK from Robert
- fix BIT macro replacements
- fix checkpatch --strict warnings
- fix unneeded commit text
- drop extra lines

Changes for v10:
- rebase on drm-misc-next
- add drm_of_dsi_find_panel_or_bridge
- add devm_drm_of_dsi_get_bridge
- fix host initialization (Thanks to Marek Szyprowski)
- rearrange the tiny patches for easy to review
- update simple names for enum hw_type
- add is_hw_exynos macro
- rework on commit messages

Changes for v9:
- rebase on drm-misc-next
- drop drm bridge attach fix for Exynos
- added prepare_prev_first flag
- added pre_enable_prev_first flag
- fix bridge chain order for exynos
- added fix for Exynos host init for first DSI transfer
- added MEDIA_BUS_FMT_FIXED
- return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt
  list is unsupported.
- added MEDIA_BUS_FMT_YUYV10_1X20
- added MEDIA_BUS_FMT_YUYV12_1X24

Changes for v8:
* fixed comment lines
* fixed commit messages
* fixed video mode bits
* collect Marek Ack
* fixed video mode bit names
* update input formats logic
* added imx8mplus support

Changes for v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic

Changes for v6:
* handle previous bridge for exynos dsi while attaching bridge 

Changes for v5:
* bridge changes to support multi-arch
* updated and clear commit messages
* add hw_type via plat data
* removed unneeded quirk
* rebased on linux-next

Changes for v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build
* update init handling to ensure host init done on first cmd transfer

Changes for v3:
* fix the mult-arch build
* fix dsi host init
* updated commit messages

Changes for v2:
* fix bridge handling
* fix dsi host init
* correct the commit messages

Tested in Engicam i.Core MX8M Mini SoM.

Repo:
https://github.com/openedev/kernel/tree/imx8mm-dsi-v12

v11:
https://lore.kernel.org/all/20230123151212.269082-1-jagan@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (16):
  drm: of: Lookup if child node has DSI panel or bridge
  drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
  drm: exynos: dsi: Drop explicit call to bridge detach
  drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
  drm: exynos: dsi: Mark PHY as optional
  drm: exynos: dsi: Add platform PLL_P (PMS_P) offset
  drm: exynos: dsi: Introduce hw_type platform data
  drm: exynos: dsi: Add atomic check
  drm: exynos: dsi: Add input_bus_flags
  drm: exynos: dsi: Add atomic_get_input_bus_fmts
  drm: exynos: dsi: Consolidate component and bridge
  drm: exynos: dsi: Add host helper for te_irq_handler
  drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support
  drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

Marek Szyprowski (1):
  drm: exynos: dsi: Handle proper host initialization

Marek Vasut (1):
  drm: bridge: samsung-dsim: Add i.MX8M Plus support

 .../bindings/display/exynos/exynos_dsim.txt   |    2 +
 MAINTAINERS                                   |    9 +
 drivers/gpu/drm/bridge/Kconfig                |   12 +
 drivers/gpu/drm/bridge/Makefile               |    1 +
 drivers/gpu/drm/bridge/panel.c                |   34 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1922 +++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  112 +-
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1819 +---------------
 include/drm/bridge/samsung-dsim.h             |  115 +
 include/drm/drm_bridge.h                      |    2 +
 include/drm/drm_of.h                          |   12 +
 12 files changed, 2289 insertions(+), 1752 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

Comments

Rasmus Villemoes Jan. 27, 2023, 10:33 a.m. UTC | #1
Hi Jagan and others

I'm trying to test this series on our imx8mp-based boards, which has the
mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
full-size DP-connector). But I don't know how to add the proper nodes to
imx8mp.dtsi. My current, obviously incomplete, attempt is

	mipi_dsi: dsi@32e60000 {
		compatible = "fsl,imx8mp-mipi-dsim";
		reg = <0x32e60000 0x400>;
		clocks = <&clk IMX8MP_CLK_MEDIA_APB_ROOT>,
			 <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
		clock-names = "bus_clk", "sclk_mipi";

		/* assigned-clocks = <&clk IMX8MM_CLK_DSI_CORE>, */
		/* 		  <&clk IMX8MM_VIDEO_PLL1_OUT>, */
		/* 		  <&clk IMX8MM_CLK_DSI_PHY_REF>; */
		/* assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_266M>, */
		/* 			 <&clk IMX8MM_VIDEO_PLL1_BYPASS>, */
		/* 			 <&clk IMX8MM_VIDEO_PLL1_OUT>; */
		/* assigned-clock-rates = <266000000>, <594000000>, <27000000>; */

		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
		power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_MIPI_DSI_1>;
		samsung,burst-clock-frequency = <891000000>;
		samsung,esc-clock-frequency = <54000000>;
		samsung,pll-clock-frequency = <27000000>;
		status = "disabled";

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				#address-cells = <1>;
				#size-cells = <0>;

				dsi_in_lcdif: endpoint@0 {
					reg = <0>;
					remote-endpoint = <&lcdif_out_dsi>;
				};
			};

			port@1 {
				reg = <1>;
			};
		};
	};

	lcdif1: display-controller@32e80000 {
		compatible = "fsl,imx8mp-lcdif";
		reg = <0x32e80000 0x238>;
		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
		clocks = <&clk IMX8MP_CLK_MEDIA_DISP1_PIX_ROOT>,
			 <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
			 <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
		clock-names = "pix", "axi", "disp_axi";
		assigned-clocks = <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
				  <&clk IMX8MP_VIDEO_PLL1>;
		assigned-clock-parents = <&clk IMX8MP_VIDEO_PLL1_OUT>,
					 <&clk IMX8MP_VIDEO_PLL1_REF_SEL>;
		assigned-clock-rates = <0>, <1039500000>;
		power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_LCDIF_1>;
		status = "disabled";

		port {
			lcdif_out_dsi: endpoint {
				remote-endpoint = <&dsi_in_lcdif>;
			};
		};
	};

The lcdif1 node is based on
https://lore.kernel.org/linux-arm-kernel/20221208090842.2869374-1-alexander.stein@ew.tq-group.com/
, which is now in next-20230127 as commit 94e6197dadc9. I know that one
works because one of our boards has an lvds display, but I don't know if
I've done the appropriate changes when copying the lcdif2 node to
lcdif1. And I'm even more at a loss when trying to fill out the mipi_dsi
node; I've tried doing some surgery of the one in imx8mm.dtsi with the
one from the NXP 5.15.32 kernel, but it's obviously not finished, and
I'm out of ideas.

Thanks,
Rasmus
Jagan Teki Jan. 27, 2023, 10:39 a.m. UTC | #2
On Fri, Jan 27, 2023 at 4:03 PM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> Hi Jagan and others
>
> I'm trying to test this series on our imx8mp-based boards, which has the
> mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
> full-size DP-connector). But I don't know how to add the proper nodes to
> imx8mp.dtsi. My current, obviously incomplete, attempt is

Please use this repo - https://github.com/openedev/kernel/tree/imx8mm-dsi-v12

Jagan.
Rasmus Villemoes Jan. 27, 2023, 10:56 a.m. UTC | #3
On 27/01/2023 11.39, Jagan Teki wrote:
> On Fri, Jan 27, 2023 at 4:03 PM Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
>>
>> Hi Jagan and others
>>
>> I'm trying to test this series on our imx8mp-based boards, which has the
>> mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
>> full-size DP-connector). But I don't know how to add the proper nodes to
>> imx8mp.dtsi. My current, obviously incomplete, attempt is
> 
> Please use this repo - https://github.com/openedev/kernel/tree/imx8mm-dsi-v12

Thanks, but that's exactly what I'm doing, and I don't see any
modification of imx8mp.dtsi in that branch. I'm basically looking for
help to do the equivalent of

  88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
  f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support

for imx8mp in order to test those patches on our boards (we have two
variants).

Rasmus
Jagan Teki Jan. 27, 2023, 11:04 a.m. UTC | #4
On Fri, Jan 27, 2023 at 4:26 PM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 27/01/2023 11.39, Jagan Teki wrote:
> > On Fri, Jan 27, 2023 at 4:03 PM Rasmus Villemoes
> > <rasmus.villemoes@prevas.dk> wrote:
> >>
> >> Hi Jagan and others
> >>
> >> I'm trying to test this series on our imx8mp-based boards, which has the
> >> mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
> >> full-size DP-connector). But I don't know how to add the proper nodes to
> >> imx8mp.dtsi. My current, obviously incomplete, attempt is
> >
> > Please use this repo - https://github.com/openedev/kernel/tree/imx8mm-dsi-v12
>
> Thanks, but that's exactly what I'm doing, and I don't see any
> modification of imx8mp.dtsi in that branch. I'm basically looking for
> help to do the equivalent of
>
>   88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>   f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>
> for imx8mp in order to test those patches on our boards (we have two
> variants).

Marek, any help here, thanks.

Jagan.
Marek Vasut Jan. 27, 2023, 11:30 a.m. UTC | #5
On 1/27/23 12:04, Jagan Teki wrote:
> On Fri, Jan 27, 2023 at 4:26 PM Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
>>
>> On 27/01/2023 11.39, Jagan Teki wrote:
>>> On Fri, Jan 27, 2023 at 4:03 PM Rasmus Villemoes
>>> <rasmus.villemoes@prevas.dk> wrote:
>>>>
>>>> Hi Jagan and others
>>>>
>>>> I'm trying to test this series on our imx8mp-based boards, which has the
>>>> mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
>>>> full-size DP-connector). But I don't know how to add the proper nodes to
>>>> imx8mp.dtsi. My current, obviously incomplete, attempt is
>>>
>>> Please use this repo - https://github.com/openedev/kernel/tree/imx8mm-dsi-v12
>>
>> Thanks, but that's exactly what I'm doing, and I don't see any
>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>> help to do the equivalent of
>>
>>    88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>    f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>
>> for imx8mp in order to test those patches on our boards (we have two
>> variants).
> 
> Marek, any help here, thanks.

Try attached patch.
Rasmus Villemoes Jan. 30, 2023, 12:45 p.m. UTC | #6
On 27/01/2023 12.30, Marek Vasut wrote:
> On 1/27/23 12:04, Jagan Teki wrote:

>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>> help to do the equivalent of
>>>
>>>    88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>    f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>
>>> for imx8mp in order to test those patches on our boards (we have two
>>> variants).
>>
>> Marek, any help here, thanks.
> 
> Try attached patch.

Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
of errors during boot:

  clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
media_apb to sys_pll1_266m: -22

and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
is because

  clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
media_apb

Further, the mipi_dsi fails to probe due to

  /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
'samsung,burst-clock-frequency' property

All other .dtsi files seem to have those samsung,burst-clock-frequency
and samsung,esc-clock-frequency properties, so I suppose those should
also go into the imx8mp.dtsi and are not something that the board .dts
file should supply(?).


[There's also some differences between your patch and Alexander's
regarding the lcdif2 and ldb nodes, so while my lvds display still sorta
works, I get

  fsl-ldb 32ec0000.blk-ctrl:lvds-ldb: Configured LDB clock (297000000
Hz) does not match requested LVDS clock: 346500000 Hz

and the image is oddly distorted/shifted. But I suppose that's
orthogonal to getting the lcdif1 -> mipi-dsi -> ... pipeline working.]

Rasmus
Alexander Stein Jan. 31, 2023, 7:27 a.m. UTC | #7
Hi Rasmus,

Am Montag, 30. Januar 2023, 13:45:38 CET schrieb Rasmus Villemoes:
> On 27/01/2023 12.30, Marek Vasut wrote:
> > On 1/27/23 12:04, Jagan Teki wrote:
> >>> Thanks, but that's exactly what I'm doing, and I don't see any
> >>> modification of imx8mp.dtsi in that branch. I'm basically looking for
> >>> help to do the equivalent of
> >>> 
> >>>    88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
> >>>    f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
> >>> 
> >>> for imx8mp in order to test those patches on our boards (we have two
> >>> variants).
> >> 
> >> Marek, any help here, thanks.
> > 
> > Try attached patch.
> 
> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
> of errors during boot:
> 
>   clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
> media_apb to sys_pll1_266m: -22
> 
> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
> is because
> 
>   clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
> media_apb
> 
> Further, the mipi_dsi fails to probe due to
> 
>   /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
> 'samsung,burst-clock-frequency' property
> 
> All other .dtsi files seem to have those samsung,burst-clock-frequency
> and samsung,esc-clock-frequency properties, so I suppose those should
> also go into the imx8mp.dtsi and are not something that the board .dts
> file should supply(?).
> 
> 
> [There's also some differences between your patch and Alexander's
> regarding the lcdif2 and ldb nodes, so while my lvds display still sorta
> works, I get
> 
>   fsl-ldb 32ec0000.blk-ctrl:lvds-ldb: Configured LDB clock (297000000
> Hz) does not match requested LVDS clock: 346500000 Hz
> 
> and the image is oddly distorted/shifted. But I suppose that's
> orthogonal to getting the lcdif1 -> mipi-dsi -> ... pipeline working.]

It seems my patch indicates exactly what's your problem here. Your clock rate 
configuration for LCDIF2 and LDB are not compatible (ratio 1:7). For now 
manual clock config is necessary in this case.
Check the clock tree in debugfs how your root clocks are configured and if it 
affects lcdif1 and lcdif2.

Best regards
Alexander
Frieder Schrempf Feb. 1, 2023, 8:37 a.m. UTC | #8
On 26.01.23 15:44, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Patch 0001 - 0004: adding devm_drm_of_dsi_get_bridge
> 
> Patch 0005 - 0006: optional PHY, PMS_P offset
> 
> Patch 0007       : introduce hw_type
> 
> Patch 0008	 : fixing host init
> 
> Patch 0009	 : atomic_check
> 
> Patch 0010	 : input_bus_flags
> 
> Patch 0011	 : atomic_get_input_bus_fmts
> 
> Patch 0012 - 0013: component vs bridge
> 
> Patch 0014	 : DSIM bridge
> 
> Patch 0015 - 0016: i.MX8M Mini/Nano
> 
> Patch 0017 - 0018: i.MX8M Plus
> 
> Changes for v12:
> - collect RB from Marek V
> - add te_irq_handler hook
> - fix comments from Marek V
> - update atomic_get_input_bus_fmts logic
> 
> Changes for v11:
> - collect RB from Frieder Schrempf
> - collect ACK from Rob
> - collect ACK from Robert
> - fix BIT macro replacements
> - fix checkpatch --strict warnings
> - fix unneeded commit text
> - drop extra lines
> 
> Changes for v10:
> - rebase on drm-misc-next
> - add drm_of_dsi_find_panel_or_bridge
> - add devm_drm_of_dsi_get_bridge
> - fix host initialization (Thanks to Marek Szyprowski)
> - rearrange the tiny patches for easy to review
> - update simple names for enum hw_type
> - add is_hw_exynos macro
> - rework on commit messages
> 
> Changes for v9:
> - rebase on drm-misc-next
> - drop drm bridge attach fix for Exynos
> - added prepare_prev_first flag
> - added pre_enable_prev_first flag
> - fix bridge chain order for exynos
> - added fix for Exynos host init for first DSI transfer
> - added MEDIA_BUS_FMT_FIXED
> - return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt
>   list is unsupported.
> - added MEDIA_BUS_FMT_YUYV10_1X20
> - added MEDIA_BUS_FMT_YUYV12_1X24
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support
> 
> Changes for v7:
> * fix the drm bridge attach chain for exynos drm dsi driver
> * fix the hw_type checking logic
> 
> Changes for v6:
> * handle previous bridge for exynos dsi while attaching bridge 
> 
> Changes for v5:
> * bridge changes to support multi-arch
> * updated and clear commit messages
> * add hw_type via plat data
> * removed unneeded quirk
> * rebased on linux-next
> 
> Changes for v4:
> * include Inki Dae in MAINTAINERS
> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
> * update init handling to ensure host init done on first cmd transfer
> 
> Changes for v3:
> * fix the mult-arch build
> * fix dsi host init
> * updated commit messages
> 
> Changes for v2:
> * fix bridge handling
> * fix dsi host init
> * correct the commit messages
> 
> Tested in Engicam i.Core MX8M Mini SoM.
> 
> Repo:
> https://github.com/openedev/kernel/tree/imx8mm-dsi-v12
> 
> v11:
> https://lore.kernel.org/all/20230123151212.269082-1-jagan@amarulasolutions.com/

I have tested this series (again) on Kontron DL i.MX8MM (= Kontron BL
i.MX8MM + 7" LVDS display connected through SN65DSI84 bridge).

Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron DL
i.MX8MM
Marek Vasut Feb. 1, 2023, 10 p.m. UTC | #9
On 1/30/23 13:45, Rasmus Villemoes wrote:
> On 27/01/2023 12.30, Marek Vasut wrote:
>> On 1/27/23 12:04, Jagan Teki wrote:
> 
>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>> help to do the equivalent of
>>>>
>>>>     88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>     f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>
>>>> for imx8mp in order to test those patches on our boards (we have two
>>>> variants).
>>>
>>> Marek, any help here, thanks.
>>
>> Try attached patch.
> 
> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
> of errors during boot:
> 
>    clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
> media_apb to sys_pll1_266m: -22
> 
> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
> is because
> 
>    clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
> media_apb
> 
> Further, the mipi_dsi fails to probe due to
> 
>    /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
> 'samsung,burst-clock-frequency' property
> 
> All other .dtsi files seem to have those samsung,burst-clock-frequency
> and samsung,esc-clock-frequency properties, so I suppose those should
> also go into the imx8mp.dtsi and are not something that the board .dts
> file should supply(?).

No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on 
your panel/bridge) and samsung,burst-clock-frequency (that's the HS 
clock) should go into board DT, as those are property of the attached 
panel/bridge.

> [There's also some differences between your patch and Alexander's
> regarding the lcdif2 and ldb nodes, so while my lvds display still sorta
> works, I get
> 
>    fsl-ldb 32ec0000.blk-ctrl:lvds-ldb: Configured LDB clock (297000000
> Hz) does not match requested LVDS clock: 346500000 Hz
> 
> and the image is oddly distorted/shifted. But I suppose that's
> orthogonal to getting the lcdif1 -> mipi-dsi -> ... pipeline working.]

Alexander is right in the reply below, you have to configure the LVDS 
serializer clock in DT and they must match LCDIF2 pixel clock which are 
also configured in DT then, else you won't get the correct LVDS clock.
Rasmus Villemoes Feb. 3, 2023, 12:29 p.m. UTC | #10
On 01/02/2023 23.00, Marek Vasut wrote:
> On 1/30/23 13:45, Rasmus Villemoes wrote:
>> On 27/01/2023 12.30, Marek Vasut wrote:
>>> On 1/27/23 12:04, Jagan Teki wrote:
>>
>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>>> help to do the equivalent of
>>>>>
>>>>>     88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>>     f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>>
>>>>> for imx8mp in order to test those patches on our boards (we have two
>>>>> variants).
>>>>
>>>> Marek, any help here, thanks.
>>>
>>> Try attached patch.
>>
>> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
>> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
>> of errors during boot:
>>
>>    clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
>> media_apb to sys_pll1_266m: -22
>>
>> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
>> is because
>>
>>    clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
>> media_apb
>>
>> Further, the mipi_dsi fails to probe due to
>>
>>    /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
>> 'samsung,burst-clock-frequency' property
>>
>> All other .dtsi files seem to have those samsung,burst-clock-frequency
>> and samsung,esc-clock-frequency properties, so I suppose those should
>> also go into the imx8mp.dtsi and are not something that the board .dts
>> file should supply(?).
> 
> No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on
> your panel/bridge) and samsung,burst-clock-frequency (that's the HS
> clock) should go into board DT, as those are property of the attached
> panel/bridge.

OK.

But I simply can't make that match what I see in that branch. For
example, there's imx8mm-icore-mx8mm-ctouch2-of10.dts and
imx8mm-icore-mx8mm-edimm2.2.dts which both seem to have a ti,sn65dsi84
bridge, neither override the values defined in imx8mm.dtsi, which are

        samsung,burst-clock-frequency = <891000000>;
        samsung,esc-clock-frequency = <54000000>;

and that 891MHz value seems to be out of range for the dsi84 bridge -
under Recommended Operating Conditions, the data sheet says "DSI HS
clock input frequency", min 40, max 500 MHz.

There's also the "clk sys_pll1_266m can not be parent of clk media_apb".
Are you sure about those assigned-clocks and assigned-clock-parents
settings?

Rasmus
Frieder Schrempf Feb. 6, 2023, 8:11 a.m. UTC | #11
On 03.02.23 13:29, Rasmus Villemoes wrote:
> On 01/02/2023 23.00, Marek Vasut wrote:
>> On 1/30/23 13:45, Rasmus Villemoes wrote:
>>> On 27/01/2023 12.30, Marek Vasut wrote:
>>>> On 1/27/23 12:04, Jagan Teki wrote:
>>>
>>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>>>> help to do the equivalent of
>>>>>>
>>>>>>     88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>>>     f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>>>
>>>>>> for imx8mp in order to test those patches on our boards (we have two
>>>>>> variants).
>>>>>
>>>>> Marek, any help here, thanks.
>>>>
>>>> Try attached patch.
>>>
>>> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
>>> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
>>> of errors during boot:
>>>
>>>    clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
>>> media_apb to sys_pll1_266m: -22
>>>
>>> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
>>> is because
>>>
>>>    clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
>>> media_apb
>>>
>>> Further, the mipi_dsi fails to probe due to
>>>
>>>    /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
>>> 'samsung,burst-clock-frequency' property
>>>
>>> All other .dtsi files seem to have those samsung,burst-clock-frequency
>>> and samsung,esc-clock-frequency properties, so I suppose those should
>>> also go into the imx8mp.dtsi and are not something that the board .dts
>>> file should supply(?).
>>
>> No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on
>> your panel/bridge) and samsung,burst-clock-frequency (that's the HS
>> clock) should go into board DT, as those are property of the attached
>> panel/bridge.
> 
> OK.
> 
> But I simply can't make that match what I see in that branch. For
> example, there's imx8mm-icore-mx8mm-ctouch2-of10.dts and
> imx8mm-icore-mx8mm-edimm2.2.dts which both seem to have a ti,sn65dsi84
> bridge, neither override the values defined in imx8mm.dtsi, which are
> 
>         samsung,burst-clock-frequency = <891000000>;
>         samsung,esc-clock-frequency = <54000000>;
> 
> and that 891MHz value seems to be out of range for the dsi84 bridge -
> under Recommended Operating Conditions, the data sheet says "DSI HS
> clock input frequency", min 40, max 500 MHz.

Please note that the value in samsung,burst-clock-frequency is double
the clock rate of the effective DSI HS clock. I can confirm that a
SN65DSI84 is able to work with the default settings in general. Still
the LVDS clock is derived from the DSI clock and the sn65dsi83 driver
calculates its PLL values expecting a DSI input clock matching the panel
mode. So you might have to tune this value.

> 
> There's also the "clk sys_pll1_266m can not be parent of clk media_apb".
> Are you sure about those assigned-clocks and assigned-clock-parents
> settings?
> 
> Rasmus
>
Rasmus Villemoes Feb. 7, 2023, 9:09 a.m. UTC | #12
On 06/02/2023 09.11, Frieder Schrempf wrote:
> On 03.02.23 13:29, Rasmus Villemoes wrote:
>> On 01/02/2023 23.00, Marek Vasut wrote:
>>> On 1/30/23 13:45, Rasmus Villemoes wrote:
>>>> On 27/01/2023 12.30, Marek Vasut wrote:
>>>>> On 1/27/23 12:04, Jagan Teki wrote:
>>>>
>>>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>>>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>>>>>> help to do the equivalent of
>>>>>>>
>>>>>>>     88775338cd58 - arm64: dts: imx8mm: Add MIPI DSI pipeline
>>>>>>>     f964f67dd6ee - arm64: dts: imx8mm: Add eLCDIF node support
>>>>>>>
>>>>>>> for imx8mp in order to test those patches on our boards (we have two
>>>>>>> variants).
>>>>>>
>>>>>> Marek, any help here, thanks.
>>>>>
>>>>> Try attached patch.
>>>>
>>>> Thanks. I removed the lcdif2 and ldb nodes I had added from Alexander's
>>>> patch (94e6197dadc9 in linux-next) in order to apply it. I get a couple
>>>> of errors during boot:
>>>>
>>>>    clk: /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to reparent
>>>> media_apb to sys_pll1_266m: -22
>>>>
>>>> and enabling a pr_debug in clk_core_set_parent_nolock() shows that this
>>>> is because
>>>>
>>>>    clk_core_set_parent_nolock: clk sys_pll1_266m can not be parent of clk
>>>> media_apb
>>>>
>>>> Further, the mipi_dsi fails to probe due to
>>>>
>>>>    /soc@0/bus@32c00000/mipi_dsi@32e60000: failed to get
>>>> 'samsung,burst-clock-frequency' property
>>>>
>>>> All other .dtsi files seem to have those samsung,burst-clock-frequency
>>>> and samsung,esc-clock-frequency properties, so I suppose those should
>>>> also go into the imx8mp.dtsi and are not something that the board .dts
>>>> file should supply(?).
>>>
>>> No, that samsung,esc-clock-frequency (should be some 10-20 MHz, based on
>>> your panel/bridge) and samsung,burst-clock-frequency (that's the HS
>>> clock) should go into board DT, as those are property of the attached
>>> panel/bridge.
>>
>> OK.
>>
>> But I simply can't make that match what I see in that branch. For
>> example, there's imx8mm-icore-mx8mm-ctouch2-of10.dts and
>> imx8mm-icore-mx8mm-edimm2.2.dts which both seem to have a ti,sn65dsi84
>> bridge, neither override the values defined in imx8mm.dtsi, which are
>>
>>         samsung,burst-clock-frequency = <891000000>;
>>         samsung,esc-clock-frequency = <54000000>;
>>
>> and that 891MHz value seems to be out of range for the dsi84 bridge -
>> under Recommended Operating Conditions, the data sheet says "DSI HS
>> clock input frequency", min 40, max 500 MHz.
> 
> Please note that the value in samsung,burst-clock-frequency is double
> the clock rate of the effective DSI HS clock. I can confirm that a
> SN65DSI84 is able to work with the default settings in general. Still
> the LVDS clock is derived from the DSI clock and the sn65dsi83 driver
> calculates its PLL values expecting a DSI input clock matching the panel
> mode. So you might have to tune this value.
> 

Hm, but in my case, I don't have a DSI->LVDS bridge, but a
DSI->DisplayPort bridge (sn65dsi86), and I obviously don't and can't
know what monitor(s) will be attached at run-time.

I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
to probe with these settings

	display_port0: connector {
		compatible = "dp-connector";
		label = "DP0";
		type = "full-size";
		dp-pwr-supply = <&reg_DP_PWR>;

		port {
			dp_connector_in: endpoint {
				remote-endpoint = <&sn65dsi86_out>;
			};
		};
       };

	eDP: bridge@2c {
		compatible = "ti,sn65dsi86";
		reg = <0x2c>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_eDP>;

		interrupts-extended = <&gpio3 14 IRQ_TYPE_LEVEL_HIGH>;
		enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;

		vpll-supply = <&VDD_1V8>;
		vccio-supply = <&VDD_1V8>;
		vcca-supply = <&reg_1V2>;
		vcc-supply = <&reg_1V2>;

		clocks = <&clk_38_4MHz>;
		clock-names = "refclk";

		#pwm-cells = <1>;

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				sn65dsi86_in_a: endpoint {
					remote-endpoint = <&mipi_dsi_out>;
				};
			};

			port@1 {
				reg = <1>;
				sn65dsi86_out: endpoint {
					remote-endpoint = <&dp_connector_in>;
				};
			};
		};
	};

&mipi_dsi {
       status = "okay";
       samsung,burst-clock-frequency = <816000000>;
       samsung,esc-clock-frequency = <60000000>;

       ports {
	       port@1 {
		       reg = <1>;

		       mipi_dsi_out: endpoint {
			       remote-endpoint = <&sn65dsi86_in_a>;
		       };
	       };
       };
};

&lcdif1 {
	status = "okay";
};

Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
that's a separate issue; when I boot with a monitor attached, its edid
is correctly read out. But I still don't get any output, and the monitor
says "no signal" - my naive attempt (which has worked fine in other
cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
some important step.

Rasmus
Marek Vasut Feb. 7, 2023, 9:23 a.m. UTC | #13
On 2/7/23 10:09, Rasmus Villemoes wrote:

[...]

> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
> that's a separate issue; when I boot with a monitor attached, its edid
> is correctly read out. But I still don't get any output, and the monitor
> says "no signal" - my naive attempt (which has worked fine in other
> cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
> some important step.

You could try and tweak the DSI mode flags in 
drivers/gpu/drm/bridge/ti-sn65dsi86.c to operate in DSI burst mode 
MIPI_DSI_MODE_VIDEO_BURST instead of MIPI_DSI_MODE_VIDEO . Then you 
could configure the DSIM PLL to 891 MHz , but you also have to make sure 
the DSI86 would expect the 891 MHz (please check the datasheet).

Try and look up patches below for related approach:
drm/bridge: ti-sn65dsi83: Add and use hs_rate and lp_rate
drm: bridge: samsung-dsim: Select DSI HS clock rate from downstream 
bridge limits
Rasmus Villemoes Feb. 14, 2023, 10:55 a.m. UTC | #14
On 07/02/2023 10.23, Marek Vasut wrote:
> On 2/7/23 10:09, Rasmus Villemoes wrote:
> 
> [...]
> 
>> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
>> that's a separate issue; when I boot with a monitor attached, its edid
>> is correctly read out. But I still don't get any output, and the monitor
>> says "no signal" - my naive attempt (which has worked fine in other
>> cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
>> some important step.
> 
> You could try and tweak the DSI mode flags in
> drivers/gpu/drm/bridge/ti-sn65dsi86.c to operate in DSI burst mode
> MIPI_DSI_MODE_VIDEO_BURST instead of MIPI_DSI_MODE_VIDEO . Then you
> could configure the DSIM PLL to 891 MHz , but you also have to make sure
> the DSI86 would expect the 891 MHz (please check the datasheet).

Well, the data sheet for the dsi86 says up to 750MHz DSI HS clock, and
if the value specified in samsung,burst-clock-frequency is twice the DSI
HS clk, I suppose I should be good up to 1.5GHz? I have tried many
different values, but I never seem to get anything through; I think I'm
missing some piece.

So now I've tried to use these patches on the imx8mp-evk with the
mipi->hdmi accessory from NXP, just to see if I can ever get any
graphics through the mipi interface. And there the story is the same:
the adv7535 bridge gets probed, and can read out the edid from the
monitor over hdmi. And while the mipi block and the bridge seem to
attach to each other, I still don't get any output.

Do any of you happen to have this working on the imx8mp-evk, and if so,
can you share the .dts updates you've done and how exactly you test the
graphics?

Thanks,
Rasmus
Rasmus Villemoes Feb. 14, 2023, 11:08 a.m. UTC | #15
On 14/02/2023 11.55, Rasmus Villemoes wrote:
> On 07/02/2023 10.23, Marek Vasut wrote:
> 
> Do any of you happen to have this working on the imx8mp-evk, and if so,
> can you share the .dts updates you've done and how exactly you test the
> graphics?
>

Oh, and could those of you who have some graphics working with the
mainline kernel on imx8mp tell which U-Boot you're using (NXP or
mainline, and which version). I'm using mainline U-Boot 2022.10.

Rasmus
Fabio Estevam Feb. 14, 2023, 11:09 a.m. UTC | #16
Hi Rasmus,

On Tue, Feb 14, 2023 at 7:55 AM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:

> Well, the data sheet for the dsi86 says up to 750MHz DSI HS clock, and
> if the value specified in samsung,burst-clock-frequency is twice the DSI
> HS clk, I suppose I should be good up to 1.5GHz? I have tried many
> different values, but I never seem to get anything through; I think I'm
> missing some piece.
>
> So now I've tried to use these patches on the imx8mp-evk with the
> mipi->hdmi accessory from NXP, just to see if I can ever get any
> graphics through the mipi interface. And there the story is the same:
> the adv7535 bridge gets probed, and can read out the edid from the
> monitor over hdmi. And while the mipi block and the bridge seem to
> attach to each other, I still don't get any output.
>
> Do any of you happen to have this working on the imx8mp-evk, and if so,
> can you share the .dts updates you've done and how exactly you test the
> graphics?

I don't have access to an imx8mp-evk, but I tested the ADV7535 MIPI to
HDMI daughter card on an imx8mm-evk.

Some extra ADV7535 patches were needed. Please check patches 0020-0023
and see if they help.
Fabio Estevam Feb. 14, 2023, 11:11 a.m. UTC | #17
On Tue, Feb 14, 2023 at 8:09 AM Fabio Estevam <festevam@gmail.com> wrote:

> Some extra ADV7535 patches were needed. Please check patches 0020-0023
> and see if they help.

Sorry, forgot to put the repo URL:

https://github.com/fabioestevam/meta-imx8mmevk-bsp/tree/kirkstone/recipes-kernel/linux/linux-stable/6.1/imx8mmevk
Rasmus Villemoes Feb. 17, 2023, 8:55 a.m. UTC | #18
On 14/02/2023 12.09, Fabio Estevam wrote:
> Hi Rasmus,
> 
> On Tue, Feb 14, 2023 at 7:55 AM Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
> 
>> Well, the data sheet for the dsi86 says up to 750MHz DSI HS clock, and
>> if the value specified in samsung,burst-clock-frequency is twice the DSI
>> HS clk, I suppose I should be good up to 1.5GHz? I have tried many
>> different values, but I never seem to get anything through; I think I'm
>> missing some piece.
>>
>> So now I've tried to use these patches on the imx8mp-evk with the
>> mipi->hdmi accessory from NXP, just to see if I can ever get any
>> graphics through the mipi interface. And there the story is the same:
>> the adv7535 bridge gets probed, and can read out the edid from the
>> monitor over hdmi. And while the mipi block and the bridge seem to
>> attach to each other, I still don't get any output.
>>
>> Do any of you happen to have this working on the imx8mp-evk, and if so,
>> can you share the .dts updates you've done and how exactly you test the
>> graphics?
> 
> I don't have access to an imx8mp-evk, but I tested the ADV7535 MIPI to
> HDMI daughter card on an imx8mm-evk.
> 
> Some extra ADV7535 patches were needed. Please check patches 0020-0023
> and see if they help.

Thanks, but they don't seem to make a difference.

I've started trying to simply compare registers between the NXP 5.15
kernel and the imx8mm-dsi-v12 branch with Marek's patch on top. Already
in MEDIA_BLK_CTRL, 0x32ec0000, there's something interesting:

 ## Media Mix Clock Enable Register
-CLK_EN                 0004    0080e133
+CLK_EN                 0004    00800133
 ## MIPI PHY Control Register
-MIPI_RESET_DIV         0008    40030000
+MIPI_RESET_DIV         0008    00020000

So with the NXP kernel, there are three bits set in CLK_EN which are not
set with the "mainline", but those bits are marked reserved in the RM,
so I have no idea if they are just some RO bits that get set due to some
other munging. Then there's the MIPI_RESET_DIV register where bits 16
and 30 do not get set. Of course, there are lots of other differences,
but perhaps this gives somebody an idea.

Thanks,
Rasmu
Rasmus Villemoes Feb. 17, 2023, 6:22 p.m. UTC | #19
On 07/02/2023 10.09, Rasmus Villemoes wrote:

> I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
> to probe with these settings
> 
[...]
> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
> that's a separate issue; when I boot with a monitor attached, its edid
> is correctly read out. But I still don't get any output, and the monitor
> says "no signal" - my naive attempt (which has worked fine in other
> cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
> some important step.

No idea if it's important, but in the NXP kernel, there's a

	display-subsystem {
		compatible = "fsl,imx-display-subsystem";
		ports = <&lcdif1_disp>,
			<&lcdif2_disp>,
			<&lcdif3_disp>;
	};

node in imx8mp.dtsi, and when commenting out that node, the graphics
ceases to work, even if all the devices in the lcdif->mipi->bridge chain
actually probes. However, adding a corresponding node in mainline, which
does have a driver for that "fsl,imx-display-subsystem", makes no
difference; with or without that, I do get a /dev/fb0 device and the
whole chain probes, but again the monitor says no signal.

Rasmus
Frieder Schrempf Feb. 22, 2023, 10:05 a.m. UTC | #20
On 17.02.23 19:22, Rasmus Villemoes wrote:
> On 07/02/2023 10.09, Rasmus Villemoes wrote:
> 
>> I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
>> to probe with these settings
>>
> [...]
>> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
>> that's a separate issue; when I boot with a monitor attached, its edid
>> is correctly read out. But I still don't get any output, and the monitor
>> says "no signal" - my naive attempt (which has worked fine in other
>> cases) was to just dd /dev/urandom to /dev/fb0, so I'm clearly missing
>> some important step.
> 
> No idea if it's important, but in the NXP kernel, there's a
> 
> 	display-subsystem {
> 		compatible = "fsl,imx-display-subsystem";
> 		ports = <&lcdif1_disp>,
> 			<&lcdif2_disp>,
> 			<&lcdif3_disp>;
> 	};
> 
> node in imx8mp.dtsi, and when commenting out that node, the graphics
> ceases to work, even if all the devices in the lcdif->mipi->bridge chain
> actually probes. However, adding a corresponding node in mainline, which
> does have a driver for that "fsl,imx-display-subsystem", makes no
> difference; with or without that, I do get a /dev/fb0 device and the
> whole chain probes, but again the monitor says no signal.

The NXP kernel is completely different. AFAIK it uses the component
helpers to bundle all subdrivers from a central driver
(display-subsystem). This is not how the mainline approach using the
bridge driver interface works. So you can't compare them.

Did you look at this extensive thread with findings from Adam?

https://lore.kernel.org/lkml/CAHCN7xJ=N1vWVTBjArskJ59fyaLzmAGWfc0E=_iGizrDNR_Udw@mail.gmail.com/

It is related to HDMI, but I guess a lot of things are valid for DP, too.

Anyway, we need to get this series merged. Otherwise we can't work on
fixing all the other issues on top.
Rasmus Villemoes Feb. 24, 2023, 2:08 p.m. UTC | #21
On 22/02/2023 11.05, Frieder Schrempf wrote:

> The NXP kernel is completely different. AFAIK it uses the component
> helpers to bundle all subdrivers from a central driver
> (display-subsystem). This is not how the mainline approach using the
> bridge driver interface works. So you can't compare them.
> 
> Did you look at this extensive thread with findings from Adam?
> 
> https://lore.kernel.org/lkml/CAHCN7xJ=N1vWVTBjArskJ59fyaLzmAGWfc0E=_iGizrDNR_Udw@mail.gmail.com/
> 
> It is related to HDMI, but I guess a lot of things are valid for DP, too.
> 
> Anyway, we need to get this series merged. Otherwise we can't work on
> fixing all the other issues on top.

Alright, I finally managed to get the imx8mm-dsi-v12 branch (commit
fdde97c7d553) to work, by modifying Marek's patch for enabling the
lcdif->mipi pipeline a little. The end result is in
https://github.com/Villemoes/linux/tree/imx8mp-mipi . There are also a
few cherry-picks of by-now-upstream patches to imx8mp.dtsi included.

It works on our custom hardware, with the ti,sn65dsi86 mipi->eDP bridge.

It does not seem to work on the imx8mp-evk with the adv7535 hdmi bridge
daughter board, but that's probably just as much the fault of the
adv7535 driver as anything in the SOC - it's impossible to get a real
data sheet for that thing, and there's no end of random patches floating
around, with the NXP kernel doing completely their own thing. So I've
given up on getting that to work.

Rasmus
Adam Ford Feb. 24, 2023, 3 p.m. UTC | #22
On Fri, Feb 24, 2023 at 8:08 AM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 22/02/2023 11.05, Frieder Schrempf wrote:
>
> > The NXP kernel is completely different. AFAIK it uses the component
> > helpers to bundle all subdrivers from a central driver
> > (display-subsystem). This is not how the mainline approach using the
> > bridge driver interface works. So you can't compare them.
> >
> > Did you look at this extensive thread with findings from Adam?
> >
> > https://lore.kernel.org/lkml/CAHCN7xJ=N1vWVTBjArskJ59fyaLzmAGWfc0E=_iGizrDNR_Udw@mail.gmail.com/
> >
> > It is related to HDMI, but I guess a lot of things are valid for DP, too.
> >
> > Anyway, we need to get this series merged. Otherwise we can't work on
> > fixing all the other issues on top.
>
> Alright, I finally managed to get the imx8mm-dsi-v12 branch (commit
> fdde97c7d553) to work, by modifying Marek's patch for enabling the
> lcdif->mipi pipeline a little. The end result is in
> https://github.com/Villemoes/linux/tree/imx8mp-mipi . There are also a
> few cherry-picks of by-now-upstream patches to imx8mp.dtsi included.
>
> It works on our custom hardware, with the ti,sn65dsi86 mipi->eDP bridge.
>
> It does not seem to work on the imx8mp-evk with the adv7535 hdmi bridge
> daughter board, but that's probably just as much the fault of the
> adv7535 driver as anything in the SOC - it's impossible to get a real
> data sheet for that thing, and there's no end of random patches floating
> around, with the NXP kernel doing completely their own thing. So I've
> given up on getting that to work.

I have a board with an ADV7535, and for that chip to work, there needs
to be some work to do some math on the front porch, back port, and
sync timings based on the number of lanes.  I have a work-in-progress
which supports 1080p, but I was waiting for the series to get accepted
first, since it seems to work when interacting directly with DSI
displays.  I have my patch working on imx8mm, imx8mn and imx8mp.  Once
the base driver is accepted, I'll push the patch for review.

adam



>
> Rasmus
>