[REGRESSION][BISECTED] No display on rk3399-gru-kevin
Vicente Bergas
vicencb at gmail.com
Mon Jun 22 10:08:00 PDT 2026
On Mon, Jun 22, 2026 at 4:02 AM Damon Ding <damon.ding at rock-chips.com> wrote:
>
> Hi Vicente,
>
> On 6/19/2026 7:51 AM, Vicente Bergas wrote:
> > On Thu, Jun 18, 2026 at 5:49 AM Damon Ding <damon.ding at rock-chips.com> wrote:
> >>
> >> Hi Vicente,
> >>
> >> On 6/18/2026 7:15 AM, Vicente Bergas wrote:
> >>> On Wed, Jun 17, 2026 at 10:45 AM Heiko Stübner <heiko at sntech.de> wrote:
> >>>>
> >>>> Hi Vicente,
> >>>>
> >>>> Am Mittwoch, 17. Juni 2026, 01:05:27 Mitteleuropäische Sommerzeit schrieb Vicente Bergas:
> >>>>> Hello,
> >>>>> there are two issues that result on a black screen on the rk3399-gru-kevin.
> >>>>>
> >>>>> The first one is due to:
> >>>>> c8079f83e0bf312645050c17d9c87deb707369c1
> >>>>> gpio: rockchip: convert to dynamic GPIO base allocation
> >>>>
> >>>> can you check that your kernel contains
> >>>> "gpio: rockchip: Fix GPIO regression after conversion to dynamic base allocation"
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5cd9c6d332f46d1de8b68117fe2a3f1b08ee80ff
> >>>
> >>> Yes, that commit is in v7.1 and it indeed fixes the gpio issue.
> >>> I tested reverting c8079f83 alone and reverting all three.
> >>> Now i've tested only reverting 51eb548a and d84b087c, and it works.
> >>> The thing is both bugs coexisted at some point and
> >>> git bisect finds them in order.
> >>>
> >>>>> Reverting this does not fix the problem as there is a second one:
> >>>>> 51eb548ade20158b4f4f8693a95b1f31a2480e8e
> >>>>> drm/bridge: analogix_dp: Apply DP helper API drm_dp_channel_eq_ok()
> >>>>>
> >>>>> That second one depends on:
> >>>>> d84b087c7662dd65cd51b228219987c31b1cee02
> >>>>> drm/bridge: analogix_dp: Apply DP helper APIs to get adjusted voltages
> >>>>> and pre-emphasises
> >>>>>
> >>>>> Reverting all three commits from v7.1 make the display work again.
> >>>>>
> >>>>> Please, can this be resolved?
> >>>>
> >>>> and as Damon wrote, please provide logs, so we can see the actual problem
> >>>
> >>> It is quite difficult to read the logs from a black screen...
> >>> Jokes apart, here they are:
> >>>
> >>> Relevant log entries:
> >>> <6>[ 0.043668] /dp at fec00000: Fixed dependency cycle(s) with /vop at ff8f0000
> >>> <6>[ 0.043735] /vop at ff8f0000: Fixed dependency cycle(s) with /dp at fec00000
> >>> <6>[ 0.044192] /dp at fec00000: Fixed dependency cycle(s) with /vop at ff900000
> >>> <6>[ 0.044250] /vop at ff900000: Fixed dependency cycle(s) with /dp at fec00000
> >>> <6>[ 0.045064] /vop at ff900000: Fixed dependency cycle(s) with /dp at ff970000
> >>> <6>[ 0.045122] /vop at ff8f0000: Fixed dependency cycle(s) with /dp at ff970000
> >>> <6>[ 0.045194] /dp at ff970000: Fixed dependency cycle(s) with /vop at ff8f0000
> >>> <6>[ 0.045264] /dp at ff970000: Fixed dependency cycle(s) with /vop at ff900000
> >>> <6>[ 0.058590] /dp at ff970000: Fixed dependency cycle(s) with /edp-panel
> >>> <6>[ 0.058733] /edp-panel: Fixed dependency cycle(s) with /dp at ff970000
> >>> <6>[ 0.101266] platform ff8f0000.vop: Adding to iommu group 2
> >>> <6>[ 0.102073] platform ff900000.vop: Adding to iommu group 3
> >>> <3>[ 0.105258] rockchip-dp ff970000.dp: no DP phy configured
> >>> <3>[ 0.308638] rockchip-dp ff970000.dp: no DP phy configured
> >>> <6>[ 0.310104] panfrost ff9a0000.gpu: clock rate = 500000000
> >>> <6>[ 0.311210] panfrost ff9a0000.gpu: mali-t860 id 0x860 major 0x2
> >>> minor 0x0 status 0x0
> >>> <6>[ 0.311223] panfrost ff9a0000.gpu: features: 00000000,00000407,
> >>> issues: 00000000,24040400
> >>> <6>[ 0.311231] panfrost ff9a0000.gpu: Features: L2:0x07120206
> >>> Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff
> >>> JS:0x7
> >>> <6>[ 0.311239] panfrost ff9a0000.gpu: shader_present=0xf l2_present=0x1
> >>> <6>[ 0.312664] [drm] Initialized panfrost 1.6.0 for ff9a0000.gpu on minor 0
> >>> <3>[ 0.624232] rockchip-dp ff970000.dp: no DP phy configured
> >>> <3>[ 0.639611] rockchip-dp ff970000.dp: no DP phy configured
> >>> <6>[ 0.641512] rockchip-drm display-subsystem: bound ff900000.vop
> >>> (ops 0xffff800080c9a3c8)
> >>> <6>[ 0.642646] rockchip-drm display-subsystem: bound ff8f0000.vop
> >>> (ops 0xffff800080c9a3c8)
> >>> <4>[ 0.643198] [drm] Missing drm_bridge_add() before attach
> >>> <6>[ 0.643238] rockchip-drm display-subsystem: bound ff970000.dp
> >>> (ops 0xffff800080c9e840)
> >>> <6>[ 0.644029] rockchip-drm display-subsystem: bound fec00000.dp
> >>> (ops 0xffff800080c9f0c8)
> >>> <6>[ 0.644102] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not
> >>> connected; disabling cdn
> >>> <6>[ 0.644837] [drm] Initialized rockchip 1.0.0 for
> >>> display-subsystem on minor 1
> >>> <4>[ 0.786773] panel-edp edp-panel: Skipping disable of already
> >>> disabled panel
> >>> <3>[ 0.796517] rockchip-dp ff970000.dp: EQ Max loop
> >>> <3>[ 0.797745] rockchip-dp ff970000.dp: LT EQ failed!
> >>> <3>[ 0.797757] rockchip-dp ff970000.dp: eDP link training failed (-5)
> >>> <3>[ 0.797770] rockchip-dp ff970000.dp: unable to do link train, ret=-5
> >>> <3>[ 0.797783] [drm:analogix_dp_bridge_atomic_enable] *ERROR* dp
> >>> commit error, ret = -5
> >>> <3>[ 0.797823] rockchip-dp ff970000.dp: failed to set bridge, retry: 0
> >>> <4>[ 0.797937] panel-edp edp-panel: Skipping disable of already
> >>> disabled panel
> >>> <3>[ 0.808097] rockchip-dp ff970000.dp: EQ Max loop
> >>> <3>[ 0.809284] rockchip-dp ff970000.dp: LT EQ failed!
> >>> <3>[ 0.809299] rockchip-dp ff970000.dp: eDP link training failed (-5)
> >>> <3>[ 0.809314] rockchip-dp ff970000.dp: unable to do link train, ret=-5
> >>> <3>[ 0.809326] [drm:analogix_dp_bridge_atomic_enable] *ERROR* dp
> >>> commit error, ret = -5
> >>> <3>[ 0.809353] rockchip-dp ff970000.dp: failed to set bridge, retry: 1
> >>> <4>[ 0.809463] panel-edp edp-panel: Skipping disable of already
> >>> disabled panel
> >>> <3>[ 0.819481] rockchip-dp ff970000.dp: EQ Max loop
> >>> <3>[ 0.820745] rockchip-dp ff970000.dp: LT EQ failed!
> >>> <3>[ 0.820758] rockchip-dp ff970000.dp: eDP link training failed (-5)
> >>> <3>[ 0.820772] rockchip-dp ff970000.dp: unable to do link train, ret=-5
> >>> <3>[ 0.820781] [drm:analogix_dp_bridge_atomic_enable] *ERROR* dp
> >>> commit error, ret = -5
> >>> <3>[ 0.820806] rockchip-dp ff970000.dp: failed to set bridge, retry: 2
> >>> <4>[ 0.820919] panel-edp edp-panel: Skipping disable of already
> >>> disabled panel
> >>> <3>[ 0.831075] rockchip-dp ff970000.dp: EQ Max loop
> >>> <3>[ 0.832336] rockchip-dp ff970000.dp: LT EQ failed!
> >>> <3>[ 0.832346] rockchip-dp ff970000.dp: eDP link training failed (-5)
> >>> <3>[ 0.832356] rockchip-dp ff970000.dp: unable to do link train, ret=-5
> >>> <3>[ 0.832367] [drm:analogix_dp_bridge_atomic_enable] *ERROR* dp
> >>> commit error, ret = -5
> >>> <3>[ 0.832388] rockchip-dp ff970000.dp: failed to set bridge, retry: 3
> >>> <4>[ 0.832496] panel-edp edp-panel: Skipping disable of already
> >>> disabled panel
> >>> <3>[ 0.842613] rockchip-dp ff970000.dp: EQ Max loop
> >>> <3>[ 0.843754] rockchip-dp ff970000.dp: LT EQ failed!
> >>> <3>[ 0.843765] rockchip-dp ff970000.dp: eDP link training failed (-5)
> >>> <3>[ 0.843778] rockchip-dp ff970000.dp: unable to do link train, ret=-5
> >>> <3>[ 0.843791] [drm:analogix_dp_bridge_atomic_enable] *ERROR* dp
> >>> commit error, ret = -5
> >>> <3>[ 0.843815] rockchip-dp ff970000.dp: failed to set bridge, retry: 4
> >>> <3>[ 0.843857] rockchip-dp ff970000.dp: too many times retry set
> >>> bridge, give it up
> >>> <6>[ 0.854625] Console: switching to colour frame buffer device 300x100
> >>> <6>[ 0.887526] rockchip-drm display-subsystem: [drm] fb0:
> >>> rockchipdrmfb frame buffer device
> >>>
> >>>
> >>
> >> I have tested RK3399 IND EVB locally based on kernel v7.1, and eDP
> >> training completes successfully with normal display output with patch
> >> 0001-arm64-dts-rockchip-Enable-eDP-display-for-RK3399-IND.patch applied.
> >>
> >> From your logs, the failure occurs during the EQ stage of eDP training.
> >> Please apply the additional patch
> >> 0002-drm-bridge-analogix_dp-Read-CR-EQ-delay-from-DPCD-in.patch without
> >> reverting the two commits mentioned above (51eb548a and d84b087c), then
> >> retest to check if the issue gets improved.
> >> (BTW: This is a test-only temporary patch with minor style flaws, but
> >> the patch needs upstreaming. I'll rework and send a formal version soon.)
> >
> > Hi Damon,
> > applying patch 0001 and 0002 does not fix the issue.
> > The logs are mostly the same.
> >
> >> If the problem persists, try adding a small delay at the location
> >> mentioned below for further verification:
> >
> > applying the extra delay results are the same, just small noise in the
> > dmesg timestamps.
> >
> > Besides this, i've done another test:
> > i have reverted 51eb548a while keeping d84b087c, which i had to rebase.
> > The result is again the same: black screen and the logs are again equivalent.
> > That proves that both patches 51eb548a and d84b087c each introduce a regression.
> >
>
> Thanks a lot for all these thorough tests, your results give me much
> clearer clues.
>
> I suspect the root cause is not the EQ training delay, but incorrect PE
> (pre-emphasis) and VS (voltage swing) register configuration.
>
> Please do not revert any of the two commits mentioned above. Instead,
> apply the following patch which may properly resolve the black screen
> issue you are seeing:
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index a5dc645d7005..30ad952c5c12 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -306,7 +306,9 @@ static void
> analogix_dp_get_adjust_training_lane(struct analogix_dp_device *dp,
> lane_count = dp->link_train.lane_count;
> for (lane = 0; lane < lane_count; lane++) {
> voltage_swing =
> drm_dp_get_adjust_request_voltage(link_status, lane);
> + voltage_swing >>= DP_TRAIN_VOLTAGE_SWING_SHIFT;
> pre_emphasis =
> drm_dp_get_adjust_request_pre_emphasis(link_status, lane);
> + pre_emphasis >>= DP_TRAIN_PRE_EMPHASIS_SHIFT;
> training_lane = DPCD_VOLTAGE_SWING_SET(voltage_swing) |
> DPCD_PRE_EMPHASIS_SET(pre_emphasis);
>
> @@ -352,7 +354,9 @@ static int analogix_dp_process_clock_recovery(struct
> analogix_dp_device *dp)
> for (lane = 0; lane < lane_count; lane++) {
> training_lane = analogix_dp_get_lane_link_training(dp,
> lane);
> voltage_swing =
> drm_dp_get_adjust_request_voltage(link_status, lane);
> + voltage_swing >>= DP_TRAIN_VOLTAGE_SWING_SHIFT;
> pre_emphasis =
> drm_dp_get_adjust_request_pre_emphasis(link_status, lane);
> + pre_emphasis >>= DP_TRAIN_PRE_EMPHASIS_SHIFT;
>
> if (DPCD_VOLTAGE_SWING_GET(training_lane) ==
> voltage_swing &&
> DPCD_PRE_EMPHASIS_GET(training_lane) == pre_emphasis)
>
>
> Without this fix, there is no obvious error when pre-emphasis equals 0,
> but wrong register values will be programmed once PE is non-zero.
You found it!
Applying the shifts makes it work.
Thanks,
Vicente.
> Best regards,
> Damon
More information about the Linux-rockchip
mailing list