[Letux-kernel] [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
H. Nikolaus Schaller
hns at goldelico.com
Tue Nov 10 17:49:33 CET 2020
> Am 10.11.2020 um 14:49 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>
> Hi Tomi,
>
>> Am 09.11.2020 um 12:33 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
>>
>> 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?
There is indeed one kernel worker running at 100% CPU load.
top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3196 root 20 0 0 0 0 R 100.0 0.0 2:58.76 kworker/0:8+events
More analysis shows that it hangs in drm_client_modeset_probe() in the loop
for (i = 0; i < connector_count; i++)
total_modes_count += connectors[i]->funcs->fill_modes(connectors[i], width, height);
Most likely not in the loop because that looks sane, but connectors[i]->funcs->fill_modes().
So I have to find out what function connectors[i]->funcs->fill_modes is...
BTW: connector_count = 2.
BR and thanks,
Nikolaus
More information about the Letux-kernel
mailing list