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@xxxxxxxxxx>
---
RFC verion of the change:
* https://lore.kernel.org/all/20250513143918.2572689-1-vladimir.zapolskiy@xxxxxxxxxx/
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.
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.
--
Best wishes,
Vladimir
