Hi Tomi,
> Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
>
> On 09/11/2020 13:09, H. Nikolaus Schaller wrote:
>
>>>> I see.
>>>> Anyways there is missing some simple thing which makes the driver not prepared/enabled.
>>>> Or is this related to VC?
>>>
>>> No, that's not related to the VC.
>>
>> Ok, then it is worth searching for that independently. Any idea/hint what could be missing?
>
> Well, if I had to guess, I would go for either 1) some registration or such is missing from the
> panel driver, or 2) some config value is invalid, which makes the DRM framework or the DSI driver
> fail before calling prepare or enable.
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?
BR,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
