On 03-06-2021 01:32, rajeevny@codeaurora.org wrote:
On 02-06-2021 02:28, Rob Herring wrote:
On Mon, May 31, 2021 at 07:03:53PM +0530, Rajeev Nandan wrote:
+properties:
- compatible:
- oneOf:
- const: qcom,dsi-phy-7nmWhen would one use this?
This is for SM8250.
- const: qcom,dsi-phy-7nm-7280- const: qcom,dsi-phy-7nm-8150These don't look like full SoC names (sm8150?) and it's <vendor>,<soc>-<block>.
Thanks, Rob, for the review.
I just took the `compatible` property currently used in the DSI PHY driver (drivers/gpu/drm/msm/dsi/phy/dsi_phy.c), and added a new entry for sc7280. A similar pattern of `compatible` names are used in other variants of the DSI PHY driver e.g. qcom,qcom,dsi-phy-10nm-8998, qcom,dsi-phy-14nm-660 etc.
The existing compatible names "qcom,dsi-phy-7nm-8150" (SoC at the end) make some sense, if we look at the organization of the dsi phy driver code. I am new to this and don't know the reason behind the current code organization and this naming.
Yes, I agree with you, we should use full SoC names. Adding the SoC name at the end does not feel very convincing, so I will change this to the suggested format e.g. "qcom,sm8250-dsi-phy-7nm", and will rename the occurrences in the driver and device tree accordingly. Do I need to make changes for 10nm, 14nm, 20nm, and 28nm DSI PHY too? Bindings doc for these PHYs recently got merged to msm-next [1]
[1] https://gitlab.freedesktop.org/drm/msm/-/commit/8fc939e72ff80116c090aaf03952...
Hi Rob,
I missed adding "robh+dt@kernel.org" earlier in this thread.
Please check my response to your review comments. Regarding your suggestion to use <vendor>,<soc>-<block> format for compatible property, should I also upload a new patch to make changes in 10nm, 14nm, 20nm, and 28nm DSI PHY DT bindings?
Thanks, Rajeev