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

Hi Adam,

Adam Ford [off-list ref] 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