Re: imx8mp: HDMI display blank/black problems

[Frieder Schrempf <frieder.schrempf@kontron.de>]

Am 30.10.24 um 9:20 PM schrieb Saravana Kannan:
> On Wed, Oct 30, 2024 at 10:28 AM Adam Ford <aford173@gmail.com> wrote:
>>
>> On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf
>> <frieder.schrempf@kontron.de> wrote:
>>>
>>> Hi Johannes,
>>>
>>> On 25.10.24 10:05 AM, mailinglist1@johanneskirchmair.de wrote:
>>>> [Sie erhalten nicht häufig E-Mails von mailinglist1@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-saravanak@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!