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 :-) -- Regards, Laurent Pinchart