[PATCH v2 0/4] rockchip: rk3399: Fix HDMI out

[PATCH v2 0/4] rockchip: rk3399: Fix HDMI out

[Jagan Teki]

Due to recent Linux dts(i) sync for rk3399. the existing
vop driver is not working with HDMI out on RK3399.

This is v2 patchset, for previous version fixes[1].  

[1] https://patchwork.ozlabs.org/cover/1228297/

Changes for v2:
- use usbkbd as stdin
- enable USB Keyboard

Any inputs?
Jagan.

Jagan Teki (4):
  arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates
  video: rockchip: Fix vop modes for rk3399
  rockchip: Enable pre console for rk3399
  rockchip: Enable HDMI output on rk3399 board w/ HDMI

 arch/arm/dts/rk3399-u-boot.dtsi                 |  4 ++++
 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++++++++++
 arch/arm/mach-rockchip/Kconfig                  |  1 +
 common/Kconfig                                  |  1 +
 configs/nanopc-t4-rk3399_defconfig              |  7 +++++++
 configs/nanopi-m4-rk3399_defconfig              |  7 +++++++
 configs/nanopi-neo4-rk3399_defconfig            |  7 +++++++
 configs/roc-pc-rk3399_defconfig                 |  6 ++++++
 drivers/video/rockchip/rk3399_vop.c             |  2 --
 drivers/video/rockchip/rk_vop.c                 |  4 ++++
 include/configs/evb_rk3399.h                    |  5 +++++
 11 files changed, 53 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH v2 0/4] rockchip: rk3399: Fix HDMI out

[Jagan Teki]

Due to recent Linux dts(i) sync for rk3399. the existing
vop driver is not working with HDMI out on RK3399.

This is v2 patchset, for previous version fixes[1].  

[1] https://patchwork.ozlabs.org/cover/1228297/

Changes for v2:
- use usbkbd as stdin
- enable USB Keyboard

Any inputs?
Jagan.

Jagan Teki (4):
  arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates
  video: rockchip: Fix vop modes for rk3399
  rockchip: Enable pre console for rk3399
  rockchip: Enable HDMI output on rk3399 board w/ HDMI

 arch/arm/dts/rk3399-u-boot.dtsi                 |  4 ++++
 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++++++++++
 arch/arm/mach-rockchip/Kconfig                  |  1 +
 common/Kconfig                                  |  1 +
 configs/nanopc-t4-rk3399_defconfig              |  7 +++++++
 configs/nanopi-m4-rk3399_defconfig              |  7 +++++++
 configs/nanopi-neo4-rk3399_defconfig            |  7 +++++++
 configs/roc-pc-rk3399_defconfig                 |  6 ++++++
 drivers/video/rockchip/rk3399_vop.c             |  2 --
 drivers/video/rockchip/rk_vop.c                 |  4 ++++
 include/configs/evb_rk3399.h                    |  5 +++++
 11 files changed, 53 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

Linux supporting assigned-clocks for VOP on rk3399 by assuming
U-Boot not initializing it on this linux commit:

commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")

There is no specific need to initialize these assigned clock
in U-Boot as video drivers still work with default aclk and  
hclk values. So, these clocks are simply not supported by rk3399
clock driver.

But, during stdio probe of vidconsole, the device probe
will try to check whether the assigned clocks on that video
console node is initialized or not? and return error if not.

So, delete these property via -u-boot dtsi as there is
no specific need in U-Boot.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none

 arch/arm/dts/rk3399-u-boot.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 8b857ccfc7..b846f9cde7 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -99,9 +99,13 @@
 };
 
 &vopb {
+	/delete-property/ assigned-clocks;
+	/delete-property/ assigned-clock-rates;
 	u-boot,dm-pre-reloc;
 };
 
 &vopl {
+	/delete-property/ assigned-clocks;
+	/delete-property/ assigned-clock-rates;
 	u-boot,dm-pre-reloc;
 };
-- 
2.17.1


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

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

Linux supporting assigned-clocks for VOP on rk3399 by assuming
U-Boot not initializing it on this linux commit:

commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")

There is no specific need to initialize these assigned clock
in U-Boot as video drivers still work with default aclk and ?
hclk values. So, these clocks are simply not supported by rk3399
clock driver.

But, during stdio probe of vidconsole, the device probe
will try to check whether the assigned clocks on that video
console node is initialized or not? and return error if not.

So, delete these property via -u-boot dtsi as there is
no specific need in U-Boot.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none

 arch/arm/dts/rk3399-u-boot.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 8b857ccfc7..b846f9cde7 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -99,9 +99,13 @@
 };
 
 &vopb {
+	/delete-property/ assigned-clocks;
+	/delete-property/ assigned-clock-rates;
 	u-boot,dm-pre-reloc;
 };
 
 &vopl {
+	/delete-property/ assigned-clocks;
+	/delete-property/ assigned-clock-rates;
 	u-boot,dm-pre-reloc;
 };
-- 
2.17.1

[PATCH v2 2/4] video: rockchip: Fix vop modes for rk3399

[Jagan Teki]

VOP display endpoint pipeline configuration is differs
between rk3288 vs rk3399.

These VOP pipeline configuration depends on how the
different display interfaces connected in sequence to
IN and OUT ports like for,

RK3288:

vopb_out: port {
	#address-cells = <1>;
	#size-cells = <0>;
	vopb_out_edp: endpoint@0 {
		reg = <0>;
		remote-endpoint = <&edp_in_vopb>;
	};
	vopb_out_hdmi: endpoint@1 {
		reg = <1>;
                remote-endpoint = <&hdmi_in_vopb>;
        };
        vopb_out_lvds: endpoint@2 {
                reg = <2>;
                remote-endpoint = <&lvds_in_vopb>;
        };
        vopb_out_mipi: endpoint@3 {
                reg = <3>;
                remote-endpoint = <&mipi_in_vopb>;
        };
};

RK3399:

