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

Bryan O'Donoghue
2026-03-27T14:38:19Z

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 ?

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