[Letux-kernel] [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel

Tomi Valkeinen tomi.valkeinen at ti.com
Tue Nov 10 16:25:15 CET 2020


On 10/11/2020 15:49, H. Nikolaus Schaller wrote:

> I did now some tests based on v5.10-rc3 by adding mre and more printk() and dump_stack().
> And I did blacklist the panel driver so that I could boot and after modprobing it manually
> I could trigger a re-probe by inserting some USB memory stick.
> 
> With this procedure I could trace the problem down to this call sequence:
> 
> 	dsi_probe()
>           ...
> 	  w677l_probe()
>             drm_panel_add()   -- after this, of_drm_find_panel() is successful
>           ...
> 	  component_add()
> 	    try_to_bring_up_master()
>  	      master->ops->bind(master->dev)
> 
> This call to bind() does not return and likely the probing thread is then blocked and
> holds some locks which manifests itself in that the system isn't running stable any
> more (e.g. heartbeat LEDs are sometimes stuck although console still works).
> 
> dbg_info() in try_to_bring_up_master() prints:
> 
> [  102.199362] omapdss_dss 58000000.dss: trying to bring up master
> 
> So I am not sure if this is a panel driver issue at all or the DSI patch set is not
> running stable on OMAP5.
> 
> Is a good next step to trace dss_bind() in drivers/gpu/drm/omapdrm//dss/dss.c?

For me, on omap5 uevm, the dss bind goes fine. But it gets stuck in videomode clock calculations.
Something related to pixel clock, I think, as the pclk dsi receives is 3708754968 kHz (so, garbage).
I'll try to debug more tomorrow.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the Letux-kernel mailing list