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

From: Bryan O'Donoghue

Date: Fri Mar 27 2026 - 19:45:59 EST

On 27/03/2026 23:23, Dmitry Baryshkov wrote:
On Sat, Mar 28, 2026 at 01:12:22AM +0200, Vladimir Zapolskiy wrote:
On 3/28/26 00:29, Bryan O'Donoghue wrote:
On 27/03/2026 20:51, Dmitry Baryshkov wrote:
That's just not true. If you read the camx source code you can see
split/combo mode 2+1 1+1 data/clock mode requires special programming of the
PHY to support.
This needs to be identified from the data-lanes / clock-lanes topology.
And once you do that, there would be (probably) no difference in the
hardware definition.


In other words, I'd also ask to drop this mode from the DT. This
infromation can and should be deduced from other, already-defined
properties.

It still needs to be communicated to the PHY from the controller,
however that is not a problem I am trying to solve now.

If I can't get consensus for PHY_QCOM_CSI2_MODE_SPLIT_DPHY then so be it.

I'll aim for DPHY only and we can come back to this topic when someone
actually tries to enable it.


DPHY may be the only supported phy type in the driver, it does not matter
at this point, however it's totally essential to cover the called by you
'split mode' right from the beginning in the renewed device tree binding
descriptions of CAMSS IPs to progress further.

Okay. How would we describe that there are two sensors connected to the
single PHY anyway? How would it be described with the current bindings?

--
With best wishes
Dmitry

Assuming you add endpoints to the PHY i.e. that is what Neil appears to be asking for and I personally am _fine_ with that, then it should just be

port@0
port@1

if port@1 exists, you know you are in split-phy mode.

Its actually straight forward enough, really. To be clear though I can write that yaml - the _most_ support I'm willing to put into the PHY code is to detect the port@1 and say "nope not supported yet", since like CPHY its not.

---
bod