From: Gjorgji Rosikopulos <gjorgji.rosikopulos@oss.qualcomm.com>

This series adds V4L2 subdev streams API support to the CAMSS driver.

Each subdevice gains streams-aware enable_streams/disable_streams pad
ops alongside the existing legacy (non-streams) subdev ops, guarded by
a new per-instance streams_enable resource flag.

Patches 1-4 add the CSIPHY/CSID mechanism:
 - CSIPHY: passthrough routing, NO_STREAM_MIX/NO_N_TO_1 validation, and
   shared D-PHY lane enable/disable gated on stream-count transitions.
 - CSID: per-source-pad routing (a single sink stream propagated to
   every source pad by default, remappable for multi-VC sensors),
   VC/DT discovery via get_frame_desc, and new hw_ops
   (configure_rx/enable_stream/disable_stream) with a gen2 backend
   implementation.

Patch 5 is a standalone bug fix, independent of the streams API:
camss_link_entities() used to create an all-to-all CSID-to-VFE
crossbar, but SM8250's hardware wiring is a fixed 1:1 pairing
(csid[i] <-> vfe[i]). Enabling a mismatched link (e.g. csid0 -> vfe1)
exposed a media link with no real hardware datapath. Fixed via an
opt-in csid_vfe_fixed_pairing flag, set only for sm8250_resources.

Patches 6-8 complete the mechanism and turn it on for real hardware:
 - VFE: streams-aware pad ops. VFE lines are inherently single-consumer
   (vfe_link_setup() enforces one link per pad), so no refcounting is
   needed there.
 - camss-video: the video device pipeline walk now checks, via
   v4l2_subdev_has_op(), whether the directly-connected subdev supports
   enable_streams/disable_streams; if so it issues a single top-level
   call instead of manually walking the pipeline one subdev at a time
   with .s_stream(). Falls back to the existing legacy path unchanged
   when the remote subdev doesn't support the streams API, so no other
   platform is affected.
 - SM8250: streams_enable is set true on every CSIPHY, CSID, and VFE
   line resource entry, turning the mechanism on for real hardware.
   Every other platform keeps using the legacy non-streams subdev ops,
   so this is a no-op everywhere else.

A practical benefit of the CSID routing change (patch 4) is routing
flexibility for multi-VC sensors: the CSID's routing table maps sink
streams to source pads/streams via userspace-configurable
v4l2_subdev_route entries instead of a fixed pad<->VC assignment, so a
sensor emitting multiple virtual channels can have each VC directed to
a different RDI output (and thus a different VFE line/video node)
with a set_routing call, rather than being constrained to whatever
fixed mapping the driver hardcodes.

When a sink stream is shared by multiple source pads/streams, CSID
only enables the corresponding upstream CSIPHY stream on the first
source stream that needs it, and only disables it once the last
remaining source stream using it is disabled. Enabling or disabling
additional consumers of an already-active shared stream is a no-op
upstream, so no consumer can double-enable or prematurely disable a
stream still in use by another. This also avoids ever hitting v4l2
core's own -EALREADY re-enable gate.

Verified clean with checkpatch --strict. Built, flashed, and tested on
RB5/SM8250 hardware; ran the no-routing capture verification test
across all four CSID/VFE RDI pairs (csid0->vfe0, csid1->vfe1,
csid2->vfe2, csid3->vfe3) at 4056x3040 - all four passed with
correctly-sized frame captures.

Gjorgji Rosikopulos (8):
  media: qcom: camss: Add streams API support for CSIPHY
  media: qcom: camss: Add streams API hw_ops to CSID interface
  media: qcom: camss: Implement CSID streams API hw_ops for gen2
  media: qcom: camss: Add streams API support in CSID subdevice
  media: qcom: camss: Fix CSID-to-VFE all-to-all link crossbar on sm8250
  media: qcom: camss: add streams API support for VFE
  media: qcom: camss: add streams API support in camss-video
  media: qcom: camss: enable streams API on SM8250

 .../platform/qcom/camss/camss-csid-gen2.c     |  59 ++-
 .../media/platform/qcom/camss/camss-csid.c    | 494 +++++++++++++++++-
 .../media/platform/qcom/camss/camss-csid.h    |  45 ++
 .../media/platform/qcom/camss/camss-csiphy.c  | 223 +++++++-
 .../media/platform/qcom/camss/camss-csiphy.h  |   2 +
 drivers/media/platform/qcom/camss/camss-vfe.c | 119 ++++-
 drivers/media/platform/qcom/camss/camss-vfe.h |   1 +
 .../media/platform/qcom/camss/camss-video.c   | 119 ++++-
 drivers/media/platform/qcom/camss/camss.c     |  21 +-
 drivers/media/platform/qcom/camss/camss.h     |   7 +
 10 files changed, 1046 insertions(+), 44 deletions(-)

