[Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link training result

[Imre Deak]

On Sat, Aug 21, 2021 at 02:02:03AM +0300, Imre Deak wrote:
> On Sat, Aug 21, 2021 at 01:20:04AM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 18, 2021 at 07:17:12PM +0300, Imre Deak wrote:
> > > On Wed, Aug 18, 2021 at 06:09:43PM +0300, Lee, Shawn C wrote:
> > > > On Tue, 2021-07-07, Lee Shawn C <shawn.c.lee at intel.com> wrote:
> > > > >On Tue, 2021-07-07, Almahallawy, Khaled <khaled.almahallawy at intel.com> wrote:
> > > > >>I believe Imre's LT fallback:
> > > > >>https://github.com/ideak/linux/commits/linktraining-fallback-fix  and Chrome user space fix:
> > > > >>https://chromium-review.googlesource.com/c/chromium/src/+/3003487
> > > > >>should address Chrome concerns for LT failure and LTTPRs
> > > > >>
> > > > >
> > > > >Thanks for comment! The new fallback patch should help on this DPRX problem.
> > > > >One more thing. If driver did not handle DPRX link train failed properly.
> > > > >It would impact link layer compliance test case in below.
> > > > >
> > > > >400.3.1.3
> > > > >400.3.1.4
> > > > >400.3.1.6
> > > > >400.3.1.12
> > > > >400.3.1.13
> > > > >400.3.1.14
> > > > >
> > > > >Best regards,
> > > > >Shawn
> > > > >
> > > > 
> > > > Hi all, before Imre's patch series land on upstream driver. The link train failed
> > > > handling works for LTTPR only. But DPRX does not. Could you please consider to have
> > > > this change as temporary solution? Thanks!
> > > 
> > > I sent already fixing this, see
> > > https://lore.kernel.org/intel-gfx/20201027133600.3656665-1-imre.deak@intel.com/
> > > 
> > > but it fell through the cracks. Applied now your patch, thanks.
> > 
> > We seem to have a tgl that fails consistently at DPRX link training:
> > https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-1115g4.html
> > 
> > Previously the error went unnoticed.
> 
> Yea, didn't notice this. Can't see anything obvious, besides that it's a
> DPCD rev 1.1 monitor, so maybe not compatible with LTTPRs. I follow up
> if I find something.

Power cycling the machine and replugging the monitor and Type C dongle
and native DP cable fixed it. So, it could be a flaky connection
(unlikely, because detection worked), or the port in a stuck state even
across warm-reboots. The latter would mean the machine wasn't power cycled
for a long time and that's likely because the pstore kernel didn't boot
(grub failed to load it due to a missing initrd).

One possibile root cause is the TypeC PHY getting stuck across warm
reboots issue (and nothing recovering it besides a power-cycle), that was
fixed by
151ec347b06a2fb ("drm/i915: Force a TypeC PHY disconnect during suspend/shutdown")

I'll re-check this after more CI testruns.

> > -- 
> > Ville Syrjälä
> > Intel