[Intel-gfx] [PATCH v4 RESEND 0/4] Kernel PSR Fix-ups

Jim Bride jim.bride at linux.intel.com
Wed Jul 26 17:09:20 UTC 2017


On Tue, Jul 25, 2017 at 08:13:03PM +0300, David Weinehall wrote:
> On Tue, Jul 25, 2017 at 09:48:07AM -0700, Jim Bride wrote:
> > These patches, along with an upcoming series for IGT, enable our
> > PSR IGT tests to run reliably once again on HSW, BDW, and SKL.
> > The first change enables us to run the PSR tests on some RVP platforms
> > whose panels have too slow of a setup time when running in their
> > preferred mode.  The second fixes a minor problem with the way that
> > we were initializing SRD_CTL that caused us to clobber a bit that we
> > are not supposed to change in that register on SKL and KBL.  The third
> > change re-introduces some changes to our link training code to be less
> > aggressive about changing link state for eDP, because PSR depends on
> > the link state being the same at PSR exit as it was at PSR entry.
> > The fourth change greatly increases the reliability of reading the
> > sink CRC generated by the eDP panel.
> > 
> > v2 Highlights:
> >    * Rebased to current drm-tip
> >    * Greatly reduced looping around trying to read sink CRC (Jani)
> >    * Reduce amount of changes in the sink CRC patch (Jani)
> >    * Field-wise init of EDP_PSR_MAX_SLEEP_TIME (Rodrigo)
> >    * Minor commit message / cover letter tweaks
> > 
> > v3:
> >    * Re-ordered patches to put reviewed patches first.
> >    * Rebased to current drm-tip
> > 
> > v4: 
> >    * Addressed review feedback (see patches for details)
> >    * Rebase
> 
> Is this a pure resend, or does it include any fixes on top of earlier
> versions? As mentioned elsewhere I experienced issues with both your
> previous patch series and the two before that one.

Yes, it's a pure resend (I didn't see that CI had picked them up.).
These patches still run fine for me on my HW (all RVPs) on HSW, BDW,
and SKL.  Have you tried to ssh into the systems to see if it's just
the display having issues vs. the whole system being hung?

Jim


> I'll run a new testrun with this series just in case (it might be that
> the issues I noticed were caused by bad interaction with some other
> component).
> 
> 
> Kind regards, David Weinehall


More information about the Intel-gfx mailing list