-- 
2.34.1

Hi Gjorgji,

I tested this series on RB3 Gen2 (QCS6490 / SC7280) with two GMSL
cameras behind a MAX9296A deserializer, one camera per CSI-2 port, so
that the deserializer subdev heads two independent camss pipelines.
That is the case my own series [1] patches 6-8 tried to handle in
camss-video; with your series enabled on SC7280 they are not needed,
and I have dropped them from v2 of that series.

Results with streams_enable set on the SC7280 CSIPHY/CSID/VFE
resources (patch below):

- each camera alone, repeated start/stop: 5/5 and 5/5
- both cameras streaming at the same time: works
- the second camera started and stopped 8 times while the first one
  keeps streaming: 7/8, the first camera never disturbed. The one miss
  is a sensor/serializer settling issue we see on every kernel when
  the second camera is started within ~2 s of the first, unrelated to
  camss.
- CSID test pattern generator still works.

One problem found, fixed by the first patch below: with the streams
API a non-lite CSID registers 4 pads, but camss_link_entities() still
links CSID source pad MSM_CSID_PAD_FIRST_SRC + j to line j of every
VFE. On SC7280 the non-lite csid0 is linked to vfe_lite0, which has
four lines, so it asks for source pad 4 and the driver fails to probe:

  WARNING: drivers/media/mc/mc-entity.c:1150 media_create_pad_link
  qcom-camss acb3000.isp: Failed to link msm_csid0->msm_vfe3_rdi3 entities: -22

SM8250 does not see it because of csid_vfe_fixed_pairing. You may
prefer to fold the guard into patch 4, or keep all MSM_CSID_PADS_NUM
pads for the non-lite CSID; either works for me.

A note on the test tree: the series applies cleanly to next-20260911,
but our board runs the qualcomm-linux qcom-next branch (v7.2), whose
camss-csiphy.c has a legacy/generic-PHY ops split that yours does not
know about. I ported the CSIPHY part by hand there (a second
csiphy_streams_v4l2_ops carrying the legacy core ops, and the
enable/disable_streams helpers calling csiphy_set_stream_legacy() when
csiphy->phy is not available). Worth keeping in mind if this series
is meant to land in qcom-next as well.

The three VFE fixes in [1] (buffer done gating, write master
selection on 17x, VFE reset with another line streaming) are needed
on top of your series too for two RDI lines on one VFE; they are
independent and I have kept them in v2.

[1] https://lore.kernel.org/linux-media/20260914133416.1030231-1-hitesh@ebytelogic.com/

Tested-by: Hitesh Patel <hitesh@ebytelogic.com>

Hitesh Patel (2):
  media: qcom: camss: Do not link CSID source pads the CSID does not have
  media: qcom: camss: Enable the streams API on SC7280

(the two patches follow as replies to this mail)

On 11/09/2026 07:22, 
Gjorgji.Rosikopulos.gjorgji.rosikopulos@oss.qualcomm.com wrote:
> From: Gjorgji Rosikopulos <gjorgji.rosikopulos@oss.qualcomm.com>
> 
> This series adds V4L2 subdev streams API support to the CAMSS driver.

Can you please provide a use-case and test in your overview.

i.e. show what it does and show it doesn't break anything in a way a 
reviewer can test ?

