i.MX8MP IMX-LCDIF Underrun Question(s)

i.MX8MP IMX-LCDIF Underrun Question(s)

[Adam Ford]

I have been testing various settings on the HDMI out of the i.MX8MP.

I noticed that sometimes my monitor would not sync, but sometimes it
would on the same resolution/refresh rate.  Frieder noted the LCDIF
was sometimes underflowing, so read up on it a little bit.

In the comments of the LCDIF driver, it's noted:
    Set FIFO Panic watermarks, low 1/3, high 2/3 .

However, in the downstream kernels, NXP changes the threshold to 1/2
and 3/4 on the LCDIF that drives the HDMI, while leaving the other
LCDIF interfaces at the default.

When I increased the threshold to 1/2 and 3/4, it appeared that
several resolutions that my monitor was struggling to sync started
working, and it appeared to sync faster.  I don't have an HDMI
analyzer, so I cannot verify much beyond knowing if my monitor can or
cannot sync.

Could the threshold and underrun cause this monitor intermittent
issue, or would this be something else?

Does it make sense to have a flag or device tree option to override
the default thresholds to change the panic level?

adam

RE: i.MX8MP IMX-LCDIF Underrun Question(s)

[Peng Fan]

> Subject: i.MX8MP IMX-LCDIF Underrun Question(s)
> 
> I have been testing various settings on the HDMI out of the i.MX8MP.
> 
> I noticed that sometimes my monitor would not sync, but sometimes it
> would on the same resolution/refresh rate.  Frieder noted the LCDIF
> was sometimes underflowing, so read up on it a little bit.
> 
> In the comments of the LCDIF driver, it's noted:
>     Set FIFO Panic watermarks, low 1/3, high 2/3 .
> 
> However, in the downstream kernels, NXP changes the threshold to
> 1/2 and 3/4 on the LCDIF that drives the HDMI, while leaving the other
> LCDIF interfaces at the default.
> 
> When I increased the threshold to 1/2 and 3/4, it appeared that several
> resolutions that my monitor was struggling to sync started working,
> and it appeared to sync faster.  I don't have an HDMI analyzer, so I
> cannot verify much beyond knowing if my monitor can or cannot sync.

You mean the two?
        thres-low  = <1 2>;             /* (FIFO * 1 / 2) */                                        
        thres-high = <3 4>;             /* (FIFO * 3 / 4) */
> 
> Could the threshold and underrun cause this monitor intermittent issue,
> or would this be something else?

The threshold could cause display flicker if the value could not satisfy
the bandwidth.

> 
> Does it make sense to have a flag or device tree option to override the
> default thresholds to change the panic level?

I think it would be good to have a property as above.

+ DT maintainer to comment.

Regards
Peng.
> 
> adam

Re: i.MX8MP IMX-LCDIF Underrun Question(s)

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

On Fri, Sep 06, 2024 at 08:03:38AM GMT, Peng Fan wrote:
> > Subject: i.MX8MP IMX-LCDIF Underrun Question(s)
> > 
> > I have been testing various settings on the HDMI out of the i.MX8MP.
> > 
> > I noticed that sometimes my monitor would not sync, but sometimes it
> > would on the same resolution/refresh rate.  Frieder noted the LCDIF
> > was sometimes underflowing, so read up on it a little bit.
> > 
> > In the comments of the LCDIF driver, it's noted:
> >     Set FIFO Panic watermarks, low 1/3, high 2/3 .
> > 
> > However, in the downstream kernels, NXP changes the threshold to
> > 1/2 and 3/4 on the LCDIF that drives the HDMI, while leaving the other
> > LCDIF interfaces at the default.
> > 
> > When I increased the threshold to 1/2 and 3/4, it appeared that several
> > resolutions that my monitor was struggling to sync started working,
> > and it appeared to sync faster.  I don't have an HDMI analyzer, so I
> > cannot verify much beyond knowing if my monitor can or cannot sync.
> 
> You mean the two?
>         thres-low  = <1 2>;             /* (FIFO * 1 / 2) */                                        
>         thres-high = <3 4>;             /* (FIFO * 3 / 4) */
> > 
> > Could the threshold and underrun cause this monitor intermittent issue,
> > or would this be something else?
> 
> The threshold could cause display flicker if the value could not satisfy
> the bandwidth.
> 
> > 
> > Does it make sense to have a flag or device tree option to override the
> > default thresholds to change the panic level?
> 
> I think it would be good to have a property as above.
> 
> + DT maintainer to comment.

Why do you think it's something that should be tuned as a
per-platform/board basis?

If it's something that needs to be adjusted based on the resolution,
then it should always be done in the driver, and that has nothing to do
in the DT.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: i.MX8MP IMX-LCDIF Underrun Question(s)

[Frieder Schrempf]

