| Message ID | 20250220230818.275262-1-demonsingur@gmail.com |
|---|---|
| Headers | show |
| Series | media: v4l: add support for Virtual Channel IDs | expand |
On 2/21/25 10:38 AM, Sakari Ailus wrote: > Hi Cosmin, > > Thanks for the patches. > > On Fri, Feb 21, 2025 at 01:08:09AM +0200, Cosmin Tanislav wrote: >> Multi-camera systems often have issues with receiving video streams >> from multiple cameras at the same time because the cameras use the same >> Virtual Channel IDs. >> >> CSI bridges might not support remapping the Virtual Channel IDs, making >> it impossible to receive the separate video streams at the same >> time, while the CSI receiver is able to de-mux streams based on VC IDs. >> >> Cameras sometimes have support for changing the VC IDs they output >> themselves. >> >> For a practical example, GMSL2 deserializer chips do not support VC ID >> remapping in tunnel mode, and neither do the serializers. Allowing the >> cameras to have their VC IDs configured would allow multi-camera setups >> to use tunnel mode. > > We've tried to avoid having virtual channels in firmware and in UAPI, > I'm not yet entirely convinced we need to depart from the established > practices. Let's see. Apart from that, please see my comments below. > Sadly there's no other way to handle multi-camera support for GMSL devices that don't support VC ID remapping. And upcomming GMSL3 devices only support tunnel mode which doesn't support any type of remapping. >> >> Add support for specifying these Virtual Channel IDs in Video Interface >> Endpoints. The supported values are 0 to 3, with a maximum of 4 values. >> Although the CSI-2 specification allows for up to 32 virtual channels, >> most hardware doesn't support more than 4. This can be extended later >> if need be. >> >> Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com> >> --- >> .../devicetree/bindings/media/video-interfaces.yaml | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml >> index 038e85b45befa..414b5fa8f3472 100644 >> --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml >> +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml >> @@ -231,6 +231,17 @@ properties: >> shall be interpreted as 0 (ABC). This property is valid for CSI-2 C-PHY >> busses only. >> >> + vc-ids: > > Other properties aren't using abbreviations, at least most of them. How > about "virtual-channels"? > That works for me. >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 1 >> + maxItems: 4 > > Shouldn't this be 32? > For the moment I picked 4 VC IDs (2 bits per VC ID) because any more than that doesn't seem to be supported by CSI receivers, since most do not support extended VC IDs. Also, from the MIPI specification: The Data Identifier byte contains the Virtual Channel Identifier (VC) value and the Data Type (DT) value as illustrated in Figure 32. The Virtual Channel Identifier is contained in the two MS bits of the Data Identifier Byte. The Data Type value is contained in the six LS bits of the Data Identifier Byte. >> + items: >> + maximum: 3 > > 31 here, too. > >> + description: >> + An array of Virtual Channel IDs. These are unsigned integers that specify > > I'd leave out the explanation on the data type. It's redundant. > >> + the VC IDs used by the device for its data streams. This property is valid >> + for MIPI CSI-2 only. >> + >> strobe: >> $ref: /schemas/types.yaml#/definitions/uint32 >> enum: [ 0, 1 ] >
Multi-camera systems often have issues with receiving video streams from multiple cameras at the same time because the cameras use the same Virtual Channel IDs. CSI bridges might not support remapping the Virtual Channel IDs, making it impossible to receive the separate video streams at the same time, while the CSI receiver is able to de-mux streams based on VC IDs. Cameras sometimes have support for changing the VC IDs they output themselves. For a practical example, GMSL2 deserializer chips do not support VC ID remapping in tunnel mode, and neither do the serializers. Allowing the cameras to have their VC IDs configured would allow multi-camera setups to use tunnel mode. Add support for specifying these Virtual Channel IDs in Video Interface Endpoints. Add support for parsing VC IDs in v4l2_fwnode_endpoint_parse(). This allows us to retrieve the specified VC IDs in camera drivers and configure the hardware to use them. The supported values are 0 to 3, with a maximum of 4 values. Although the CSI-2 specification allows for up to 32 virtual channels, most hardware doesn't support more than 4. This can be extended later if need be. The driver must validate the number of VC IDs and the VC IDs themselves. Add an example implementation for IMX219. V2: * goto err_rpm_put on failure to configure VC ID in imx219, and print error Cosmin Tanislav (5): dt-bindings: media: video-interfaces: add support for Virtual Channel IDs media: v4l: fwnode: parse Virtual Channel IDs for CSI2 buses dt-bindings: media: imx219: add support for Virtual Channel IDs media: i2c: imx219: pass format's code to imx219_get_format_bpp() media: i2c: imx219: implement configurable VC ID Laurent Pinchart (1): media: i2c: imx219: Report streams using frame descriptors .../devicetree/bindings/media/i2c/imx219.yaml | 2 + .../bindings/media/video-interfaces.yaml | 11 ++++ drivers/media/i2c/imx219.c | 56 ++++++++++++++++++- drivers/media/v4l2-core/v4l2-fwnode.c | 15 +++++ include/media/v4l2-mediabus.h | 5 ++ 5 files changed, 86 insertions(+), 3 deletions(-)