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

[Liu Ying]

Hello Laurent,

On Tue, 2022-02-08 at 05:03 +0200, Laurent Pinchart wrote:
> Hello Liu Ying,
> 
> On Tue, Feb 08, 2022 at 10:41:59AM +0800, Liu Ying wrote:
> > On Mon, 2022-02-07 at 11:43 +0100, Marek Vasut wrote:
> > > On 2/7/22 10:18, Liu Ying wrote:
> > > > > > 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.
> > > > 
> > > > Agreed.
> > > > 
> > > > > 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
> > > > > (*).
> > > > 
> > > > I also think the QoS would help if it is configureable.
> > > 
> > > It is programmable, it's just the port mapping which is
> > > undocumented.
> > > 
> > > > > Do you know if there is some additional NOC/NIC documentation
> > > > > for i.MX8M
> > > > > Mini available ?
> > > > 
> > > > No.
> > > 
> > > Can you ask someone internally in NXP maybe ?
> > 
> > Maybe, you may try community.nxp.com, like the i.MXRT case.
> 
> Overall we seem to have had little luck with community.nxp.com. I
> wonder
> if it would be possible for key community members to get some more
> direct access to support when working on upstream drivers. I'm pretty
> sure nobody will try to abuse it :-)

I'm not sure if it is possible. It's not a bad idea in my personal
opinion.

Liu Ying