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

[Neil Armstrong]

Le 27/03/2026 à 15:38, Bryan O'Donoghue a écrit :
> On 27/03/2026 10:07, Konrad Dybcio wrote:
> > On 3/26/26 2:04 AM, Bryan O'Donoghue wrote:
> > > Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
> > > PHY devices.
> > >
> > > The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
> > > capture those modes as:
> > >
> > > - PHY_QCOM_CSI2_MODE_DPHY
> > > - PHY_QCOM_CSI2_MODE_CPHY
> > > - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
> > Does the_PHY_ DT node need to be aware about this upfront?
>
> Yeah that's a fair question.
>
> The standard model is to pass the mode via binding right now. You _could_ configure it @ run time in principle.
>
> And you could even conceive of a sensor hardware that might find value in that - but IMO it's a 100% hypothetical use-case - you'd basically need an FPGA that could output CPHY, DPHY or for some reason SPLIT_MODE DPHY.
>
> But that's a pretty off the wall use-case to hypothesize. Split-mode OTOH is a board-level physical reality which => a DT description not a runtime choice.
>
> > If we have some sideband signal (e.g. the sensor driver specifically
> > requesting C-PHY mode), we can simply throw all this complexity into
> > phy_mode + phy_configure_opts, all at runtime
>
> Like I say its conceivable but IMO not a real thing and unless your sensor is an FPGA not possible to support in real hardware.
>
> > Further, the combo/split mode may possibly be selected through
> > aggregation of requests.
> >
> > The question remains whether the sensor should have a direct connection to
> > the PHY itself (i.e. phys = <&csiphyN> or of_graph straight into the PHY)
> > or whether it's going to be translated by the camss node (which would be
> > the one holding a PHY reference) - there's probably surface for adding such
> > negotiation logic in both places
>
> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?

This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.

The CSIPHYs are not tied to a single "consumer" block, they can be connected to different consumers at runtime, which is not something classic PHY devices are designed for. So they are de facto a media element in the dynamic camera pipeline.

> The model we have right now, right or wrong is sensor endpoint to controller. Similarly the <&phy MODE_GOES_HERE> is a pattern Rob Herring suggested and IMO is a consistent pattern we should aim for upstream. We see it in latest Rockchip, Cadence.

This doesn’t properly describe the data path, we got out of this classic scheme when implementing the whole USB-C complex on qualcomm SoCs where we had to describe the data flow within all the USB/DSP/DP/PHYs elements, and we have a link between the DP controller and the Combo PHY acting as a DRM bridge.
And actually Rob Herring asked use to define the complete data flow, it was a strong requirement. I don't see why we wouldn't here.

Looking at other vendors and sticking to this is wrong, we need to solve how to describe the Qualcomm CAMSS complex with accurate representation of the data flow and hw components interconnections. The choice of kernel API to access an HW element is irrelevant in the discussion.

Starting refactoring the DT representation of CAMSS is good, starting with PHY is weird since I don't see what it does solve we can't solve already,
but you need to take in account how the CSIPHYs are connected to other HW blocks. Simply adding a "phys =" reference from CAMSS node doesn't reflect
at all which HW element will consume the PHY, and what are the link parameters between the consumer and the PHY and between the PHY and the Sensor.
Those are the whole meaning of the port/endpoint links, where we can define multiple endpoints for a same connection to, for example, define multiple sensors on a same PHY for the split-mode.

Neil

> > Note this is a question and I'm not aware of all the possible combinations
> >
> > Konrad