MIPI panel driver stalls system

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MIPI panel driver stalls system

2,034件の閲覧回数
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 件の賞賛
6 返答(返信)

2,014件の閲覧回数
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 件の賞賛

2,009件の閲覧回数
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 件の賞賛

2,000件の閲覧回数
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 件の賞賛

1,990件の閲覧回数
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 件の賞賛

1,985件の閲覧回数
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 件の賞賛

1,955件の閲覧回数
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 件の賞賛