MIPI panel driver stalls system

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

MIPI panel driver stalls system

2,025 Views
STHansen
Contributor I

I am trying to have a MIPI display working on an imx8mq based system.

Panel is based on ili9881c - 800x1280.

OS is yocto dunfell.

I am using LCDIF -> MIPI -> Panel.

System stalls in the panel driver prepare function.

I have managed to trace the calls into the nwl_dsi where it in the nwl_dsi_write function calls regmap_write from which it never returns. 

As far as I can see this is a write to a register in the mipi interface of the cpu and thus it should not stall the system?

Anyone who knows what could cause this?

Thanks in advance.

STHansen

0 Kudos
6 Replies

2,005 Views
STHansen
Contributor I

I found that the MIPI core clock is not enabled until after the panel prepare function has been run.

This means the panel init code can not go into the prepare function, but has to be placed in the enable function.

After moving the init code the system no longer stalls, but there is still no picture on the panel.

And i have no indications to why.

Any ideas?

 

0 Kudos

2,000 Views
jamesbone
NXP TechSupport
NXP TechSupport

It seems that other customers had the issues regarding this Panel, let me share the thread that has a functional driver:

 

https://community.nxp.com/t5/i-MX-Processors/Driver-of-ST7703-under-Linux-5-4-3/m-p/1267249/highligh...

 

 

0 Kudos

1,991 Views
STHansen
Contributor I

Thanks for sharing.

The driver still doesn't bring any picture to the display. But I can see there is a patch for clock on the imx8mm.

Is there a corresponding patch for the imx8mq?

It looks as there are no valid video input to the MIPI bridge, either the clock or the data is wrong. 

 

0 Kudos

1,981 Views
jamesbone
NXP TechSupport
NXP TechSupport

Basically the i.MX8MM it is a version of the i.MX8MQ, so if a patch it is for the Mini you can try with the QM.

 

0 Kudos

1,976 Views
STHansen
Contributor I

The clk-imx8mm.c is very different from clk-imx8mq.c

And it looks as vital mapping is different.

dmesg shows this 'mxsfb 30320000.lcdif: Failed to create outputs'

0 Kudos

1,946 Views
STHansen
Contributor I

In nwl-drv.c I find this

if (!dsi->use_dcss) {
/* LCDIF + NWL needs active high sync */
adjusted->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
adjusted->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
} else {
adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
adjusted->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
}

 

and in nwl-dsi.c I find this

/*
* Adjusting input polarity based on the video mode results in
* a black screen so always pick active low:
*/
nwl_dsi_write(dsi, NWL_DSI_VSYNC_POLARITY,
                       NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW);
nwl_dsi_write(dsi, NWL_DSI_HSYNC_POLARITY,
                       NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW);

So the question is what is right and what is wrong?

If I use memtool to look at the LCDIF_VDCTRL0n register it looks as if the sync is high no matter what I do.

 

0 Kudos