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

[Hitesh Patel]

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.

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.

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.

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;

in drivers/media/v4l2-core/v4l2-subdev.c. Until that is set to 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. I lost a while to that before realising the
driver was fine and only the uAPI was hidden.

Bryan, the SoC-level change you asked for is in and tested: streams_enable
on struct camss_resources, read as camss->res->streams_enable by the
three subdevs. SM8250 goes from fourteen assignments to one, SC7280 to a
single line.

I can post the four patches (set_fmt fix, SoC-level flag, SC7280 enable,
CSID pad guard) on top of this series, or Gjorgji can fold them into v2 -
whichever you prefer.

Still to do on my side: the two-camera case with the MAX9296A, which needs
our GMSL board DT ported onto the upstream rb3gen2 files; the result above
is the on-board IMX577 only. I will follow up with that.

Tested-by: Hitesh Patel <hitesh@xxxxxxxxxxxxxx>  # SC7280, single camera

---
Hitesh