[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

[Ville Syrjälä]

On Tue, Sep 06, 2016 at 12:20:51PM +0300, Ville Syrjälä wrote:
> On Sun, Aug 28, 2016 at 05:28:46PM +0200, Andrea Arcangeli wrote:
> > Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> > model which is based on IvyBridge.
> > 
> > The commit that introduced the regression is
> > 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > 
> > The Skylake workaround for the regression was introduced in commit
> > aeddda06c1a704bb97c8a7bfe7a472120193bd56
> > 
> > Signed-off-by: Andrea Arcangeli <aarcange at redhat.com>
> > ---
> >  drivers/gpu/drm/i915/intel_opregion.c | 12 +++++++-----
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
> > index adca262..ca17ab6 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -1073,12 +1073,14 @@ intel_opregion_get_panel_type(struct drm_i915_private *dev_priv)
> >  	}
> >  
> >  	/*
> > -	 * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> > -	 * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> > -	 * vswing instead. Low vswing results in some display flickers, so
> > -	 * let's simply ignore the OpRegion panel type on SKL for now.
> > +	 * FIXME On Dell XPS 13 9350 and Dell XPS 13 L322X the
> > +	 * OpRegion panel type (0) gives us low vswing for eDP,
> > +	 * whereas the VBT panel type (2) gives us normal vswing
> > +	 * instead. Low vswing results in some display flickers, so
> > +	 * let's simply ignore the OpRegion panel type on SKL and
> > +	 * IVYBRIDGE for now.
> >  	 */
> > -	if (IS_SKYLAKE(dev_priv)) {
> > +	if (IS_SKYLAKE(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
> >  		DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> >  		return -ENODEV;
> >  	}
> 
> Argh. I guess we'll just have to revert the whole opregion panel type thing
> and ty to figure out some way to do this only for the system(s) that need it.
> 
> Hmm. Can someone test the top commit from [1] on top of the broken kernel?
> If we can get an EDID somehow for the panel then the panel type shouldn't
> matter that much any more.
> 
> [1] git://github.com/vsyrjala/linux.git acpi_edid

Actually I just cooked up another branch [2]. It just throws in some
memory barriers to the opregion code, and adds a a new debug print so
to show the response from the BIOS. I'm not too optimistic that the
memory barriers would fix it, but at least we'd get to see the full
response from the BIOS. Can you give this a try?

[2] git://github.com/vsyrjala/linux.git opregion_panel_type_stuff

-- 
Ville Syrjälä
Intel OTC