Re: FYI: i.MX8MP ISP (RKISP1) MI registers corruption

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

Hi,

still investigating the problem, but I can't see a simple way to work
around it.

It happens with the second ISP only, so the single camera setups (using
isp0) are immune.

The ISP MI (memory interface) register read operations are not
a problem, the workaround uses LDP instructions (for registers located
at addresses not on 32-byte boundary) or read multiple times and return
the most frequent result (fortunately the MI reads have no side
effects).

The writes are a problem, though. Especially writing to
RKISP1_CIF_MI_ICR register (address 0x32E21504) can (and does) corrupt
other MI registers, like RKISP1_CIF_MI_CTRL (0x32E21400):

Camera apps just started:
32E21400:   7A2001       20 3C180000   1FA400
32E21410:        0        0        0 3C200000
32E21420:    FD200        0        0        0
32E21470:        0    10001 3C0C0000   1FA400
32E21480:        0        0 3C140000    FD200
32E214F0:        0        0        1       3C
32E21540:        0        0        0  2000000
32E21550:      780        0        0        1
32E21560:        0      780      438   1FA400
32E21570:        0 1E1E00EF 1E2200E0        0

Video stream halted:
32E21400:  1000007       20 3C240000   1FA400
32E21410:        0        0        0 3C2C0000
32E21420:    FD200        0        0        0
32E21470:        0        0 3C0C0000   1FA400
32E21480:        0        0 3C140000    FD200
32E21490:    7E900        0        0        0
32E214F0:        0        0        1       7C
32E21500:        0        0        0        7
32E21540:        0        0        0  2000000
32E21550:      780        0        0        1
32E21560:        0      780      438   1FA400
32E21570:        0 1E060000 1E0A0000       77

Note that e.g. the 0x32E21400 register, MI_CTRL, has changed value from
the valid one (0x7A2001) to 0x1000007, which probably originated in
MI_MIS (and was to be written to MI_ICR).


It appears the problems are not constant, they manifest themselves in
maybe 10% of system boots. Once a system boots, the problems are either
present (and don't go away) or not.

It appears the ISP uses 3 clocks (+2 used by CSI receiver) - dump of
their CCM registers (Clock Control Module, IMX8MPRM page 227 and so on):
MEDIA_ISP           EN mux 7       post 0 SYSTEM_PLL2_DIV2 = 500 MHz
MEDIA_AXI           EN mux 1 pre 1 post 0 SYSTEM_PLL2_CLK / 2 = 500 MHz
MEDIA_APB           EN mux 2 pre 3 post 0 SYSTEM_PLL1_CLK / 4 = 200 MHz
MEDIA_MIPI_PHY1_REF EN mux 0 pre 0 post 0 24M_REF_CLK = 24 MHz
MEDIA_CAM2_PIX      EN mux 2 pre 0 post 0 SYSTEM_PLL2_DIV4 = 250 MHz

Now, it appears that in certain cases changing the MEDIA_APB
(MEDIA_APB_CLOCK_ROOT) "fixes" the problem (for current boot only), or
make it less (or more) visible. I'm changing the POST divider in
CCM_POST_ROOT21_SET register directly (the MEDIA_APB frequency is then
100 MHz):

0x30388A80 MEDIA_APB EN mux 2 pre 3 post 0 SYSTEM_PLL1_CLK / 4 = 200 MHz
# devmem write32 0x30388AA4 1
0x30388A80 MEDIA_APB EN mux 2 pre 3 post 1 SYSTEM_PLL1_CLK / 8 = 100 MHz

Examples - bad read counts from register 0x32E21400 (mi_ctrl)
per 10 millions of read operations:
POST=0 (default)  with POST=1
945               1
1448              2361
1088              2419
1842              2451
1333              0
67                5
2033              0
1                 8
13                16
2                 4
7                 0
1                 0
539               0
2605              0
1                 0
1723              1

I'm starting to run out of ideas.
-- 
Krzysztof "Chris" Hałasa

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