linux-kernel - Re: FYI: i.MX8MP ISP (RKISP1) MI registers corruption: resolved

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <m3v7mrst78.fsf@t19.piap.pl>
Date: Wed, 13 Aug 2025 07:10:03 +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 Adam,

Adam Ford <aford173@...il.com> writes:

> I was reading through the data sheet (not the reference manual), and
> it lists a few limitations for the clocks:
>
> For single Camera, MIPI CSI 1 can support up to 400/500 MHz pixel
> clock in the Nominal/Overdrive mode.
> For single Camera, MIPI CSI 2 can support up to 277 MHz pixel clock.
> For dual Camera, both MIPI CSI can support up to 266 MHz pixel clock.
>
> If you're running dual cameras, it sounds like you're capped at 266
> MHz regardless of whether or not you're in overdrive or nominal.

Right. But these are pixel clocks, not ISP clock. At least theoretically
entirely different stuff.
For example, I'm using (at most) two IMX290/462 1920x1080p60 sensors in
12-bit (Bayer) mode, resulting in:
- 148.5 MHz pixel clocks
- 1782 Mb/s total bandwidth (for each sensor - 12 bits)
- 445.5 Mb/s per lane (each sensor uses 4 MIPI lanes)
- 222.75 MHz MIPI clocks (MIPI uses DDR, the double data rate)

So I'm well within specs. Though I don't know if the people writing the
datasheets did really mean what they wrote, or maybe they meant ISP core
clocks as well. Why? Because ISP blocks (and all such logic blocks)
require a certain number of their core clocks for a signal rate (in this
case, a pixel rate). And maybe what they specified in the datasheets was
a calculation of this (unpublished?) required pixel/ISP clock ratio and
the max ISP clock rate (specified incorrectly at 400/500 MHz).
Anyway, this is only a possibility. Another one is that ISP2 simply
cannot reliably run at 500 MHz, for some "analog" reason, design bug
etc.

> My understanding is that the imx8mp.dtsi is pre-configured for
> overdrive mode, so if you need to run the ISP in nominal, the clock
> updates should go into imx8mp-nominial.dtsi.

It seems my modules are setup for overdrive mode.
-- 
Krzysztof "Chris" Hałasa

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