Message-ID: <CAHCN7xKq_o_u7PhPMcZ2W9nzrFP8+CnhaYJOyxnjpKfbMTBCEw@mail.gmail.com>
Date: Tue, 12 Aug 2025 13:22:54 -0500
From: Adam Ford <aford173@...il.com>
To: Stefan Klug <stefan.klug@...asonboard.com>
Cc: Krzysztof Hałasa <khalasa@...p.pl>, 
	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

On Tue, Aug 12, 2025 at 10:07 AM Stefan Klug
<stefan.klug@...asonboard.com> wrote:
>
> Hi Krzysztof, hi Laurent,
>
> Quoting Laurent Pinchart (2025-08-12 12:32:43)
> > Hi Krzysztof,
> >
> > On Tue, Aug 12, 2025 at 07:54:46AM +0200, Krzysztof Hałasa wrote:
> > > Hi Stefan et al,
> > >
> > > BTW I've added Lucas Stach and Shawn Guo to "Cc" list.
> > >
> > > The problem is the CPU core power supply voltage :-)
> >
> > Ah, the dreadful overdrive mode.
> >
> > > - while the reference manual specifies the max ISP and MEDIA clocks at
> > >   500 MHz, the datasheets show this requires the "overdrive" mode =
> > >   increased CPU power supply voltage. In "normal" mode the ISPs are
> > >   limited to 400 MHz (there are other limits, too).
> > >
> > > - I've tried lowering the clock rate after booting the systems (with
> > >   a CCM register write), but it didn't fix the problem. I guess some
> > >   reset logic is affected here, and the (lower) clock rate must be set
> > >   right from the start, in the DT.
> >
> > That's interesting. I wouldn't have expected that.
> >
> > > - anyway, lowering the frequencies of ISP and MEDIA root clocks fixes
> > >   the ISP2 MI corruption. I'm currently investigating PMIC settings
> > >   (both my Compulab and SolidRun modules use PCA9450C PMICs), so perhaps
> > >   I'll be able to use the higher 500 MHz clocks. It doesn't matter much,
> > >   though.

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.



> > >
> > > - the question is if we should lower the clocks in the main imx8mp.dtsi
> > >   DT file, or the overdrive mode should stay there, and the changes
> > >   should be made to the individual board files, or maybe the U-Boot
> > >   configs (PMIC output voltages) should be changed etc.
> >
> > I think it would make sense to lower the default clock frequencies, and
> > provide an overlay to enable overdrive mode.
> >
> > It's also interesting that the issue only affected the second ISP, as
> > the first one should also be limited to 400 MHz in normal mode.
>
> I support that. As a side note, there is already imx8mp-nominal.dtsi
> which is only used by one board. That dtsi also uses the
> fsl,operating-mode property which enables additional clock checks. So I
> ask myself if the default imx8mp.dtsi should specify overdrive mode, or
> if we should add a imx8mp-overdrive.dtsi (then we should possibly rename
> them to imx8mp-mode-xxx.dtsi so that they sit side by side) to make it
> easier to create overlays for both cases.

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.

adam
>
> Best regards,
> Stefan
>
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
>

Powered by blists - more mailing lists