Display pixel clock limitation to 74.25 MHz

[sebastian1]

Hi,

I'm using a board with the IMX8 SoC and 4.14.98 IMX kernel.

I'm trying to add support for a MIPI-DSI display (800x480@60Hz) that needs a pixel clock of ~25MHz.

The problem is that there is a minimum limit for the pixel clock of 74.25MHz, both in the LCDIF and DCSS driver.

In the drivers there is mentioned a TODO about fixing this minimum limit.

https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/mxsfb/mxsfb_drv.c?h=imx_4....
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/imx/dcss/dcss-dtg.c?h=imx_4.14...

Any plans or timeline on fixing this clock limit?

Thank you!

[igorpadykov]

Hi Sebastian

yes this is known problem however no timelines are known, some additional info

were sent via mail.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kishorepoojari]

Dear Igor,

Our custom MIPI panel display works at the frequency of 77.94 MHZ, We are interfacing MIPI display to Imx-8MQ and we are using kernel version 4.14.98 (OS: Android Pi 9.0.X).  How to get the patch for the Kernel 4.14.98 to make it support for Lower MIPI display Clock Frequency.

If we configure less than 80 MHZ we are getting below error.

[    1.784154] imx-drm display-subsystem: bound imx-dcss-crtc.0 (ops dcss_crtc_ops)
[    1.791665] nwl_dsi-imx mipi_dsi@30A00000: Using DCSS as input source
[    1.798870] nwl-mipi-dsi 30a00000.mipi_dsi_bridge: [drm:nwl_dsi_host_attach] lanes=4, format=0x0 flags=0x415
[    1.808957] imx-drm display-subsystem: bound mipi_dsi@30A00000 (ops imx_nwl_dsi_component_ops)
[    1.817634] [drm] Cannot find any crtc or sizes

Regards,

Kishore P

[daniel_schmidt]

Hi Kishore,

I added more phyref_rates into the "nwl-dsi.c" so the tables for me looks like this:

static const char IRQ_NAME[] = "nwl-dsi";

/* Possible valid PHY reference clock rates*/
static u32 phyref_rates[] = {
  1000000,
  3000000,
  6000000,
 12000000,
 27000000,
 25000000,
 24000000,
};

It least it works for me. I don't know if this is the right way todo.

Daniel

[kishorepoojari]

Dear Daniel,

Thanks for the information, but same error we are getting after above change.

[    1.784154] imx-drm display-subsystem: bound imx-dcss-crtc.0 (ops dcss_crtc_ops)
[    1.791665] nwl_dsi-imx mipi_dsi@30A00000: Using DCSS as input source
[    1.798870] nwl-mipi-dsi 30a00000.mipi_dsi_bridge: [drm:nwl_dsi_host_attach] lanes=4, format=0x0 flags=0x415
[    1.808957] imx-drm display-subsystem: bound mipi_dsi@30A00000 (ops imx_nwl_dsi_component_ops)
[    1.817634] [drm] Cannot find any crtc or sizes

Regards,

Kishore P

[N_Coesel]

I ran into similar problems with a 1024x640 panel. I've added the changes to the dcss driver from the Kopera Linux kernel (as linked above) and on top of that I made a change to drivers/gpu/drm/bridge/nwl-dsi.c . Set the last parameter 'best match' in the calls to mixel_phy_mipi_set_phy_speed() to 'true' so the clock gets adjusted to a valid rate. This makes it easier to configure a display panel. The panel I'm using specifies a typical clock rate of 51.2MHz. This gets rounded to 50MHz automatically instead of failing.

This thread also contains useful hints:

Display pixel clock limitation to 74.25 MHz 

[sotero]

Hi Igor.

I have the same problem. It is even worst. My pixel clock is lower: 6.5 MHz (400x240). Is not possible to drive this kind of low resolution screens with iMX8MQ? We are developing a new product and we need to know if we have to change platform if this is not possible. Thanks.

Best regards,

Santiago Otero

[daniel_schmidt]

Hallo Santiago,

could you please a bit more specific how you achieved the 6.5MHz? Currently I use a Variscite Dart with a 4.14.98.

Thank you

Daniel

[sotero]

Hello Daniel.

With kernel 4.14.98 it's not possible to achieve 6.5MHz. I'm using new kernel 4.19.35_1.1.0. If you want to use 4.14.98 take a look at GitHub - kopera/linux-imx  . This kernel has some patches related to this.

[sebastian1]

I received on e-mail some patches from NXP that allow you to set any pixel clock(in theory).

