| Message ID | 20230126144427.607098-1-jagan@amarulasolutions.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Add Samsung MIPI DSIM bridge | expand |
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
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.
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
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.
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.
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
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
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
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.
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
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 >
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 = <®_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 = <®_1V2>; vcc-supply = <®_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
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
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
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
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.
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
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
Am Freitag, 17. Februar 2023, 09:55:22 CET schrieb Rasmus Villemoes: > 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. Looking at drivers/soc/imx/imx8m-blk-ctrl.c the bits for MIPI_RESET_DIV are 16: MIPI_CSI1 17: MIPI_DSI 30: MIPI_CSI2 So i think that's okay here. Best regards, Alexander
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
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.
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
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 >