On Fri, Oct 23, 2020 at 8:48 AM Jason Andryuk <jandryuk@xxxxxxxxx> wrote: > > We're seeing channel equalization "fail" consistently coming out of DPMS > on the eDP of a Dell Latitude 7200 2-in-1. When the display tries to > come out of DPMS, it briefly flashes on before going dark. This repeats > once per second, and the system is unusable. ssh-ing into the system, > it also seems to be sluggish when in this state. You have to reboot to > get the display back. > > In intel_dp_link_training_channel_equalization, lane 0 can get to state > 0x7 by the 3rd pattern, but lane 1 never gets further than 0x1. > [drm] ln0_1:0x0 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x0 adj_req2_3:0x0 > [drm] ln0_1:0x11 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x44 adj_req2_3:0x0 > [drm] ln0_1:0x11 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x88 adj_req2_3:0x0 > [drm] ln0_1:0x71 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0 > [drm] ln0_1:0x71 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0 > [drm] ln0_1:0x71 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0 > > Narrow fast vs. wide slow is not an option because the max clock is > 270000 and the 1920x1280 resolution requires 2x270000. > [drm] DP link computation with lane count min/max 1/2 270000/270000 bpp > min/max 18/24 pixel clock 164250KHz > > The display is functional even though lane 1 is in state 0x1, so just > return success for channel equalization on eDP. > > Introduce QUIRK_EDP_CHANNEL_EQ and match the DMI for a Dell Latitude > 7200 2-in-1. This quirk allows channel equalization to succeed even > though it failed. > > Workaround for https://gitlab.freedesktop.org/drm/intel/-/issues/1378 CI reported the patch doesn't apply to drm-tip. It was developed against 5.4 and forward ported to 5.10-rc1-ish when I submitted it. It applied there but not to drm-tip. 5.4 & 5.6.6 is fine until DPMS. Then when it tries to come out, it fails link training and gives the flashing. 5.8.16 starts flashing during boot. I guess the driver now runs link training during boot? drm-tip doesn't have the flashing issue. I guess "drm/i915: Switch to LTTPR non-transparent mode link training" or some of the other link training change lets the hardware succeed? Oh, this is interesting: kernel: i915 0000:00:02.0: [drm:hsw_set_signal_levels [i915]] Using signal levels 02000000 kernel: [drm:intel_dp_link_train_phy [i915]] ln0_1:0x71 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0 kernel: i915 0000:00:02.0: [drm:intel_dp_link_train_phy [i915]] Channel equalization failed 5 times kernel: i915 0000:00:02.0: [drm:intel_dp_link_train_phy [i915]] [CONNECTOR:95:eDP-1] Link Training failed at link rate = 270000, lane count = 2, at DPRX kernel: i915 0000:00:02.0: [drm:intel_enable_pipe [i915]] enabling pipe A Note DPRX above, so not using LTTPR. Looks like the link training logic is wrong. : intel_dp_link_training_channel_equalization fails, so intel_dp_link_train_phy fails, but: intel_dp_link_train_all_phys(struct intel_dp *intel_dp, const struct intel_crtc_state *crtc_state, int lttpr_count) { bool ret = true; int i; intel_dp_prepare_link_train(intel_dp, crtc_state); for (i = lttpr_count - 1; i >= 0; i--) { enum drm_dp_phy dp_phy = DP_PHY_LTTPR(i); ret = intel_dp_link_train_phy(intel_dp, crtc_state, dp_phy); intel_dp_disable_dpcd_training_pattern(intel_dp, dp_phy); if (!ret) break; } if (ret) intel_dp_link_train_phy(intel_dp, crtc_state, DP_PHY_DPRX); Here we don't update ret, so linking training "succeeds" for DPRX. This does let the 7200 display "work", but it's probably not what you want in general. Regards, Jason
