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

[Tomi Valkeinen]

On 10/11/2020 18:49, H. Nikolaus Schaller wrote:
> 
>> 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.

I guess you have the same issue. It goes to dsi_bridge_mode_valid, then __dsi_calc_config, and stays
there finding good clocks.

 Tomi

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