[PATCH 0/4] Properly support FriendlyElec HD702E

[PATCH 0/4] Properly support FriendlyElec HD702E

[Robin Murphy]

Hi all,

I've been using the HD702E LCD/touchscreen on my NanoPC-T4 for a few
years using my own DT with the "simple-panel" binding, but now we have
upstream overlays I figured it's about time to try doing it properly.
The screen itself doesn't seem to want to work as a generic "edp-panel",
as it appears the EDID isn't readable until after the whole lot is
enabled - I'm guessing this might be to do with the Analogix driver's
force-hpd behaviour - but since we do already have the legacy data, it
doesn't seem unreasonable to keep using it.

Thanks,
Robin.


Robin Murphy (4):
  dt-bindings: display: panel: Move FriendlyElec HD702E to eDP
  drm/panel-edp: Move FriendlyELEC HD702E
  arm64: dts: rockchip: Move RK3399 eDP pinctrl to boards
  arm64: dts: rockchip: Add overlay for FriendlyElec HD702E

 .../display/panel/panel-edp-legacy.yaml       |  2 +
 .../bindings/display/panel/panel-simple.yaml  |  2 -
 arch/arm64/boot/dts/rockchip/Makefile         |  5 ++
 arch/arm64/boot/dts/rockchip/rk3399-base.dtsi |  2 -
 .../dts/rockchip/rk3399-gru-chromebook.dtsi   |  2 +
 .../dts/rockchip/rk3399-nanopc-t4-hd702e.dtso | 62 +++++++++++++++++++
 .../boot/dts/rockchip/rk3399-pinebook-pro.dts |  2 -
 .../rockchip/rk3399-sapphire-excavator.dts    |  2 +
 drivers/gpu/drm/panel/panel-edp.c             | 26 ++++++++
 drivers/gpu/drm/panel/panel-simple.c          | 25 --------
 10 files changed, 99 insertions(+), 31 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4-hd702e.dtso

-- 
2.34.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 1/4] dt-bindings: display: panel: Move FriendlyElec HD702E to eDP

[Robin Murphy]

The "E" alludes to the fact that FriendlyElec's HD702E is actually an
eDP panel - move its compatible to the appropriate binding doc.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 .../devicetree/bindings/display/panel/panel-edp-legacy.yaml     | 2 ++
 .../devicetree/bindings/display/panel/panel-simple.yaml         | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml
index b308047c1edf..afe7dc54ebf4 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml
@@ -44,6 +44,8 @@ properties:
       - boe,nv133fhm-n62
         # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
       - boe,nv140fhmn49
+        # FriendlyELEC HD702E 800x1280 LCD panel
+      - friendlyarm,hd702e
         # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
       - innolux,n116bca-ea1
         # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 24e277b19094..a01cf025aad1 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -144,8 +144,6 @@ properties:
       - foxlink,fl500wvr00-a0t
         # Frida FRD350H54004 3.5" QVGA TFT LCD panel
       - frida,frd350h54004
-        # FriendlyELEC HD702E 800x1280 LCD panel
-      - friendlyarm,hd702e
         # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
       - giantplus,gpg48273qs5
         # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
-- 
2.34.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 1/4] dt-bindings: display: panel: Move FriendlyElec HD702E to eDP

[Rob Herring (Arm)]

On Tue, 30 Dec 2025 17:20:31 +0000, Robin Murphy wrote:
> The "E" alludes to the fact that FriendlyElec's HD702E is actually an
> eDP panel - move its compatible to the appropriate binding doc.
> 
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  .../devicetree/bindings/display/panel/panel-edp-legacy.yaml     | 2 ++
>  .../devicetree/bindings/display/panel/panel-simple.yaml         | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 2/4] drm/panel-edp: Move FriendlyELEC HD702E

[Robin Murphy]

FriendlyELEC's HD702E module is an eDP panel (in as much as it's some
LVDS LCD behind a Chrontel CH7511B eDP bridge), so move its data over
to the eDP driver, also resolving the warning about the missing bpc
value in the process.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/gpu/drm/panel/panel-edp.c    | 26 ++++++++++++++++++++++++++
 drivers/gpu/drm/panel/panel-simple.c | 25 -------------------------
 2 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
index 415b894890ad..dd53ccc209ce 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1256,6 +1256,29 @@ static const struct panel_desc boe_nv140fhmn49 = {
 	},
 };
 
