[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