linux-kernel - Re:Re: [PATCH 0/6] Add support for RK3588 DisplayPort Controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4003289a.41da.195887b0462.Coremail.andyshrk@163.com>
Date: Wed, 12 Mar 2025 11:51:58 +0800 (CST)
From: "Andy Yan" <andyshrk@....com>
To: "Piotr Oniszczuk" <piotr.oniszczuk@...il.com>
Cc: heiko@...ech.de, neil.armstrong@...aro.org,
	sebastian.reichel@...labora.com, devicetree@...r.kernel.org,
	hjc@...k-chips.com, mripard@...nel.org, linux-kernel@...r.kernel.org,
	linux-rockchip@...ts.infradead.org, yubing.zhang@...k-chips.com,
	dri-devel@...ts.freedesktop.org,
	"Andy Yan" <andy.yan@...k-chips.com>, krzk+dt@...nel.org,
	robh@...nel.org, linux-arm-kernel@...ts.infradead.org,
	lumag@...nel.org, stephen@...xa.com
Subject: Re:Re: [PATCH 0/6] Add support for RK3588 DisplayPort Controller


Hi Piotr,
在 2025-03-10 04:53:50，"Piotr Oniszczuk" <piotr.oniszczuk@...il.com> 写道：
>
>
>> Wiadomość napisana przez Andy Yan <andyshrk@....com> w dniu 7 mar 2025, o godz. 01:48:
>> 
>> 
>> Hi Piotr,
>> 在 2025-03-06 22:28:08，"Piotr Oniszczuk" <piotr.oniszczuk@...il.com> 写道：
>>> 
>>> 
>> 
>> All dump information currently appears to be correct, so I'm temporarily unsure why
>> there is no display on the monitor.
>> Maybe try some plug and unplug for the DP cable, or try another cable or monitor?
>> 
>> It seems that this board uses a DP to HDMI converter? Does this transmitter need a driver?
>> 
>> I won't be at my computer over the next two or three days, so any further replies to your email
>> might have to wait until next week.
>> 
>> 
>
>Andy,
>FYI:
>
>I done test on mine rock5a with applied Naoki dp0 enablement in dts (and only in dts).
>No any changes in dw dp driver (so i’m on vanilla  https://patchwork.kernel.org/project/linux-rockchip/cover/20250223113036.74252-1-andyshrk@163.com/   )
>
>on mine rock5a ra620 hdmi port works ok.
>(I contacted also Radxa about ra620 and they confirmed: ra620 is just DP->HDMI converter. No any driver nor special programming/enablement is needed)
>
>This tells me that dp0 (rock5a) works ok while dp1 (rock5itx) not.


>i suspect issue is probably in https://patchwork.kernel.org/project/linux-rockchip/cover/20250223113036.74252-1-andyshrk@163.com/ and is related to dp1 handling?

With help from Stephen, we do some online debug, the DP1 display is  ok on his rock5itx board now。


Try the patch as bellow:

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index 75a03e6a875c..d9434310a141 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -329,7 +329,7 @@ struct dw_dp {
 
        struct dw_dp_link link;
        struct dw_dp_video video;
-       const struct dw_dp_plat_data *plat_data;
+       struct dw_dp_plat_data plat_data;


@@ -1998,7 +2012,7 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
        dp->dev = dev;
        dp->video.pixel_mode = DW_DP_MP_QUAD_PIXEL;
 
-       dp->plat_data = plat_data;
+       dp->plat_data.max_link_rate = plat_data->max_link_rate;
        bridge = &dp->bridge;
        mutex_init(&dp->irq_lock);
        INIT_WORK(&dp->hpd_work, dw_dp_hpd_work);
 


diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 17a98845fd31..2cf79a1409af 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2089,9 +2089,9 @@ static unsigned long rk3588_set_intf_mux(struct vop2_video_port *vp, int id, u32
                dip |= FIELD_PREP(RK3588_DSP_IF_POL__DP0_PIN_POL, polflags);
                break;
        case ROCKCHIP_VOP2_EP_DP1:
-               die &= ~RK3588_SYS_DSP_INFACE_EN_MIPI1_MUX;
-               die |= RK3588_SYS_DSP_INFACE_EN_MIPI1 |
-                          FIELD_PREP(RK3588_SYS_DSP_INFACE_EN_MIPI1_MUX, vp->id);
+               die &= ~RK3588_SYS_DSP_INFACE_EN_DP1_MUX;
+               die |= RK3588_SYS_DSP_INFACE_EN_DP1 |
+                          FIELD_PREP(RK3588_SYS_DSP_INFACE_EN_DP1_MUX, vp->id);
                dip &= ~RK3588_DSP_IF_POL__DP1_PIN_POL;
                dip |= FIELD_PREP(RK3588_DSP_IF_POL__DP1_PIN_POL, polflags);
                break;



>
>BTW: there seems to be issue with video modes handling on dp0 port: 
>-playing video 1920@...0@50 - ok
>-playing then video1920@...0@59,64 hangs board….
>
>hdmi0 works ok. video modes issue is only on dp0
The dclk for vp2 is default from GPLL, it can't divde pixel clock for such a refresh rates, 
But it should not hang the board, Sebastian, it seems the frequence of  GPLL be changed?


Plesase try it like this: bond the dclk source for VP2 from V0PLL.

+&vop {
+	assigned-clocks = <&cru DCLK_VOP2_SRC>;
+	assigned-clock-parents = <&cru PLL_V0PLL>;
+	status = "okay";
+};
+
>
>