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

[Bryan O'Donoghue]

On 16/07/2026 09:56, Loic Poulain wrote:
> On Mon, Jul 13, 2026 at 1:18 AM Bryan O'Donoghue <bod@xxxxxxxxxx> wrote:
> > On 09/07/2026 08:40, Vladimir Zapolskiy wrote:
> > > > As explained in the cover letter: I'm following guidance from Rob on that.
> > > Pehaps you've misread a given review comment, because Rob's guidance is
> > > to remove 'phy-type' property,
> >
> > I'll just quote verbatim "Perhaps putting this in phy cells would be
> > better because the consumer decides on the mode."
> >
> > That is not "remove phy-type" - it's "move the mode into the cell". I'm
> > shifting this back to the DT schema maintainers since, I take their
> > feedback literally, seriously and canonically.
> >
> > Any of the triumvirate will do, Rob, Krzysztof or Conor.
> >
> > Absent a different answer from the DT schema guys, v10 ships with the
> > consumer deciding the mode as per Rob's original guidance.
>
> On the #phy-cells question, IMO we should drop #phy-cells to 0 and
> derive the C-PHY/D-PHY mode from the endpoint bus-type. The operating
> mode is really a configuration of the link rather than a hardware
> description/limitation of the PHY block itself,and the sensor endpoint
> is conventionally where the bus type originates. I guess this costs us
> nothing on the driver side today, we only support D-PHY, so the
> mode-check just moves into the endpoint parsing we already do in
> phy_qcom_mipi_csi2_parse_routing(). It can be a minimal
> fwnode_property_read_u32(ep, "bus-type", ...) sanity check and adding
> C-PHY later is then a one-line case MEDIA_BUS_TYPE_CSI2_CPHY
> with no DT ABI change.

So I take your point on link-type - in theory you can select the mode 
from the sensor @ config time. The established practice is that the 
consumer decides the PHY mode, so if we wanted to make this a _runtime_ 
configuration - then that should be information that is passed to the 
PHY via configure() not via DT because we've said its a link-mode 
abstracted from the DT entirely.

In the extreme case I have a user-space utility selecting sensor mode, 
which the CSI controller parses and then signals the PHY to switch modes.

If its a run-time config, then its a run-time config and DT should be 
excluded from the mode selection tree.

I'm in fact willing to entertain this idea - but it will require passing 
the PHY mode to configure() not consuming - DT data from the endpoint.

My core point here is both acknowleding Rob's point the consumer decides 
the mode - and _if_ we go the runtime configuration route, then actually 
making the selection @ configure not at probe/dt parse time.

I just wonder if there's any real upside to all that additional work and 
delay/churn.

> On data-lanes numbering, I don't have a strong opinion here. Keeping
> the current 0-based values is defensible, in this driver the value is
> used as a physical lane index and it selects the per-lane register
> bank (0x200 * n), so 0 maps to physical LN0. In that sense 0-based is
> a faithful representation of the physical lane position on the SoC.
>
> Regards,
> Loic