vopb_out: port {
         #address-cells = <1>;
         #size-cells = <0>;
         vopb_out_edp: endpoint@0 {
                reg = <0>;
                remote-endpoint = <&edp_in_vopb>;
         };
         vopb_out_mipi: endpoint@1 {
                reg = <1>;
                remote-endpoint = <&mipi_in_vopb>;
         };
         vopb_out_hdmi: endpoint@2 {
                reg = <2>;
                remote-endpoint = <&hdmi_in_vopb>;
         };
         vopb_out_mipi1: endpoint@3 {
                reg = <3>;
                remote-endpoint = <&mipi1_in_vopb>;
         };
         vopb_out_dp: endpoint@4 {
                reg = <4>;
                remote-endpoint = <&dp_in_vopb>;
         };
};

here, HDMI interface has endpoint 1 in rk3288 and 2 in rk3399.

The rockchip vop driver often depends on this determined endpoint
number and stored in vop_mode. So based on this vop_mode the bpp
and pin polarity would configure on detected display interface.

Since, the existing driver using rk3288 vop mode settings enabling
the same will result wrong display interface configuration for rk3399.

Add the patch for fixing these vop modes for rk3399.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v2:
- none

 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++++++++++
 drivers/video/rockchip/rk3399_vop.c             |  2 --
 drivers/video/rockchip/rk_vop.c                 |  4 ++++
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
index 8398249509..872a158b71 100644
--- a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
+++ b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
@@ -85,6 +85,16 @@ enum {
 	LB_RGB_1280X8 = 0x5
 };
 
+#if defined(CONFIG_ROCKCHIP_RK3399)
+enum vop_modes {
+	VOP_MODE_EDP = 0,
+	VOP_MODE_MIPI,
+	VOP_MODE_HDMI,
+	VOP_MODE_MIPI1,
+	VOP_MODE_DP,
+	VOP_MODE_NONE,
+};
+#else
 enum vop_modes {
 	VOP_MODE_EDP = 0,
 	VOP_MODE_HDMI,
@@ -94,6 +104,7 @@ enum vop_modes {
 	VOP_MODE_AUTO_DETECT,
 	VOP_MODE_UNKNOWN,
 };
+#endif
 
 /* VOP_VERSION_INFO */
 #define M_FPGA_VERSION (0xffff << 16)
diff --git a/drivers/video/rockchip/rk3399_vop.c b/drivers/video/rockchip/rk3399_vop.c
index 81c122d7a9..1d5b3931a6 100644
--- a/drivers/video/rockchip/rk3399_vop.c
+++ b/drivers/video/rockchip/rk3399_vop.c
@@ -45,8 +45,6 @@ static void rk3399_set_pin_polarity(struct udevice *dev,
 				V_RK3399_DSP_MIPI_POL(polarity));
 		break;
 
-	case VOP_MODE_LVDS:
-		/* The RK3399 has neither parallel RGB nor LVDS output. */
 	default:
 		debug("%s: unsupported output mode %x\n", __func__, mode);
 	}
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index e91d4dfa7f..e1bd656bee 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -118,10 +118,12 @@ static void rkvop_enable_output(struct udevice *dev, enum vop_modes mode)
 				V_EDP_OUT_EN(1));
 		break;
 
+#if defined(CONFIG_ROCKCHIP_RK3288)
 	case VOP_MODE_LVDS:
 		clrsetbits_le32(&regs->sys_ctrl, M_ALL_OUT_EN,
 				V_RGB_OUT_EN(1));
 		break;
