[PATCH v2 0/5] media: qcom: camss: fixes for 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.

Patches 1-3 are fixes for two RDI lines streaming on the same VFE, hit
by any configuration in which the CSID demultiplexes several virtual
channels, not only by a bridge: the VFE 17x interrupt handler drops
write master buffer done events, VFE 17x hands the second line the
wrong write master, and stopping one line resets the VFE underneath
the other.

Patch 4 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. Patch 5 lets one transmitter with several CSI-2 outputs link
each output to its own CSIPHY.

The v1 patches 6-8 (shared CSIPHY/CSID refcount and the streams API
handling in camss-video) are dropped. Gjorgji's "add V4L2 subdev streams
API support" series [1] covers that ground properly: tested on RB3 Gen2
with streams enabled for SC7280, both cameras stream and start/stop
independently without them. The SC7280 enablement and one fix for that
series are posted on its thread.

A CCI fix found during the same bring-up, enabling SCL clock stretching
in standard mode, has been sent separately to linux-i2c [2]. 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. v2 was re-run on the
qcom-next tree, including the CSID test pattern generator after patch
4. Each patch builds and was bisected against next-20260911 for arm64.

Changes in v2:
- Fixes first, with Fixes: tags and "Fix" titles, commit logs rewritten
  (Bryan)
- 1/5: no PIX special case, plain removal of the IRQ_STATUS_0 gate
  (Bryan)
- 2/5: use vfe_get_output_v2() on 17x like the other gen2 VFEs instead
  of a 17x-only mapping; no PIX special case (Bryan)
- 3/5: commit log rewritten without part names and with the affected
  line spelled out (Bryan)
- 4/5: camss taken from the entity's media device instead of an extra
  argument, so the callers are unchanged; multi-line clause split
  (Bryan)
- 5/5: Reviewed-by added (Bryan)
- v1 6-8 dropped in favour of [1] (Loic, Bryan)

[1] https://lore.kernel.org/all/20260911062213.195007-1-gjorgji.rosikopulos@xxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/linux-i2c/20260914132328.976902-1-hitesh@xxxxxxxxxxxxxx/


Hitesh Patel (5):
  media: qcom: camss: vfe-17x: Fix write master buffer done being
    dropped
  media: qcom: camss: vfe-17x: Fix write master selection for RDI lines
  media: qcom: camss: vfe: Fix VFE reset while another line is streaming
  media: qcom: camss: Take the link frequency from the CSI-2 transmitter
  media: qcom: camss: Create the source to CSIPHY link per endpoint

 .../media/platform/qcom/camss/camss-vfe-17x.c |  46 +------
 drivers/media/platform/qcom/camss/camss-vfe.c |   8 ++
 drivers/media/platform/qcom/camss/camss.c     | 121 ++++++++++++------
 3 files changed, 93 insertions(+), 82 deletions(-)


base-commit: 68142f986ff04b2b70b31db00f719bf690f64a9a
-- 
2.43.0