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

Lucas Stach l.stach at pengutronix.de
Tue Jun 22 07:30:54 UTC 2021


Am Montag, dem 21.06.2021 um 18:45 +0200 schrieb 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.

Yea, I just wanted to have this thought considered. If you think the
probability of introducing regressions on MX28 is low, that's fine with
me. I guess MX28 systems likely don't have a big enough screen attached
to drown the memory controller in read requests.

Reviewed-by: Lucas Stach <l.stach at pengutronix.de>




More information about the dri-devel mailing list