Re: [PATCH 08/10] dt-bindings: media: qcom: Add Qualcomm MIPI C-/D-PHY schema for CSIPHY IPs

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 6/12/25 6:44 PM, Vladimir Zapolskiy wrote:
> On 6/12/25 19:17, Konrad Dybcio wrote:
>> On 6/12/25 9:57 AM, Vladimir Zapolskiy wrote:
>>> On 6/12/25 10:39, Krzysztof Kozlowski wrote:
>>>> On 12/06/2025 09:38, Krzysztof Kozlowski wrote:
>>>>> On 12/06/2025 03:15, Vladimir Zapolskiy wrote:
>>>>>> Add dt-binding schema for Qualcomm CAMSS CSIPHY IP, which provides
>>>>>> MIPI C-PHY/D-PHY interfaces on Qualcomm SoCs.
>>>>>>
>>>>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>>>>> ---
>>>>>> RFC verion of the change:
>>>>>> * https://lore.kernel.org/all/20250513143918.2572689-1-vladimir.zapolskiy@linaro.org/
>>>>>>
>>>>>> Changes from RFC to v1:
>>>>>> * moved from phy/qcom,csiphy.yaml to media/qcom,csiphy.yaml,
>>>>>> * added 'clock-names' property,
>>>>>> * removed SM8250 CSIPHY specifics, a generic binding is good enough for now,
>>>>
>>>>
>>>> Now I noticed this... weird change and clearly a no-go.
>>>>
>>>> Device binding cannot be generic, so it is not good enough for now.
>>>> Please write specific bindings for specific hardware.
>>>>
>>>
>>> Can I add platform specific changes on top of the displayed generic one
>>> like in Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
>>> etc?
>>>
>>> The generic compatible is sufficienlty good for adding the enhanced
>>> CSIPHY support to any currently present in the upstream platform CAMSS.
>>>
>>> Obviously I can rename it to something SoC-specific, but then a question
>>> arises, if a selected platform has to be a totally new one in the upstream,
>>> or it could be among any of platforms with a ready CAMSS, and a backward
>>> compatibility is preserved by these series and the new CSIPHY dt bindings.
>>
>> A YAML file hosting common properties will probably be very welcome, but
>> the compatibles must be specific to avoid having to redo this dance in
>> a couple years..
> 
> Right, that's a good way for sure, and I keep this option in my mind.
> 
> My concern is that it might be not a perfect fit particularly for CAMSS
> CSIPHY IPs, because likely at least all currently supported in the upstream
> CAMSS IPs will get one in one equal hardware descriptions, despite CSIPHY
> IPs are obviously different. In other words I anticipate that there will
> be just one platform prefixed YAML file with a long list of various platform
> specific CSIPHYs, and therefore it's just one potential $ref user of this
> hypothetical YAML file containing common device tree properties of CSIPHYs.

One big YAML file may be okay too.. think:

compatible:
	enum:
		- qcom,csiphy-v1.0.0
		- qcom,csiphy-v1.2.0
		- qcom,csiphy-v2.0.0

clocks:
	// if oneOf then that many clocks, else that many

etc. etc.

> 
>> Then, the camera ip is well-versioned, so you can use that as the 'specific'
>> part. It'll also make it easier to resolve the unlikely case of a SoC using
>> a mix of different PHY versions.
>>
> 
> Many thanks for input and reviews, regression test results of the given
> CAMSS driver changes will be also very much appreciated, it may be helpful
> for Bryan.

I'm afraid I don't have any board which would be both unique and
with working camera..

Konrad