From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Dafna Hirschfeld <dafna@fastmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Heiko Stuebner <heiko@sntech.de>,
Paul Elder <paul.elder@ideasonboard.com>,
Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
Ondrej Jirman <megi@xff.cz>,
linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: FYI: i.MX8MP ISP (RKISP1) MI registers corruption
Date: Thu, 17 Jul 2025 15:03:54 +0200 [thread overview]
Message-ID: <m38qknx939.fsf@t19.piap.pl> (raw)
In-Reply-To: <m3h5zbxkc6.fsf@t19.piap.pl> ("Krzysztof Hałasa"'s message of "Thu, 17 Jul 2025 11:00:57 +0200")
> The "reference" (NXP) VVCam driver simply does the operations twice
> (i.e., reads twice with the first result discarded, and writes twice).
> This fixes the problem on most accesses, but the problems still persist.
It appears the corruptions are quite frequent, though.
Using "ldp qXX, qYY, [x0]" (2 * 128-bit load pair) I get results like
this (each data row is a result of a single ldp):
addr: 32E21400 32E21404 32E21408 32E2140C 32E21410 32E21414 32E21418 32E2141C
--------------------------------------------------------------------------------
values 3D000007 20 3C300000 1FA400 0 0 0 3C380000 count 99993097
values 0 20 3C300000 1FA400 0 0 0 3C380000 count 5930
values 7E900 20 3C300000 1FA400 0 0 0 3C380000 count 338
values FD200 20 3C300000 1FA400 0 0 0 3C380000 count 223
values 3C380000 20 3C300000 1FA400 0 0 0 3C380000 count 220
values 40 20 3C300000 1FA400 0 0 0 3C380000 count 192
The valid value (in 0x32E21400 register) is 3D000007 only, the rest are
corruptions: ca. 6 errors per 100k reads. With other registers, 15 errors
per 100k reads etc.
I also got this:
addr: 32E213F0 32E213F4 32E213F8 32E213FC 32E21400 32E21404 32E21408 32E2140C
--------------------------------------------------------------------------------
values 0 0 0 0 3D000007 20 3C300000 1FA400 count 98638773
values 0 0 0 0 0 20 3C300000 1FA400 count 1330227
values 0 0 0 0 40 20 3C300000 1FA400 count 3721
values 0 0 0 0 3C380000 20 3C300000 1FA400 count 314
values 0 0 0 0 7E900 20 3C300000 1FA400 count 572
values 0 0 0 0 FD200 20 3C300000 1FA400 count 428
values 0 0 0 0 4C010 20 3C300000 1FA400 count 25965
which is ca. 14 errors per 1k reads, though maybe it's special -
non-MI/MI boundary (at 0x32E21400), reserved addresses (0x32E213Fx) etc.
> The problems show themselves maybe in 5% or 10% of boots.
Well, now it appears more like 20%: e.g. in 41 system runs (soft reboots
only, no power-downs), I got problems 8 times.
Obviously I can post the tester source if anyone is interested.
Generally ISP MI register read accesses which can be corrupted are:
- first 32 bits read in a given transfer, and additionally
- every 32 bits on a 32-byte boundary (addresses 0x....00, ...20 etc.).
This means, in practice, on i.MX8MP only, RKISP1_CIF_MI_CTRL and
RKISP1_CIF_MI_MP_CB_SIZE_INIT (with the workaround).
What is this 32-byte boundary?
Writing is a bigger problem, though.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
next prev parent reply other threads:[~2025-07-17 14:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 9:00 FYI: i.MX8MP ISP (RKISP1) MI registers corruption Krzysztof Hałasa
2025-07-17 13:03 ` Krzysztof Hałasa [this message]
2025-07-21 8:46 ` Stefan Klug
2025-07-21 13:16 ` Krzysztof Hałasa
2025-07-23 10:19 ` Stefan Klug
2025-07-23 12:06 ` Krzysztof Hałasa
2025-07-23 12:09 ` Laurent Pinchart
2025-07-24 4:20 ` Krzysztof Hałasa
2025-07-24 8:21 ` Krzysztof Hałasa
2025-07-25 11:09 ` Stefan Klug
2025-07-30 10:30 ` Krzysztof Hałasa
2025-08-01 12:19 ` Krzysztof Hałasa
2025-08-05 10:57 ` Krzysztof Hałasa
2025-08-05 11:13 ` Krzysztof Hałasa
2025-08-12 5:54 ` FYI: i.MX8MP ISP (RKISP1) MI registers corruption: resolved Krzysztof Hałasa
2025-08-12 10:32 ` Laurent Pinchart
2025-08-12 12:28 ` Krzysztof Hałasa
2025-08-12 15:02 ` Stefan Klug
2025-08-12 18:22 ` Adam Ford
2025-08-13 5:10 ` Krzysztof Hałasa
2025-09-02 9:54 ` Krzysztof Hałasa
2025-09-02 11:23 ` Alexander Stein
2025-09-03 0:56 ` Paul Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m38qknx939.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=dafna@fastmail.com \
--cc=heiko@sntech.de \
--cc=jacopo.mondi@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=megi@xff.cz \
--cc=paul.elder@ideasonboard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox