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

[Vladimir Zapolskiy]

On 3/27/26 03:03, Bryan O'Donoghue wrote:
> 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.

You are welcome to ask questions, it may save time.

> 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.

I don't think it is the must.

> 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.

First of all, nobody says/defines that the phy type is mandatory to be
present in the cell at all, for instance it could be provided over bus-type
property of media endpoints, and a connected sensor unavoidably postulates
the value of this property.

> 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.

You may think how it should be done, it's been asked for a while to provide
a complete valid example, it may help you to get a better understanding of
the whole picture.

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

Some kind of split mode representation should be in DT, it does not
mean that it sticks to phy.h or whatever else. Lanes (and bus-type) are
described under endpoint device tree nodes, this is totally sufficient
to separate what you call "a split mode". So, it excludes phy.h.

> <&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.

We still discuss a hardware description, it should not be problematic to
provide descriptions of regular DPHY and what you call 'split mode' DPHY
without any new extentions of the existing dt bindings.

> > > 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.

Unnecessary extention of the dt bindings ABI is not needed to complete
the task.

--
Best wishes,
Vladimir