Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue
Date: Fri Mar 27 2026 - 10:39:15 EST
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 CSI2Does the_PHY_ DT node need to be aware about this upfront?
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
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 ?
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.
Note this is a question and I'm not aware of all the possible combinations
Konrad