Re: [PATCH 1/8] media: qcom: camss: Add streams API support for CSIPHY

From: Hitesh Patel

Date: Mon Oct 12 2026 - 05:25:20 EST


On 11/10/2026 23:39, Bryan O'Donoghue wrote:
> ++<<<<<<< HEAD
> + if (camss->legacy_phy)
> + v4l2_subdev_init(sd, &csiphy_v4l2_ops_legacy);
> + else
> + v4l2_subdev_init(sd, &csiphy_v4l2_ops);

That conflict is the legacy/generic-PHY ops split in camss-csiphy.c, which
landed after this series was written. I hit the same thing when I tested the
series on RB3 Gen2, because our board runs qualcomm-linux qcom-next (v7.2),
whose camss-csiphy.c already carries that split.

I resolved it there as follows, in case it saves someone the work:

- a second ops table, csiphy_streams_v4l2_ops_legacy, carrying the legacy
core ops alongside the streams pad ops, so the selection becomes a 2x2
of (legacy_phy, streams_enable) rather than an either/or;

- csiphy_enable_streams()/csiphy_disable_streams() call
csiphy_set_stream_legacy() when csiphy->phy is not available, so the
lane enable/disable on the 0 -> 1 and 1 -> 0 stream transitions goes
through whichever of the two paths the platform actually has.

With that, the streams API and the legacy PHY path coexist and both
continue to work on SC7280.

I am happy to post that as a patch on top of the series, or to hand the
hunks to Gjorgji for folding into v2 - whichever you prefer. I have the
hardware set up and can re-verify either way.

On the wider point from the SC7280 thread:

> Set it @ the SoC not for each csiphy and csid.

Agreed, and legacy_phy itself is the precedent - it is a field on
struct camss_resources, set once per SoC. Moving streams_enable there
makes the two flags consistent and removes the per-subdev repetition my
own patch was adding. Gjorgji, if you would rather I prepare that part,
say so; otherwise I will leave it to v2 and verify the result.

---
Hitesh