The driver loads correctly for my 26MHz pixelclock, framebuffer is created and all that stuff but there is no MIPI data.

Experimentally, I saw that the MIPI data starts to show up on the oscilloscope when the pixel clock is >= 92MHz.

[ashasampathkuma]

Hello Sebastian,

We are also facing same issue, not able to reduce the clock, please share the patch for the Kernel version (4.14.98)

Regards,

Asha S,

[sotero]

Hi Sebastian.

Finally I am able to set a 6.5 MHz pixeclock. I have found a linux kernel in GitHub - kopera/linux-imx that allows me to set this pixelclock.

Best regards,

Santiago Otero

[sebastian1]

Hi Santiago,

Thank you for the link!

Did you test with the display to see that it actually works? Or did you just see in the kernel logs that the driver loaded successfully?

Regards!

[sotero]

It actually works. I'm using LCDIF with a custom panel driver. I didn't try DCSS yet.

[sebastian1]

Thank you for the answer!

I'm using the LCDIF too and is connected to the MIPI-DSI bridge.

Are you also using the MIPI-DSI bridge or you dislpay is driven directly by the LCDIF?

[sotero]

Hi Sebastian.

I'm using the LCD connected to the MIPI-DSI bridge too. I think there is no other way for using the LCDIF in iMX8MQ.

[sebastian1]

Hi Santiago,

Thank you so much for taking your time to reply!

Are you modifying the "IMX8MQ_VIDEO_PLL1" clock rate as in this patch clock : reducing IMX8MQ_VIDEO_PLL1 to 500MHz so as not to consume too… · kopera/linux-imx@4327c46 · ... ?

Also, do you use the "clock-drop-level = <>; " property in the device tree?

If you could paste a piece of your dt related to the lcdif, mipi_dsi_bridge and mipi_dsi nodes, it would be great, but it's easy to understand if you can't do that.

Regards!

[sotero]

Hi Sebastian.

I'm using the same patch (IMX8MQ_VIDEO_PLL1). I don't use clock-drop-level. It does not work for me. I send you part of my dts:

&lcdif {
    status = "okay";

    port@0 {
        lcdif_mipi_dsi: mipi-dsi-endpoint {
            remote-endpoint = <&mipi_dsi_in>;
        };
    };
};

&mipi_dsi_phy {
    status = "okay";
};

&mipi_dsi {
    status = "okay";
    as_bridge;
    sync-pol = <1>;
    pwr-delay = <10>;

    port@1 {
        mipi_dsi_in: endpoint {
            remote-endpoint = <&lcdif_mipi_dsi>;
        };
    };
};

&mipi_dsi_bridge {
    status = "okay";
    panel@0 {
        compatible = "toshiba,tc358867";
        reg = <0>;
        status = "okay";
        clock-names = "ref";
        clocks = <&edp_refclk>;

        dsi-lanes = <1>;
        panel-width-mm = <68>;
        panel-height-mm = <121>;

        port {
            panel1_in: endpoint {
                remote-endpoint = <&mipi_dsi_bridge_tc>;
            };
        };
    };

    port@2 {
        mipi_dsi_bridge_tc: endpoint {
            remote-endpoint = <&panel1_in>;
        };
    };
};

[jemish_1990]

Hi @sotero 

I was following this thread and understood that you are have worked on toshiba,tc358867 in your project.

We are also using same IC in our project. We are also using LCD via eLCDIF + MIPI DSI. Now the issue is that we are seeing pixel clock 6.5Mhz coming out  from chip but we don't see any data and sync signals (HSYNC, VSYNC, DE) are either low/high depending on polarity. Which is wrong.

Is it possible for you to share driver of this chip?

Thanks,

Jemish

[sebastian1]

Thank you very much Santiago!

I added the "pwr-delay = <10>;" to my "mipi_dsi" node in the device tree and now MIPI data and clock is generated.

My display still doesn't work yet, but this is a big improvement.

It seems that "pwr-delay = <10>;"  is mandatory for lower than 95MHz pixel clock.

What I find strange is that you are setting "dsi-lanes = <1>;", which for me prevents my display from being enabled.

This is somehow expected, because the driver takes a different path if DSI lanes number is smaller than 2, according to NXP patches that fix the pixelclock issue: MLK-21958-6: drm/bridge: nwl: Improve the clock calculation · kopera/linux-imx@80eb057 · GitHub 

Maybe your driver hardcodes the dsi-lanes value to a value > 1.

Thank you so much for your help!

[sotero]

I'm using only one lane. You're right, nwl_dsi_bridge_mode_fixup does not allow lanes = 1. I had to patch this.