Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema

Bryan O'Donoghue
2026-03-27T01:03:33Z

On 26/03/2026 14:49, Vladimir Zapolskiy wrote:
> Here the description of hardware is done, and my point is that the new
> PHY_QCOM_CSI2_MODE_SPLIT_DPHY phy type is simply not needed, since it's
> possible to give a proper description of hardware without this invention.

Perhaps I'm not understanding you.

If we use PHY_TYPE_DPHY

include/dt-bindings/phy/phy.h:#define PHY_TYPE_DPHY 10

We _must_ then add SPLIT_MODE to phy.h if/when we implement that
support. Which means successfully arguing the toss of weather SPLIT_MODE
is a Qualcommism - a vendor specific mode or not.

<&phy PHY_TYPE_DPHY> committed to an upstream dts will then need to be
supported perpetually.

So for example qrb5615 - kona/rb5 support split mode.

Pretend go with <&phy PHY_TYPE_DPHY>; and retrofit individual PHY
support to this platform.

Grand so far.

The pretend we want to switch from one sensor to a split-mode sensor on
the existing mezzanine.

Then we need a representation of split mode in phy.h to represent that
in DT.

<&phy PHY_TYPE_DPHY_SPLIT_MODE>;

Except split-mode is not an appropriate mode to define in phy.h since it
is vendor specific - even if a few vendors support it, its not a generic
PHY mode.

Hence we would have an enormously difficult time justifying adding that
mode to phy.h and rightly so.

>> https://review.lineageos.org/c/LineageOS/
>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>> cam_csiphy/cam_csiphy_core.c#b285
>>
>> There is disjunction all over this file depending on the mode.
>>
>> https://review.lineageos.org/c/LineageOS/
>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>> cam_csiphy/cam_csiphy_core.c#b767

OTOH

- SPLIT_MODE will certainly require _both_ separate init sequences
and specific logical disjunction for additional configuration steps
lane-assignment and masking, etc.

- That phy.h isn't the right location for SPLIT_MODE as its vendor
specific. Just look at the modes we have for the USB PHYs
same logic => include/dt-bindings/phy/phy-qcom-qmp.h same
raison d'être

- And that specifying PHY_TYPE_DPHY now binds us into an ABI that we
cannot subsequently change - it will not be possible to introduce
include/dt-bindings/phy/phy-qcom-mipi-csi2.h later on with our mode

So therefore include/dt-bindings/phy/phy-qcom-mipi-csi2.h + PHY modes is
the logical outcome.

---
bod