> Each subdevice gains streams-aware enable_streams/disable_streams pad
> ops alongside the existing legacy (non-streams) subdev ops, guarded by
> a new per-instance streams_enable resource flag.
> 
> Patches 1-4 add the CSIPHY/CSID mechanism:
>   - CSIPHY: passthrough routing, NO_STREAM_MIX/NO_N_TO_1 validation, and
>     shared D-PHY lane enable/disable gated on stream-count transitions.
>   - CSID: per-source-pad routing (a single sink stream propagated to
>     every source pad by default, remappable for multi-VC sensors),
>     VC/DT discovery via get_frame_desc, and new hw_ops
>     (configure_rx/enable_stream/disable_stream) with a gen2 backend
>     implementation.
> 
> Patch 5 is a standalone bug fix, independent of the streams API:
> camss_link_entities() used to create an all-to-all CSID-to-VFE
> crossbar, but SM8250's hardware wiring is a fixed 1:1 pairing
> (csid[i] <-> vfe[i]). Enabling a mismatched link (e.g. csid0 -> vfe1)
> exposed a media link with no real hardware datapath. Fixed via an
> opt-in csid_vfe_fixed_pairing flag, set only for sm8250_resources.
> 
> Patches 6-8 complete the mechanism and turn it on for real hardware:
>   - VFE: streams-aware pad ops. VFE lines are inherently single-consumer
>     (vfe_link_setup() enforces one link per pad), so no refcounting is
>     needed there.
>   - camss-video: the video device pipeline walk now checks, via
>     v4l2_subdev_has_op(), whether the directly-connected subdev supports
>     enable_streams/disable_streams; if so it issues a single top-level
>     call instead of manually walking the pipeline one subdev at a time
>     with .s_stream(). Falls back to the existing legacy path unchanged
>     when the remote subdev doesn't support the streams API, so no other
>     platform is affected.
>   - SM8250: streams_enable is set true on every CSIPHY, CSID, and VFE
>     line resource entry, turning the mechanism on for real hardware.
>     Every other platform keeps using the legacy non-streams subdev ops,
>     so this is a no-op everywhere else.
> 
> A practical benefit of the CSID routing change (patch 4) is routing
> flexibility for multi-VC sensors: the CSID's routing table maps sink
> streams to source pads/streams via userspace-configurable
> v4l2_subdev_route entries instead of a fixed pad<->VC assignment, so a
> sensor emitting multiple virtual channels can have each VC directed to
> a different RDI output (and thus a different VFE line/video node)
> with a set_routing call, rather than being constrained to whatever
> fixed mapping the driver hardcodes.
> 
> When a sink stream is shared by multiple source pads/streams, CSID
> only enables the corresponding upstream CSIPHY stream on the first
> source stream that needs it, and only disables it once the last
> remaining source stream using it is disabled. Enabling or disabling
> additional consumers of an already-active shared stream is a no-op
> upstream, so no consumer can double-enable or prematurely disable a
> stream still in use by another. This also avoids ever hitting v4l2
> core's own -EALREADY re-enable gate.
> 
> Verified clean with checkpatch --strict. Built, flashed, and tested on
> RB5/SM8250 hardware; ran the no-routing capture verification test
> across all four CSID/VFE RDI pairs (csid0->vfe0, csid1->vfe1,
> csid2->vfe2, csid3->vfe3) at 4056x3040 - all four passed with
> correctly-sized frame captures.

What's that - please detail your exact steps in the cover letter. What I 
need to see in the first instance is that nothing breaks.

Maybe try running libcamera cam with or without gpuisp. Show some yavta 
commands to prove nothing breaks and then something to show how to use 
your code.

> 
> Gjorgji Rosikopulos (8):
>    media: qcom: camss: Add streams API support for CSIPHY
>    media: qcom: camss: Add streams API hw_ops to CSID interface
>    media: qcom: camss: Implement CSID streams API hw_ops for gen2
>    media: qcom: camss: Add streams API support in CSID subdevice
>    media: qcom: camss: Fix CSID-to-VFE all-to-all link crossbar on sm8250
>    media: qcom: camss: add streams API support for VFE
>    media: qcom: camss: add streams API support in camss-video
>    media: qcom: camss: enable streams API on SM8250
> 
>   .../platform/qcom/camss/camss-csid-gen2.c     |  59 ++-
>   .../media/platform/qcom/camss/camss-csid.c    | 494 +++++++++++++++++-
>   .../media/platform/qcom/camss/camss-csid.h    |  45 ++
>   .../media/platform/qcom/camss/camss-csiphy.c  | 223 +++++++-
>   .../media/platform/qcom/camss/camss-csiphy.h  |   2 +
>   drivers/media/platform/qcom/camss/camss-vfe.c | 119 ++++-
>   drivers/media/platform/qcom/camss/camss-vfe.h |   1 +
>   .../media/platform/qcom/camss/camss-video.c   | 119 ++++-
>   drivers/media/platform/qcom/camss/camss.c     |  21 +-
>   drivers/media/platform/qcom/camss/camss.h     |   7 +
>   10 files changed, 1046 insertions(+), 44 deletions(-)
>

Hi Bryan thanks for the review,

On 9/11/2026 1:19 PM, Bryan O'Donoghue wrote:
> On 11/09/2026 07:22, 
> Gjorgji.Rosikopulos.gjorgji.rosikopulos@oss.qualcomm.com wrote:
>> From: Gjorgji Rosikopulos <gjorgji.rosikopulos@oss.qualcomm.com>
>>
>> This series adds V4L2 subdev streams API support to the CAMSS driver.
> 
> Can you please provide a use-case and test in your overview.

