linux-kernel - Re: [PATCH] Enable MIPI filtering by DT on i.MX8M*

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <m3frgm5q7t.fsf@t19.piap.pl>
Date: Fri, 30 May 2025 12:48:38 +0200
From: Krzysztof Hałasa <khalasa@...p.pl>
To: Jacopo Mondi <jacopo.mondi@...asonboard.com>
Cc: Xavier Roumegue <xavier.roumegue@....nxp.com>,  Laurent Pinchart
 <laurent.pinchart@...asonboard.com>,  Rui Miguel Silva <rmfrfs@...il.com>,
  Martin Kepplinger <martink@...teo.de>,  Purism Kernel Team
 <kernel@...i.sm>,  Mauro Carvalho Chehab <mchehab@...nel.org>,  Shawn Guo
 <shawnguo@...nel.org>,  Sascha Hauer <s.hauer@...gutronix.de>,
  Pengutronix Kernel Team <kernel@...gutronix.de>,  Fabio Estevam
 <festevam@...il.com>,  linux-media@...r.kernel.org,  imx@...ts.linux.dev,
  linux-arm-kernel@...ts.infradead.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Enable MIPI filtering by DT on i.MX8M*

Jacopo,

> Let me recap all of this.
>
> With:
>
> - MIPI_CSIx_CSIS_COMMON_CTRL[11:10]
>  "Select Interleave mode" = 0x00 = CH0 only, no data interleave
>
> - MIPI_CSIx_ISP_CONFIGn[7:2]
>   "Image Data Format" = 0x2c = RAW12
>
> Embedded data and OB pixels are filtered (which means we're filtering
> on DT even if MIPI_CSIx_CSIS_COMMON_CTRL[11:10] = 0x0x would suggest
> filtering is not enabled)
>
> However corrupted pixels are still sent through.

Right.

But there is more: there are 3 separate "DT filters":

0x32E40040       0xB0 ISP Configuration Register (ISP_CONFIG_CH0)
   DT 2Ch (RAW12)
0x32E40044  0x2D00500 ISP Resolution Register (ISP_RESOLUTION_CH0) => 1280 * 720

0x32E40050       0xDC ISP Configuration Register (ISP_CONFIG_CH1)
   DT 37h (User Defined 8-bit Data Type 8)
0x32E40054  0x2D00500 ISP Resolution Register (ISP_RESOLUTION_CH1) => 1280 * 720

0x32E40060       0x48 ISP Configuration Register (ISP_CONFIG_CH2)
   DT 12h (Embedded 8-bit non Image Data)
0x32E40064  0x2D00500 ISP Resolution Register (ISP_RESOLUTION_CH2) => 1280 * 720

The 4th set looks the same, but doesn't appear to have its SHADOW
register set, so I'll ignore it for now. I'm ignoring the SYNC registers
as well (offsets ...0x58) - they are zeroed.

It appears the 2 LS bits of ISP_CONFIG_CH* are the number of some output
port. #0 goes to ISP, not sure about the others. Will have a look.

I.e., I can disable CH0 and use CH1 or CH2 to feed image data do ISP -
it works.

MIPI_CSIx_CSIS_COMMON_CTRL:
Bits 18, 17 and 16 respectively reload SHADOW registers for CH2, CH1 and
CH0. For these tests, I have to use
"devmem write 32-bit CSIS_COMMON_CTRL 0x7xxxx" instead of 0x1xxxx so that
all 3 shadow sets are updated (and not only #0, the one in the docs and
used by the drivers).

0x32E40080       0xB0 Shadow Configuration Register (SHADOW_CONFIG_CH0)
   DT 2Ch (RAW12)
0x32E40084  0x2D00500 Shadow Resolution Register (SHADOW_RESOLUTION_CH0) => 1280 * 720
0x32E40090       0xDC Shadow Configuration Register (SHADOW_CONFIG_CH1)
   DT 37h (User Defined 8-bit Data Type 8)
0x32E40094  0x2D00500 Shadow Resolution Register (SHADOW_RESOLUTION_CH1) => 1280 * 720
0x32E400A0       0x48 Shadow Configuration Register (SHADOW_CONFIG_CH2)
   DT 12h (Embedded 8-bit non Image Data)
0x32E400A4  0x2D00500 Shadow Resolution Register (SHADOW_RESOLUTION_CH2) => 1280 * 720

Also:
0x32E40100     0x5F10 Frame Counter (FRAME_COUNTER_CH0)
0x32E40104     0x57C4 Frame Counter (FRAME_COUNTER_CH1)
0x32E40108     0x33CF Frame Counter (FRAME_COUNTER_CH2)

Data selected by all 3 sets is somehow fed to the ISP. Now the data
isn't simply appended to the previous fragment. It seems the DT 37h
lines (which appear before the actual image data on the MIPI bus)
somehow overwrite (only) the first line of the image. I'm looking at
it.

INTERLEAVE_MODE = 0 or 2 => only CH0 is used, the first 32 bit in the image
		on CSI1 are corrupted.
INTERLEAVE_MODE = 1 => all 3 CHannels are used, no corruption

There appear to be some subtle differences between 0 and 2, and 1 vs 3.

> If you
>
> - MIPI_CSIx_CSIS_COMMON_CTRL[11:10]
>  "Select Interleave mode" = 0x01 = DT (Data type) only
>
> Embedded data and OB pixels are still filtered, and your corrupt
> pixels are filtered as well.

Right.

> Now, why are "corrupted pixels" filtered away by enabling this option ?
>
> As far as I understand bad pixels are corrupt in their data values,
> the CSI-2 packet header which contains the DT is correct. Is my
> understanding correct ?

I think so. Maybe the corruption happens after the packets are received,
on the 32-bit internal bus maybe.

> It would be nice to actually understand what it does before enabling
> it unconditionally.

Still trying :-) Next Monday, maybe.

Especially I don't know how do I receive multiple DT types, including
12-bit RAW pixels and 8-bit user data. I know it wasn't probably
designed for this, but nevertheless.
-- 
Krzysztof "Chris" Hałasa

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