[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3qzxyug1s.fsf@t19.piap.pl>
Date: Wed, 30 Jul 2025 12:30:23 +0200
From: Krzysztof Hałasa <khalasa@...p.pl>
To: Stefan Klug <stefan.klug@...asonboard.com>
Cc: Dafna Hirschfeld <dafna@...tmail.com>, Laurent Pinchart
<laurent.pinchart@...asonboard.com>, Heiko Stuebner <heiko@...ech.de>,
Paul Elder <paul.elder@...asonboard.com>, Jacopo Mondi
<jacopo.mondi@...asonboard.com>, Ondrej Jirman <megi@....cz>,
linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: FYI: i.MX8MP ISP (RKISP1) MI registers corruption
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
Powered by blists - more mailing lists