On 06.09.24 3:46 AM, Adam Ford wrote:
> I have been testing various settings on the HDMI out of the i.MX8MP.
> 
> I noticed that sometimes my monitor would not sync, but sometimes it
> would on the same resolution/refresh rate.  Frieder noted the LCDIF
> was sometimes underflowing, so read up on it a little bit.
> 
> In the comments of the LCDIF driver, it's noted:
>     Set FIFO Panic watermarks, low 1/3, high 2/3 .
> 
> However, in the downstream kernels, NXP changes the threshold to 1/2
> and 3/4 on the LCDIF that drives the HDMI, while leaving the other
> LCDIF interfaces at the default.
> 
> When I increased the threshold to 1/2 and 3/4, it appeared that
> several resolutions that my monitor was struggling to sync started
> working, and it appeared to sync faster.  I don't have an HDMI
> analyzer, so I cannot verify much beyond knowing if my monitor can or
> cannot sync.

For me this change doesn't seem to cause any improved behavior. My
monitor still fails to sync every few times I run "modetest -s" .

Also we have a downstream kernel based on 6.1 with backported HDMI
support and I don't see the issues there. But I need to make some
further tests to make any reliable statements.

> 
> Could the threshold and underrun cause this monitor intermittent
> issue, or would this be something else?
> 
> Does it make sense to have a flag or device tree option to override
> the default thresholds to change the panic level?
> 
> adam

RE: i.MX8MP IMX-LCDIF Underrun Question(s)

[Peng Fan]

> Subject: Re: i.MX8MP IMX-LCDIF Underrun Question(s)
> 
> On 06.09.24 3:46 AM, Adam Ford wrote:
> > I have been testing various settings on the HDMI out of the i.MX8MP.
> >
> > I noticed that sometimes my monitor would not sync, but sometimes
> it
> > would on the same resolution/refresh rate.  Frieder noted the LCDIF
> > was sometimes underflowing, so read up on it a little bit.
> >
> > In the comments of the LCDIF driver, it's noted:
> >     Set FIFO Panic watermarks, low 1/3, high 2/3 .
> >
> > However, in the downstream kernels, NXP changes the threshold to
> 1/2
> > and 3/4 on the LCDIF that drives the HDMI, while leaving the other
> > LCDIF interfaces at the default.
> >
> > When I increased the threshold to 1/2 and 3/4, it appeared that
> > several resolutions that my monitor was struggling to sync started
> > working, and it appeared to sync faster.  I don't have an HDMI
> > analyzer, so I cannot verify much beyond knowing if my monitor can
> or
> > cannot sync.
> 
> For me this change doesn't seem to cause any improved behavior. My
> monitor still fails to sync every few times I run "modetest -s" .
> 
> Also we have a downstream kernel based on 6.1 with backported
> HDMI support and I don't see the issues there. But I need to make
> some further tests to make any reliable statements.
> 

Downstream kernel has some NOC settings that not supported
in upstream kernel, that maybe the issue.

If you check 6.6 kernel, you could see some noc related settings
in imx8mp-blk-ctl.c imx8m-blk-ctl.c and gpcv2.c. You may give a
try with those noc settings applied and see whether that would
improve.

Regards,
Peng.

> >
> > Could the threshold and underrun cause this monitor intermittent
> > issue, or would this be something else?
> >
> > Does it make sense to have a flag or device tree option to override
> > the default thresholds to change the panic level?
> >
> > adam

Re: i.MX8MP IMX-LCDIF Underrun Question(s)

[Frieder Schrempf]

On 09.09.24 5:00 AM, Peng Fan wrote:
>> Subject: Re: i.MX8MP IMX-LCDIF Underrun Question(s)
>>
>> On 06.09.24 3:46 AM, Adam Ford wrote:
>>> I have been testing various settings on the HDMI out of the i.MX8MP.
>>>
>>> I noticed that sometimes my monitor would not sync, but sometimes
>> it
>>> would on the same resolution/refresh rate.  Frieder noted the LCDIF
>>> was sometimes underflowing, so read up on it a little bit.
>>>
>>> In the comments of the LCDIF driver, it's noted:
>>>     Set FIFO Panic watermarks, low 1/3, high 2/3 .
>>>
>>> However, in the downstream kernels, NXP changes the threshold to
>> 1/2
>>> and 3/4 on the LCDIF that drives the HDMI, while leaving the other
>>> LCDIF interfaces at the default.
>>>
>>> When I increased the threshold to 1/2 and 3/4, it appeared that
>>> several resolutions that my monitor was struggling to sync started
>>> working, and it appeared to sync faster.  I don't have an HDMI
>>> analyzer, so I cannot verify much beyond knowing if my monitor can
>> or
>>> cannot sync.
>>
>> For me this change doesn't seem to cause any improved behavior. My
>> monitor still fails to sync every few times I run "modetest -s" .
>>
>> Also we have a downstream kernel based on 6.1 with backported
>> HDMI support and I don't see the issues there. But I need to make
>> some further tests to make any reliable statements.
>>
> 
> Downstream kernel has some NOC settings that not supported
> in upstream kernel, that maybe the issue.
> 
> If you check 6.6 kernel, you could see some noc related settings
> in imx8mp-blk-ctl.c imx8m-blk-ctl.c and gpcv2.c. You may give a
> try with those noc settings applied and see whether that would
> improve.

With "downstream kernel" I didn't mean linux-imx. I meant our Kontron
linux-ktn, which is based on mainline. I didn't test linux-imx to see if
the issue occurs there, but that might be one task for further debugging.