[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Thu, Sep 08, 2016 at 01:09:23PM +0200, Martin van Es wrote: > On donderdag 8 september 2016 13:18:41 CEST Ville Syrjälä wrote: > > On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote: > > > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > > > > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > > > > 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 > > > > > > This kernel doesn't boot (for me). > > > > > > I cloned the repo, copied .config from 4.7 kernel, make oldconfig, > > > accepted > > > all defaults and made+installed the kernel. This installed an image > > > 4.0.0-rc7+ (is that correct?) that was unbootable (halts at loading > > > ramdisk). > > The version should be 4.7 or 4.8 something. Maybe you used the wrong > > branch? > > Oh silly me and git. I thought I'd be checking out the correct branch on > cloning that repo. I now checked out opregion_panel_type_quirk branch and > that > resulted in a 4.8.0-rc5+ kernel. > > Booting that kernel resulted in a correct functioning backlight based on > acpi_video0 driver. Graphics glitches however were so bad I had to reboot > into > 4.7.3 to write this mail. > > dmesg of 4.8.0-rc5+ boot with drm.debug=0xe attached. Thanks Martin. I was in vacation last week, let me know if you need me to test as well but me and Martin are reproducing the exact same issue so I believe his testing should have provided all info needed for now. While talking about graphics glitches this reminds I'm getting corrupted graphics on terminals (sandy bridge HD3000) with any intel driver >=x11-drivers/xf86-video-intel-2.99.917_p20160803 I had to add: cat /etc/portage/package.mask/x11 >=x11-drivers/xf86-video-intel-2.99.917_p20160803 Last working version for me is: qlist -I -v video-intel x11-drivers/xf86-video-intel-2.99.917_p20160704 That is most certainly an unrelated issue with the backlight, and I'm not even sure if it affects the Ivy Bridge laptop with hd4000, as I ended up never testing anything above 2.99.917_p20160704 on it. But in my experience you may want to try to downgrade the xorg intel video driver version too if you get graphic glitches.
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote: > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > > 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 > > This kernel doesn't boot (for me). > > I cloned the repo, copied .config from 4.7 kernel, make oldconfig, accepted > all defaults and made+installed the kernel. This installed an image > 4.0.0-rc7+ > (is that correct?) that was unbootable (halts at loading ramdisk). The version should be 4.7 or 4.8 something. Maybe you used the wrong branch? Anywyas I pushed a new branch "opregion_panel_type_quirk" which I'm hoping will be the final fix we go with. Just waiting for confirmation that I got the quirk right and that the original machine fixed by the OpRegion stuff still works. You might want to test that one as well. -- Ville Syrjälä Intel OTC
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On donderdag 8 september 2016 13:18:41 CEST Ville Syrjälä wrote: > On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote: > > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > > > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > > > 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 > > > > This kernel doesn't boot (for me). > > > > I cloned the repo, copied .config from 4.7 kernel, make oldconfig, > > accepted > > all defaults and made+installed the kernel. This installed an image > > 4.0.0-rc7+ (is that correct?) that was unbootable (halts at loading > > ramdisk). > The version should be 4.7 or 4.8 something. Maybe you used the wrong > branch? Oh silly me and git. I thought I'd be checking out the correct branch on cloning that repo. I now checked out opregion_panel_type_quirk branch and that resulted in a 4.8.0-rc5+ kernel. Booting that kernel resulted in a correct functioning backlight based on acpi_video0 driver. Graphics glitches however were so bad I had to reboot into 4.7.3 to write this mail. dmesg of 4.8.0-rc5+ boot with drm.debug=0xe attached. Best regards, Martin -- next part -- [0.542922] RPC: Registered tcp transport module. [0.542923] RPC: Registered tcp NFSv4.1 backchannel transport module. [0.542931] pci :00:02.0: Video device with shadowed ROM at [mem 0x000c-0x000d] [0.543421] PCI: CLS 64 bytes, default 64 [0.543467] Unpacking initramfs... [0.714001] Freeing initrd memory: 8652K (880036f0a000 - 88003777d000) [0.714004] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [0.714007] software IO TLB [mem 0xa12e8000-0xa52e8000] (64MB) mapped at [8800a12e8000-8800a52e7fff] [0.714121] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer [0.714122] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [0.714123] RAPL PMU: hw unit of domain package 2^-16 Joules [0.714123] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules [0.715012] futex hash table entries: 1024 (order: 4, 65536 bytes) [0.715028] audit: initializing netlink subsys (disabled) [0.715039] audit: type=2000 audit(1473332278.712:1): initialized [0.715316] workingset: timestamp_bits=56 max_order=21 bucket_order=0 [0.717297] FS-Cache: Netfs 'nfs' registered for caching [0.717425] NFS: Registering the id_resolver key type [0.717430] Key type id_resolver registered [0.717431] Key type id_legacy registered [0.717434] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [0.717436] Installing knfsd (copyright (C) 1996 okir at monad.swb.de). [0.717606] FS-Cache: Netfs 'cifs' registered for caching [0.717665] Key type cifs.spnego registered [0.717667] Key type cifs.idmap registered [0.717669] ntfs: driver 2.1.32 [Flags: R/W]. [0.717760] fuse init (API version 7.25) [0.719052] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [0.719054] io scheduler noop registered [0.719055] io scheduler deadline registered [0.719060] io scheduler cfq registered (default) [0.719297] intel_idle: MWAIT substates: 0x21120 [0.719298] intel_idle: v0.4.1 model 0x3A [0.719458] intel_idle: lapic_timer_reliable_states 0x [0.823856] ACPI: AC Adapter [ADP0] (on-line) [0.823923] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 [0.823927] ACPI: Power Button [PWRB] [0.823963] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 [0.823964] ACPI: Sleep Button [SLPB] [0.824000] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 [0.824401] ACPI: Lid Switch [LID0] [0.824453] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [0.824456] ACPI: Power Button [PWRF] [0.827283] thermal LNXTHERM:00: registered as thermal_zone0 [0.827285] ACPI: Thermal Zone [TZ00] (59 C) [0.827538] thermal LNXTHERM:01: registered as thermal_zone1 [0.827539] ACPI: Thermal Zone [TZ01] (59 C) [0.828297] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [0.830483] Linux agpgart interface v0.103 [0.830520] [drm:drm_core_init] Initialized drm 1.1.0 20060810 [0.830676] [drm:intel_detect_pch] Found PantherPoint PCH [0.830679] [drm:get_allowed_dc_mask] Allowed DC state mask 00 [0.830724] [drm:intel_device_info_dump] i915 device info: gen=7, pciid=0x0166 rev=0x09
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > 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 This kernel doesn't boot (for me). I cloned the repo, copied .config from 4.7 kernel, make oldconfig, accepted all defaults and made+installed the kernel. This installed an image 4.0.0-rc7+ (is that correct?) that was unbootable (halts at loading ramdisk). Best regards, Martin
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
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
> > > ---
> > > 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
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
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
> > ---
> > 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
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
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
> ---
> 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
--
Ville Syrjälä
Intel OTC
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Tue, 30 Aug 2016, Martin van Es wrote: > Hi Andrea, > > I'd be happy to test, but what am I testing when applying these boot > parameters? In other words: what should I report? The point is, for an ivybridge setting those parameters should not make *any* difference. BR, Jani. > > And just to be sure, I THINK I own an IVB but intel is not very vocal about > it > when searching for familyname. I have a > > vendor_id : GenuineIntel > cpu family : 6 > model : 58 > model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz > stepping: 9 > microcode : 0x17 > > Regards, > Martin > > On maandag 29 augustus 2016 20:48:43 CEST Andrea Arcangeli wrote: >> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: >> > If it's an Iybridge, there's no low vswing, and that explanation is >> > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 >> > on an unpatched kernel. >> >> CC'ed Martin who filed the bz, he can reproduce too >> https://bugzilla.kernel.org/show_bug.cgi?id=151731 >> >> Since you can reproduce would you have the time to test the two above >> options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid >> I won't be able to test it today and I'll be mostly offline for a week >> starting tomorrow. >> >> Thanks, >> Andrea -- Jani Nikula, Intel Open Source Technology Center
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On dinsdag 30 augustus 2016 11:13:40 CEST Jani Nikula wrote: > On Tue, 30 Aug 2016, Martin van Es wrote: > > Hi Andrea, > > > > I'd be happy to test, but what am I testing when applying these boot > > parameters? In other words: what should I report? > > The point is, for an ivybridge setting those parameters should not make > *any* difference. I can confirm that neither i915.edp_vswing=1 nor i915.edp_vswing=2 fixes the problem in 4.7.2 for me (intel_backlight devices takes precedence). Best regards, Martin
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Mon, 29 Aug 2016, Andrea Arcangeli wrote: > On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: >> If it's an Iybridge, there's no low vswing, and that explanation is >> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 >> on an unpatched kernel. > > CC'ed Martin who filed the bz, he can reproduce too > https://bugzilla.kernel.org/show_bug.cgi?id=151731 > > Since you can reproduce would you have the time to test the two above > options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid > I won't be able to test it today and I'll be mostly offline for a week > starting tomorrow. As I tried to explain, the low voltage swing is not related to backlight issues. BR, Jani. > > Thanks, > Andrea -- Jani Nikula, Intel Open Source Technology Center
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
Hi Andrea, I'd be happy to test, but what am I testing when applying these boot parameters? In other words: what should I report? And just to be sure, I THINK I own an IVB but intel is not very vocal about it when searching for familyname. I have a vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping: 9 microcode : 0x17 Regards, Martin On maandag 29 augustus 2016 20:48:43 CEST Andrea Arcangeli wrote: > On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: > > If it's an Iybridge, there's no low vswing, and that explanation is > > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 > > on an unpatched kernel. > > CC'ed Martin who filed the bz, he can reproduce too > https://bugzilla.kernel.org/show_bug.cgi?id=151731 > > Since you can reproduce would you have the time to test the two above > options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid > I won't be able to test it today and I'll be mostly offline for a week > starting tomorrow. > > Thanks, > Andrea
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: > If it's an Iybridge, there's no low vswing, and that explanation is > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 > on an unpatched kernel. CC'ed Martin who filed the bz, he can reproduce too https://bugzilla.kernel.org/show_bug.cgi?id=151731 Since you can reproduce would you have the time to test the two above options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid I won't be able to test it today and I'll be mostly offline for a week starting tomorrow. Thanks, Andrea
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Mon, 29 Aug 2016, Andrea Arcangeli wrote: > On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: >> If it's an Iybridge, there's no low vswing, and that explanation is >> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 >> on an unpatched kernel. > > What I should look for when trying those two settings? Will they > successfully fix my problem with intel_backlight with upstream 4.8-rc? > > I thought it had to be the same issue as on skylake as I get the > backlight flikering at low frequency but getting brighter and darker > in a cycle lasting a few seconds and I thought there couldn't be too > many other random bugs that ends up with the same side effect. Your Ivybridge does not have low voltage swing *and* low voltage swing has nothing to do with the backlight. The regressing commit may be the same for you, but the failure mode appears to be completely different. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: > If it's an Iybridge, there's no low vswing, and that explanation is > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 > on an unpatched kernel. What I should look for when trying those two settings? Will they successfully fix my problem with intel_backlight with upstream 4.8-rc? I thought it had to be the same issue as on skylake as I get the backlight flikering at low frequency but getting brighter and darker in a cycle lasting a few seconds and I thought there couldn't be too many other random bugs that ends up with the same side effect. It looks like the hardware actually broke, software issue isn't the first thing that comes to mind. As it's hard to imagine a timer in the kernel reprogramming the backlight setting higher and lower just to annoy me :). First in fact I thought at a plasma issue, but I tried to downgrade the kernel first as that was quicker than downgrading kde/plasma... I initially thought there were two userland daemons stepping into each other toes. Another thing is that if I keep decreasing the brightness the screen eventually goes off and it returns on as I increase the backlight level again (then low freq flickering starts). With acpi_video0 even at the lowest brightness setting of 0, it never turns off the screen completely. > Doesn't mean there can't be something else wrong with the mode you get > using a different panel_type. And this makes me wonder what the point is > in trying to patch up the commit instead of reverting. Reverting the whole thing would be sure fine with me, I don't know what the benefits there should be in using intel_backlight instead of acpi_video0 like the previous code did, but I couldn't imagine too many hw to behave like this if intel_backlight clearly has to work stable for someone or it wouldn't exist in the first place. This is just a "echo " into a backlight file if I tweak the backlight settings... doesn't sound performance critical stuff to me, ACPI will do just fine. However I'm not even sure how this problem could surface in the first place without the kernel continuously reprogramming the hw values.
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
On Sun, 28 Aug 2016, 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
That's a merge commit, the real one is
commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä
Date: Mon Apr 11 10:23:51 2016 +0300
drm/i915: Get panel_type from OpRegion panel details
> The Skylake workaround for the regression was introduced in commit
> aeddda06c1a704bb97c8a7bfe7a472120193bd56
>
> Signed-off-by: Andrea Arcangeli
> ---
> 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 it's an Iybridge, there's no low vswing, and that explanation is
false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
on an unpatched kernel.
Doesn't mean there can't be something else wrong with the mode you get
using a different panel_type. And this makes me wonder what the point is
in trying to patch up the commit instead of reverting.
BR,
Jani.
> - 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;
> }
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge
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
---
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;
}