+static const struct drm_display_mode friendlyarm_hd702e_mode = {
+	.clock		= 67185,
+	.hdisplay	= 800,
+	.hsync_start	= 800 + 20,
+	.hsync_end	= 800 + 20 + 24,
+	.htotal		= 800 + 20 + 24 + 20,
+	.vdisplay	= 1280,
+	.vsync_start	= 1280 + 4,
+	.vsync_end	= 1280 + 4 + 8,
+	.vtotal		= 1280 + 4 + 8 + 4,
+	.flags		= DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc friendlyarm_hd702e = {
+	.modes = &friendlyarm_hd702e_mode,
+	.num_modes = 1,
+	.bpc = 8,
+	.size = {
+		.width	= 94,
+		.height	= 151,
+	},
+};
+
 static const struct drm_display_mode innolux_n116bca_ea1_mode = {
 	.clock = 76420,
 	.hdisplay = 1366,
@@ -1663,6 +1686,9 @@ static const struct of_device_id platform_of_match[] = {
 	}, {
 		.compatible = "boe,nv140fhmn49",
 		.data = &boe_nv140fhmn49,
+	}, {
+		.compatible = "friendlyarm,hd702e",
+		.data = &friendlyarm_hd702e,
 	}, {
 		.compatible = "innolux,n116bca-ea1",
 		.data = &innolux_n116bca_ea1,
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b26b682826bc..3ea52667b858 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2359,28 +2359,6 @@ static const struct panel_desc frida_frd350h54004 = {
 	.connector_type = DRM_MODE_CONNECTOR_DPI,
 };
 
-static const struct drm_display_mode friendlyarm_hd702e_mode = {
-	.clock		= 67185,
-	.hdisplay	= 800,
-	.hsync_start	= 800 + 20,
-	.hsync_end	= 800 + 20 + 24,
-	.htotal		= 800 + 20 + 24 + 20,
-	.vdisplay	= 1280,
-	.vsync_start	= 1280 + 4,
-	.vsync_end	= 1280 + 4 + 8,
-	.vtotal		= 1280 + 4 + 8 + 4,
-	.flags		= DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
-};
-
-static const struct panel_desc friendlyarm_hd702e = {
-	.modes = &friendlyarm_hd702e_mode,
-	.num_modes = 1,
-	.size = {
-		.width	= 94,
-		.height	= 151,
-	},
-};
-
 static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
 	.clock = 9000,
 	.hdisplay = 480,
@@ -5235,9 +5213,6 @@ static const struct of_device_id platform_of_match[] = {
 	}, {
 		.compatible = "frida,frd350h54004",
 		.data = &frida_frd350h54004,
-	}, {
-		.compatible = "friendlyarm,hd702e",
-		.data = &friendlyarm_hd702e,
 	}, {
 		.compatible = "giantplus,gpg482739qs5",
 		.data = &giantplus_gpg482739qs5
-- 
2.34.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 2/4] drm/panel-edp: Move FriendlyELEC HD702E

[neil.armstrong]

On 12/30/25 18:20, Robin Murphy wrote:
> FriendlyELEC's HD702E module is an eDP panel (in as much as it's some
> LVDS LCD behind a Chrontel CH7511B eDP bridge), so move its data over
> to the eDP driver, also resolving the warning about the missing bpc
> value in the process.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>   drivers/gpu/drm/panel/panel-edp.c    | 26 ++++++++++++++++++++++++++
>   drivers/gpu/drm/panel/panel-simple.c | 25 -------------------------
>   2 files changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> index 415b894890ad..dd53ccc209ce 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -1256,6 +1256,29 @@ static const struct panel_desc boe_nv140fhmn49 = {
>   	},
>   };
>   
> +static const struct drm_display_mode friendlyarm_hd702e_mode = {
> +	.clock		= 67185,
> +	.hdisplay	= 800,
> +	.hsync_start	= 800 + 20,
> +	.hsync_end	= 800 + 20 + 24,
> +	.htotal		= 800 + 20 + 24 + 20,
> +	.vdisplay	= 1280,
> +	.vsync_start	= 1280 + 4,
> +	.vsync_end	= 1280 + 4 + 8,
> +	.vtotal		= 1280 + 4 + 8 + 4,
> +	.flags		= DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc friendlyarm_hd702e = {
> +	.modes = &friendlyarm_hd702e_mode,
> +	.num_modes = 1,
> +	.bpc = 8,
> +	.size = {
> +		.width	= 94,
> +		.height	= 151,
> +	},
> +};
> +
>   static const struct drm_display_mode innolux_n116bca_ea1_mode = {
>   	.clock = 76420,
>   	.hdisplay = 1366,
> @@ -1663,6 +1686,9 @@ static const struct of_device_id platform_of_match[] = {
>   	}, {
>   		.compatible = "boe,nv140fhmn49",
>   		.data = &boe_nv140fhmn49,
> +	}, {
> +		.compatible = "friendlyarm,hd702e",
> +		.data = &friendlyarm_hd702e,
>   	}, {
>   		.compatible = "innolux,n116bca-ea1",
>   		.data = &innolux_n116bca_ea1,
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index b26b682826bc..3ea52667b858 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2359,28 +2359,6 @@ static const struct panel_desc frida_frd350h54004 = {
>   	.connector_type = DRM_MODE_CONNECTOR_DPI,
>   };
>   
> -static const struct drm_display_mode friendlyarm_hd702e_mode = {
> -	.clock		= 67185,
> -	.hdisplay	= 800,
> -	.hsync_start	= 800 + 20,
> -	.hsync_end	= 800 + 20 + 24,
> -	.htotal		= 800 + 20 + 24 + 20,
> -	.vdisplay	= 1280,
> -	.vsync_start	= 1280 + 4,
> -	.vsync_end	= 1280 + 4 + 8,
> -	.vtotal		= 1280 + 4 + 8 + 4,
> -	.flags		= DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> -};
> -
> -static const struct panel_desc friendlyarm_hd702e = {
> -	.modes = &friendlyarm_hd702e_mode,
> -	.num_modes = 1,
> -	.size = {
> -		.width	= 94,
> -		.height	= 151,
> -	},
> -};
> -
>   static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
>   	.clock = 9000,
>   	.hdisplay = 480,
> @@ -5235,9 +5213,6 @@ static const struct of_device_id platform_of_match[] = {
>   	}, {
>   		.compatible = "frida,frd350h54004",
>   		.data = &frida_frd350h54004,
> -	}, {
> -		.compatible = "friendlyarm,hd702e",
> -		.data = &friendlyarm_hd702e,
>   	}, {
>   		.compatible = "giantplus,gpg482739qs5",
>   		.data = &giantplus_gpg482739qs5

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Thanks,
Neil

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 2/4] drm/panel-edp: Move FriendlyELEC HD702E

[Doug Anderson]

Hi,

On Tue, Dec 30, 2025 at 9:20 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> FriendlyELEC's HD702E module is an eDP panel (in as much as it's some
> LVDS LCD behind a Chrontel CH7511B eDP bridge), so move its data over
> to the eDP driver, also resolving the warning about the missing bpc
> value in the process.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/gpu/drm/panel/panel-edp.c    | 26 ++++++++++++++++++++++++++
>  drivers/gpu/drm/panel/panel-simple.c | 25 -------------------------
>  2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> index 415b894890ad..dd53ccc209ce 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -1256,6 +1256,29 @@ static const struct panel_desc boe_nv140fhmn49 = {
>         },
>  };
>
> +static const struct drm_display_mode friendlyarm_hd702e_mode = {
> +       .clock          = 67185,
> +       .hdisplay       = 800,
> +       .hsync_start    = 800 + 20,
> +       .hsync_end      = 800 + 20 + 24,
> +       .htotal         = 800 + 20 + 24 + 20,
> +       .vdisplay       = 1280,
> +       .vsync_start    = 1280 + 4,
> +       .vsync_end      = 1280 + 4 + 8,
> +       .vtotal         = 1280 + 4 + 8 + 4,
> +       .flags          = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc friendlyarm_hd702e = {
> +       .modes = &friendlyarm_hd702e_mode,
> +       .num_modes = 1,
> +       .bpc = 8,
> +       .size = {
> +               .width  = 94,
> +               .height = 151,
> +       },
> +};
> +
>  static const struct drm_display_mode innolux_n116bca_ea1_mode = {
>         .clock = 76420,
>         .hdisplay = 1366,
> @@ -1663,6 +1686,9 @@ static const struct of_device_id platform_of_match[] = {
>         }, {
>                 .compatible = "boe,nv140fhmn49",
>                 .data = &boe_nv140fhmn49,
> +       }, {
> +               .compatible = "friendlyarm,hd702e",
> +               .data = &friendlyarm_hd702e,

Do you actually need this? I notice that in the DTS patch you've got
things under the DP AUX bus, which should enable you to use the
generic "edp-panel" compatible string assuming the EDID is populated
properly and there are no problems with power sequencing. IMO the only
reasons we should be adding new entries to "platform_of_match" these
days is if we need to work with some legacy eDP controller that can't
be updated to handle the DP AUX BUS or we've got a controller with a
bogus EDID...

-Doug

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 3/4] arm64: dts: rockchip: Move RK3399 eDP pinctrl to boards

[Robin Murphy]

The EDP_HOTPLUG pin is optional, and muxed with other functions (notably
HDMI CEC), so move its selection from the SoC DTSI to the boards which
apparently want it, namely those which enable eDP without "force-hpd".
By the same token we drop it from Pinebook Pro, which already uses
"force-hpd", and according to the schematics does not have the pin wired
at all.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-base.dtsi              | 2 --
 arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi    | 2 ++
 arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts       | 2 --
 arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts | 2 ++
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
index 4dcceb9136b7..19a312baa9f1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
@@ -2145,8 +2145,6 @@ edp: dp@ff970000 {
 		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>;
 		clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>, <&cru PCLK_VIO_GRF>;
 		clock-names = "dp", "pclk", "grf";
-		pinctrl-names = "default";
-		pinctrl-0 = <&edp_hpd>;
 		power-domains = <&power RK3399_PD_EDP>;
 		resets = <&cru SRST_P_EDP_CTRL>;
 		reset-names = "dp";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index 9d07353df52c..3f3cb0eb5809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -241,6 +241,8 @@ &dmc {
 };
 
 &edp {
+	pinctrl-names = "default";
+	pinctrl-0 = <&edp_hpd>;
 	status = "okay";
 
 	/*
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index eaaca08a7601..dcab04863d28 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -401,8 +401,6 @@ &cpu_l3 {
 
 &edp {
 	force-hpd;
-	pinctrl-names = "default";
-	pinctrl-0 = <&edp_hpd>;
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
index a4ceafe6dd7a..80d6ea0eda84 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
@@ -141,6 +141,8 @@ sdio_pwrseq: sdio-pwrseq {
 };
 
 &edp {
+	pinctrl-names = "default";
+	pinctrl-0 = <&edp_hpd>;
 	status = "okay";
 };
 
-- 
2.34.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 3/4] arm64: dts: rockchip: Move RK3399 eDP pinctrl to boards

[Dragan Simic]

Hello Robin,

On Tuesday, December 30, 2025 18:20 CET, Robin Murphy <robin.murphy@arm.com> wrote:
> The EDP_HOTPLUG pin is optional, and muxed with other functions (notably
> HDMI CEC), so move its selection from the SoC DTSI to the boards which
> apparently want it, namely those which enable eDP without "force-hpd".
> By the same token we drop it from Pinebook Pro, which already uses
> "force-hpd", and according to the schematics does not have the pin wired
> at all.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-base.dtsi              | 2 --
>  arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi    | 2 ++
>  arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts       | 2 --
>  arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts | 2 ++
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
> index 4dcceb9136b7..19a312baa9f1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
> @@ -2145,8 +2145,6 @@ edp: dp@ff970000 {
>  		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>;
>  		clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>, <&cru PCLK_VIO_GRF>;
>  		clock-names = "dp", "pclk", "grf";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&edp_hpd>;
>  		power-domains = <&power RK3399_PD_EDP>;
>  		resets = <&cru SRST_P_EDP_CTRL>;
>  		reset-names = "dp";
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> index 9d07353df52c..3f3cb0eb5809 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> @@ -241,6 +241,8 @@ &dmc {
>  };
>  
>  &edp {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&edp_hpd>;
>  	status = "okay";
>  
>  	/*
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> index eaaca08a7601..dcab04863d28 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> @@ -401,8 +401,6 @@ &cpu_l3 {
>  
>  &edp {
>  	force-hpd;
> -	pinctrl-names = "default";
> -	pinctrl-0 = <&edp_hpd>;
>  	status = "okay";
>  };
>  
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
> index a4ceafe6dd7a..80d6ea0eda84 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
> @@ -141,6 +141,8 @@ sdio_pwrseq: sdio-pwrseq {
>  };
>  
>  &edp {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&edp_hpd>;
>  	status = "okay";
>  };

Thanks for this patch!  These changes are looking good to me, and the
board dts files changed in this patch are the right ones, i.e. those that
enable the "edp" node without specifying the "force-hpd" property.

Additionally,"/omit-if-no-ref/" should be added to the "edp" pinctrl node
in rk3399-base.dtsi, to not include the "edp_hpd" pinctrl definition in
the board dtb files where that actuually isn't used.

With the note above addressed, please feel free to include

Reviewed-by: Dragan Simic <dsimic@manjaro.org>


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 3/4] arm64: dts: rockchip: Move RK3399 eDP pinctrl to boards

[Robin Murphy]

On 2026-01-14 11:49 am, Dragan Simic wrote:
> Hello Robin,
> 
> On Tuesday, December 30, 2025 18:20 CET, Robin Murphy <robin.murphy@arm.com> wrote:
>> The EDP_HOTPLUG pin is optional, and muxed with other functions (notably
>> HDMI CEC), so move its selection from the SoC DTSI to the boards which
>> apparently want it, namely those which enable eDP without "force-hpd".
>> By the same token we drop it from Pinebook Pro, which already uses
>> "force-hpd", and according to the schematics does not have the pin wired
>> at all.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3399-base.dtsi              | 2 --
>>   arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi    | 2 ++
>>   arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts       | 2 --
>>   arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts | 2 ++
>>   4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
>> index 4dcceb9136b7..19a312baa9f1 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
>> @@ -2145,8 +2145,6 @@ edp: dp@ff970000 {
>>   		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>;
>>   		clocks = <&cru PCLK_EDP>, <&cru PCLK_EDP_CTRL>, <&cru PCLK_VIO_GRF>;
>>   		clock-names = "dp", "pclk", "grf";
>> -		pinctrl-names = "default";
>> -		pinctrl-0 = <&edp_hpd>;
>>   		power-domains = <&power RK3399_PD_EDP>;
>>   		resets = <&cru SRST_P_EDP_CTRL>;
>>   		reset-names = "dp";
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
>> index 9d07353df52c..3f3cb0eb5809 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
>> @@ -241,6 +241,8 @@ &dmc {
>>   };
>>   
>>   &edp {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&edp_hpd>;
>>   	status = "okay";
>>   
>>   	/*
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
>> index eaaca08a7601..dcab04863d28 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
>> @@ -401,8 +401,6 @@ &cpu_l3 {
>>   
>>   &edp {
>>   	force-hpd;
>> -	pinctrl-names = "default";
>> -	pinctrl-0 = <&edp_hpd>;
>>   	status = "okay";
>>   };
>>   
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
>> index a4ceafe6dd7a..80d6ea0eda84 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
>> @@ -141,6 +141,8 @@ sdio_pwrseq: sdio-pwrseq {
>>   };
>>   
>>   &edp {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&edp_hpd>;
>>   	status = "okay";
>>   };
> 
> Thanks for this patch!  These changes are looking good to me, and the
> board dts files changed in this patch are the right ones, i.e. those that
> enable the "edp" node without specifying the "force-hpd" property.
> 
> Additionally,"/omit-if-no-ref/" should be added to the "edp" pinctrl node
> in rk3399-base.dtsi, to not include the "edp_hpd" pinctrl definition in
> the board dtb files where that actuually isn't used.

Ah, indeed - I can't think of a realistic good reason for the pinctrl to 
only be selected by an overlay rather than the base board, and even if 
anyone did conjure up some such crazy modular system, they could always 
change it back. Good thing I got distracted and didn't get round to 
sending v2 last night :)

> With the note above addressed, please feel free to include
> 
> Reviewed-by: Dragan Simic <dsimic@manjaro.org>

Thanks!

Robin.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH 4/4] arm64: dts: rockchip: Add overlay for FriendlyElec HD702E

[Robin Murphy]

Add an overlay to support FriendlyElec's HD702E 7" eDP LCD touchscreen
module for the NanoPC-T4 board:

https://www.friendlyelec.com/index.php?route=product/product&path=81&product_id=230

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 arch/arm64/boot/dts/rockchip/Makefile         |  5 ++
 .../dts/rockchip/rk3399-nanopc-t4-hd702e.dtso | 62 +++++++++++++++++++
 2 files changed, 67 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4-hd702e.dtso

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index dbdda9783e93..4ab58a5961aa 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -62,6 +62,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4-hd702e.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
@@ -238,6 +239,10 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-ringneck-haikou-haikou-video-demo.dtb
 px30-ringneck-haikou-haikou-video-demo-dtbs := px30-ringneck-haikou.dtb \
 	px30-ringneck-haikou-video-demo.dtbo
 
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4-hd702e.dtb
+rk3399-nanopc-t4-hd702e-dtbs := rk3399-nanopc-t4.dtb \
+	rk3399-nanopc-t4-hd702e.dtbo
+
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou-haikou-video-demo.dtb
 rk3399-puma-haikou-haikou-video-demo-dtbs := rk3399-puma-haikou.dtb \
 	rk3399-puma-haikou-video-demo.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4-hd702e.dtso b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4-hd702e.dtso
new file mode 100644
index 000000000000..ab643a1edd7b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4-hd702e.dtso
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec HD702E LCD on NanoPC-T4 board
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+&{/} {
+	pwm_bl: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm0 0 25000 0>;
+		enable-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
+		brightness-levels = <0 255>;
+		default-brightness-level = <200>;
+		num-interpolated-steps = <255>;
+	};
+};
+
+&edp {
+	force-hpd;
+	status = "okay";
+
+	aux-bus {
+		edp-panel {
+			compatible = "friendlyarm,hd702e";
+			backlight = <&pwm_bl>;
+			no-hpd;
+			power-supply = <&vcc12v0_sys>;
+
+			port {
+				panel_in_edp: endpoint {
+					remote-endpoint = <&edp_out_panel>;
+				};
+			};
+		};
+	};
+};
+
+&edp_out {
+	edp_out_panel: endpoint {
+		remote-endpoint = <&panel_in_edp>;
+	};
+};
+
+&i2c4 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	touchscreen@5d {
+		compatible = "goodix,gt9271";
+		reg = <0x5d>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PC4 IRQ_TYPE_EDGE_FALLING>;
+		irq-gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
+	};
+};
-- 
2.34.1


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 4/4] arm64: dts: rockchip: Add overlay for FriendlyElec HD702E

[Doug Anderson]

Hi,

On Tue, Dec 30, 2025 at 9:21 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> +&{/} {
> +       pwm_bl: backlight {

nit: up to you, but I happened to notice that other rk3399 boards just
use the label "backlight:" instead of "pwm_bl:"


> +               compatible = "pwm-backlight";
> +               pwms = <&pwm0 0 25000 0>;

40kHz is awfully fast for a PWM backlight. Are you sure you need it that fast?


> +               enable-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;

Not that I'm doing a thorough review here, but I happened to notice
that you're referring to a GPIO without adding a pinctrl entry. I
think the usual convention is to add one.


> +               brightness-levels = <0 255>;
> +               default-brightness-level = <200>;
> +               num-interpolated-steps = <255>;
> +       };
> +};
> +
> +&edp {
> +       force-hpd;
> +       status = "okay";
> +
> +       aux-bus {
> +               edp-panel {
> +                       compatible = "friendlyarm,hd702e";

As per my response in your driver patch, any chance this can just be
"edp-panel"?


> +                       backlight = <&pwm_bl>;
> +                       no-hpd;
> +                       power-supply = <&vcc12v0_sys>;

While not strictly required, it seems highly likely that you want
"hpd-absent-delay-ms". It's highly unlikely that you would have
"no-hpd" plus a "power-supply" but no hardcoded delay to wait here. I
haven't seen panels that turn on and respond instantly.


> +
> +                       port {
> +                               panel_in_edp: endpoint {
> +                                       remote-endpoint = <&edp_out_panel>;
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
> +&edp_out {
> +       edp_out_panel: endpoint {
> +               remote-endpoint = <&panel_in_edp>;
> +       };
> +};
> +
> +&i2c4 {
> +       #address-cells = <1>;
> +       #size-cells = <0>;

The base dts already specifies #address-cells and #size-cells, right?


> +       touchscreen@5d {
> +               compatible = "goodix,gt9271";
> +               reg = <0x5d>;
> +               interrupt-parent = <&gpio1>;
> +               interrupts = <RK_PC4 IRQ_TYPE_EDGE_FALLING>;
> +               irq-gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
> +               reset-gpios = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;

There's no power supply here, so I'll assume it follows the power
supply of the panel? You probably want to be a "panel-follower" then,
right? AKA you'd want to add a "panel = " node here to refer to your
edp-panel.

Oh, except that the goodix driver you're using doesn't support
panel-follower. That's annoying. I guess you'd have to add support for
that (see history around "is_panel_follower" in "i2c-hid-core.c")?
Without it then I assume you'll just be lucky that things work? ...or
you'd need to mark the power supply as always-on?

I guess I can also note the same comment that there is no pinctrl for
your GPIOs here.

-Doug

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 4/4] arm64: dts: rockchip: Add overlay for FriendlyElec HD702E

[Robin Murphy]

Hi Doug,

On 2026-01-05 5:39 pm, Doug Anderson wrote:
> Hi,
> 
> On Tue, Dec 30, 2025 at 9:21 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> +&{/} {
>> +       pwm_bl: backlight {
> 
> nit: up to you, but I happened to notice that other rk3399 boards just
> use the label "backlight:" instead of "pwm_bl:"

Sure, if you prefer.

>> +               compatible = "pwm-backlight";
>> +               pwms = <&pwm0 0 25000 0>;
> 
> 40kHz is awfully fast for a PWM backlight. Are you sure you need it that fast?

I guess I just copied this from somewhere without too much thought, but 
double-checking the schematic[1] now, the backlight driver where this 
signal ends up is apparently a SY7200A, whose datasheet says "And the 
recommend dimming frequency range is 20kHz~1MHz." So relative to that 
range it doesn't seem too bad!

> 
>> +               enable-gpios = <&gpio4 RK_PD5 GPIO_ACTIVE_HIGH>;
> 
> Not that I'm doing a thorough review here, but I happened to notice
> that you're referring to a GPIO without adding a pinctrl entry. I
> think the usual convention is to add one.

Ah yes, good point! (Too easy to forget the boring details when doing a 
holiday project away from home...)

>> +               brightness-levels = <0 255>;
>> +               default-brightness-level = <200>;
>> +               num-interpolated-steps = <255>;
>> +       };
>> +};
>> +
>> +&edp {
>> +       force-hpd;
>> +       status = "okay";
>> +
>> +       aux-bus {
>> +               edp-panel {
>> +                       compatible = "friendlyarm,hd702e";
> 
> As per my response in your driver patch, any chance this can just be
> "edp-panel"?

Per the cover letter, I did try...

>> +                       backlight = <&pwm_bl>;
>> +                       no-hpd;
>> +                       power-supply = <&vcc12v0_sys>;
> 
> While not strictly required, it seems highly likely that you want
> "hpd-absent-delay-ms". It's highly unlikely that you would have
> "no-hpd" plus a "power-supply" but no hardcoded delay to wait here. I
> haven't seen panels that turn on and respond instantly.

...but even with both delays bumped up and up and up to a ridiculous 
2000ms it still didn't work. It reads the EDID as all-zeros then fails 
to probe due to a lack of modes. Whereas with the hard-coded mode, the 
display lights up immediately upon probe, so I don't think it's a timing 
issue. My working theory is that there's some fundamental ordering issue 
based on the comments in analogix_dp_detect_hpd() about aux not working 
until HPD is forced at the controller end, and from a brief skim of the 
history, quite possibly related to f2600d08d4e8 ("drm/bridge: 
analogix_dp: Improve panel on time") which maybe prevents that happening?

By that point it's well beyond my expertise, hence my conclusion that 
since I'm not *adding* the legacy panel data, just rearranging what's 
already upstream to finally put it to proper use, that's just about 
acceptable :)

The power-supply entry is really just for cleanliness, to avoid a "dummy 
regulator" message - the screen module has all its own regulation on 
board, which didn't seem worth modelling in detail as it's all fixed and 
always-on, but the source is the board's main 12V input, so that much 
*is* true.

>> +
>> +                       port {
>> +                               panel_in_edp: endpoint {
>> +                                       remote-endpoint = <&edp_out_panel>;
>> +                               };
>> +                       };
>> +               };
>> +       };
>> +};
>> +
>> +&edp_out {
>> +       edp_out_panel: endpoint {
>> +               remote-endpoint = <&panel_in_edp>;
>> +       };
>> +};
>> +
>> +&i2c4 {
>> +       #address-cells = <1>;
>> +       #size-cells = <0>;
> 
> The base dts already specifies #address-cells and #size-cells, right?

Indeed, but dtc doesn't know that when compiling the .dtbo in isolation.

>> +       touchscreen@5d {
>> +               compatible = "goodix,gt9271";
>> +               reg = <0x5d>;
>> +               interrupt-parent = <&gpio1>;
>> +               interrupts = <RK_PC4 IRQ_TYPE_EDGE_FALLING>;
>> +               irq-gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
>> +               reset-gpios = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
> 
> There's no power supply here, so I'll assume it follows the power
> supply of the panel? You probably want to be a "panel-follower" then,
> right? AKA you'd want to add a "panel = " node here to refer to your
> edp-panel.
> 
> Oh, except that the goodix driver you're using doesn't support
> panel-follower. That's annoying. I guess you'd have to add support for
> that (see history around "is_panel_follower" in "i2c-hid-core.c")?
> Without it then I assume you'll just be lucky that things work? ...or
> you'd need to mark the power supply as always-on?

Yeah, as above it is in fact always-on anyway - somehow I missed that 
the goodix driver is getting regulators too. The 12V input is stepped 
down to a main VDD_3.3V rail from which everything else is derived, so 
if I add a fixed-regulator node for that which is sufficiently close to 
the truth for both these and the panel supply, would that be clear enough?

> I guess I can also note the same comment that there is no pinctrl for
> your GPIOs here.

Ack.

Cheers,
Robin.

[1] https://wiki.friendlyelec.com/wiki/images/f/f3/LCD-HD702E-2106_SCH.PDF

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 4/4] arm64: dts: rockchip: Add overlay for FriendlyElec HD702E

[Doug Anderson]

Hi,

On Mon, Jan 5, 2026 at 11:39 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> >> +&{/} {
> >> +       pwm_bl: backlight {
> >
> > nit: up to you, but I happened to notice that other rk3399 boards just
> > use the label "backlight:" instead of "pwm_bl:"
>
> Sure, if you prefer.

Totally up to you--I was just comparing what you had to what other
rk3399 boards had and the fact that this was different made it take 15
seconds longer to find the PWM backlight on the bother boards. :-P


> >> +               compatible = "pwm-backlight";
> >> +               pwms = <&pwm0 0 25000 0>;
> >
> > 40kHz is awfully fast for a PWM backlight. Are you sure you need it that fast?
>
> I guess I just copied this from somewhere without too much thought, but
> double-checking the schematic[1] now, the backlight driver where this
> signal ends up is apparently a SY7200A, whose datasheet says "And the
> recommend dimming frequency range is 20kHz~1MHz." So relative to that
> range it doesn't seem too bad!

OK, cool! I just know in the past that I've seen cases where people
copied the PWM values from elsewhere and ended up wildly out of spec
without really noticing. :-) Sounds like you're good.


> >> +&edp {
> >> +       force-hpd;
> >> +       status = "okay";
> >> +
> >> +       aux-bus {
> >> +               edp-panel {
> >> +                       compatible = "friendlyarm,hd702e";
> >
> > As per my response in your driver patch, any chance this can just be
> > "edp-panel"?
>
> Per the cover letter, I did try...
>
> >> +                       backlight = <&pwm_bl>;
> >> +                       no-hpd;
> >> +                       power-supply = <&vcc12v0_sys>;
> >
> > While not strictly required, it seems highly likely that you want
> > "hpd-absent-delay-ms". It's highly unlikely that you would have
> > "no-hpd" plus a "power-supply" but no hardcoded delay to wait here. I
> > haven't seen panels that turn on and respond instantly.
>
> ...but even with both delays bumped up and up and up to a ridiculous
> 2000ms it still didn't work. It reads the EDID as all-zeros then fails
> to probe due to a lack of modes. Whereas with the hard-coded mode, the
> display lights up immediately upon probe, so I don't think it's a timing
> issue. My working theory is that there's some fundamental ordering issue
> based on the comments in analogix_dp_detect_hpd() about aux not working
> until HPD is forced at the controller end, and from a brief skim of the
> history, quite possibly related to f2600d08d4e8 ("drm/bridge:
> analogix_dp: Improve panel on time") which maybe prevents that happening?
>
> By that point it's well beyond my expertise, hence my conclusion that
> since I'm not *adding* the legacy panel data, just rearranging what's
> already upstream to finally put it to proper use, that's just about
> acceptable :)

OK. It's unfortunate, but fair enough. :-) It would certainly be
interesting to know what eventually makes the EDID read correctly, but
I agree that it's a bit much to ask you to debug that.

FWIW, I took a _quick_ gander at the schematics you sent, and I
actually wonder if it's the "backlight" enable signal that you need.
Depending on the stuffing options, maybe that connects to the PWRDN
pin? If I trust the stuffing options in the schematic that GPIO
doesn't connect to anything at all, but I know stuffing options on
schematics aren't always right... In any case, it's also OK to just do
what you're doing...


> The power-supply entry is really just for cleanliness, to avoid a "dummy
> regulator" message - the screen module has all its own regulation on
> board, which didn't seem worth modelling in detail as it's all fixed and
> always-on, but the source is the board's main 12V input, so that much
> *is* true.

Fair enough.


> >> +&i2c4 {
> >> +       #address-cells = <1>;
> >> +       #size-cells = <0>;
> >
> > The base dts already specifies #address-cells and #size-cells, right?
>
> Indeed, but dtc doesn't know that when compiling the .dtbo in isolation.

Oh, right.


> >> +       touchscreen@5d {
> >> +               compatible = "goodix,gt9271";
> >> +               reg = <0x5d>;
> >> +               interrupt-parent = <&gpio1>;
> >> +               interrupts = <RK_PC4 IRQ_TYPE_EDGE_FALLING>;
> >> +               irq-gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
> >> +               reset-gpios = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
> >
> > There's no power supply here, so I'll assume it follows the power
> > supply of the panel? You probably want to be a "panel-follower" then,
> > right? AKA you'd want to add a "panel = " node here to refer to your
> > edp-panel.
> >
> > Oh, except that the goodix driver you're using doesn't support
> > panel-follower. That's annoying. I guess you'd have to add support for
> > that (see history around "is_panel_follower" in "i2c-hid-core.c")?
> > Without it then I assume you'll just be lucky that things work? ...or
> > you'd need to mark the power supply as always-on?
>
> Yeah, as above it is in fact always-on anyway - somehow I missed that
> the goodix driver is getting regulators too. The 12V input is stepped
> down to a main VDD_3.3V rail from which everything else is derived, so
> if I add a fixed-regulator node for that which is sufficiently close to
> the truth for both these and the panel supply, would that be clear enough?

Sure, it's fine from my point of view. Really pretty much all of the
dts is up to Heiko. I'm mostly here because of the eDP-panel stuff.
;-)

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 0/4] Properly support FriendlyElec HD702E

[Doug Anderson]

Hi,

On Tue, Dec 30, 2025 at 9:20 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> Hi all,
>
> I've been using the HD702E LCD/touchscreen on my NanoPC-T4 for a few
> years using my own DT with the "simple-panel" binding, but now we have
> upstream overlays I figured it's about time to try doing it properly.
> The screen itself doesn't seem to want to work as a generic "edp-panel",
> as it appears the EDID isn't readable until after the whole lot is
> enabled - I'm guessing this might be to do with the Analogix driver's
> force-hpd behaviour - but since we do already have the legacy data, it
> doesn't seem unreasonable to keep using it.

Oh, I guess I should have read the cover letter before the patches. Sorry! :(

I'm hoping that with the "hpd-absent-delay-ms" you'll be able to read
the EDID. I'd be surprised if something else is required, but let me
know if that doesn't work.

-Doug

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip