From: Quentin Schulz quentin.schulz@cherry.de
RK3399 Puma has support for driving multiple displays at the same time, the most notable scenario being HDMI+DSI since there exists a devkit with both DSI display and HDMI output.
While HDMI seems to work fine in U-Boot, as the U-Boot logo is shown whenever the EFI bootmeth is used, it messes up DSI in HDMI+DSI setup in the Linux kernel. There are some ways to work around this bug but no known appropriate fix for now, so let's rather not trigger this bug.
Since there isn't any client of ours that seems to be using this feature, let's disable it for now. Users can re-enable this feature in the event they have HDMI-only products.
Signed-off-by: Quentin Schulz quentin.schulz@cherry.de --- @linux-rockchip: you've been added to this as it's an issue in the Linux kernel but that gets triggered from U-Boot. This is a patch for U-Boot but I wanted it to be available in linux-rockchip archives :)
We recently ported Puma from 2022.10 to 2024.07 in our vendor tree but discovered that this broke the DSI display on our devkit whenever an HDMI display would be connected at boot.
While VIDEO has been enabled for a few years already on Puma, something actually started to make use of it in the "normal" boot process (it seems to be the EFI bootmeth?). While it seems to work okay-ish as the U-Boot logo is shown properly, it is followed by artefacts whenever the kernel is taking over in the boot flow. Additionally, whenever one boots with HDMI connected and has a secondary DSI display, DSI is now broken in the Linux kernel until I unplug HDMI.
A bit of debugging later, it seems we have a different clock for the DCLK of the VOP used for DSI. GPLL is used whenever no HDMI is plugged in, otherwise VPLL is used. The rate of the frac clock is also different, with 59756KHz when it doesn't work and 59400KHz when it does.
I discovered that the frac clock doesn't try to set the rate of its parent, the div clock, so tried the following:
""" diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c index 4f1a5782c2308..fd5d11b9e12ed 100644 --- a/drivers/clk/rockchip/clk-rk3399.c +++ b/drivers/clk/rockchip/clk-rk3399.c @@ -1166,7 +1166,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = { RK3399_CLKSEL_CON(49), 8, 2, MFLAGS, 0, 8, DFLAGS, RK3399_CLKGATE_CON(10), 12, GFLAGS),
- COMPOSITE_FRACMUX_NOGATE(DCLK_VOP0_FRAC, "dclk_vop0_frac", "dclk_vop0_div", 0, + COMPOSITE_FRACMUX_NOGATE(DCLK_VOP0_FRAC, "dclk_vop0_frac", "dclk_vop0_div", CLK_SET_RATE_PARENT, RK3399_CLKSEL_CON(106), 0, &rk3399_dclk_vop0_fracmux),
@@ -1196,7 +1196,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] __initdata = { RK3399_CLKSEL_CON(50), 8, 2, MFLAGS, 0, 8, DFLAGS, RK3399_CLKGATE_CON(10), 13, GFLAGS),
- COMPOSITE_FRACMUX_NOGATE(DCLK_VOP1_FRAC, "dclk_vop1_frac", "dclk_vop1_div", 0, + COMPOSITE_FRACMUX_NOGATE(DCLK_VOP1_FRAC, "dclk_vop1_frac", "dclk_vop1_div", CLK_SET_RATE_PARENT, RK3399_CLKSEL_CON(107), 0, &rk3399_dclk_vop1_fracmux), """
which made it work! But... the rate of the frac (but not the div!) is the same as well as the parent of div clock (still VPLL), so this smelled fishy, something like a timing issue.
I therefore tried to reorder the probing of HDMI and DSI with:
""" diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 6492f3caf0174..482b9a169653e 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -524,10 +524,10 @@ static int __init rockchip_drm_init(void) ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver, CONFIG_ROCKCHIP_ANALOGIX_DP); ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP); - ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver, - CONFIG_ROCKCHIP_DW_HDMI); ADD_ROCKCHIP_SUB_DRIVER(dw_mipi_dsi_rockchip_driver, CONFIG_ROCKCHIP_DW_MIPI_DSI); + ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver, + CONFIG_ROCKCHIP_DW_HDMI); ADD_ROCKCHIP_SUB_DRIVER(inno_hdmi_driver, CONFIG_ROCKCHIP_INNO_HDMI); ADD_ROCKCHIP_SUB_DRIVER(rk3066_hdmi_driver, CONFIG_ROCKCHIP_RK3066_HDMI); """
this worked too!
Then, I tried something else, applying https://lore.kernel.org/all/20240615170417.3134517-14-jonas@kwiboo.se/
... which also made it work! But re-ordering the probe order like above, broke it again. So not perfect...
It does seem that HDMI may need to be on VOPB in multidisplay scenarios? I honestly do not have any idea of what's going on here and I am not aware of any of our users using video in U-Boot, so we'll just be disabling it for now until some of our users request it in a multi-display context. Basically sweeping the dirt under the rug until someone lifts it. --- configs/puma-rk3399_defconfig | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig index 9e5499a1fec..ccc7f355dbd 100644 --- a/configs/puma-rk3399_defconfig +++ b/configs/puma-rk3399_defconfig @@ -19,6 +19,7 @@ CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb" +CONFIG_CONSOLE_MUX=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_MAX_SIZE=0x2e000 CONFIG_SPL_PAD_TO=0x38000 @@ -40,7 +41,6 @@ CONFIG_CMD_MMC=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_PMIC=y @@ -102,12 +102,4 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y -CONFIG_VIDEO=y -# CONFIG_VIDEO_BPP8 is not set -CONFIG_DISPLAY=y -CONFIG_VIDEO_ROCKCHIP=y -CONFIG_DISPLAY_ROCKCHIP_HDMI=y -CONFIG_BMP_16BPP=y -CONFIG_BMP_24BPP=y -CONFIG_BMP_32BPP=y CONFIG_ERRNO_STR=y
--- base-commit: 9366640449ac3ef702b624e2f6f7604754a9082b change-id: 20240729-puma-no-video-3d9e11ac6104
Best regards,