How to make camera driver supporting multiple MIPI CSI-2 virtual channels?

Question

I'm in the process of writing driver for a device streaming video over MIPI CSI-2 (later called pseudo-camera). Hardware wise it acts as some form of muxer which produces multiple streams over virtual channels.

Doing my research I've found typical CSI-2 cameras in the kernel source are just I²C drivers with struct v4l2_subdev and struct media_pad pad kept in the private structure. Then a pad is an endpoint that links them with other V4L2 subdevices. None of these camera drivers seem to be in anyway tied to the notion of CSI-2 bus, what - as further diggings revealed - means the CSI-2 driver is something abstracted and only logically linked with my pseudo-camera driver.

OK, at this point things are relatively simple - I have driver that sets some frame and pixel formats and tells the hardware to start or stop streaming over I²C bus.

Where I stuck is how MIPI CSI-2 Virtual Channels are represented in this picture. The only place where I can find notion of the Virtual Channel is v4l2_mbus_frame_desc_entry_csi2 data type which seems to be part of the actual frame header. How to configure separate streams of any CSI-2 peripheral of SoC?

Then if I know my physical device connected via FPC to the CSI-2 receiver of the SoC, but transmits more than one Virtual Channel, how to represent them in the driver?

The traditional camera driver's private structure looks more less like this:

struct traditional_i2c_camera {
    struct v4l2_subdev sd;
    struct media_pad pad;
    struct v4l2_mbus_framefmt fmt;
    
    struct clk *xclk;
    unsigned long xclk_freq;

    struct regulator_bulk_data supplies[3];
    struct gpio_desc *enable_gpio;

    struct regmap *map;

    struct ti2cc_controls controls;

    struct mutex mutex;
    bool streaming;
};

To handle multiple Virtual Channels do I need one driver with multiple v4l2_subdev instances or with multiple media_pad instances?

Google is not only helpless in finding relevant information, it's practically misleading pointing at information irrelevant to this particular case.

I wonder how this framework is going to work with first CSI-3 cameras, where there are not only video streams but other data possible.