[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m31popxjqk.fsf@t19.piap.pl>
Date: Tue, 02 Sep 2025 11:54:27 +0200
From: Krzysztof Hałasa <khalasa@...p.pl>
To: Adam Ford <aford173@...il.com>
Cc: Stefan Klug <stefan.klug@...asonboard.com>, Laurent Pinchart
<laurent.pinchart@...asonboard.com>, Dafna Hirschfeld
<dafna@...tmail.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: resolved
Hi,
summary:
I've done a few additional tests and it seems the MEDIA_AXI clock is the
problem. Reducing it to 400 MHz while still running MEDIA_ISP at 500 MHz
produces no errors.
MEDIA_ISP at 400 MHz and MEDIA_AXI at 500 MHz produces errors, though
(register address errors while reading and writing from/to ISP MI
(memory interface) registers, only on the secondary ISP (isp1), and
generally only while streaming data from the ISP).
What is driven by MEDIA_AXI clock root? MEDIAMIX: ISI, LCDIF, ISP, DWE.
According to both datasheets (industrial and commercial), MEDIA_AXI
is limited to 400 MHz in normal mode and 500 MHz in overdrive mode.
All my hardware is setup for overdrive mode, though (two manufacturers,
both using the same PMIC setup).
Since no hardware in the official Linux kernel tree (DT) uses the second
ISP... Should we just add a warning to the imx8mp.dtsi and be done with
it?
Out of tree hardware using isp1 (csi1) obviously exists.
--
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