Rk3588: bump to 6.12 for edge and current

[amazingfate]

Description

• Most of the work is from RK3588: edge: Bump kernel from v6.11 to v6.12-rc #7372 , but that pr is not mergable.
• Why bump both current and edge? 6.11 is not a lts version of linux and it's better to keep it sync with edge when there is no lts version available. And this would allow us to delete rockchip-rk3588-6.11 when bumping kernel, which let us see the patch changes more clearly.
• I also change kernel config name to common linux-rockchip-rk3588-edge.config and linux-rockchip-rk3588-current.config.
• kernel version is bumped to 6.12-rc6

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

• ./compile.sh kernel BOARD=rock-3a BRANCH=edge DEB_COMPRESS=xz KERNEL_CONFIGURE=no KERNEL_GIT=shallow

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[SuperKali]

@amazingfate I will test on my nano pc t6 lts, firstly I need to add a patch for hdmi that is missing on nanopc t6/lts

[SuperKali]

can you take this patch https://github.com/OpenSource-YYT/build/blob/9624aa719fbac8202a8c44bee49bd93f4c3d92dd/patch/kernel/archive/rockchip-rk3588-6.12/1052-board-nanopc-t6-Add-HDMI-support.patch that enable missing nodes for nanopc t6/lts

[amazingfate]

I'm testing hdmi on armsom sige7 now. After confirming hdmi works I will add patches of T6

[SuperKali]

@amazingfate with this PR, my nanopc not works correctly, no boot from sd card, only boot from emmc and nvme, I don't have any video output.

[SuperKali]

rockchip-vop2 fdd90000.vop: [drm:vop2_bind] ERROR failed to get hdmi0_phy_pll source

[SuperKali]

I still investigating about the sd card issue, regarding hdmi seems like the clock name are inaccessible, you've tested on your side if HDMI works?

[SuperKali]

sd card issue was about my balena etcher.. I used dd and works

[SuperKali]

No hdmi output:

nanopct6-lts:~:# dmesg | grep -i vop
[    0.135544] platform fdd90000.vop: Fixed dependency cycle(s) with /hdmi@fde80000
[    0.135588] platform fde80000.hdmi: Fixed dependency cycle(s) with /vop@fdd90000
[    2.691510] rockchip-vop2 fdd90000.vop: Adding to iommu group 0
[    2.808861] rockchip-drm display-subsystem: bound fdd90000.vop (ops rockchip_drm_fini [rockchipdrm])
nanopct6-lts:~:# dmesg | grep -i hdmi
[    0.135544] platform fdd90000.vop: Fixed dependency cycle(s) with /hdmi@fde80000
[    0.135588] platform fde80000.hdmi: Fixed dependency cycle(s) with /vop@fdd90000
[    2.808922] dwhdmiqp-rockchip fde80000.hdmi: [drm] *ERROR* Unable to get rockchip,vo-grf
[    2.808930] rockchip-drm display-subsystem: failed to bind fde80000.hdmi (ops rockchip_drm_fini [rockchipdrm]): -19
nanopct6-lts:~:#

the patch:

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: SuperKali <hello@superkali.me>
Date: Sun, 10 Nov 2024 20:01:01 +0000
Subject: Add support HDMI for NanoPC T6 & LTS

