[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them
Imre Deak
imre.deak at intel.com
Fri Sep 3 17:42:38 UTC 2021
On Fri, Sep 03, 2021 at 06:39:14PM +0300, Imre Deak wrote:
> On Fri, Sep 03, 2021 at 06:03:30PM +0300, Ville Syrjälä wrote:
> > On Fri, Sep 03, 2021 at 02:10:17PM +0300, Jani Nikula wrote:
> > > 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
> >
> > Couldn't hurt I suppose. Although those bits should default to 0, unless
> > the BIOS/something mucks them up for whatever reason.
>
> I tried the two patches (I assume the above failure was on shards-iclb2)
> and it still fails. The panel reports that it supports TPS4 while it
> doesn't support TPS3, which is a bit odd. I also tried if LT works with
> TPS3, but that also fails.
>
> Still checking if this panel works on other hosts.
Tried it on the above and another ICL and TGL both on Linux and Windows,
link training fails. I assume this panel only supports TPS2, the DPCD/FW
(or the panel) is just buggy. I wonder if it's possible to reflash the
FW on it.
For now I replaced it on shards-iclb2 with another 4k panel with TPS4
support with that LT passes with the two patches applied.
--Imre
> This panel could be simply buggy (wrong FW on it?). I found two other panels in
> CI with TPS4:
> CI_DRM_10549/fi-icl-u2/0/boot.log:<7> i915 0000:00:02.0: [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 00 c4 c1 00 00 01 c0 02 00 00 00 00 0b 00
> CI_DRM_10549/fi-tgl-y/0/boot.log:<7> i915 0000:00:02.0: [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 00 c4 c1 00 00 01 c0 02 00 00 00 00 0b 00
>
> On fi-icl-u2 LT passes with TPS4, on fi-tgl-y only TPS3 is used (no HBR3
> support there).
>
> We could either quirk this panel, or fall back to TPS2/3 if LT failed
> with TPS4.
>
> The EDP_DPCD_REV>=0x4 check as a dependency for TPS4, seems to match the
> eDP spec:
>
> """
> Use of DPCD Rev. 1.4 extends the new DP v1.3 capabilities to eDP v1.4a
> (and higher) devices, including features as HBR3 and TPS4.
> Identification of an eDP v1.4a (and higher) Sink device is indicated by
> a value of 04h (and higher) in the EDP_DPCD_REV register (DPCD Address
> 00700h).
> """
More information about the Intel-gfx
mailing list