[PATCH v5 0/6] media: qcom: camss: fixes for several cameras behind a CSI-2 bridge
From: Hitesh Patel
Date: Mon Sep 28 2026 - 08:22:24 EST
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 is Loic's removal of the unused gen2 frame skip lookup [1],
carried here because patch 5 would otherwise have to decide what that
lookup should ask. Patch 5 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 6 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) remain dropped. Gjorgji's "add V4L2 subdev
streams API support" series [2] covers that ground properly: tested on
RB3 Gen2 with streams enabled for SC7280, both cameras stream and start
and stop independently without them.
A CCI fix found during the same bring-up, enabling SCL clock stretching,
has been sent separately to linux-i2c [3]. 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 CSID test pattern
generator was exercised after patch 4 as well.
v4 was re-tested on the RB3 Gen2 with the reworked 3/5 and 4/5 in place,
including the case patches 1-3 address: with both cameras aggregated as
VC0 and VC1 on one CSIPHY, so that CSID0 feeds RDI0 and RDI1 of the same
VFE, the two of them stream concurrently and one can be restarted five
times out of five while the other keeps streaming without losing a
frame. Dual-port streaming, the per-camera captures and the resulting
IFE and CSID clock rates are unchanged from before the series.
Re-checked against next-20260925: the series applies cleanly, every
patch builds on its own with W=1 for arm64 (defconfig plus
CONFIG_VIDEO_QCOM_CAMSS=m) and checkpatch --strict is clean.
Changes in v5:
- 4/6: carry Loic's "vfe: Remove unused frame-skip" [1] ahead of the
link frequency patch, at his suggestion
- 5/6: with the gen2 frame skip lookup gone, only camss_get_link_freq()
and camss_get_pixel_clock() move to the transmitter pad and
camss_find_transmitter_pad() can stay static. camss_find_sensor_pad()
stays for the gen1 VFE, whose frame skip query is a genuine sensor
operation and whose result it does program into the hardware
- 1/6, 2/6, 6/6 unchanged
Changes in v4:
- 3/5: move the reset into vfe_disable() and do it under stream_lock as
part of the decrement that reaches zero, instead of sampling
stream_count in vfe_disable_output(), which raced with a concurrent
disable and could skip the reset entirely (Bryan, Loic)
- 4/5: use camss_find_transmitter_pad() for the pixel clock as well
(Loic)
- 1/5, 2/5: Reviewed-by added (Bryan, Loic); 5/5 unchanged
Changes in v3:
- Resend as a standalone series rather than a reply to the v1 thread
(Bryan); no code changes
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 [2] (Loic, Bryan)
[1] https://lore.kernel.org/all/20260928-camss-misc-fixes-v1-1-3e0155af6df5@xxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/20260911062213.195007-1-gjorgji.rosikopulos@xxxxxxxxxxxxxxxx/
[3] https://lore.kernel.org/linux-i2c/20260921131954.1690578-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
Loic Poulain (1):
media: qcom: camss: vfe: Remove unused frame-skip
.../media/platform/qcom/camss/camss-vfe-17x.c | 46 +-----
drivers/media/platform/qcom/camss/camss-vfe.c | 18 +--
drivers/media/platform/qcom/camss/camss.c | 131 ++++++++++++------
3 files changed, 93 insertions(+), 102 deletions(-)
base-commit: f5f84daefcd92d7a630066635ecea1433ed5eac7
--
2.43.0