On 10/11/2020 18:49, H. Nikolaus Schaller wrote: > >> Am 10.11.2020 um 14:49 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: >> >> 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? > > 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
