Re: [RFC PATCH v2 12/16] media: i2c: add Maxim GMSL2/3 serializer and deserializer drivers

[Cosmin Tanislav <demonsingur@gmail.com>]

On 5/7/25 2:22 PM, Dave Stevenson wrote:
> Hi Jakub and Cosmin
> 
> On Tue, 6 May 2025 at 19:34, Jakub Kostiw <jakub.kostiw@videtronic.com> wrote:
>>
>> Hi Cosmin
>>
>> Awesome work. The initiative to establish a common framework for GMSL
>> devices is a great idea.
>>
>> I believe that we have found few bugs:
>>
>>> +#define MAX9296A_BACKTOP22(x)                        (0x31d * (x) * 0x3)
>>
>> The first multiplication is wrong and should be replaced with addition:
>>
>> +#define MAX9296A_BACKTOP22(x)                  (0x31d + (x) * 0x3)
>>
>> The same goes for MAX96724 equivalent macro:
>>
>>> +#define MAX96724_BACKTOP22(x)                        (0x415 * (x) * 0x3)
>>
>> In MAX96714 driver there is an issue with setting up lane-polarities.
>>
>>> +static const struct max9296a_chip_info max96714_info = {
>>> +     .max_register = 0x5011,
>>> +     .set_pipe_stream_id = max96714_set_pipe_stream_id,
>>> +     .set_pipe_enable = max96714_set_pipe_enable,
>>> +     .set_pipe_tunnel_enable = max96714_set_pipe_tunnel_enable,
>>> +     .phys_configs = {
>>> +             .num_configs = ARRAY_SIZE(max96714_phys_configs),
>>> +             .configs = max96714_phys_configs,
>>> +     },
>>> +     .polarity_on_physical_lanes = true,
>>> +     .supports_phy_log = true,
>>> +     .adjust_rlms = true,
>>> +     .num_pipes = 1,
>>> +     .pipe_hw_ids = { 1 },
>>> +     .num_phys = 1,
>>> +     .phy_hw_ids = { 1 },
>>> +     .num_links = 1,
>>> +};
>>
>> In order to make thing work we had to set
>>
>>> +     .polarity_on_physical_lanes = true,
>>
>> To false. So this field is either improperly set for MAX96714, or handling of this case is wrong:
>>
>>> +             if (priv->info->polarity_on_physical_lanes)
>>> +                     map = phy->mipi.data_lanes[i];
>>> +             else
>>> +                     map = i;
>>
>> Upon mentioned changes we have successfully tested two GMSL2
>> combinations on Raspberry 5 platform:
>>
>> 1. MAX96724 + MAX96717 (only 2 MIPI-CSI2 lanes with single camera due to
>> hardware limitations)
>>
>> 2. MAX96714 + MAX96717
> 
> Feel free to shout if you want help on the Pi side.
> 
> Pi5 should be able to extract multiple virtual channels to support
> several sensors simultaneously (up to 4 VC/DT combinations). It does
> need a rework so the CFE runs from memory rather than being fed data
> directly from the CSI-2 receiver, but I believe that is pencilled in
> as future work with libcamera already.
> 

Hi Dave, thanks for your input! I'm glad this is getting some traction.

I'm currently testing using Tomi's pyv4l2 tool, which already contains
RPi5 GMSL configs.

I've tested the multi-camera simultaneously streaming usecase already,
all is working well, and I was able to get 4 separate camera image
streams (or 2 image and 2 meta), streaming to the RPi5, and then to
a remote host (where debayer is feasible to do without the help of an
ISP).

Last time I tried libcamera it was not able to properly configure all
entities, so testing with just the mainline CFE using pyv4l2 makes it
much simpler, since we're only interested in getting our hardware
supported.

> Unless things have regressed, libcamera should report all connected
> sensors to SerDes setups, and set up Media Controller appropriately to
> use them one at a time. I know I've had that working with simple CSI-2
> multiplexers and thought I'd had it working with TI FPD-Link III
> SerDes (Arducam's IMX219 V3Link kit, modded to remove their MCU). I
> don't have any GMSL hardware to test with.
> 
> We're also fairly open to merging drivers and overlays for 3rd party
> hardware into the downstream Pi kernel. If they've been reviewed and
> merged upstream then that is the ideal, but if you're prepared to
> support them, then it saves the user the headache of having to build
> out-of-tree modules.
> 
> Cheers
>    Dave