+#endif
 
 	case VOP_MODE_MIPI:
 		clrsetbits_le32(&regs->sys_ctrl, M_ALL_OUT_EN,
@@ -313,7 +315,9 @@ static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 	/* Set bitwidth for vop display according to vop mode */
 	switch (vop_id) {
 	case VOP_MODE_EDP:
+#if defined(CONFIG_ROCKCHIP_RK3288)
 	case VOP_MODE_LVDS:
+#endif
 		l2bpp = VIDEO_BPP16;
 		break;
 	case VOP_MODE_HDMI:
-- 
2.17.1

[PATCH v2 2/4] video: rockchip: Fix vop modes for rk3399

[Jagan Teki]

VOP display endpoint pipeline configuration is differs
between rk3288 vs rk3399.

These VOP pipeline configuration depends on how the
different display interfaces connected in sequence to
IN and OUT ports like for,

RK3288:

vopb_out: port {
	#address-cells = <1>;
	#size-cells = <0>;
	vopb_out_edp: endpoint at 0 {
		reg = <0>;
		remote-endpoint = <&edp_in_vopb>;
	};
	vopb_out_hdmi: endpoint at 1 {
		reg = <1>;
                remote-endpoint = <&hdmi_in_vopb>;
        };
        vopb_out_lvds: endpoint at 2 {
                reg = <2>;
                remote-endpoint = <&lvds_in_vopb>;
        };
        vopb_out_mipi: endpoint at 3 {
                reg = <3>;
                remote-endpoint = <&mipi_in_vopb>;
        };
};

RK3399:

vopb_out: port {
         #address-cells = <1>;
         #size-cells = <0>;
         vopb_out_edp: endpoint at 0 {
                reg = <0>;
                remote-endpoint = <&edp_in_vopb>;
         };
         vopb_out_mipi: endpoint at 1 {
                reg = <1>;
                remote-endpoint = <&mipi_in_vopb>;
         };
         vopb_out_hdmi: endpoint at 2 {
                reg = <2>;
                remote-endpoint = <&hdmi_in_vopb>;
         };
         vopb_out_mipi1: endpoint at 3 {
                reg = <3>;
                remote-endpoint = <&mipi1_in_vopb>;
         };
         vopb_out_dp: endpoint at 4 {
                reg = <4>;
                remote-endpoint = <&dp_in_vopb>;
         };
};

here, HDMI interface has endpoint 1 in rk3288 and 2 in rk3399.

The rockchip vop driver often depends on this determined endpoint
number and stored in vop_mode. So based on this vop_mode the bpp
and pin polarity would configure on detected display interface.

Since, the existing driver using rk3288 vop mode settings enabling
the same will result wrong display interface configuration for rk3399.

Add the patch for fixing these vop modes for rk3399.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none

 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++++++++++
 drivers/video/rockchip/rk3399_vop.c             |  2 --
 drivers/video/rockchip/rk_vop.c                 |  4 ++++
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
index 8398249509..872a158b71 100644
--- a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
+++ b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
@@ -85,6 +85,16 @@ enum {
 	LB_RGB_1280X8 = 0x5
 };
 
+#if defined(CONFIG_ROCKCHIP_RK3399)
+enum vop_modes {
+	VOP_MODE_EDP = 0,
+	VOP_MODE_MIPI,
+	VOP_MODE_HDMI,
+	VOP_MODE_MIPI1,
+	VOP_MODE_DP,
+	VOP_MODE_NONE,
+};
+#else
 enum vop_modes {
 	VOP_MODE_EDP = 0,
 	VOP_MODE_HDMI,
@@ -94,6 +104,7 @@ enum vop_modes {
 	VOP_MODE_AUTO_DETECT,
 	VOP_MODE_UNKNOWN,
 };
+#endif
 
 /* VOP_VERSION_INFO */
 #define M_FPGA_VERSION (0xffff << 16)
diff --git a/drivers/video/rockchip/rk3399_vop.c b/drivers/video/rockchip/rk3399_vop.c
index 81c122d7a9..1d5b3931a6 100644
--- a/drivers/video/rockchip/rk3399_vop.c
+++ b/drivers/video/rockchip/rk3399_vop.c
@@ -45,8 +45,6 @@ static void rk3399_set_pin_polarity(struct udevice *dev,
 				V_RK3399_DSP_MIPI_POL(polarity));
 		break;
 
-	case VOP_MODE_LVDS:
-		/* The RK3399 has neither parallel RGB nor LVDS output. */
 	default:
 		debug("%s: unsupported output mode %x\n", __func__, mode);
 	}
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index e91d4dfa7f..e1bd656bee 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -118,10 +118,12 @@ static void rkvop_enable_output(struct udevice *dev, enum vop_modes mode)
 				V_EDP_OUT_EN(1));
 		break;
 
+#if defined(CONFIG_ROCKCHIP_RK3288)
 	case VOP_MODE_LVDS:
 		clrsetbits_le32(&regs->sys_ctrl, M_ALL_OUT_EN,
 				V_RGB_OUT_EN(1));
 		break;
+#endif
 
 	case VOP_MODE_MIPI:
 		clrsetbits_le32(&regs->sys_ctrl, M_ALL_OUT_EN,
@@ -313,7 +315,9 @@ static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 	/* Set bitwidth for vop display according to vop mode */
 	switch (vop_id) {
 	case VOP_MODE_EDP:
+#if defined(CONFIG_ROCKCHIP_RK3288)
 	case VOP_MODE_LVDS:
+#endif
 		l2bpp = VIDEO_BPP16;
 		break;
 	case VOP_MODE_HDMI:
-- 
2.17.1

[PATCH v2 3/4] rockchip: Enable pre console for rk3399

[Jagan Teki]

Enable pre console buffer for rk3399 platform.

This would help to capture the console messages prior to
the console being initialised. Enabling this would help
to capture all the console messages on video output source
like HDMI. So we can find the full console messages of
U-Boot proper on HDMI display when enabled it for RK3399
platform boards.

Buffer address used for pre console is 0x0f200000 which is
ram base plus 240MiB. right now the Allwinner SoC is using
similar computation.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v2:
- none

 arch/arm/mach-rockchip/Kconfig | 1 +
 common/Kconfig                 | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ed7514ab75..0cb1f23d0f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -229,6 +229,7 @@ config ROCKCHIP_RK3399
 	select DM_PMIC
 	select DM_REGULATOR_FIXED
 	select BOARD_LATE_INIT
+	imply PRE_CONSOLE_BUFFER
 	imply ROCKCHIP_COMMON_BOARD
 	imply ROCKCHIP_SDRAM_COMMON
 	imply SPL_ROCKCHIP_COMMON_BOARD
diff --git a/common/Kconfig b/common/Kconfig
index 46e4193fc8..bd35de3056 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -568,6 +568,7 @@ config PRE_CON_BUF_ADDR
 	default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
 	default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
 	default 0x0f000000 if ROCKCHIP_RK3288
+	default 0x0f200000 if ROCKCHIP_RK3399
 	help
 	  This sets the start address of the pre-console buffer. This must
 	  be in available memory and is accessed before relocation and
-- 
2.17.1

[PATCH v2 3/4] rockchip: Enable pre console for rk3399

[Jagan Teki]

Enable pre console buffer for rk3399 platform.

This would help to capture the console messages prior to
the console being initialised. Enabling this would help
to capture all the console messages on video output source
like HDMI. So we can find the full console messages of
U-Boot proper on HDMI display when enabled it for RK3399
platform boards.

Buffer address used for pre console is 0x0f200000 which is
ram base plus 240MiB. right now the Allwinner SoC is using
similar computation.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none

 arch/arm/mach-rockchip/Kconfig | 1 +
 common/Kconfig                 | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ed7514ab75..0cb1f23d0f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -229,6 +229,7 @@ config ROCKCHIP_RK3399
 	select DM_PMIC
 	select DM_REGULATOR_FIXED
 	select BOARD_LATE_INIT
+	imply PRE_CONSOLE_BUFFER
 	imply ROCKCHIP_COMMON_BOARD
 	imply ROCKCHIP_SDRAM_COMMON
 	imply SPL_ROCKCHIP_COMMON_BOARD
diff --git a/common/Kconfig b/common/Kconfig
index 46e4193fc8..bd35de3056 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -568,6 +568,7 @@ config PRE_CON_BUF_ADDR
 	default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I
 	default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I
 	default 0x0f000000 if ROCKCHIP_RK3288
+	default 0x0f200000 if ROCKCHIP_RK3399
 	help
 	  This sets the start address of the pre-console buffer. This must
 	  be in available memory and is accessed before relocation and
-- 
2.17.1

[PATCH v2 4/4] rockchip: Enable HDMI output on rk3399 board w/ HDMI

[Jagan Teki]

Enable config options and console setting to respective
rk3399 board for HDMI output.

Boards supported and tested on this patch are:
- NanoPc T4
- NanoPi M4
- NanoPi Neo4
- ROC-RK3399-PC

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v2:
- use usbkbd in stdin
- enable USB_KEYBOARD

 configs/nanopc-t4-rk3399_defconfig   | 7 +++++++
 configs/nanopi-m4-rk3399_defconfig   | 7 +++++++
 configs/nanopi-neo4-rk3399_defconfig | 7 +++++++
 configs/roc-pc-rk3399_defconfig      | 6 ++++++
 include/configs/evb_rk3399.h         | 5 +++++
 5 files changed, 32 insertions(+)

diff --git a/configs/nanopc-t4-rk3399_defconfig b/configs/nanopc-t4-rk3399_defconfig
index 9ea9b11574..607a00dbf7 100644
--- a/configs/nanopc-t4-rk3399_defconfig
+++ b/configs/nanopc-t4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-m4-rk3399_defconfig b/configs/nanopi-m4-rk3399_defconfig
index ad0e808bf6..3fcb7ac2d7 100644
--- a/configs/nanopi-m4-rk3399_defconfig
+++ b/configs/nanopi-m4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-neo4-rk3399_defconfig b/configs/nanopi-neo4-rk3399_defconfig
index d038a8cab9..b9ea535e43 100644
--- a/configs/nanopi-neo4-rk3399_defconfig
+++ b/configs/nanopi-neo4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index d540a17aeb..be76524cef 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -59,3 +59,9 @@ CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
index c0b0358893..2d3db22877 100644
--- a/include/configs/evb_rk3399.h
+++ b/include/configs/evb_rk3399.h
@@ -6,6 +6,11 @@
 #ifndef __EVB_RK3399_H
 #define __EVB_RK3399_H
 
+#define ROCKCHIP_DEVICE_SETTINGS \
+		"stdin=serial,usbkbd\0" \
+		"stdout=serial,vidconsole\0" \
+		"stderr=serial,vidconsole\0"
+
 #include <configs/rk3399_common.h>
 
 #if defined(CONFIG_ENV_IS_IN_MMC)
-- 
2.17.1

[PATCH v2 4/4] rockchip: Enable HDMI output on rk3399 board w/ HDMI

[Jagan Teki]

Enable config options and console setting to respective
rk3399 board for HDMI output.

Boards supported and tested on this patch are:
- NanoPc T4
- NanoPi M4
- NanoPi Neo4
- ROC-RK3399-PC

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- use usbkbd in stdin
- enable USB_KEYBOARD

 configs/nanopc-t4-rk3399_defconfig   | 7 +++++++
 configs/nanopi-m4-rk3399_defconfig   | 7 +++++++
 configs/nanopi-neo4-rk3399_defconfig | 7 +++++++
 configs/roc-pc-rk3399_defconfig      | 6 ++++++
 include/configs/evb_rk3399.h         | 5 +++++
 5 files changed, 32 insertions(+)

diff --git a/configs/nanopc-t4-rk3399_defconfig b/configs/nanopc-t4-rk3399_defconfig
index 9ea9b11574..607a00dbf7 100644
--- a/configs/nanopc-t4-rk3399_defconfig
+++ b/configs/nanopc-t4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-m4-rk3399_defconfig b/configs/nanopi-m4-rk3399_defconfig
index ad0e808bf6..3fcb7ac2d7 100644
--- a/configs/nanopi-m4-rk3399_defconfig
+++ b/configs/nanopi-m4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-neo4-rk3399_defconfig b/configs/nanopi-neo4-rk3399_defconfig
index d038a8cab9..b9ea535e43 100644
--- a/configs/nanopi-neo4-rk3399_defconfig
+++ b/configs/nanopi-neo4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index d540a17aeb..be76524cef 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -59,3 +59,9 @@ CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
index c0b0358893..2d3db22877 100644
--- a/include/configs/evb_rk3399.h
+++ b/include/configs/evb_rk3399.h
@@ -6,6 +6,11 @@
 #ifndef __EVB_RK3399_H
 #define __EVB_RK3399_H
 
+#define ROCKCHIP_DEVICE_SETTINGS \
+		"stdin=serial,usbkbd\0" \
+		"stdout=serial,vidconsole\0" \
+		"stderr=serial,vidconsole\0"
+
 #include <configs/rk3399_common.h>
 
 #if defined(CONFIG_ENV_IS_IN_MMC)
-- 
2.17.1

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Mark Kettenis]

> From: Jagan Teki <jagan@amarulasolutions.com>
> Cc: sunil@amarulasolutions.com, u-boot@lists.denx.de,
>         linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com,
>         Jagan Teki <jagan@amarulasolutions.com>
> Date: Mon, 30 Mar 2020 23:46:10 +0530
> Content-Type: text/plain; charset=UTF-8
> 
> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> U-Boot not initializing it on this linux commit:
> 
> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> 
> There is no specific need to initialize these assigned clock
> in U-Boot as video drivers still work with default aclk and  
> hclk values. So, these clocks are simply not supported by rk3399
> clock driver.
> 
> But, during stdio probe of vidconsole, the device probe
> will try to check whether the assigned clocks on that video
> console node is initialized or not? and return error if not.
> 
> So, delete these property via -u-boot dtsi as there is
> no specific need in U-Boot.

Deleting these properties isn't very helpful as it means the U-Boot
device tree can no longer be used by the kernel.  Isn't it a better
idea to implement these clocks as stubs in the u-boot clock driver?

> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - none
> 
>  arch/arm/dts/rk3399-u-boot.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8b857ccfc7..b846f9cde7 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -99,9 +99,13 @@
>  };
>  
>  &vopb {
> +	/delete-property/ assigned-clocks;
> +	/delete-property/ assigned-clock-rates;
>  	u-boot,dm-pre-reloc;
>  };
>  
>  &vopl {
> +	/delete-property/ assigned-clocks;
> +	/delete-property/ assigned-clock-rates;
>  	u-boot,dm-pre-reloc;
>  };
> -- 
> 2.17.1
> 
> 

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Mark Kettenis]

