Mipi-dsi clock issue on imx8qxp.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Mipi-dsi clock issue on imx8qxp.

1,228 Views
jakos
Contributor III

Hi,

I am working on a project involving IMX8QXP processor. We are using kernel 4.14 with Yocto project (NXP BSP layers - Sumo). The issue we have encountered is related with mipi clock signals.

In our design mipi1 signals coming from processor are connected to mipi-hdmi bridge (LT9611). It has it's own MCU thus is "transparent" to the system - no initialization is required. Here is our device tree :

 

&mipi_dsi_bridge2 {
    status = "okay";

    panel@0 {
        compatible = "raydium,rm67191";
        power-supply = <&reg_seq3_peri>;
        reg = <0>;
        dsi-lanes = <4>;

        display-timings {
            timing {
                clock-frequency = <132000000>;
                hactive = <1080>;
                vactive = <1920>;
                hfront-porch = <20>;
                hsync-len = <2>;
                hback-porch = <34>;
                vfront-porch = <10>;
                vsync-len = <5>;
                vback-porch = <4>;
                hsync-active = <0>;
                vsync-active = <0>;
                de-active = <0>;
                pixelclk-active = <0>;
            };
        };

        port {
            panel1_in_bendpoint {
                remote-endpoint = <&mipi_dsi_bridge_out>;
            };
        };
    };

    port@2 {
        mipi_dsi_bridge_outendpoint {
            remote-endpoint = <&panel1_in_b>;
        };
    };
};

&mipi_dsi2 {
    pwr-delay = <10>;
    status = "okay";
};

&mipi_dsi_phy2 {
    status = "okay";
};
 
We have received proper binary for the bridge (flashed via i2c with the use of external tools) in accordance to the setting. Unfortunately we do not receive any video on the screen. The bridge has uart configured as a logger, and here is the output:
 
 
Mipi pcr unstable!!!!!!!!!!!!!!!!!!!!!!!!
mipi byteclk = 98991
Set Mipi Settle: 0x06
Input MIPI FMT: RGB888
h_act = 1080
v_act = 1920
v_total = 1939
video_resolution = video_1080x1920_60
pclk_khz = 132162
Htotal_sysclk_num = 201
Frame_sysclk_num = 400524
HDMI 1.4
txpll calibration done
Mipi pcr unstable!!!!!!!!!!!!!!!!!!!!!!!!
mipi byteclk = 98991
Set Mipi Settle: 0x06
Input MIPI FMT: RGB888
h_act = 1080
v_act = 1920
v_total = 1939
video_resolution = video_1080x1920_60
pclk_khz = 132162
Htotal_sysclk_num = 202
Frame_sysclk_num = 400524
HDMI 1.4
txpll calibration done
Mipi pcr unstable!!!!!!!!!!!!!!!!!!!!!!!!
mipi byteclk = 98990
Set Mipi Settle: 0x06
Input MIPI FMT: RGB888
h_act = 1080
v_act = 1920
v_total = 1939
video_resolution = video_1080x1920_60
pclk_khz = 132162
Htotal_sysclk_num = 216
Frame_sysclk_num = 400524
HDMI 1.4
txpll calibration done
 
As You can see "htotal_sysclk_num" differs - this should be stable, hence the bridge won't output any TDMS signals.
 
We have found sort of similar issue here, for different processor: 
 
Most of the patches found in above thread were succesfully applied (except the one related strictly to imx8qmm). No difference.
 
A snippet from dmesg:
 
[ 2.699323] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.705967] [drm] No driver support for vblank timestamp query.
[ 2.726664] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_bliteng_ops)
[ 2.735370] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_ops)
[ 2.743097] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_ops)
[ 2.750806] nwl-mipi-dsi 56248000.mipi_dsi_bridge: [drm:nwl_dsi_host_attach] lanes=4, format=0x0 flags=0x411
[ 2.760794] imx-drm display-subsystem: bound mipi_dsi@56248000 (ops imx_nwl_dsi_component_ops)
[ 2.962407] imx-drm display-subsystem: fb0: frame buffer device
[ 2.968967] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0
 
Is there something that we are missing in the devicetree? Or perhaps this is a known problem for which patches exist ? Any help would be much appreciated as this is a crutial element in our desgin.
 
BR
Jakub
0 Kudos
4 Replies

1,200 Views
igorpadykov
NXP Employee
NXP Employee

Hi Jakub

 

if rm67191 driver is used as starting point one can pay attention to struct display_timing rad_default_timing = {}, functions rad_panel_enable(), rad_bl_get_brightness( ), in particular last fuction expects to get data from radium panel:

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/fsl-imx8qxp-...

https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/panel/panel-raydium-rm6719...

One can use AN12631  Normal and Secure Debug for i.MX8/8X Family of Applications Processors

 

Best regards
igor

0 Kudos

1,197 Views
jakos
Contributor III

We have discussed this with manufacturer. The bridge we use ignores any commands sent to it. Once it's firmware is initialized it's sending data directly. The only issue then is the unstable clock  that i have mentioned.

0 Kudos

1,179 Views
jakos
Contributor III

A custom panel has been created without any mipi commands initialization, just a dummy panel providing video setting. It is successfully registered withing linux system, and mipi signals are visible on the oscilloscope. The issue with unstable clock remains, are there perhaps any patches for this ?

0 Kudos

1,172 Views
igorpadykov
NXP Employee
NXP Employee

unfortunately I am not aware of any patches for this,

in general one can reuse rm67191 driver and remove mipi commands initialization.

 

Best regards
igor

0 Kudos