From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C916EC83F17 for ; Wed, 23 Jul 2025 12:09:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FVcJX6f+q3EXcgJzIGoC9bNqE5gUBpU3/WwfAaYpaQQ=; b=uO8FKW+2exht0copKC2XvxBSlA EwDYE/HjDE2ZQkljdUtKuKTQwTORtRpfR5jkOwiHLRjuKSKWW/QzUDHvEksKQHhNBrMTYf12hXrrH yL0a8ikip/b10RBN32zcB51PM+QIhBslcpBhj1YIeKTDQKQ3LDfO5v8r56MmhhcWkyvUmaWw2x3gJ J61LRBGzUkeka+CRrFn4x/OsjuDkW9onJbQBOd2t1Vae55T3qldwTDbkbhKtSlr6Unqgx3wRb2JCg dMI/OvZTlp+QjTTfEPGTHNdYI/jSlsP6csUUEiz/4dfyYqM++7+NEBpIgZwFLSFEwmgMj7368kDVj xtcTNcTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1ueYHk-00000004sY3-0BLI; Wed, 23 Jul 2025 12:09:24 +0000 Received: from [195.187.100.5] (helo=ni.piap.pl) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1ueYFI-00000004sLj-0IqA; Wed, 23 Jul 2025 12:06:55 +0000 Received: from t19.piap.pl (OSB1819.piap.pl [10.0.9.19]) by ni.piap.pl (Postfix) with ESMTPS id BF790C3E4DE9; Wed, 23 Jul 2025 14:06:43 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 ni.piap.pl BF790C3E4DE9 From: =?utf-8?Q?Krzysztof_Ha=C5=82asa?= To: Stefan Klug Cc: Dafna Hirschfeld , Laurent Pinchart , Heiko Stuebner , Paul Elder , Jacopo Mondi , Ondrej Jirman , 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 In-Reply-To: <175326599663.2811177.16620980968274114885@localhost> (Stefan Klug's message of "Wed, 23 Jul 2025 12:19:56 +0200") References: <175308758352.3134829.9472501038683860006@localhost> <175326599663.2811177.16620980968274114885@localhost> Date: Wed, 23 Jul 2025 14:06:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250723_050652_272797_EA186D81 X-CRM114-Status: GOOD ( 17.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Stefan, Stefan Klug writes: > Just a quick heads up. I ran the tester and so far no unexpected > results. I'll run it from time to time after a reboot to see if I ever > hit that condition. > > How does your device tree look like? Any chance the ISP is clocked for > overdrive but the device is not or something similar? Although I have a > hard time imagining how that would lead to such effects. Interesting. I tested it on two different devices (a Compulab UCM-based camera and a Solidrun Hummingboard Mate) and it's the same on both. I think the first one uses 1600 MHz industrial CPU: (U-boot) CPU: i.MX8MP[8] rev1.1 at 1200 MHz Not sure about the Hummingboard. Both cameras apparently are connected to the second MIPI. Well... maybe if it's only the second ISP, and there is only one camera, then we could reroute the data to the first ISP? The MIPI receiver has a crossbar I think. And the other way around: for a test, one could reroute MIPI0 to ISP1. Will have a look. The DT has the usual stuff (for the second MIPI/ISP): &i2c6 { clock-frequency =3D <400000>; pinctrl-names =3D "default"; pinctrl-0 =3D <&pinctrl_i2c6>; single-master; status =3D "okay"; imx462_camera@1a { compatible =3D "sony,imx462"; reg =3D <0x1a>; clocks =3D <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names =3D "xclk"; clock-frequency =3D <37125000>; reset-gpios =3D <&gpio2 1 GPIO_ACTIVE_HIGH>; status =3D "okay"; port { imx462_mipi_ep: endpoint { data-lanes =3D <1 2 3 4>; clock-lanes =3D <0>; link-frequencies =3D /bits/ 64 <222750000 148500000>; remote-endpoint =3D <&mipi_csi_1_in>; }; }; }; }; &mipi_csi_1 { status =3D "okay"; ports { port@0 { reg =3D <0>; mipi_csi_1_in: endpoint { remote-endpoint =3D <&imx462_mipi_ep>; data-lanes =3D <1 2 3 4>; }; }; port@1 { reg =3D <1>; mipi_csi_1_out: endpoint { remote-endpoint =3D <&isp_1_in>; }; }; }; }; &isp_1 { status =3D "okay"; ports { port@1 { isp_1_in: endpoint { bus-type =3D ; remote-endpoint =3D <&mipi_csi_1_out>; }; }; }; }; The CCM registers show basically (p. 229 in i.MX8MP ref manual): 8 MEDIA_ISP mux 7 post 0 SYSTEM_PLL2_DIV2 =3D 500 MHz 20 MEDIA_AXI mux 1 pre 1 post 0 SYSTEM_PLL2_CLK / 2 =3D 500 MHz 21 MEDIA_APB mux 2 pre 3 post 0 SYSTEM_PLL1_CLK / 4 =3D 200 MHz 123 MEDIA_MIPI_PHY1_REF mux 0 pre 0 post 0 24M_REF_CLK =3D 24 MHz 125 MEDIA_CAM2_PIX mux 2 pre 0 post 0 SYSTEM_PLL2_DIV4 =3D 250 MHz The first 3 are at the max values, MEDIA_MIPI_PHY1_REF max is 125 MHz, MEDIA_CAM2_PIX max is 266 MHz. Maybe I should try changing these clocks, but not sure how do I do that (any change causes rkisp1 driver loading to fail). Will look at it. BTW the double read and double write in NXP driver (isp-vvcam) were introduced by (in their repo): Author: hexing 2022-08-05 10:19:49 Committer: Robby Cai 2022-08-08 04:50:48 M865SW-1031: the second isp port jump frames Reason:mi read or write reg occasionally it does not take effect WorkAround:read or write twice of mi reg ---------------------------- vvcam/isp/isp_ioctl.c ------------------------= ---- index 60741bd..e0d3048 100644 @@ -118,5 +118,8 @@ void isp_write_reg(struct isp_ic_dev *dev, u32 offset, = u32 val) if (offset >=3D ISP_REG_SIZE) return; - __raw_writel(val, dev->base + offset); + writel(val, dev->base + offset); + if ((offset >=3D REG_ADDR(mi_mp_y_base_ad_init)) + && (offset <=3D REG_ADDR(mi_mp_y_pic_size))) + writel(val, dev->base + offset); // isp_info("%s addr 0x%08x val 0x%08x\n", __func__, offset, val); } @@ -128,5 +131,8 @@ u32 isp_read_reg(struct isp_ic_dev *dev, u32 offset) if (offset >=3D ISP_REG_SIZE) return 0; - val =3D __raw_readl(dev->base + offset); + val =3D readl(dev->base + offset); + if ((offset >=3D REG_ADDR(mi_mp_y_base_ad_init)) + && (offset <=3D REG_ADDR(mi_mp_y_pic_size))) + val =3D readl(dev->base + offset); // isp_info("%s addr 0x%08x val 0x%08x\n", __func__, offset, val); return val; --=20 Krzysztof "Chris" Ha=C5=82asa Sie=C4=87 Badawcza =C5=81ukasiewicz Przemys=C5=82owy Instytut Automatyki i Pomiar=C3=B3w PIAP Al. Jerozolimskie 202, 02-486 Warszawa