> From: Jagan Teki <jagan@amarulasolutions.com>
> Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
>         linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
>         Jagan Teki <jagan@amarulasolutions.com>
> Date: Mon, 30 Mar 2020 23:46:10 +0530
> Content-Type: text/plain; charset=UTF-8
> 
> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> U-Boot not initializing it on this linux commit:
> 
> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> 
> There is no specific need to initialize these assigned clock
> in U-Boot as video drivers still work with default aclk and ?
> hclk values. So, these clocks are simply not supported by rk3399
> clock driver.
> 
> But, during stdio probe of vidconsole, the device probe
> will try to check whether the assigned clocks on that video
> console node is initialized or not? and return error if not.
> 
> So, delete these property via -u-boot dtsi as there is
> no specific need in U-Boot.

Deleting these properties isn't very helpful as it means the U-Boot
device tree can no longer be used by the kernel.  Isn't it a better
idea to implement these clocks as stubs in the u-boot clock driver?

> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - none
> 
>  arch/arm/dts/rk3399-u-boot.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8b857ccfc7..b846f9cde7 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -99,9 +99,13 @@
>  };
>  
>  &vopb {
> +	/delete-property/ assigned-clocks;
> +	/delete-property/ assigned-clock-rates;
>  	u-boot,dm-pre-reloc;
>  };
>  
>  &vopl {
> +	/delete-property/ assigned-clocks;
> +	/delete-property/ assigned-clock-rates;
>  	u-boot,dm-pre-reloc;
>  };
> -- 
> 2.17.1
> 
> 

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
>
> > From: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > Cc: sunil-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org, u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org,
> >         linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org,
> >         Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > Date: Mon, 30 Mar 2020 23:46:10 +0530
> > Content-Type: text/plain; charset=UTF-8
> >
> > Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > U-Boot not initializing it on this linux commit:
> >
> > commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> >
> > There is no specific need to initialize these assigned clock
> > in U-Boot as video drivers still work with default aclk and
> > hclk values. So, these clocks are simply not supported by rk3399
> > clock driver.
> >
> > But, during stdio probe of vidconsole, the device probe
> > will try to check whether the assigned clocks on that video
> > console node is initialized or not? and return error if not.
> >
> > So, delete these property via -u-boot dtsi as there is
> > no specific need in U-Boot.
>
> Deleting these properties isn't very helpful as it means the U-Boot
> device tree can no longer be used by the kernel.  Isn't it a better
> idea to implement these clocks as stubs in the u-boot clock driver?

