Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy
Date: Mon Mar 30 2026 - 06:45:31 EST
On 3/30/26 12:02, Bryan O'Donoghue wrote:
On 30/03/2026 08:49, Neil Armstrong wrote:
On 3/27/26 18:42, Bryan O'Donoghue wrote:
On 27/03/2026 15:28, Neil Armstrong wrote:
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.
I'm not sure what point it is you are trying to make here. Are you
trying to say drivers/phy is OK with you but you want an endpoint ? If
so, please just say so.
I'm against using the "phys = <>" property in the CAMSS to reference the
PHYs, a "PHY" in the classic terminology is tied to a single consumer,
and if it can be shared to multiple consumer you must model a mux or
whatever in the middle.
The CSIPHY-to-CSID routing is runtime-configurable and is already
managed by the media controller framework.
DT describes static hardware connections. The dynamic mux is a software
concern, not a hardware description concern.
The PHY API as an internal software implementation is probably fine,
even if it makes implementation of split mode much much harder and
doesn't really solve anything, you can just call init()/poweron()/
poweroff()/exit() directly from the CSIPHY media callbacks.
Great.
I can see an argument for that hence my response to Konrad, I just
don't see why its a Qualcomm specific argument and of course
understood stuff bubbles up in review, we have a public debate and
come to a consensus - that's a good thing.
However, I'd want wider buy-in and understanding that endpoints in the
PHYs is a more accurate description of the data-flow.
It is, and it was designed for that, and extensively used in the media
DT representation, so I wonder here you would not use it...
In an ideal world, you would add nodes for each CAMSS hw elements and
adds port/endpoints links between all nodes to describe the data graph,
this would be used to construct the media controller graph, and make it
much easier supporting new hardware.
Yes but be pragmatic Neil. The first step in making the monolith into
sub-nodes is the CSIPHY.
Once the CSIPHY is in, we can follow on with adding new nodes that way
IPE, BPS, ICP, JPEG whatever and also work on implementing the old stuff
in that new way.
We've been applying DT bindings aplenty without that so far. So we
would establish new CSI2 PHY bindings should represent the sensor
endpoints.
We've been using a dummy representation of CAMM in a single node with
only endpoints connecting to the sensors and hiding all the hardware
layout in code, it doesn't scale and makes supporting new HW hard.
I mean this is common sense, why would we continue to stick to the
current CAMSS bindings ???
We _won't_ I just don't support a big bang integration. Progressive
changes over a longer timeline make the transition manageable, without
accepting endless sub-standard stuff in the meantime or holding up all
new SoC submission unless/until.
I mean there is a CAMSS meeting which I've been running for nearly a
year now that both you and Vlad are invited to where we have been
discussing this for months...
The established process of Linux kernel development is based on email
discussions, the sent changes including CSIPHY dt bindings were plainly
ignored by the maintainer, because it's a NIH material or whatever.
There was a chance to discuss CSIPHY dt bindings changes one year ago,
now it might be not a coincidence that eventually after the series of
updates the new CSIPHY dt bindings will be very close to the once
displayed ones, it took a year, but still this is a good progress IMO.
--
Best wishes,
Vladimir