Signed-off-by: SuperKali <hello@superkali.me>
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 35 ++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
index ac537e3b9c35..9444e41d36e7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
@@ -9,10 +9,11 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/usb/pd.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
 #include "rk3588.dtsi"
 
 / {
 	model = "FriendlyElec NanoPC-T6";
 	compatible = "friendlyarm,nanopc-t6", "rockchip,rk3588";
@@ -257,10 +258,15 @@ &cpu_b2 {
 
 &cpu_b3 {
 	cpu-supply = <&vdd_cpu_big1_s0>;
 };
 
+&display_subsystem {
+	clocks = <&hdptxphy_hdmi0>;
+	clock-names = "hdmi0_phy_pll";
+};
+
 &gpio0 {
 	gpio-line-names = /* GPIO0 A0-A7 */
 			  "", "", "", "",
 			  "", "", "", "",
 			  /* GPIO0 B0-B7 */
@@ -337,10 +343,24 @@ &gpio4 {
 &gpu {
 	mali-supply = <&vdd_gpu_s0>;
 	status = "okay";
 };
 
+&hdmi0 {
+	status = "okay";
+};
+
+&hdmi0_in {
+	hdmi0_in_vp0: endpoint {
+		remote-endpoint = <&vp0_out_hdmi0>;
+	};
+};
+
+&hdptxphy_hdmi0 {
+	status = "okay";
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0m2_xfer>;
 	status = "okay";
 
@@ -1095,5 +1115,20 @@ &usb_host1_ehci {
 };
 
 &usb_host1_ohci {
 	status = "okay";
 };
+
+&vop {
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
+&vp0 {
+	vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+		reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+		remote-endpoint = <&hdmi0_in_vp0>;
+	};
+};
-- 
Created with Armbian build tools https://github.com/armbian/build

[amazingfate]

There is also no hdmi output on armsom sige7, I'm checking it now.

[amazingfate]

HDMI is working now, the dts patch of hdmi bridge should get updated.

[SuperKali]

@amazingfate now working on my side:

[igorpecovnik]

Approve when you think this is ready. We ship this with 24.11

[ColorfulRhino]

HDMI is working now, the dts patch of hdmi bridge should get updated.

Have a look at 71aef28 I had updated this patch weeks ago 😄

[ColorfulRhino]

I also change kernel config name to common linux-rockchip-rk3588-edge.config and linux-rockchip-rk3588-current.config.

This was the old behaviour. @rpardini (I believe) changed it to use kernel version instead of kernel branch. IIRC this should be the default for all kernels in the future. But since I don't mind either at the moment, please discuss this with @rpardini

[igorpecovnik]

Since everyone has a slightly different opinion on how current vs edge kernel should work in general (not just rk3588),

I think observed discrepancy is related only to RK3588. Is this seen elsewhere?

[ColorfulRhino]

Since everyone has a slightly different opinion on how current vs edge kernel should work in general (not just rk3588),

I think observed discrepancy is related only to RK3588. Is this seen elsewhere?

I don't have much insights into kernels other than Rockchip, but I believe this is true, likely because we had current before there was an LTS kernel version.
Nevertheless, the more the Armbian project grows, the more impact some guidelines would have, also to help newcomers understand the difference e.g. in kernel versions more clearly. And also to maintain consistency across all kernels.

For example even for me it's still after all this time not entirely clear if the predominant main goal of the current kernel is simply

"this is a kernel based on the latest (non-rc) LTS kernel release, but besides kernel version number is has no goals of additional stability versus edge kernel and edge kernel might even be more stable due to additional hardware fixes in more recent non-LTS kernel versions"

or "this is a kernel based on the latest LTS kernel release and provides the most stable experience versus the edge kernel"

While these details won't matter for everyone, I'm sure that at least some new users and new devs might be confused about this too 😄

[amazingfate]

In my opinion if the kernel is confirmed working, we can treat it as stable current.

Above comments have discovered glitches in desktop mode. This is just an opinionated view, but while glitches like that should not be in a current kernel due to higher stability expectations, it is fine on an edge kernel if that's one of a few issues left due to lower expected overall stability.

Nevertheless, I'm sure you're able to fix this issue soon 😄

This is not an issue introduced by 6.12, it also happens with 6.11 kernel. X11 desktop performance always sucks from the old time when we are using panfork driver, and unfortunately I don't have much ability to deal with it. All I can do is to recommend uses switching to wayland.

Here are the reasons why it's better to choose an LTS kernel as current:

• all non-LTS kernels only have short support cycle, about 3 months. Then the version no longer provide security fixes, and less people will use it.
• LTS kernels have long support cycle, which means there will be much more people using it for long time purpose. For example, debian and ubuntu package LTS kernel in their LTS release. The more people using it, the more bugs get fixed, which will provide a more stable state.
• For armbian's developer, bumping kernel versions is always costing their precioustime and energy. And a LTS kernel will at least provide a break for them, so they can just bump 6.13 to 6.15 for edge if they don't have enough time for 6.14, as there is already a LTS 6.12 for current. Two LTS kernel one year, and also two current kernel one year will make developers focus more on the stability of current kernel.

There are some familes which do not set LTS as current for some reasons. For example, sm8250, that is because there are only few people in the world maintaining the kernel branch (2 or 3), so it's their decision to set which version to be stable.

[rpardini]

I also change kernel config name to common linux-rockchip-rk3588-edge.config and linux-rockchip-rk3588-current.config.
This was the old behaviour. @rpardini (I believe) changed it to use kernel version instead of kernel branch. IIRC this should be the default for all kernels in the future. But since I don't mind either at the moment, please discuss this with @rpardini
The config file with version number is introduced in this commit: a6b5ea7, and rockchip-rk3588 should be one of few families using this new behaviour.

Yes. We went that way back when there was no current branch and rk3588 mainline was very much in flux, people would say "have you tried Armbian's 6.8 yet?". Seems the flux continues, but the addition of current, which was meant to enable us to experiment more freely in edge, instead causes us to try to keep a semblance of stability to something that really has none. It's all wip.

I also hoped rockchip-rk3588 family would disappear in the future, once enough landed upstream that we could merge it back into rockchip64 proper.

So I don't mind any changes in the naming, it's clear those attempts lead nowhere.

I think observed discrepancy is related only to RK3588. Is this seen elsewhere?

Heh. We've families where current is a vendor kernel, we've families where current is a fully wip mainline.

And then we have the "big X" (rk/rk64/meson64/sunxi/sunxi64) where current means "latest LTS, best-effort rebase-patched and mostly left alone once released except if it breaks"

Here are the reasons why it's better to choose an LTS kernel as current

+1. Fully support this for this family. 6.12 is about to be released, and it's not like we have a 6.6 anyone wants to maintain.

[ColorfulRhino]

Here are the reasons why it's better to choose an LTS kernel as current:

Of course, there was never any doubt that current should be an LTS kernel 😄 I believe there was a misunderstanding.
My questions/confusions about the unclear nature still stand, however.

[efectn]

I've just tested the PR with Khadas Edge 2 and Orange Pi 5. The HDMI only works barely and not able to get proper DE experience, there are a lot of glitches. Also there are some interrupt errors in dmesg output. I've not investigated the problem further yet.
https://hastebin.com/share/dalirovowo.yaml

Do you mean desktop has a lot of glitches but tty cli is displayed well in hdmi?

No it's not usable at all. I will debug it further to see what's wrong

[amazingfate]

@efectn there is dt/rk3588s-orangepi-5.dts, I recommend deleting it because patches will be overwritten by this file.

[efectn]

@efectn there is dt/rk3588s-orangepi-5.dts, I recommend deleting it because patches will be overwritten by this file.

I don't think it's opi-specific. The other SBCs have the same issue as well. There are also approximately 2k interrupts/s by VOP2.

[amazingfate]

@efectn there is dt/rk3588s-orangepi-5.dts, I recommend deleting it because patches will be overwritten by this file.

I don't think it's opi-specific. The other SBCs have the same issue as well. There are also approximately 2k interrupts/s by VOP2.

At least opi5 has the issue now. There is no "&display_subsystem" node in dts of opi5.

[efectn]

@efectn there is dt/rk3588s-orangepi-5.dts, I recommend deleting it because patches will be overwritten by this file.

I don't think it's opi-specific. The other SBCs have the same issue as well. There are also approximately 2k interrupts/s by VOP2.

At least opi5 has the issue now. There is no "&display_subsystem" node in dts of opi5.

Ok will check it. I think we should remove all dt files which has already been mainlined