From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Adam Ford <aford173@gmail.com>
Cc: Stefan Klug <stefan.klug@ideasonboard.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Dafna Hirschfeld <dafna@fastmail.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: resolved
Date: Wed, 13 Aug 2025 07:10:03 +0200 [thread overview]
Message-ID: <m3v7mrst78.fsf@t19.piap.pl> (raw)
In-Reply-To: <CAHCN7xKq_o_u7PhPMcZ2W9nzrFP8+CnhaYJOyxnjpKfbMTBCEw@mail.gmail.com> (Adam Ford's message of "Tue, 12 Aug 2025 13:22:54 -0500")
Hi Adam,
Adam Ford <aford173@gmail.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
next prev parent reply other threads:[~2025-08-13 5: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
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 [this message]
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=m3v7mrst78.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=aford173@gmail.com \
--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 \
--cc=stefan.klug@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