[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

Jani Nikula jani.nikula at linux.intel.com
Fri Sep 3 11:10:17 UTC 2021


On Mon, 22 Mar 2021, Ville Syrjälä <ville.syrjala at 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.almahallawy@intel.com


-- 
Jani Nikula, Intel Open Source Graphics Center


More information about the Intel-gfx mailing list