I did try this before sorting out these changes, seems like it
requires a bit more tweaking the clock wrt display code. I really
didn't see any use case as of now for just to print u-boot log on
display out, and more over this support has been broken since from
releases. so bypassing these nodes can be a solutions for now.

Jagan.

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Jagan Teki <jagan@amarulasolutions.com>
> > Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
> >         linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
> >         Jagan Teki <jagan@amarulasolutions.com>
> > Date: Mon, 30 Mar 2020 23:46:10 +0530
> > Content-Type: text/plain; charset=UTF-8
> >
> > Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > U-Boot not initializing it on this linux commit:
> >
> > commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> >
> > There is no specific need to initialize these assigned clock
> > in U-Boot as video drivers still work with default aclk and
> > hclk values. So, these clocks are simply not supported by rk3399
> > clock driver.
> >
> > But, during stdio probe of vidconsole, the device probe
> > will try to check whether the assigned clocks on that video
> > console node is initialized or not? and return error if not.
> >
> > So, delete these property via -u-boot dtsi as there is
> > no specific need in U-Boot.
>
> Deleting these properties isn't very helpful as it means the U-Boot
> device tree can no longer be used by the kernel.  Isn't it a better
> idea to implement these clocks as stubs in the u-boot clock driver?

I did try this before sorting out these changes, seems like it
requires a bit more tweaking the clock wrt display code. I really
didn't see any use case as of now for just to print u-boot log on
display out, and more over this support has been broken since from
releases. so bypassing these nodes can be a solutions for now.

Jagan.

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Kever Yang]

Hi Jagan,

On 2020/3/31 下午1:59, Jagan Teki wrote:
> On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>> From: Jagan Teki <jagan@amarulasolutions.com>
>>> Cc: sunil@amarulasolutions.com, u-boot@lists.denx.de,
>>>          linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com,
>>>          Jagan Teki <jagan@amarulasolutions.com>
>>> Date: Mon, 30 Mar 2020 23:46:10 +0530
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
>>> U-Boot not initializing it on this linux commit:
>>>
>>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
>>>
>>> There is no specific need to initialize these assigned clock
>>> in U-Boot as video drivers still work with default aclk and
>>> hclk values. So, these clocks are simply not supported by rk3399
>>> clock driver.
>>>
>>> But, during stdio probe of vidconsole, the device probe
>>> will try to check whether the assigned clocks on that video
>>> console node is initialized or not? and return error if not.
>>>
>>> So, delete these property via -u-boot dtsi as there is
>>> no specific need in U-Boot.
>> Deleting these properties isn't very helpful as it means the U-Boot
>> device tree can no longer be used by the kernel.  Isn't it a better
>> idea to implement these clocks as stubs in the u-boot clock driver?
> I did try this before sorting out these changes, seems like it
> requires a bit more tweaking the clock wrt display code. I really
> didn't see any use case as of now for just to print u-boot log on
> display out, and more over this support has been broken since from
> releases. so bypassing these nodes can be a solutions for now.


I agree with Mark for not touch the dts first. I don't know the detail 
of display driver but:

- The rk3399 driver use to work without touch dts from kernel;

- the clock driver have a rk3399_vop_set_clk() which does not depends on 
dts.


Thanks,

- Kever

>
> Jagan.
>
>

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Kever Yang]

Hi Jagan,

