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

[Hitesh Patel]

Gjorgji asked me to post what I have so he can fold it into v2 of

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

so here it is. These four patches apply on top of that series; they do
not build without it.

1/4 and 2/4 are what that series needs to build and apply on current
linux-next. Only its patch 1/8 needs hand work; 2/8 to 8/8 apply
unchanged.

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  Bryan asked for the flag at the SoC rather than on each CSIPHY and
     CSID. struct camss_resources is already the per-SoC descriptor, so
     declaring streams_enable there and reading camss->res->streams_enable
     takes SM8250 from fourteen assignments to one.

3/4  SC7280 enablement, now 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

     Gjorgji, you thought this one could go away in v2. It cannot, and it
     is worse than I first described: the pad count in your 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 any platform
     that links all CSIDs to all VFEs fails to probe whether or not the
     streams API is enabled for it.

The CSIPHY rebase for your 1/8 is not included here, since it is your
patch to amend; the resolution is in my reply on that thread. The short
version is that 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 Gen2 (QCS6490 / SC7280) against next-20261009:

  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.

A correction to the scope I gave on the 0/8 thread: I said I would
follow up with the two-camera MAX9296A case on linux-next. I withdraw
that. The upstream qcs6490-rb3gen2 files describe only the on-board
IMX577, and our GMSL mezzanine DT is not upstream and is not something
we plan to push, so that 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. If SER/DES behaviour matters for a future revision I
can retest there, but I cannot offer it against linux-next.

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.

v4: Posted as a series at Gjorgji's request, for folding into his v2.
    Added 1/4 (set_fmt signature) and 2/4 (SoC-level flag, per Bryan).
    3/4 is now a single line instead of fifteen. 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

 drivers/media/platform/qcom/camss/camss-csid.c   |  3 ++-
 drivers/media/platform/qcom/camss/camss-csid.h   |  1 -
 drivers/media/platform/qcom/camss/camss-csiphy.c |  4 ++--
 drivers/media/platform/qcom/camss/camss-csiphy.h |  1 -
 drivers/media/platform/qcom/camss/camss-vfe.c    | 10 +++++-----
 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, 16 insertions(+), 25 deletions(-)
-- 
2.43.0