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

[Gjorgji Rosikopulos (Consultant)]

Hi Hitesh,

Thank you for testing and verifying this—I really appreciate it. 
I don’t have the SER/DES setup on my side, so I’ll rely on your verification.

On 9/15/2026 3:15 PM, Hitesh Patel wrote:
> 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.

Thanks good to hear.

> 
> 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

Hmm, i need to check, thank you for catching this.

> 
> 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.

Yes i will take a look and verify with other boards i have. Bryan has comment
for that as well and most probably will be removed in v2 since the 4'th line
on full IFE will be functional soon.

> 
> 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.

Maybe they will need small rework afterm stream_api flag is changes
with list of SoC's which support stream_api.

> 
> [1] https://lore.kernel.org/linux-media/20260914133416.1030231-1-hitesh@xxxxxxxxxxxxxx/
> 
> Tested-by: Hitesh Patel <hitesh@xxxxxxxxxxxxxx>
> 
> 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)

Thanks i will look at them.

~Gjorgji