Hi Piotr, 在 2025-03-10 04:53:50，"Piotr Oniszczuk" <piotr.oniszc...@gmail.com> 写道： > > >> Wiadomość napisana przez Andy Yan <andys...@163.com> w dniu 7 mar 2025, o >> godz. 01:48: >> >> >> Hi Piotr, >> 在 2025-03-06 22:28:08，"Piotr Oniszczuk" <piotr.oniszc...@gmail.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-andys...@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-andys...@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@1080@50 - ok >-playing then video1920@1080@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"; +}; + > >
