[PATCH] [RFC] drm: mxsfb: Implement LCDIF scanout CRC32 support

[Marek Vasut]

On 2/7/22 06:13, Liu Ying wrote:
> Hi Marek,

Hi,

> On Sun, 2022-02-06 at 19:56 +0100, Marek Vasut wrote:
>> The LCDIF controller as present in i.MX6SX/i.MX8M Mini/Nano has a CRC_STAT
>> register, which contains CRC32 of the frame as it was clocked out of the
>> DPI interface of the LCDIF. This is likely meant as a functional safety
>> register.
>>
>> Unfortunatelly, there is zero documentation on how the CRC32 is calculated,
>> there is no documentation of the polynomial, the init value, nor on which
>> data is the checksum applied.
>>
>> By applying brute-force on 8 pixel / 2 line frame, which is the minimum
>> size LCDIF would work with, it turns out the polynomial is CRC32_POLY_LE
>> 0xedb88320 , init value is 0xffffffff , the input data are bitrev32()
>> of the entire frame and the resulting CRC has to be also bitrev32()ed.
> 
> No idea how the HW calculates the CRC value.
> I didn't hear anyone internal tried this feature.

It would be nice if the datasheet could be improved.

There are many blank areas which are undocumented, this LCDIF CRC32 
feature, i.MX8M Mini Arteris NOC at 0x32700000 , the ARM GPV NIC-301 at 
0x32{0,1,2,3,4,5,6,8}00000 and their master/slave port mapping. The NOC 
and NICs were documented at least up to i.MX6QP and then that 
information disappeared from NXP datasheets. I think reconfiguring the 
NOC/NIC QoS would help mitigate this shift issue described below (*).

Do you know if there is some additional NOC/NIC documentation for i.MX8M 
Mini available ?

>> Doing this calculation in software for each frame is unrealistic due to
>> the CPU demand, implement at least a sysfs attribute which permits testing
>> the current frame on demand.
> 
> Why not using the existing debugfs CRC support implemented
> in drivers/gpu/drm/drm_debugfs_crc.c?

I wasn't aware of that, thanks.

>> Unfortunatelly, this functionality has another problem. On all of those SoCs,
>> it is possible to overload interconnect e.g. by concurrent USB and uSDHC
>> transfers, at which point the LCDIF LFIFO suffers an UNDERFLOW condition,
>> which results in the image being shifted to the right by exactly LFIFO size
>> pixels. On i.MX8M Mini, the LFIFO is 76x256 bits = 2432 Byte ~= 810 pixel
>> at 24bpp. In this case, the LCDIF does not assert UNDERFLOW_IRQ bit, the
>> frame CRC32 indicated in CRC_STAT register matches the CRC32 of the frame
>> in DRAM, the RECOVER_ON_UNDERFLOW bit has no effect, so if this mode of
>> failure occurs, the failure gets undetected and uncorrected.
> 
> Hmmm, interesting, no UNDERFLOW_IRQ bit asserted when LCDIF suffers an
> UNDERFLOW condition?

Yes

> Are you sure LCDIF really underflows?

Mostly sure.

This problem occurs also on i.MX6SX which has no DSIM.

The failure is triggered by many short writes into DRAM to different 
addresses (I was successful at triggering it by using i.MX8M Mini with 
ASIX 88772 USB ethernet adapter, running iperf3 on the device, iperf3 -c 
... -t 0 -R -P 16 on the PC). This effectively makes the CI HDRC behave 
as a DRAM thrashing AXI master, since it triggers a lot of short USB qTD 
READs from DRAM and a lot of short ethernet packet WRITEs to DRAM. And 
that either clogs the DRAM itself, or the NOC or DISPLAY/HSIO NIC-301, 
and prevents LCDIF from getting data long enough for this underflow 
condition to happen, LFIFO to underflow, and this shift to appear. And 
the shift does not disappear automatically itself, it just stays there 
until the LCDIF is reinitialized.

And it apparently also happens on iMXRT, where a suggestion was made to 
tweak the QoS settings of the interconnect (which cannot be tested on 
i.MX8M Mini, because neither of that documentation is available, see 
above (*)):
https://community.nxp.com/t5/i-MX-RT/iMXRT1052-LCD-Screen-shifted/td-p/1069978

> If the shifted image is seen on a MIPI DSI display, could that be a
> MIPI DSI or DPHY issue, like wrong horizontal parameter(s)?

No, it happens also on i.MX6SX without DSIM, so this is LCDIF problem.