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

[Bryan O'Donoghue]

On 21/07/2026 12:24, Bryan O'Donoghue wrote:
> On 21/07/2026 12:05, Vladimir Zapolskiy wrote:
>> On 7/21/26 13:47, Bryan O'Donoghue wrote:
>>> On 21/07/2026 10:56, Vladimir Zapolskiy wrote:
>>>> On 7/21/26 12:39, Bryan O'Donoghue wrote:
>>>>> On 21/07/2026 09:17, Vladimir Zapolskiy wrote:
>>>>>>> +  "#phy-cells":
>>>>>>> +    const: 1
>>>>>>> +    description:
>>>>>>> +      The single cell specifies the PHY operating mode.
>>>>>> This has been reported before, #phy-cells shall be 0, the operation
>>>>>> mode is selected by bus-type of endpoints as it is described in
>>>>>> video-interfaces.yaml
>>>>>>
>>>>>> Two competing values are redundant and it opens a door to a wrong
>>>>>> hardware description, the technical discussion has not been started
>>>>>> yet.
>>>>> So as I said before, I'm following Rob Herring's input on this and
>>>>> Krzysztof has given RB for this binding. At this stage, I don't see
>>>>> scope to change it.
>>>>>
>>>>> Adding endpoints was already a compromise to address your feedback,
>>>>> which I hoped would bring you on board with the design.
>>>> That's my comment dated March 27, 2026, and it says moving phy type
>>>> from phy cell to the endpoint property excludes the need to set any
>>>> phy cells:
>>>>
>>>> https://lore.kernel.org/linux-arm-msm/e37ce438-12c7-462d-
>>>> b2bc-1351be62b806 at linaro.org/
>>>>
>>>> The technical comment is left unresponded so far since then.
>>>>
>>>> Since there is no expected phy cells to get on consumer's side, and
>>>> since there is another link between CSIPHY and CSID described in
>>>> video-interfaces.yaml, any kind of dependency of this IP on phy can
>>>> be just removed, which serves the purpose of hardware description
>>>> simplification.
>>>
>>> Rob's v1 feedback was consumer-decides-mode via the cell; Krzysztof has
>>> R-b'd the binding with cells=1.
>>
>> Unfortunately this is not a technical discussion to move forward
>> a better hardware description.
>>
>>> I'm happy to lock down this binding as-is on that basis.
>>>
>>> Are you arguing about phy-cells or are you actually arguing the entire
>>> instantiation of Qualcomm MIPI CSI2 as a standalone generic driver in
>>> drivers/phy ? Its not the same debate at all.
>>
>> So far I don't review the driver, only CSIPHY IP hardware description.
>>
>> In the current version of the hardware description one may find that
>> the exploited 'video-intefaces' interface completely covers the 'phys'
>> interface between CSIPHY and CSID, quite probably both are not needed
>> at the same time, and the simpler 'phys' can be removed without any
>> losses. But if it is kept, then its cell value is anyway redundant.
>>
>>> As the CAMSS maintainer, I'm fully against adding more inline monolithic
>>> CSIPHY init sequences. That could be represented as a separate
>>> linux-media driver but, then that implies that _all_ upstream CSIPHY
>>> drivers in drivers/phy are wrong, and I just don't accept that.
>>
>> Other two drivers are different and should be excluded as good
>> references, both of them links exactly one sensor to exactly one
>> CSI-2 decoder, it's not the case here. Also one of these two drivers
>> has no upstream users.
>>
>>> The bindings have DT maintainer RB, and the driver has Qcom engineer
>>> tested-by, review-by.
>>>
>>> Vinod, Kishon - Again, I'd request this merges as-is.
>>>
>>
> 
> The graph and phys are different layers, endpoints describe the
> media topology, phys is how CSID controls the PHY through the PHY
> framework (phy_get/configure/power_on).
> 
> Removing phys doesn't simplify the description, it removes the control
> interface which is the monolith again.
> 
> We have multiple examples of this model upstream, cdns-dphy-rx +
> ti-csi2rx in-tree, with users.
> 
> I'm still kicking this up to Vinod, Kishon, request stands.
> 
> Multiple DT and driver users are RB/Tested-by on the schema and driver,
> lots of other work is gated.
> 
> It is time to merge.
> 
> Please adjudicate.
> 
> ---
> bod

Had a brief discussion with Vlad, Neil and Vinod

Resolution:

- phys = <> retained
- phy-cells = <0>
- bus-type from the media-controller
   Already specified with camss still aligns with Rob's declaration
   "the consumer defines the mode" so I'm comfortable with this
   compromise position.
   This will still facilitate CPHY work/mode-selection via
   phy_ops->configure() with how to define the CPHY part TBD.
- data-lanes = <0 1 2 3> valid
- MAX_LANES 8 instead of MAX_DATA_LANES 7

- v14 with these changes shortly.

---
bod