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.