On 2020/3/31 ??1:59, Jagan Teki wrote:
> On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>> From: Jagan Teki <jagan@amarulasolutions.com>
>>> Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
>>>          linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
>>>          Jagan Teki <jagan@amarulasolutions.com>
>>> Date: Mon, 30 Mar 2020 23:46:10 +0530
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
>>> U-Boot not initializing it on this linux commit:
>>>
>>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
>>>
>>> There is no specific need to initialize these assigned clock
>>> in U-Boot as video drivers still work with default aclk and
>>> hclk values. So, these clocks are simply not supported by rk3399
>>> clock driver.
>>>
>>> But, during stdio probe of vidconsole, the device probe
>>> will try to check whether the assigned clocks on that video
>>> console node is initialized or not? and return error if not.
>>>
>>> So, delete these property via -u-boot dtsi as there is
>>> no specific need in U-Boot.
>> Deleting these properties isn't very helpful as it means the U-Boot
>> device tree can no longer be used by the kernel.  Isn't it a better
>> idea to implement these clocks as stubs in the u-boot clock driver?
> I did try this before sorting out these changes, seems like it
> requires a bit more tweaking the clock wrt display code. I really
> didn't see any use case as of now for just to print u-boot log on
> display out, and more over this support has been broken since from
> releases. so bypassing these nodes can be a solutions for now.


I agree with Mark for not touch the dts first. I don't know the detail 
of display driver but:

- The rk3399 driver use to work without touch dts from kernel;

- the clock driver have a rk3399_vop_set_clk() which does not depends on 
dts.


Thanks,

- Kever

>
> Jagan.
>
>

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

Hi Kever,

On Thu, Apr 2, 2020 at 2:48 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Jagan,
>
> On 2020/3/31 下午1:59, Jagan Teki wrote:
> > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >>> From: Jagan Teki <jagan@amarulasolutions.com>
> >>> Cc: sunil@amarulasolutions.com, u-boot@lists.denx.de,
> >>>          linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com,
> >>>          Jagan Teki <jagan@amarulasolutions.com>
> >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> >>> Content-Type: text/plain; charset=UTF-8
> >>>
> >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> >>> U-Boot not initializing it on this linux commit:
> >>>
> >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> >>>
> >>> There is no specific need to initialize these assigned clock
> >>> in U-Boot as video drivers still work with default aclk and
> >>> hclk values. So, these clocks are simply not supported by rk3399
> >>> clock driver.
> >>>
> >>> But, during stdio probe of vidconsole, the device probe
> >>> will try to check whether the assigned clocks on that video
> >>> console node is initialized or not? and return error if not.
> >>>
> >>> So, delete these property via -u-boot dtsi as there is
> >>> no specific need in U-Boot.
> >> Deleting these properties isn't very helpful as it means the U-Boot
> >> device tree can no longer be used by the kernel.  Isn't it a better
> >> idea to implement these clocks as stubs in the u-boot clock driver?
> > I did try this before sorting out these changes, seems like it
> > requires a bit more tweaking the clock wrt display code. I really
> > didn't see any use case as of now for just to print u-boot log on
> > display out, and more over this support has been broken since from
> > releases. so bypassing these nodes can be a solutions for now.
>
>
> I agree with Mark for not touch the dts first. I don't know the detail
> of display driver but:
>
> - The rk3399 driver use to work without touch dts from kernel;
>
> - the clock driver have a rk3399_vop_set_clk() which does not depends on
> dts.

The existing video drivers are written based on the puma dts and those
are not inline to Linux dts files, i.e. the reason the code is pushed
I think. The rest of rk3399 dtsi files are now inline to Linux as and
display out on these are broken from last 2 releases. so my idea is to
resolve the things one-after-another like
1. Make existing video stuff work with all rk3399 (this series along
with this patch)
2. Drop this patch change and make video drivers working w/o any
explicit changes in dts like this patch does.

Since step 2, would take time, and require close testing of all boards
I would like to pick the existing stuff for the release. Mark my words
to fix the things for the next release.

Jagan.

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

Hi Kever,

On Thu, Apr 2, 2020 at 2:48 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Jagan,
>
> On 2020/3/31 ??1:59, Jagan Teki wrote:
> > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >>> From: Jagan Teki <jagan@amarulasolutions.com>
> >>> Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
> >>>          linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
> >>>          Jagan Teki <jagan@amarulasolutions.com>
> >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> >>> Content-Type: text/plain; charset=UTF-8
> >>>
> >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> >>> U-Boot not initializing it on this linux commit:
> >>>
> >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> >>>
> >>> There is no specific need to initialize these assigned clock
> >>> in U-Boot as video drivers still work with default aclk and
> >>> hclk values. So, these clocks are simply not supported by rk3399
> >>> clock driver.
> >>>
> >>> But, during stdio probe of vidconsole, the device probe
> >>> will try to check whether the assigned clocks on that video
> >>> console node is initialized or not? and return error if not.
> >>>
> >>> So, delete these property via -u-boot dtsi as there is
> >>> no specific need in U-Boot.
> >> Deleting these properties isn't very helpful as it means the U-Boot
> >> device tree can no longer be used by the kernel.  Isn't it a better
> >> idea to implement these clocks as stubs in the u-boot clock driver?
> > I did try this before sorting out these changes, seems like it
> > requires a bit more tweaking the clock wrt display code. I really
> > didn't see any use case as of now for just to print u-boot log on
> > display out, and more over this support has been broken since from
> > releases. so bypassing these nodes can be a solutions for now.
>
>
> I agree with Mark for not touch the dts first. I don't know the detail
> of display driver but:
>
> - The rk3399 driver use to work without touch dts from kernel;
>
> - the clock driver have a rk3399_vop_set_clk() which does not depends on
> dts.

The existing video drivers are written based on the puma dts and those
are not inline to Linux dts files, i.e. the reason the code is pushed
I think. The rest of rk3399 dtsi files are now inline to Linux as and
display out on these are broken from last 2 releases. so my idea is to
resolve the things one-after-another like
1. Make existing video stuff work with all rk3399 (this series along
with this patch)
2. Drop this patch change and make video drivers working w/o any
explicit changes in dts like this patch does.

