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@xxxxxxxxxx>
> > > ---
> > > 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
