STM32MP157CAA3 LCD ili9881 coupling

[MWoło.2]

Hi,

I try to couple LCD TFT ili9881c (mipi dsi 2 lanes interface) with stm32mp157caa3.

My custom driver seems to be loading correctly.

When I type lsmod I get

Module                  Size  Used by                                           
cfg80211              651264  0                                                 
usb_f_rndis            24576  2                                                 
u_ether                20480  1 usb_f_rndis                                     
libcomposite           49152  10 usb_f_rndis                                    
galcore               516096  2                                                 
panel_ilitek_ili9881c    20480  0                                               
dwmac_stm32            16384  0                                                 
stmmac_platform        20480  1 dwmac_stm32                                     
stm32_adc_core         20480  0                                                 
spi_stm32              24576  0                                                 
sch_fq_codel           20480  3                                                 
ip_tables              24576  0                                                 
x_tables               24576  1 ip_tables                                       
ipv6                  512000  42

Unfortunately, the display is not working, only the backlight is working.

I checked twice the dts and looks good, driver is loading well. I can't find anything with 'drm'. What I missed? Shall I add some additional driver in the kernel or something install in the roofs?

In the log, I can see only

[    0.079013] platform 5a000000.dsi: Fixing up cyclic dependency with 5a001000.display-controller

and

[   13.730531] [drm] Initialized stm 1.0.0 20170330 for 5a001000.display-controller on minor 0

[Erwan SZYMANSKI]

Hi @Michał Wołowik​ ,

I do not see obvious thing in the IOC file and everything looks to work well at boot time.

Just to be sure, can you probe again your entry lanes of the panel after doing this command :

modetest -M stm -s 31:720x1280 -v ?

Kind regards,

Erwan.

[Erwan SZYMANSKI]

Edit: no relevant comment

[MWoło.2]

Hi Erwan,

The result of

modetest -M stm -s 31:720x1280 -v

failed to find mode "720x1280" for connector 31                                                         
failed to create dumb buffer: Invalid argument                                                          
failed to create dumb buffer: Invalid argument

but now after moving to the latest OpenStLinux from v22.11.23 installation I get some waveform on lines

DSI-D0-N DSI-D0-N DSI-D1-N DSI-D1-N.

On line DSI-CK-N(P), I see only a transition from 0 to 1. As I good remember for DSI this is right due to the negotiation phase(command mode), if a correct switch to all lines and high clock(video mode). Besides I saw that during boot-up display some reactions became white and slowly disappeared to black again.

I check again very carefully hardware issues and maybe the initialization list of the display is wrong.

I let know soon.

Thanks

[MWoło.2]

I thnik I found display issue.

When I enable in the U-Boot dts one of the available drivers, I'm able to see during the transition from U-Boot to Kernel data between CPU and Display.

Unfortunately, this initialization comes from the U-Boot driver which has a wrong initialization list.

When I disable the driver in U-Boot I see nothing on the lines which means the Kernel does nothing. I predict that Kernel expects configuration from U-Boot due to displaying blinking unconditioned contents during the transition.

Now the question is how to force the Kernel to reinitialize the display without initialization from the U-Boot?

[MWoło.2]

I decided to go back to this topic due to new issues.

I think I found something I don't understand. I have a function 'static int ili9881c_prepare(struct drm_panel *panel)' in the driver. This function for some reason is not invoked.

I marked some places in it

static int ili9881c_prepare(struct drm_panel *panel)
{
	struct ili9881c *ctx = panel_to_ili9881c(panel);
	unsigned int i;
	int ret;
 
	/* Power the panel */
	ret = regulator_enable(ctx->power);
	if (ret){
		printk(KERN_ERR "MIPI DSI PANEL PREPARE ERROR !!!!!!!!");
		return ret;
	}
	msleep(5);
 
	printk(KERN_ERR "MIPI DSI PANEL PREPARE !!!!!!!!");
 
	/* And reset it */
	gpiod_set_value(ctx->reset, 1);
	printk(KERN_ERR "MIPI DSI PANEL RST ON !!!!!!!!");
	msleep(20);
 
	gpiod_set_value(ctx->reset, 0);
	printk(KERN_ERR "MIPI DSI PANEL RST OFF !!!!!!!!");
	msleep(20);

during the system log, but I can't see any of them.

I go deeper and this driver is used by the drm_panel driver which invokes this prepare function. The question is why this function is not invoked. Besides this, the driver exists in the system and loads correctly and of course the LCD show nothing.

[MWoło.2]

I found something in the driver. Incorrect line

dsi->mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE

for this display should be

dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS;

Now looks much better.

On the MIPI lines, I have some waveforms. In the configuration phase, I see what is sent but after configuration over on all MIPI lines, I see waveform with 77kHz frequency and duty 20%. After initialization LCD became white for a moment and after minutes start slowly became black again. No valid picture, no picture at all.

What is the problem now?

PS. During the configuration phase on Dx lines, the waveform is much faster.

[MWoło.2 · Accepted solution]

I think I can close this topic. The real problem is related with display itself. STM32MP1x support only 2 lane displays. My display have 4 lane and it can't be reconfigured by software to 2 lane - missing access to IM pins. So I think mipi works but the display can't be handled by 2 lanes.

[wiyarun]

My team encountered an issue something like this, but we found that the ili9881C can be configured to use 2 lanes by adjusting a resistor to enable that feature. After configuring it, our STM32U5 board successfully communicated with the ili9881C via MIPI 2 lanes.

I hope this information helps someone in the future.