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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
