On Fri, Sep 03, 2021 at 02:10:17PM +0300, Jani Nikula wrote: > On Mon, 22 Mar 2021, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > > On Fri, Mar 19, 2021 at 07:08:40PM -0000, Patchwork wrote: > >> == Series Details == > >> > >> Series: drm/i915: Enable TPS3/4 on all platforms that support them > >> URL : https://patchwork.freedesktop.org/series/88186/ > >> State : success > >> > >> == Summary == > >> > >> CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815 > >> ==================================================== > >> > >> Summary > >> ------- > >> > >> **SUCCESS** > > > > That's a bit odd considering the link training still fails with this. > > Did we convert some erorrs to debugs perhaps, or maybe this never > > got flagged as an error? > > > > <7>[ 8.235008] i915 0000:00:02.0: [drm:intel_dp_start_link_train [i915]] > > Using LINK_RATE_SET value 03 > > <7>[ 8.236203] i915 0000:00:02.0: [drm:intel_dp_set_signal_levels > > [i915]] Using vswing level 0, pre-emphasis level 0, at DPRX > > <7>[ 8.236341] i915 0000:00:02.0: > > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY > > A] Using DP training pattern TPS1 > > <7>[ 8.237373] i915 0000:00:02.0: [drm:intel_dp_link_train_phy [i915]] > > clock recovery OK > > <7>[ 8.237460] i915 0000:00:02.0: > > [drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY > > A] Using DP training pattern TPS4 > > <7>[ 8.239054] i915 0000:00:02.0: [drm:intel_dp_dump_link_status.isra.4 > > [i915]] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x0 > > adj_req2_3:0x0 > > <7>[ 8.239135] i915 0000:00:02.0: [drm:intel_dp_link_train_phy [i915]] > > Clock recovery check failed, cannot continue channel equalization > > <7>[ 8.239218] i915 0000:00:02.0: [drm:intel_dp_link_train_phy [i915]] > > [CONNECTOR:308:eDP-1] Link Training failed at link rate = 270000, lane > > count = 2, at DPRX > > > > So CR lock is lost as soon as we switch to TPS4. I really wonder if the sink > > actually even implements TPS4, and maybe when we write TPS4 to the DPCD reg > > it starts to expect some other pattern? Should be semi-easy to confirm > > I guess... > > > > One thing I was pondering is whether we're detecting TPS4 vs. TPS3 > > differently > > that eg. Windows. Based on some trawling it looks to me that for some reason > > Windows uses the EDP_DPCD_REV>=0x4 check rather than DPCD_REV>=0x14 on eDP > > panels when checking for TPS4 suppport. Unfortunately following that > > convention here wouldn't help us: > > > > <7>[ 6.835706] i915 0000:00:02.0: [drm:intel_dp_init_connector [i915]] > > eDP DPCD: 04 fb ff > > <7>[ 8.234921] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: Base DPCD: > > 14 0a 82 41 00 00 01 c0 02 00 00 00 0f 09 80 > > <7>[ 8.234943] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 > > 0a 82 c1 00 00 01 c0 02 00 00 00 0f 09 80 > > Should try this in combination with [1]? > > BR, > Jani. > > > [1] > https://patchwork.freedesktop.org/patch/msgid/20210719235927.283173-1-khaled.almahall...@intel.com
Couldn't hurt I suppose. Although those bits should default to 0, unless the BIOS/something mucks them up for whatever reason. -- Ville Syrjälä Intel