Since step 2, would take time, and require close testing of all boards
I would like to pick the existing stuff for the release. Mark my words
to fix the things for the next release.

Jagan.

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Mark Kettenis]

> From: Jagan Teki <jagan@amarulasolutions.com>
> Date: Thu, 2 Apr 2020 15:07:01 +0530
> 
> Hi Kever,
> 
> On Thu, Apr 2, 2020 at 2:48 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> >
> > Hi Jagan,
> >
> > On 2020/3/31 下午1:59, Jagan Teki wrote:
> > > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >>> From: Jagan Teki <jagan@amarulasolutions.com>
> > >>> Cc: sunil@amarulasolutions.com, u-boot@lists.denx.de,
> > >>>          linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com,
> > >>>          Jagan Teki <jagan@amarulasolutions.com>
> > >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> > >>> Content-Type: text/plain; charset=UTF-8
> > >>>
> > >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > >>> U-Boot not initializing it on this linux commit:
> > >>>
> > >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> > >>>
> > >>> There is no specific need to initialize these assigned clock
> > >>> in U-Boot as video drivers still work with default aclk and
> > >>> hclk values. So, these clocks are simply not supported by rk3399
> > >>> clock driver.
> > >>>
> > >>> But, during stdio probe of vidconsole, the device probe
> > >>> will try to check whether the assigned clocks on that video
> > >>> console node is initialized or not? and return error if not.
> > >>>
> > >>> So, delete these property via -u-boot dtsi as there is
> > >>> no specific need in U-Boot.
> > >> Deleting these properties isn't very helpful as it means the U-Boot
> > >> device tree can no longer be used by the kernel.  Isn't it a better
> > >> idea to implement these clocks as stubs in the u-boot clock driver?
> > > I did try this before sorting out these changes, seems like it
> > > requires a bit more tweaking the clock wrt display code. I really
> > > didn't see any use case as of now for just to print u-boot log on
> > > display out, and more over this support has been broken since from
> > > releases. so bypassing these nodes can be a solutions for now.
> >
> >
> > I agree with Mark for not touch the dts first. I don't know the detail
> > of display driver but:
> >
> > - The rk3399 driver use to work without touch dts from kernel;
> >
> > - the clock driver have a rk3399_vop_set_clk() which does not depends on
> > dts.
> 
> The existing video drivers are written based on the puma dts and those
> are not inline to Linux dts files, i.e. the reason the code is pushed
> I think. The rest of rk3399 dtsi files are now inline to Linux as and
> display out on these are broken from last 2 releases. so my idea is to
> resolve the things one-after-another like
> 1. Make existing video stuff work with all rk3399 (this series along
> with this patch)
> 2. Drop this patch change and make video drivers working w/o any
> explicit changes in dts like this patch does.
> 
> Since step 2, would take time, and require close testing of all boards
> I would like to pick the existing stuff for the release. Mark my words
> to fix the things for the next release.

Fair enough.  I don't think fixing the issue is too difficult, but it
is better to do these things in small steps anyway.

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Mark Kettenis]

> From: Jagan Teki <jagan@amarulasolutions.com>
> Date: Thu, 2 Apr 2020 15:07:01 +0530
> 
> Hi Kever,
> 
> On Thu, Apr 2, 2020 at 2:48 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> >
> > Hi Jagan,
> >
> > On 2020/3/31 ??1:59, Jagan Teki wrote:
> > > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >>> From: Jagan Teki <jagan@amarulasolutions.com>
> > >>> Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
> > >>>          linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
> > >>>          Jagan Teki <jagan@amarulasolutions.com>
> > >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> > >>> Content-Type: text/plain; charset=UTF-8
> > >>>
> > >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > >>> U-Boot not initializing it on this linux commit:
> > >>>
> > >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> > >>>
> > >>> There is no specific need to initialize these assigned clock
> > >>> in U-Boot as video drivers still work with default aclk and
> > >>> hclk values. So, these clocks are simply not supported by rk3399
> > >>> clock driver.
> > >>>
> > >>> But, during stdio probe of vidconsole, the device probe
> > >>> will try to check whether the assigned clocks on that video
> > >>> console node is initialized or not? and return error if not.
> > >>>
> > >>> So, delete these property via -u-boot dtsi as there is
> > >>> no specific need in U-Boot.
> > >> Deleting these properties isn't very helpful as it means the U-Boot
> > >> device tree can no longer be used by the kernel.  Isn't it a better
> > >> idea to implement these clocks as stubs in the u-boot clock driver?
> > > I did try this before sorting out these changes, seems like it
> > > requires a bit more tweaking the clock wrt display code. I really
> > > didn't see any use case as of now for just to print u-boot log on
> > > display out, and more over this support has been broken since from
> > > releases. so bypassing these nodes can be a solutions for now.
> >
> >
> > I agree with Mark for not touch the dts first. I don't know the detail
> > of display driver but:
> >
> > - The rk3399 driver use to work without touch dts from kernel;
> >
> > - the clock driver have a rk3399_vop_set_clk() which does not depends on
> > dts.
> 
> The existing video drivers are written based on the puma dts and those
> are not inline to Linux dts files, i.e. the reason the code is pushed
> I think. The rest of rk3399 dtsi files are now inline to Linux as and
> display out on these are broken from last 2 releases. so my idea is to
> resolve the things one-after-another like
> 1. Make existing video stuff work with all rk3399 (this series along
> with this patch)
> 2. Drop this patch change and make video drivers working w/o any
> explicit changes in dts like this patch does.
> 
> Since step 2, would take time, and require close testing of all boards
> I would like to pick the existing stuff for the release. Mark my words
> to fix the things for the next release.

Fair enough.  I don't think fixing the issue is too difficult, but it
is better to do these things in small steps anyway.

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

