[PATCH 0/8] media: qcom: camss: support several cameras behind a CSI-2 bridge

[Hitesh Patel]

This series contains the CAMSS changes needed to run two GMSL cameras
on the RB3 Gen2 (QCS6490 / SC7280) vision mezzanine, where a MAX9296A
deserializer sits between the sensors and the SoC. The deserializer and
serializer drivers (the out-of-tree maxim-serdes work for MAX9296A and
MAX96717) and the AR0234/IMX900 sensor drivers are out of tree and not
part of this submission; only the SoC side is here.

Everything CAMSS has seen so far is one sensor wired straight to one
CSIPHY. A CSI-2 to CSI-2 bridge breaks several assumptions that follow
from that, and both bridge topologies were exercised:

 - two cameras aggregated on ONE CSI-2 port as two virtual channels,
   demultiplexed by the CSID to RDI0/RDI1 of the same VFE. The CSIPHY
   and CSID are then shared by two pipelines (patches 5, 6, 8) and the
   VFE 17x has two write masters active (patches 3, 4);

 - two cameras on the deserializer's TWO CSI-2 ports, wired to two
   CSIPHYs. The same subdev then binds for two endpoints (patch 2) and
   heads two independent pipelines (patch 7).

Patch 1 addresses the assumption that the sensor is the CSI-2
transmitter: the rate the receiver has to be programmed for belongs to
whatever drives the bus, and v4l2_get_link_freq() already knows how to
ask it.

Patches 3, 4 and 5 are bug fixes in their own right and are not
specific to a bridge: they are hit by any configuration where two RDI
lines of one VFE stream at the same time.

A CCI fix found during the same bring-up, enabling SCL clock stretching
in standard mode so a sensor reached through the bridge's I2C tunnel
can hold the clock, has been sent separately to linux-i2c. It is
independent of this series.

Tested on RB3 Gen2 with AR0234 and IMX900 cameras on MAX96717
serializers, on the vendor 6.18 tree and on the qualcomm-linux qcom-next
branch (v7.2 based): both cameras streaming concurrently on the two
CSI-2 ports, and each camera started and stopped repeatedly while the
other keeps streaming, without interference. The single-port
virtual-channel aggregation topology is what the original out-of-tree
work targeted; it could not be re-validated in the current state of the
out-of-tree serializer and sensor drivers, so patches 6-8 should be
read with that in mind. Each patch builds and was bisected against
next-20260911 for arm64.


Hitesh Patel (8):
  media: qcom: camss: take the link frequency from the CSI-2 transmitter
  media: qcom: camss: create the source to CSIPHY link per endpoint
  media: qcom: camss: vfe-17x: do not gate write master done on
    IRQ_STATUS_0
  media: qcom: camss: vfe-17x: use the write master matching the RDI
    line
  media: qcom: camss: vfe: only reset the VFE when its last line stops
  media: qcom: camss: refcount streaming on the shared CSIPHY and CSID
  media: qcom: camss: drive streams-aware transmitters through the
    streams API
  media: qcom: camss: enable only the stream of the pipeline's virtual
    channel

 .../media/platform/qcom/camss/camss-csid.c    |   2 +-
 .../media/platform/qcom/camss/camss-csid.h    |   2 +
 .../media/platform/qcom/camss/camss-csiphy.c  |   6 +-
 .../media/platform/qcom/camss/camss-csiphy.h  |   2 +
 .../media/platform/qcom/camss/camss-vfe-17x.c |  33 ++--
 drivers/media/platform/qcom/camss/camss-vfe.c |   8 +
 .../media/platform/qcom/camss/camss-video.c   | 141 ++++++++++++++-
 drivers/media/platform/qcom/camss/camss.c     | 167 +++++++++++++-----
 drivers/media/platform/qcom/camss/camss.h     |   8 +-
 9 files changed, 310 insertions(+), 59 deletions(-)


base-commit: 68142f986ff04b2b70b31db00f719bf690f64a9a
-- 
2.43.0