[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHCN7xKevGWipBSch6gKVeJRT9Zb8QTchhxg3c=96XhnAvnjZw@mail.gmail.com>
Date: Wed, 30 Oct 2024 12:28:12 -0500
From: Adam Ford <aford173@...il.com>
To: Frieder Schrempf <frieder.schrempf@...tron.de>
Cc: mailinglist1@...anneskirchmair.de, johannes.kirchmair@...data.com,
Laurent.pinchart@...asonboard.com, airlied@...il.com,
alexander.stein@...tq-group.com, andrzej.hajda@...el.com,
catalin.marinas@....com, conor+dt@...nel.org, daniel@...ll.ch,
devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
festevam@...il.com, jernej.skrabec@...il.com, jonas@...boo.se,
kernel@...gutronix.de, kishon@...nel.org, krzysztof.kozlowski+dt@...aro.org,
l.stach@...gutronix.de, linux-arm-kernel@...ts.infradead.org,
linux-imx@....com, linux-kernel@...r.kernel.org,
linux-phy@...ts.infradead.org, linux-pm@...r.kernel.org,
maarten.lankhorst@...ux.intel.com, marex@...x.de, mripard@...nel.org,
neil.armstrong@...aro.org, p.zabel@...gutronix.de, rfoss@...nel.org,
robh+dt@...nel.org, s.hauer@...gutronix.de, shawnguo@...nel.org,
tzimmermann@...e.de, ulf.hansson@...aro.org, victor.liu@....com,
vkoul@...nel.org, will@...nel.org, Saravana Kannan <saravanak@...gle.com>
Subject: Re: imx8mp: HDMI display blank/black problems
On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf
<frieder.schrempf@...tron.de> wrote:
>
> Hi Johannes,
>
> On 25.10.24 10:05 AM, mailinglist1@...anneskirchmair.de wrote:
> > [Sie erhalten nicht häufig E-Mails von mailinglist1@...anneskirchmair.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?
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.
>
> Thanks
> Frieder
>
> [1]
> https://patchwork.kernel.org/project/linux-phy/cover/20240904233100.114611-1-aford173@gmail.com/#26014057
> [2]
> https://lore.kernel.org/imx/8cfd3052-c85a-4235-b9b8-6d2929e9e455@kontron.de/T/
Powered by blists - more mailing lists