[PATCH v6 0/4] media: qcom: camss: rebase fixes and SC7280 enablement for the streams API

[Hitesh Patel]

These four patches apply on top of Gjorgji's

  [PATCH 0/8] media: qcom: camss: add V4L2 subdev streams API support
  https://lore.kernel.org/r/20260911062213.195007-1-gjorgji.rosikopulos@xxxxxxxxxxxxxxxx

and do not build without it. Gjorgji has asked for them so he can fold
them into his v2.

1/4  set_fmt has gained a const struct v4l2_subdev_client_info *
     parameter, so csid_streams_set_format() no longer matches the op it
     is assigned to.

2/4  The flag at the SoC rather than on each CSIPHY and CSID, as Bryan
     asked. struct camss_resources is already the per-SoC descriptor, so
     declaring streams_enable there takes SM8250 from fourteen
     assignments to one.

3/4  SC7280 enablement, a single line thanks to 2/4.

4/4  Without this, camss does not probe at all once the series is
     applied:

       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

     The pad count in Gjorgji's 4/8 is

       num_pads = csid_is_lite(csid) ? MSM_CSID_PADS_NUM : MSM_CSID_PADS_NUM - 1;

     which depends on lite-ness rather than on streams_enable, so any
     platform that links all CSIDs to all VFEs fails to probe whether or
     not the streams API is enabled for it. Gjorgji has since clarified
     that the pad counts converge once the non-lite IFE pixel path lands,
     at which point this guard changes shape rather than disappearing.

The CSIPHY rebase for Gjorgji's 1/8 is not included here, as that is his
patch to amend; the resolution is in my reply on that thread. SC7280 has
no camss child node named "phy", so camss_detect_legacy_phy() puts it in
legacy mode and the lane enable/disable has to dispatch on
camss->legacy_phy rather than assume the generic PHY path.

Tested on RB3 Gen 2 (QCS6490 / SC7280) against next-20261009 (the v5
base). The v6 rebase onto next-20261020 leaves all four patches
byte-identical and has not been re-run on hardware:

  qcom-camss acb3000.isp: streams_enable=1 legacy_phy=1 version=4
  msm_csiphy0-4: flags=0x14  (FL_STREAMS | FL_HAS_DEVNODE)
  msm_csid0-4:   flags=0x1c  (FL_STREAMS | FL_HAS_EVENTS | FL_HAS_DEVNODE)
  msm_csid0-2: 4 pads, msm_csid3-4 (lite): 5 pads

  imx577 -> csiphy3 -> csid0 -> vfe0_rdi0, SRGGB10_1X10/4056x3040
  msm_csiphy3 routes: 0/0 -> 1/0 [ACTIVE]
  msm_csid0   routes: 0/0 -> 1/0 [ACTIVE]

  10 frames captured off /dev/video0, 4056x3040 pRAA, 5072 bytes per
  line, with real sensor content.

Scope: that capture is the on-board IMX577. The upstream qcs6490-rb3gen2
files describe only that sensor and our GMSL mezzanine DT is not
upstream, so the two-camera MAX9296A case cannot be exercised on a plain
next-20261009. The concurrent two-pipeline result I reported in September
stands on the qualcomm-linux qcom-next branch, which sets
v4l2_subdev_enable_streams_api = true by default so it did go through the
streams API. I can retest there if SER/DES behaviour matters for a future
revision.

Note for anyone else testing this series: the streams uAPI is gated at
compile time by

  static bool v4l2_subdev_enable_streams_api;

in drivers/media/v4l2-core/v4l2-subdev.c. Until that is true,
VIDIOC_SUBDEV_QUERYCAP strips V4L2_SUBDEV_CAP_STREAMS and the routing
ioctls return early, so media-ctl reports no routes and v4l2-ctl says
"Streams API not supported" even though the subdevs have
V4L2_SUBDEV_FL_STREAMS set.

v6: No code change from v5. Reposted carrying base-commit and
    prerequisite-patch-id trailers, which v4 and v5 lost, so that b4
    and the Media CI can apply the series on top of Gjorgji's eight
    patches instead of failing against a plain linux-next. Rebased
    onto next-20261020; all four patches are unchanged by the rebase.
v5: 2/4 reads the flag through a local streams_api bool in every
    function that uses it, rather than a local in CSIPHY and CSID but
    the expression inlined at each VFE call site (Bryan). Two locals
    added in camss-vfe.c and one in msm_csiphy_unregister_entity(); no
    functional change. Rebuilt and rechecked on the board.
v4: Posted as a series at Gjorgji's request. Added 1/4 (set_fmt
    signature) and 2/4 (SoC-level flag, per Bryan). 3/4 became a single
    line. 4/4 unchanged, but its commit message no longer claims the pad
    count depends on the streams API. Tested on next-20261009 rather
    than our vendor branch.
v3: Referenced the prerequisite series with a Link: tag.
v2: Added the dependency to the commit message and as base-commit.

Hitesh Patel (4):
  media: qcom: camss: csid: Match the current set_fmt pad op signature
  media: qcom: camss: Set the streams API flag per SoC
  media: qcom: camss: Enable the streams API on SC7280
  media: qcom: camss: Do not link CSID source pads the CSID does not
    have

 .../media/platform/qcom/camss/camss-csid.c    |  3 ++-
 .../media/platform/qcom/camss/camss-csid.h    |  1 -
 .../media/platform/qcom/camss/camss-csiphy.c  |  6 ++++--
 .../media/platform/qcom/camss/camss-csiphy.h  |  1 -
 drivers/media/platform/qcom/camss/camss-vfe.c | 14 ++++++++------
 drivers/media/platform/qcom/camss/camss-vfe.h |  1 -
 drivers/media/platform/qcom/camss/camss.c     | 19 +++++--------------
 drivers/media/platform/qcom/camss/camss.h     |  2 ++
 8 files changed, 21 insertions(+), 26 deletions(-)


base-commit: 8f7df005a7564bd7ffa75da9c3085d5b996f1e16
prerequisite-patch-id: 4214ff31c7bfc998d477ae38e7bca2dbc5060b5c
prerequisite-patch-id: 5bc4256f5642555995e05c50f38edbb41d4d3212
prerequisite-patch-id: d0bf82158d99863344c206a543d3e381b24a3b51
prerequisite-patch-id: ddffbfdffba948a608fc556a5ca81b9dabae7e00
prerequisite-patch-id: dca159c5eecf280ea7ce7c67f5da2364c8449759
prerequisite-patch-id: 220ee607579892058879cad0ed9344f6696313c8
prerequisite-patch-id: d7665451d090c8d4684c79736ac517d6c7ddc1fc
prerequisite-patch-id: f297c801f0254862e4fc8440dbd27473a8b78159
-- 
2.43.0