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

["Krzysztof Hałasa" <khalasa@piap.pl>]

Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:

>> +++ b/drivers/media/platform/nxp/imx-mipi-csis.c
>> @@ -654,8 +654,7 @@ static void mipi_csis_set_params(struct mipi_csis_device *csis,
>>       val = mipi_csis_read(csis, MIPI_CSIS_CMN_CTRL);
>>       val &= ~MIPI_CSIS_CMN_CTRL_LANE_NR_MASK;
>>       val |= (lanes - 1) << MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET;
>> -     if (csis->info->version == MIPI_CSIS_V3_3)
>> -             val |= MIPI_CSIS_CMN_CTRL_INTER_MODE;
>> +     val |= MIPI_CSIS_CMN_CTRL_INTER_MODE; /* enable filtering by DT */
>
> The condition was added because the CSIS in the i.MX8MM doesn't
> implement the INTERLEAVE_MODE field. We can't remove it unconditionally.

Is this confirmed (and not just an incidental omission from the docs)?
Same version (3.6.3), and even earlier version (3.3) has it... It would
mean MM can't work with those sensors producing extra packets.

I wonder what version is shown in the #0 register on 8MM (8MP shows
3060301).

> You mentioned i.MX8MP, that's a platform where I'd like to see proper
> support for *capturing* embedded data, not just dropping it. Have you
> looked at how this could be implemented ?

I had a brief look at it, but a) the embedded data is not very
interesting in case of my IMX290, b) I don't want to interleave it with
my image data (DMA buffers and what not) and I don't see a way to store
it independently.

If you want to store it along the image, the currect code does that -
more or less correctly. This is the problem.

The RM says "13.5.2.6.6 Null and Blanking Data
For both the null and blanking data types CSIS V3.6.3 ignore the content
of the packet payload data." which is half-truth, e.g. it needs the
MIPI_CSIS_CMN_CTRL_INTER_MODE to do that, otherwise it messes it up.

Several CSIC registers are named XXXXXn, suggesting more than one
register, but the docs say only #0 exists. Nevertheless, the actual
hardware seems to contain 3 packs of registers (the 4th one is weirder):

32E40000:  3060301     4705    F0000 DEADCAFE
32E40010: FFFFFFFF        0        0        0
32E40020:       F0  900001F DEADCAFE DEADCAFE
32E40030:      1F4        0        0        0
32E40040:       B0  4380780        0 DEADCAFE <<< ISP_CONFIG0
32E40050:      8FD 80008000        0 DEADCAFE <<< ISP_CONFIG1
32E40060:      8FE 80008000        0 DEADCAFE <<< ISP_CONFIG2
32E40070:      8FF 80008000        0 DEADCAFE ???
32E40080:       B0  4380780        0 DEADCAFE <<< SHADOW_CONFIG0
32E40090:      8FD 80008000        0 DEADCAFE <<< SHADOW_CONFIG1
32E400A0:      8FE 80008000        0 DEADCAFE <<< SHADOW_CONFIG2
32E400B0:        0        0        0 DEADCAFE
32E400C0:        0 7FFFFFFF        0       E4
32E400D0:        0        0        0 DEADCAFE
32E400E0: DEADCAFE DEADCAFE DEADCAFE DEADCAFE
32E400F0: DEADCAFE DEADCAFE DEADCAFE DEADCAFE
32E40100:     22E1     22E1     22E1        0 <<< FRAME_COUNTER*
32E40110:        0        0        0        0 <<< LINE_INTERRUPT_RATIO*
32E40120:        0 DEADCAFE DEADCAFE DEADCAFE

This is the first CSI. The 3 frame counters are visibly active as well.

The manual states (MIPI_CSIx_ISP_CONFIGn) "NOTE: Not described types are
ignored" and even if not, I can't see what could we do with this extra
data.

Perhaps the CSIC internally has 3 output ports, but only the first one
is connected to ISI and ISP?
-- 
Krzysztof "Chris" Hałasa

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