[REGRESSION][BISECTED] No display on rk3399-gru-kevin
Damon Ding
damon.ding at rock-chips.com
Tue Jun 23 21:00:19 PDT 2026
On 6/23/2026 1:08 AM, Vicente Bergas wrote:
> 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.
>
Great to hear the shift logic resolves the issue!
I've submitted the finalized patches to drm-misc branch. If the patches
resolve the issue on your hardware, I'd appreciate a Reviewed-by or
Tested-by tag.
Best regards,
Damon
More information about the Linux-rockchip
mailing list