[PATCH] drm: mxsfb: Increase number of outstanding requests on V4 and newer HW

[Marek Vasut]

On 6/21/21 2:08 PM, Lucas Stach wrote:
> Am Montag, dem 21.06.2021 um 00:47 +0200 schrieb Marek Vasut:
>> In case the DRAM is under high load, the MXSFB FIFO might underflow
>> and that causes visible artifacts. This could be triggered on i.MX8MM
>> using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The
>> first "Stuck Address" test of the memtester will completely corrupt
>> the image on the panel and leave the MXSFB FIFO in odd state.
>>
>> To avoid this underflow, increase number of outstanding requests to
>> DRAM from 2 to 16, which is the maximum. This mitigates the issue
>> and it can no longer be triggered.
>>
> I see the obvious benefit of this change, but I'm not sure if enabling
> this on older SoCs is without any drawbacks. The newer SoCs have a good
> transaction scheduling on the NOC (i.MX8M) or at least a somewhat okay
> one in the DRAM controller (i.MX6). I'm not so sure about the older
> SoCs, where I could imagine too many outstanding transactions to delay
> memory traffic for other masters on the SoC.
> 
> You don't happen to have any experience with this on the older SoCs, do
> you?

The only older SoC which would be affected by this, except for the ones 
you already listed, is MX28. And the MX28 has rather decent DRAM 
controller, so I wouldn't expect problems there either.

You can look at it the other way around too however, if the DRAM gets 
saturated, the LCDIF controller suffers from FIFO underflows and that 
completely messes up the FIFO state, at which point the image on the 
display is distorted, shifted, wrapped around, or any other such odd 
effect. The underflow auto-recovery bit helps with it, but with this 
patch in place you are unlikely to run into those effects at all.