From: Stefan Klug <stefan.klug@ideasonboard.com>
To: "Krzysztof Hałasa" <khalasa@piap.pl>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Cc: 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: Tue, 12 Aug 2025 17:02:33 +0200 [thread overview]
Message-ID: <175501095338.74722.11604545949710100799@localhost> (raw)
In-Reply-To: <20250812103243.GK30054@pendragon.ideasonboard.com>
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.
> >
> > - 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.
Best regards,
Stefan
>
> --
> Regards,
>
> Laurent Pinchart
next prev parent reply other threads:[~2025-08-12 19:23 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 [this message]
2025-08-12 18:22 ` Adam Ford
2025-08-13 5:10 ` Krzysztof Hałasa
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=175501095338.74722.11604545949710100799@localhost \
--to=stefan.klug@ideasonboard.com \
--cc=dafna@fastmail.com \
--cc=heiko@sntech.de \
--cc=jacopo.mondi@ideasonboard.com \
--cc=khalasa@piap.pl \
--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 \
/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