imx93 MIPI to RGB bridge

[di-jtrumpower]

Hi

I am integrating a custom display that uses the Chipone icn6211 bridge to drive a parallel RGB interface, it has an existing driver in the kernel but I am having trouble getting it to work with a panel. All of the examples of bridge drivers I can find use i2c as the interface, where my device is just purely MIPI. The bridge is integrated to the panel along with the driver so all I am exposed to is a single lane MIPI interface. I based my device tree on the documentation for the dt-bindings for the chipone,icn6211.

the topology is the following:

lcdif(lcdif-common.c)->dsi(dw_mipi_dsi-imx.c)->icn6211(chipone-icn6211.c)-> ST7272A(panel-simple.c)->panel

The issue seems to at least start at the probing order, I cannot get the panel to ever probe which causes the bridge probe to fail since it can't find the panel in the device tree (drm_of_find_panel_or_bridge())) This repeat failure keeps happening at boot and the panel-simple probe() is never called. My latest suspicion is the probe order is somehow being determined by the drm layer (dw_mipi_dsi_imx.c) but cannot reason where.

If I remove the port/remote-endpoint between the bridge and the panel the panel probes fine, but then obviously the bridge fails to find the panel. 

Here is some research I have found on the topic:
This issue seems to be very similar to this one only we are using different bridges and an lvds panel. He looks like he was able to get the panel to probe by moving the order in the makefile but that didn't work for me:
https://stackoverflow.com/questions/74038671/linux-kernel-dsi-lvds-bridge-driver-loading-before-pane...

The issue also seems to be related to this mailing list entry for the kernel but I was not able to resolve a way for the panel to probe with their suggestions:
https://linuxlists.cc/l/1/linux-kernel/t/4104982/(patch_v2_0_8)_drm_bridge:_make_panel_and_bridge_pr...

Presentation from driver author that involves the device tree example I am basing it off (Left side of page 24):https://elinux.org/images/7/73/Jagan_Teki_-_Demystifying_Linux_MIPI-DSI_Subsystem.pdf

I attached my device tree file,

Thank you for your help!

[di-jtrumpower]

I attached the bootlog, keep in mind everywhere you see TRACE is a printk I added and not part of the normal kernel messaging

[Zhiming_Liu]

You can try to adjust  chipone_dsi_host_attach in probe function. Lots of bridge driver in kernel has the attach order issue on i.MX.

Please refer this knowledge base about LT9211.

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Patch-for-LT9211-bridge-on-i-MX/ta-p/168...

[di-jtrumpower]

I spent some time adapting the patch, but I don't think its affecting anything from my initial issue.

The issue is probe() is never getting called for the panel, so the device tree parsing for the panel in the bridge probe() always fails with a defer, and still doesn't probe after the defer. This happens before any of the attach functions would be called.

I am not sure what is impeding the the panel from probing, it must be something with how probe dependencies are ordered with the panel being an endpoint of the bridge?

Is there a way I can force a probe on the panel? When I run the panel without the bridge it looks like the probe is initiated from init, maybe there is a way to force it to probe there when connected to the bridge?

                                                 
[    0.882510] Call trace:                                                                                             
[    0.884944]  dump_backtrace+0x0/0x19c                                                                               
[    0.888602]  show_stack+0x18/0x70                                                                                   
[    0.891912]  dump_stack_lvl+0x68/0x84                                                                               
[    0.895569]  dump_stack+0x18/0x34                                                                                   
[    0.898871]  panel_simple_probe+0x3e8/0x4a8                                                                         
[    0.903048]  panel_simple_platform_probe+0x44/0x5c                                                                  
[    0.907824]  platform_probe+0x68/0xe0                                                                               
[    0.911481]  really_probe.part.0+0x9c/0x30c                                                                         
[    0.915650]  __driver_probe_device+0x98/0x144                                                                       
[    0.919992]  driver_probe_device+0x44/0x15c                                                                         
[    0.924160]  __driver_attach+0x80/0x18c                                                                             
[    0.927982]  bus_for_each_dev+0x70/0xd0                                                                             
[    0.931804]  driver_attach+0x24/0x30                                                                                
[    0.935366]  bus_add_driver+0x108/0x1fc                                                                             
[    0.939188]  driver_register+0x78/0x130                                                                             
[    0.943010]  __platform_driver_register+0x28/0x34                                                                   
[    0.947699]  panel_simple_init+0x34/0xb4                                                                            
[    0.951616]  do_one_initcall+0x50/0x1b0                                                                             
[    0.955439]  kernel_init_freeable+0x20c/0x290                                                                       
[    0.959780]  kernel_init+0x24/0x12c                                                                                 
[    0.963256]  ret_from_fork+0x10/0x20                                  

[di-jtrumpower]

Did some further work:

The -EPROBE_DEFER in dw_mipi_dsi_imx_probe() is what prevents the panel from ever probing. Still not don't have a solution but it seems correct to say the "probe defer" system is not working correctly at the platform layer. 

[Zhiming_Liu]

Hi @di-jtrumpower 

Please try to remove panel node in dsi node and move it into root node.

/ {
	model = "xxx";
	

	panel {
		compatible = "xxxx";
	};
};

[di-jtrumpower]

Thanks for the suggestion but makes no difference.

Seems like there is no way to change the probe order as the panel is a cyclical dependency of the bridge through the port/endpoint.

[Zhiming_Liu]

Add more prints in bridge driver, dsi driver and panel driver, you may fix it by figuring out the load steps.

[di-jtrumpower]

I am working on a new solution:

Like I said before the deferred bridge probing is never allowing for the panel to probe first at the platform_probe layer. I have many print statements in the kernel that corroborates this.

Since I am not using the i2c on the bridge for configuration. I am just going to write a custom driver that uses the raw mipi command mode and use it as a psuedo mipi panel driver, (e.g. raydium rm67191 driver). This will entirely circumvent what I believe to be the "broken" nature of how bridges probe in the platform layer.

I will provide an update if that resolves the issue.

[Zhiming_Liu]

Hi @di-jtrumpower 

Can you share the boot log?