On Thu, Apr 2, 2020 at 3:48 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Jagan Teki <jagan@amarulasolutions.com>
> > Date: Thu, 2 Apr 2020 15:07:01 +0530
> >
> > Hi Kever,
> >
> > On Thu, Apr 2, 2020 at 2:48 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> > >
> > > Hi Jagan,
> > >
> > > On 2020/3/31 下午1:59, Jagan Teki wrote:
> > > > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >>> From: Jagan Teki <jagan@amarulasolutions.com>
> > > >>> Cc: sunil@amarulasolutions.com, u-boot@lists.denx.de,
> > > >>>          linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com,
> > > >>>          Jagan Teki <jagan@amarulasolutions.com>
> > > >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> > > >>> Content-Type: text/plain; charset=UTF-8
> > > >>>
> > > >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > > >>> U-Boot not initializing it on this linux commit:
> > > >>>
> > > >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> > > >>>
> > > >>> There is no specific need to initialize these assigned clock
> > > >>> in U-Boot as video drivers still work with default aclk and
> > > >>> hclk values. So, these clocks are simply not supported by rk3399
> > > >>> clock driver.
> > > >>>
> > > >>> But, during stdio probe of vidconsole, the device probe
> > > >>> will try to check whether the assigned clocks on that video
> > > >>> console node is initialized or not? and return error if not.
> > > >>>
> > > >>> So, delete these property via -u-boot dtsi as there is
> > > >>> no specific need in U-Boot.
> > > >> Deleting these properties isn't very helpful as it means the U-Boot
> > > >> device tree can no longer be used by the kernel.  Isn't it a better
> > > >> idea to implement these clocks as stubs in the u-boot clock driver?
> > > > I did try this before sorting out these changes, seems like it
> > > > requires a bit more tweaking the clock wrt display code. I really
> > > > didn't see any use case as of now for just to print u-boot log on
> > > > display out, and more over this support has been broken since from
> > > > releases. so bypassing these nodes can be a solutions for now.
> > >
> > >
> > > I agree with Mark for not touch the dts first. I don't know the detail
> > > of display driver but:
> > >
> > > - The rk3399 driver use to work without touch dts from kernel;
> > >
> > > - the clock driver have a rk3399_vop_set_clk() which does not depends on
> > > dts.
> >
> > The existing video drivers are written based on the puma dts and those
> > are not inline to Linux dts files, i.e. the reason the code is pushed
> > I think. The rest of rk3399 dtsi files are now inline to Linux as and
> > display out on these are broken from last 2 releases. so my idea is to
> > resolve the things one-after-another like
> > 1. Make existing video stuff work with all rk3399 (this series along
> > with this patch)
> > 2. Drop this patch change and make video drivers working w/o any
> > explicit changes in dts like this patch does.
> >
> > Since step 2, would take time, and require close testing of all boards
> > I would like to pick the existing stuff for the release. Mark my words
> > to fix the things for the next release.
>
> Fair enough.  I don't think fixing the issue is too difficult, but it
> is better to do these things in small steps anyway.

I have managed to fix this via clock driver(which seems more
reasonable as per Kever), so this is dropped in v3. thanks for
noticing.

Jagan.

[PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

On Thu, Apr 2, 2020 at 3:48 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Jagan Teki <jagan@amarulasolutions.com>
> > Date: Thu, 2 Apr 2020 15:07:01 +0530
> >
> > Hi Kever,
> >
> > On Thu, Apr 2, 2020 at 2:48 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> > >
> > > Hi Jagan,
> > >
> > > On 2020/3/31 ??1:59, Jagan Teki wrote:
> > > > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >>> From: Jagan Teki <jagan@amarulasolutions.com>
> > > >>> Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
> > > >>>          linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
> > > >>>          Jagan Teki <jagan@amarulasolutions.com>
> > > >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> > > >>> Content-Type: text/plain; charset=UTF-8
> > > >>>
> > > >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > > >>> U-Boot not initializing it on this linux commit:
> > > >>>
> > > >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> > > >>>
> > > >>> There is no specific need to initialize these assigned clock
> > > >>> in U-Boot as video drivers still work with default aclk and
> > > >>> hclk values. So, these clocks are simply not supported by rk3399
> > > >>> clock driver.
> > > >>>
> > > >>> But, during stdio probe of vidconsole, the device probe
> > > >>> will try to check whether the assigned clocks on that video
> > > >>> console node is initialized or not? and return error if not.
> > > >>>
> > > >>> So, delete these property via -u-boot dtsi as there is
> > > >>> no specific need in U-Boot.
> > > >> Deleting these properties isn't very helpful as it means the U-Boot
> > > >> device tree can no longer be used by the kernel.  Isn't it a better
> > > >> idea to implement these clocks as stubs in the u-boot clock driver?
> > > > I did try this before sorting out these changes, seems like it
> > > > requires a bit more tweaking the clock wrt display code. I really
> > > > didn't see any use case as of now for just to print u-boot log on
> > > > display out, and more over this support has been broken since from
> > > > releases. so bypassing these nodes can be a solutions for now.
> > >
> > >
> > > I agree with Mark for not touch the dts first. I don't know the detail
> > > of display driver but:
> > >
> > > - The rk3399 driver use to work without touch dts from kernel;
> > >
> > > - the clock driver have a rk3399_vop_set_clk() which does not depends on
> > > dts.
> >
> > The existing video drivers are written based on the puma dts and those
> > are not inline to Linux dts files, i.e. the reason the code is pushed
> > I think. The rest of rk3399 dtsi files are now inline to Linux as and
> > display out on these are broken from last 2 releases. so my idea is to
> > resolve the things one-after-another like
> > 1. Make existing video stuff work with all rk3399 (this series along
> > with this patch)
> > 2. Drop this patch change and make video drivers working w/o any
> > explicit changes in dts like this patch does.
> >
> > Since step 2, would take time, and require close testing of all boards
> > I would like to pick the existing stuff for the release. Mark my words
> > to fix the things for the next release.
>
> Fair enough.  I don't think fixing the issue is too difficult, but it
> is better to do these things in small steps anyway.

I have managed to fix this via clock driver(which seems more
reasonable as per Kever), so this is dropped in v3. thanks for
noticing.

Jagan.