The use case is having multi VC sensor operating in DOL mode,
i have locally some register settings for enabling that and verify
the multi VC but unfortunately i dont have permission to post that upstream
for now... 

> 
> i.e. show what it does and show it doesn't break anything in a way a 
> reviewer can test ?

I have shell scripts setting up the links using media-ctl and streaming
with v4l2-ctl, i will post the content in the cover letter in next patchset.

> 
>> Each subdevice gains streams-aware enable_streams/disable_streams pad
>> ops alongside the existing legacy (non-streams) subdev ops, guarded by
>> a new per-instance streams_enable resource flag.
>>
>> Patches 1-4 add the CSIPHY/CSID mechanism:
>>   - CSIPHY: passthrough routing, NO_STREAM_MIX/NO_N_TO_1 validation, and
>>     shared D-PHY lane enable/disable gated on stream-count transitions.
>>   - CSID: per-source-pad routing (a single sink stream propagated to
>>     every source pad by default, remappable for multi-VC sensors),
>>     VC/DT discovery via get_frame_desc, and new hw_ops
>>     (configure_rx/enable_stream/disable_stream) with a gen2 backend
>>     implementation.
>>
>> Patch 5 is a standalone bug fix, independent of the streams API:
>> camss_link_entities() used to create an all-to-all CSID-to-VFE
>> crossbar, but SM8250's hardware wiring is a fixed 1:1 pairing
>> (csid[i] <-> vfe[i]). Enabling a mismatched link (e.g. csid0 -> vfe1)
>> exposed a media link with no real hardware datapath. Fixed via an
>> opt-in csid_vfe_fixed_pairing flag, set only for sm8250_resources.
>>
>> Patches 6-8 complete the mechanism and turn it on for real hardware:
>>   - VFE: streams-aware pad ops. VFE lines are inherently single-consumer
>>     (vfe_link_setup() enforces one link per pad), so no refcounting is
>>     needed there.
>>   - camss-video: the video device pipeline walk now checks, via
>>     v4l2_subdev_has_op(), whether the directly-connected subdev supports
>>     enable_streams/disable_streams; if so it issues a single top-level
>>     call instead of manually walking the pipeline one subdev at a time
>>     with .s_stream(). Falls back to the existing legacy path unchanged
>>     when the remote subdev doesn't support the streams API, so no other
>>     platform is affected.
>>   - SM8250: streams_enable is set true on every CSIPHY, CSID, and VFE
>>     line resource entry, turning the mechanism on for real hardware.
>>     Every other platform keeps using the legacy non-streams subdev ops,
>>     so this is a no-op everywhere else.
>>
>> A practical benefit of the CSID routing change (patch 4) is routing
>> flexibility for multi-VC sensors: the CSID's routing table maps sink
>> streams to source pads/streams via userspace-configurable
>> v4l2_subdev_route entries instead of a fixed pad<->VC assignment, so a
>> sensor emitting multiple virtual channels can have each VC directed to
>> a different RDI output (and thus a different VFE line/video node)
>> with a set_routing call, rather than being constrained to whatever
>> fixed mapping the driver hardcodes.
>>
>> When a sink stream is shared by multiple source pads/streams, CSID
>> only enables the corresponding upstream CSIPHY stream on the first
>> source stream that needs it, and only disables it once the last
>> remaining source stream using it is disabled. Enabling or disabling
>> additional consumers of an already-active shared stream is a no-op
>> upstream, so no consumer can double-enable or prematurely disable a
>> stream still in use by another. This also avoids ever hitting v4l2
>> core's own -EALREADY re-enable gate.
>>
>> Verified clean with checkpatch --strict. Built, flashed, and tested on
>> RB5/SM8250 hardware; ran the no-routing capture verification test
>> across all four CSID/VFE RDI pairs (csid0->vfe0, csid1->vfe1,
>> csid2->vfe2, csid3->vfe3) at 4056x3040 - all four passed with
>> correctly-sized frame captures.
> 
> What's that - please detail your exact steps in the cover letter. What I 
> need to see in the first instance is that nothing breaks.
>

Yes i will post them in the next patchset. Along with the routing commands when
stream_api is enabled in the kernel.

 
> Maybe try running libcamera cam with or without gpuisp. Show some yavta 
> commands to prove nothing breaks and then something to show how to use 
> your code.

Also i will verify with libcamera and gpuisp and update the results in
second patchset.

~Gjorgji