public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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


  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