public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Stefan Klug <stefan.klug@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: Tue, 12 Aug 2025 14:28:07 +0200	[thread overview]
Message-ID: <m3zfc4sp0o.fsf@t19.piap.pl> (raw)
In-Reply-To: <20250812103243.GK30054@pendragon.ideasonboard.com> (Laurent Pinchart's message of "Tue, 12 Aug 2025 13:32:43 +0300")

Hi Laurent,

>> - 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.

Well, apparently my Compulab UCM module provides overdrive power. At
least the PMIC driver says so (in /sys pseudofiles). I guess SolidRun
won't be different.

1. At least two different designs are affected (Compulab and SolidRun),
2. the PCA9450C is THE i.MX8MP PMIC, most probably connected to the CPU
   exactly as in the datasheet (at least WRT VDD_SOC power lines),
3. NXP people experienced the problem on their (which ones?) boards, too

Well... They specify (IMX8MPIEC = the datasheet):

"Two instances of 4-lane MIPI CSI interface and HDR ISP
• 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.
• 2x ISP supporting 375 Mpixel/s aggregate performance and up to
  3-exposure HDR processing.
    •When one camera is used, support up to 12MP@30fps or 4kp45
    •When two cameras are used, each supports up to 1080p80"

So, while ISP clock is not exactly pixel clock, perhaps they mean that
the ISP clock is to be limited as well.

ISP2 at 400 MHz (single camera) works for me (with a 1080p60 12-bit
IMX462 sensor), but I haven't tested in extreme conditions 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.

Right. Maybe it's not the overdrive mode after all. I will do more tests
soon.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa


  reply	other threads:[~2025-08-12 16:22 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 [this message]
2025-08-12 15:02                         ` Stefan Klug
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=m3zfc4sp0o.fsf@t19.piap.pl \
    --to=khalasa@piap.pl \
    --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