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

[Ville Syrjälä]

On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote:
> 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

And I've gone an pushed a potential fix to the same branch. So pleas try
it and let me know how it goes. And I still would like to see the dmesg
with drm.debug=0xe from that attempt.

-- 
Ville Syrjälä
Intel OTC