Am 30.10.24 um 9:20 PM schrieb Saravana Kannan: > On Wed, Oct 30, 2024 at 10:28 AM Adam Ford <aford...@gmail.com> wrote: >> >> On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf >> <frieder.schre...@kontron.de> wrote: >>> >>> Hi Johannes, >>> >>> On 25.10.24 10:05 AM, mailingli...@johanneskirchmair.de wrote: >>>> [Sie erhalten nicht häufig E-Mails von mailingli...@johanneskirchmair.de. >>>> Weitere Informationen, warum dies wichtig ist, finden Sie unter >>>> https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> Hey, >>>> We had some problems with the hdmi on the imx8mp and wanted to leave, what >>>> we found out about it, somewhere for others to find it. >>>> >>>> The problem was that our hdmi display sometimes stayed blank after hot >>>> plugging and sometimes at startup. On older kernel versions 6.6 we did not >>>> have the problem with the not mainlined hdmi patches. >>>> We tracked the commit down that introduced the problem for us. It was the >>>> following “driver core: Enable fw_devlink=rpm by default” >>>> https://lore.kernel.org/lkml/20231113220948.80089-1-sarava...@google.com/ >>>> So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t >>>> really understand what the problem with RPM is. >>>> >>>> So, this information is just for reference. Maybe someone has an idea what >>>> is going on here. And how to fix the problem in a more proper way. >>> >>> Thanks for investigating and sharing your results! >>> >>> I'm seeing the same symptoms and previously found out that this is >>> related to LCDIF underrun errors. See [1] for more information. >>> >>> Adam has also started this thread: [2]. >>> >>> Anyway, knowing that this is related to fw_devlink=rpm is really >>> helpful. I just tried with fw_devlink=on and wasn't able to see any >>> issues anymore. So this confirms your findings. >> >> I was off in the weeds thinking there was something wrong in timing >> and/or a race condition around the PLL or something. This is good >> news. >> Please forgive my ignorance, what does fw_devlink do? Is there >> something we can do in the driver itself to force its behavior? > > fw_devlink figures out supplier/consumer dependencies between devices > and creates device links between them. This ensures proper > probe/suspend/resume/shutdown/runtime PM ordering. > > fw_devlink=rpm vs on means "enforce all of these" vs "enforce all of > these except runtime PM". > >> adam >>> >>> I hope that some of the driver framework and runtime PM experts can help >>> to find out what is actually wrong and how the correct fix might look like. >>> >>> I'm also CC-ing Saravana who authored the change from fw_devlink=on to >>> fw_devlink=rpm to see if they have anything to add. > > When fw_devlink=rpm, you'll have device links created between > consumers and suppliers with the DL_FLAG_PM_RUNTIME flag set. So > before your device is runtime resumed, it'll make sure all your > suppliers are resumed first. > > My guess is that there is some issue in the runtime PM handling in > these drivers. I don't have enough context to provide further insight.
I bet you are right. I tried to have a closer look but unfortunately I didn't make any progress. The drivers involved are lcdif_drv.c, imx8mp-hdmi-tx.c and phy-fsl-samsung-hdmi.c. As we see a "LCDIF Underrun Error" with fw_devlink=rpm my first guess would be that the suppliers of LCDIF are maybe turned on in the wrong order. Lucas, Marek: As the main authors of these drivers, do you think you could help a little with further debugging? Any ideas? Thanks!
