Re: [PATCH 0/8] media: qcom: camss: add V4L2 subdev streams API support

[Gjorgji Rosikopulos (Consultant)]

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@xxxxxxxxxxxxxxxx wrote:
>> From: Gjorgji Rosikopulos <gjorgji.rosikopulos@xxxxxxxxxxxxxxxx>
>>
>> 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