Re: [PATCH] Enable MIPI filtering by DT on i.MX8M*

["Krzysztof Hałasa" <khalasa@piap.pl>]

I wrote:

> This produces (test_pattern=5 which starts with black, using ISP):
> Y =  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00...
> UV = 80 80 80 80  80 80 80 80  80 80 80 80  80 80 80 80...
>
> Now I do (perhaps I should revert the patch instead):
> ./devmem write32 0x32E50004 0x14305
>
> and this does (= without DT filtering):
> Y =  E6 FF 36 1B  00 00 00 00  00 00 00 00  00 00 00 00...
> UV = 85 6A 74 B4  7D 8C 80 80  80 80 80 80  80 80 80 80...

The corruption is visible in ISP RAW-12 mode as well: CSI2 + ISP2 without
DT filtering: IMX462 test patterns, Linux v6.14, 1280x720p25.

Only 3 first 16-bit (12-bit on MIPI) RGGB values in each frame are
changed (bits 3-0 of the third pixel aren't changed).

32EC0060h          0 Gasket 0 output disabled
32EC0090h          0 Gasket 1 output disabled
32EC0138h    2D8000h ISP Dewarp Control Register (ISP_DEWARP_CONTROL)
      ISP ID mode 0, ISP1: DT 0, ISP2: DT 2Ch (RAW12) left-just mode

32E50040h        B0h ISP Configuration Register (MIPI_CSIS_ISPCONFIG_CH0)
      DT 2Ch (RAW12)

pattern 1:   0 800   0 2AB changed into 2AA B02 B00 2AB
pattern 2 and 3: FFF FFF FFF FFF... not altered at all
pattern 4: 501 501 4C2 4C2 changed into FFF 7FF 7F2 4C2
pattern 5:   0   0   0   0 changed into 7EF FF7 FF0   0
pattern 6:   0   1   0 101 changed into FFF FFF FF0 101
pattern 7:   0 2AB   0 2AB changed into BAA BAB BA0 2AB

RAW-12 on MIPI goes like this:
 lane0    lane1   lane2 7:4   lane2 3:0   lane3
----------- MIPI Header (all 4 lanes) ----------
P1-11:4  P2-11:4    P1-3:0      P2-3:0   P3-11:4
P4-11:4  ...

This means all the changed values are located in the first 4 bytes after
the packet header (i.e., in the first byte after the header for each
lane). Which IMHO smells like a hardware bug - especially given the
problem manifests itself only on CSI2 (+ISP2, I haven't tried using
ISI).

Fortunately enabling DT filtering fixes it.

I remember I was getting a bit different results on, I believe, the
NXP's 5.15 kernels (with their = Verisilicon VVCam driver). Instead of
simply changing the first 32 bits of the MIPI payload, the rest of the
RGGB data was shifted a couple of pixels or so.


Now, what do we do with it?
Is anybody able to verify the CSIC version register value on i.MX8MM?
Something like devmem read32 0x32E50000 (or 0x32E40000 for CSI1) WHILE
RUNNING CAPTURE on that very CSI would do the trick (using your
favorite instance of devmem/devmem2/etc). Alternatively one could add
a debug printk to the csic module.

And: is anybody able to check if the DT filtering works on i.MX8MM
(= if my patch doesn't break it on 8MM)?

Alternatively I guess we can add MIPI_CSIS_V3_6_3_1 for 8MP only.

Anybody using i.MX8MM with ISP2 + CSI2 BTW? Is the corruption there as
well? I understand it may be hard to spot, it's (usually a bright) dot
in the left top corner.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa