Re: [PATCH v7 2/2] arm64: dts: qcom: Add display support for QCS615 RIDE board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/28/2025 7:02 PM, Dmitry Baryshkov wrote:
On Thu, Aug 28, 2025 at 01:12:14PM +0800, Fange Zhang wrote:


On 8/28/2025 12:41 PM, Dmitry Baryshkov wrote:
On Thu, Aug 28, 2025 at 10:57:41AM +0800, Fange Zhang wrote:


On 8/28/2025 4:01 AM, Dmitry Baryshkov wrote:
On Wed, Aug 27, 2025 at 09:08:39PM +0800, Fange Zhang wrote:
From: Li Liu <li.liu@xxxxxxxxxxxxxxxx>

Add display MDSS and DSI configuration for QCS615 RIDE board.
QCS615 has a DP port, and DP support will be added in a later patch.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
Signed-off-by: Li Liu <li.liu@xxxxxxxxxxxxxxxx>
Signed-off-by: Fange Zhang <fange.zhang@xxxxxxxxxxxxxxxx>
---
    arch/arm64/boot/dts/qcom/qcs615-ride.dts | 150 +++++++++++++++++++++++++++++++
    1 file changed, 150 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
index e663343df75d59481786192cde647017a83c4191..f6e0c82cf85459d8989332497ded8b6ea3670c76 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -39,6 +39,76 @@ xo_board_clk: xo-board-clk {
    		};
    	};
+	dp-dsi0-connector {
+		compatible = "dp-connector";
+		label = "DSI0";
+		type = "mini";
+
+		port {
+			dp_dsi0_connector_in: endpoint {
+				remote-endpoint = <&dsi2dp_bridge_out>;
+			};
+		};
+	};
+
+	vreg_12p0: vreg-12p0-regulator {

I should be more carefull when doing reviews. I thought that it was
pointed out already and didn't some of the obvious things...

First of all, the nodes are sorted. By the name, not by the label.
Second, there are already regulators in this file. Why are the new nodes
not following the existing pattern and why are they not placed at a
proper place?

Initially, we referred to https://patchwork.kernel.org/project/linux-arm-msm/patch/20250604071851.1438612-3-quic_amakhija@xxxxxxxxxxx/
as a reference, but its node ordering seems a bit unconventional.

Would this revised ordering be acceptable?

...
+ dp-dsi0-connector

vreg_conn_1p8: regulator-conn-1p8
vreg_conn_pa: regulator-conn-pa
regulator-usb2-vbus

So... Existing regulator nodes have the name of 'regulator-foo-bar'.


+ vreg_12p0: vreg-12p0-regulator
+ vreg_1p0: vreg-1p0-regulator
+ vreg_1p8: vreg-1p8-regulator
+ vreg_3p0: vreg-3p0-regulator
+ vreg_5p0: vreg-5p0-regulator

While yours use 'vreg-baz-regulator'. Why? Don't blindly c&p data from
other platforms.

Got it, The revised format will be:

+ vreg_12p0: regulator-vreg-12p0
+ vreg_1p0: regulator-vreg-1p0
+ vreg_1p8: regulator-vreg-1p8
+ vreg_3p0: regulator-vreg-3p0
+ vreg_5p0: regulator-vreg-5p0

Let me know if you have any further suggestions.

What's the name of power rail in the schematics? vreg-Np0?

I reviewed the Ride board schematics and found the following power rail mappings:

VREG_1P0 -> DSI0_DVDD10 / DSI0_AVDD10 -> ANX7625 AVDD10 / DVDD10
VREG_1P8 -> DSI0_AVDD18 -> ANX7625 AVDD18
VREG_S4A_1P8 -> DSI0_DVDD18 -> ANX7625 DVDD18
VIDEO_OUT_VREG_3P3 -> DSI0_AVDD30 -> ANX7625 AVDD30

would the current approach also be acceptable?
or we need configure the power supplies strictly according to this mapping.
Appreciate your guidance.








[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux