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

[Gjorgji Rosikopulos (Consultant)]

Hi Hitesh,

To add comments i have missed.

On 10/12/2026 1:54 PM, Hitesh Patel wrote:
> Hi Gjorgji, Bryan,
> 
> I have now run this series on RB3 Gen2 (QCS6490 / SC7280) against
> next-20261009 rather than our vendor branch, so these results apply to
> the tree you are submitting against. Four findings, two of them things
> you cannot see without this hardware.
> 
> 1) Only 1/8 needs rebasing; 2/8 to 8/8 apply unchanged.
> 
>    The CSIPHY ops split is the conflict Bryan reported. Resolution as in
>    my earlier reply: a second ops table carrying the legacy core ops, and
>    the lane enable/disable dispatched on camss->legacy_phy.
> 
>    This is not optional for SC7280. With a debug print at probe:
> 
>      qcom-camss acb3000.isp: streams_enable=1 legacy_phy=1 version=4
> 
>    SC7280 has no camss child node named "phy", so
>    camss_detect_legacy_phy() puts it in legacy mode. Without the
>    dispatch the lanes are driven through the generic PHY path that this
>    platform does not have.
> 
> 2) 4/8 no longer builds. v4l2_subdev_pad_ops::set_fmt has gained a
>    const struct v4l2_subdev_client_info * parameter, so
>    csid_streams_set_format() fails with
>    -Werror=incompatible-pointer-types.

This will be fixed thanks for the summary.

> 
> 3) The CSID pad-link guard cannot be dropped.
> 
>    Gjorgji, you suggested my "Do not link CSID source pads the CSID does
>    not have" would probably go away in v2. It cannot: without it camss
>    does not probe at all on SC7280.
> 
>      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
>      qcom-camss acb3000.isp: probe with driver qcom-camss failed with error -22
> 
>    Note the pad count in 4/8 is
> 
>      num_pads = csid_is_lite(csid) ? MSM_CSID_PADS_NUM : MSM_CSID_PADS_NUM - 1;
> 
>    which depends on lite-ness, not on streams_enable. So this hits every
>    platform that links all CSIDs to all VFEs as soon as the series is
>    applied, whether or not the streams API is enabled for it. My own
>    commit message was wrong to describe it as a streams-API consequence.
>    Confirmed on the board: csid0-2 register 4 pads, csid3-4 (lite) 5.

Maybe i did not express my-self correctly. What i want to say is that 
num of pads will be the same for csid-lite and csid when non-lite ife
pixel path is implemented. The patch will still be present with some changes.

> 
> 4) With the guard applied, the series works.
> 
>      msm_csiphy0-4: flags=0x14  (FL_STREAMS | FL_HAS_DEVNODE)
>      msm_csid0-4:   flags=0x1c  (FL_STREAMS | FL_HAS_EVENTS | FL_HAS_DEVNODE)
> 
>    Routing through the streams API, imx577 -> csiphy3 -> csid0 ->
>    vfe0_rdi0, all SRGGB10_1X10/4056x3040:
> 
>      msm_csiphy3  routes: 0/0 -> 1/0 [ACTIVE]
>      msm_csid0    routes: 0/0 -> 1/0 [ACTIVE]
> 
>    and 10 frames captured off /dev/video0 at 4056x3040 pRAA
>    (15418880 bytes each, 5072 bytes per line), with real sensor content.

Thanks i will take that in to account for verification.

> 
> One thing worth flagging for anyone else testing this: the streams uAPI
> is gated at compile time by
> 
>   static bool v4l2_subdev_enable_streams_api;

I think that this was known but good suggestion i will include that in
the cover letter.

~Gjorgji