Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > > > > I guess we'll need the bisect on this one to make progress.
>> > > > > 
>> > > > > Sigh, I was afraid that might be the next step.
>> > > > 
>> > > > OK, I have a curious data point.  I assumed the problem would
>> > > > be
>> > > > somewhere in the drm update, so I started bisecting that at the
>> > > > top. 
>> > > >  However, the top most commit:
>> > > > 
>> > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> > > > Merge: 1f40c49 a39ed68
>> > > > Author: Linus Torvalds 
>> > > > Date:   Mon May 23 11:48:48 2016 -0700
>> > > > 
>> > > > Merge branch 'drm-next' of
>> > > > git://people.freedesktop.org/~airlied/linux
>> > > > 
>> > > > Isn't actually bad.  There's no flicker here, so whatever
>> > > > caused
>> > > > the
>> > > > problem came from some update after this.
>> > > 
>> > > There was a fixes pull after this. Might be worth it to restrict
>> > > to
>> > > just
>> > > the i915 changes, which are just
>> > > 5b4fd5bb1230cd037..157d2c7fad0863222
>> > > 
>> > > Looking at those nothing seems to stick out which might explain
>> > > what's
>> > > happening for you.
>> 
>> OK, so just on the firmware, the system seems less flickery with the
>> new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
>> issue.  The flicker isn't gone for good, but seems to be reboot 
>> dependent (it's there in some boots, but gone on a reboot).
>> 
>> > This should be easy enough to try before bisecting:
>> > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git
>> > -s
>> > end-email-mika.kah...@intel.com
>> 
>> Applying this didn't seem to make a difference: still there on some 
>> and gone on other reboots.
>
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä 
Date:   Tue Sep 13 12:22:19 2016 +0300

drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes, headed upstream soon-ish.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > > > > I guess we'll need the bisect on this one to make progress.
>> > > > > 
>> > > > > Sigh, I was afraid that might be the next step.
>> > > > 
>> > > > OK, I have a curious data point.  I assumed the problem would
>> > > > be
>> > > > somewhere in the drm update, so I started bisecting that at the
>> > > > top. 
>> > > >  However, the top most commit:
>> > > > 
>> > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> > > > Merge: 1f40c49 a39ed68
>> > > > Author: Linus Torvalds 
>> > > > Date:   Mon May 23 11:48:48 2016 -0700
>> > > > 
>> > > > Merge branch 'drm-next' of
>> > > > git://people.freedesktop.org/~airlied/linux
>> > > > 
>> > > > Isn't actually bad.  There's no flicker here, so whatever
>> > > > caused
>> > > > the
>> > > > problem came from some update after this.
>> > > 
>> > > There was a fixes pull after this. Might be worth it to restrict
>> > > to
>> > > just
>> > > the i915 changes, which are just
>> > > 5b4fd5bb1230cd037..157d2c7fad0863222
>> > > 
>> > > Looking at those nothing seems to stick out which might explain
>> > > what's
>> > > happening for you.
>> 
>> OK, so just on the firmware, the system seems less flickery with the
>> new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
>> issue.  The flicker isn't gone for good, but seems to be reboot 
>> dependent (it's there in some boots, but gone on a reboot).
>> 
>> > This should be easy enough to try before bisecting:
>> > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git
>> > -s
>> > end-email-mika.kah...@intel.com
>> 
>> Applying this didn't seem to make a difference: still there on some 
>> and gone on other reboots.
>
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

Fixed by

commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639
Author: Ville Syrjälä 
Date:   Tue Sep 13 12:22:19 2016 +0300

drm/i915: Ignore OpRegion panel type except on select machines

in drm-intel-fixes, headed upstream soon-ish.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Sun, 11 Sep 2016, James Hogan  wrote:
> I've just bisected a similar (same?) problem (slow increase and
> decrease of screen brightness with a period of a few seconds) to the
> same commit (this is on a Dell XPS 13 laptop)
>
> 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 difference for me is that good commits used the acpi backlight,
> and bad ones used the intel backlight (/sys/class/backlight/). Its
> like intel_backlight is fighting with the firmware to control the
> backlight or something. Reverting the commit on v4.7.3 switches it
> back to the acpi backlight and all works nicely again.
>
> let me know if I can provide anything else to help debug.

Please try [1].

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrj...@linux.intel.com


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Sun, 11 Sep 2016, James Hogan  wrote:
> I've just bisected a similar (same?) problem (slow increase and
> decrease of screen brightness with a period of a few seconds) to the
> same commit (this is on a Dell XPS 13 laptop)
>
> 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 difference for me is that good commits used the acpi backlight,
> and bad ones used the intel backlight (/sys/class/backlight/). Its
> like intel_backlight is fighting with the firmware to control the
> backlight or something. Reverting the commit on v4.7.3 switches it
> back to the acpi backlight and all works nicely again.
>
> let me know if I can provide anything else to help debug.

Please try [1].

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrj...@linux.intel.com


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Hogan]

On 7 July 2016 at 20:19, James Bottomley
 wrote:
> On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
>> On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
>> > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
>> > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
>> > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
>> > > > > Cc: Ville
>> > > > >
>> > > > > On Mon, 20 Jun 2016, James Bottomley <
>> > > > > james.bottom...@hansenpartnership.com> wrote:
>> > > > > > OK, my candidate bad commit is this one:
>> > > > > >
>> > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> > > > > > Author: Ville Syrjälä 
>> > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
>> > > > > >
>> > > > > > drm/i915: Get panel_type from OpRegion panel details
>> > > > > >
>> > > > > > After being more careful about waiting to identify flicker,
>> > > > > > this one seems to be the one the bisect finds.  I'm now
>> > > > > > running v4.7-rc3 with this one reverted and am currently
>> > > > > > seeing no flicker problems.   It is, however, early days
>> > > > > > because the flicker can hide for long periods, so I 'll
>> > > > > > wait
>> > > > > > until Monday evening and a few reboots before declaring
>> > > > > > victory.
>> > > > >
>> > > > > If that turns out to be the bad commit, it doesn't really
>> > > > > surprise me, and that in itself is depressing.
>> > > >
>> > > > As far as I can tell, after running for a day with this
>> > > > reverted,
>> > > > this is the problem.  The flicker hasn't appeared with it
>> > > > reverted.  It's pretty noticeable with this commit included.
>> > >
>> > > Hmm. The only difference I can see is low vs. normal vswing.
>> > > Panel
>> > > 0 has low, panel 2 has normal. So either the VBT or opregion is
>> > > telling utter lies, or there's some other bug in our low vswing
>> > > support.
>> >
>> > I did a quick once over of out DDI vswing stuff and didn't find
>> > anything too serious. There were some buglets in the iboost
>> > handling,
>> > but I'm not very hopeful that fixing those would help with your
>> > machine.
>> >
>> > Here's a branch anyway in case you want to give it a go:
>> > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
>> >
>> > Actually, I think the only patch in there that might make a
>> > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI
>> > with 4 lanes on SKL")
>>
>> Running with it now (the entire branch).  So far it looks OK, but
>> I'll give it a couple of days to see if anything manifests before
>> declaring victory.
>
> Bad news, I'm afraid: after a couple of hours of run time, there is now
> noticeable flicker on the display, so although the iboost fixes may
> have lessened it, it's still present.
>
> James
>
>

I've just bisected a similar (same?) problem (slow increase and
decrease of screen brightness with a period of a few seconds) to the
same commit (this is on a Dell XPS 13 laptop)

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 difference for me is that good commits used the acpi backlight,
and bad ones used the intel backlight (/sys/class/backlight/). Its
like intel_backlight is fighting with the firmware to control the
backlight or something. Reverting the commit on v4.7.3 switches it
back to the acpi backlight and all works nicely again.

let me know if I can provide anything else to help debug.

Cheers
James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Hogan]

On 7 July 2016 at 20:19, James Bottomley
 wrote:
> On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
>> On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
>> > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
>> > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
>> > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
>> > > > > Cc: Ville
>> > > > >
>> > > > > On Mon, 20 Jun 2016, James Bottomley <
>> > > > > james.bottom...@hansenpartnership.com> wrote:
>> > > > > > OK, my candidate bad commit is this one:
>> > > > > >
>> > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> > > > > > Author: Ville Syrjälä 
>> > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
>> > > > > >
>> > > > > > drm/i915: Get panel_type from OpRegion panel details
>> > > > > >
>> > > > > > After being more careful about waiting to identify flicker,
>> > > > > > this one seems to be the one the bisect finds.  I'm now
>> > > > > > running v4.7-rc3 with this one reverted and am currently
>> > > > > > seeing no flicker problems.   It is, however, early days
>> > > > > > because the flicker can hide for long periods, so I 'll
>> > > > > > wait
>> > > > > > until Monday evening and a few reboots before declaring
>> > > > > > victory.
>> > > > >
>> > > > > If that turns out to be the bad commit, it doesn't really
>> > > > > surprise me, and that in itself is depressing.
>> > > >
>> > > > As far as I can tell, after running for a day with this
>> > > > reverted,
>> > > > this is the problem.  The flicker hasn't appeared with it
>> > > > reverted.  It's pretty noticeable with this commit included.
>> > >
>> > > Hmm. The only difference I can see is low vs. normal vswing.
>> > > Panel
>> > > 0 has low, panel 2 has normal. So either the VBT or opregion is
>> > > telling utter lies, or there's some other bug in our low vswing
>> > > support.
>> >
>> > I did a quick once over of out DDI vswing stuff and didn't find
>> > anything too serious. There were some buglets in the iboost
>> > handling,
>> > but I'm not very hopeful that fixing those would help with your
>> > machine.
>> >
>> > Here's a branch anyway in case you want to give it a go:
>> > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
>> >
>> > Actually, I think the only patch in there that might make a
>> > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI
>> > with 4 lanes on SKL")
>>
>> Running with it now (the entire branch).  So far it looks OK, but
>> I'll give it a couple of days to see if anything manifests before
>> declaring victory.
>
> Bad news, I'm afraid: after a couple of hours of run time, there is now
> noticeable flicker on the display, so although the iboost fixes may
> have lessened it, it's still present.
>
> James
>
>

I've just bisected a similar (same?) problem (slow increase and
decrease of screen brightness with a period of a few seconds) to the
same commit (this is on a Dell XPS 13 laptop)

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 difference for me is that good commits used the acpi backlight,
and bad ones used the intel backlight (/sys/class/backlight/). Its
like intel_backlight is fighting with the firmware to control the
backlight or something. Reverting the commit on v4.7.3 switches it
back to the acpi backlight and all works nicely again.

let me know if I can provide anything else to help debug.

Cheers
James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Daniel Vetter]

On Fri, Jun 24, 2016 at 01:42:06PM +0100, Chris Wilson wrote:
> On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote:
> > On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> > > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > > > On Thu, 23 Jun 2016, Steven Newbury 
> > > > > wrote:
> > > > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > > > here
> > > > > > too, to see if it's the same issue.
> > > > > 
> > > > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > > > it's a
> > > > > different failure mode.
> > > > > 
> > > > It must be something else then.  Actually, in my case linus/master
> > > > is
> > > > okay.  I saw the subject and though it must be the same issue.  I'm
> > > > seeing it with drm-intel nightly/next branches.  Shall I try to
> > > > bisect
> > > > it?  Symptoms are similar, although I would describe it more like
> > > > flashes of a different buffer across parts of the screen.
> > > 
> > > Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> > > -Chris
> > > 
> > 
> > Yes, thanks, that "fixed" it.  So atomic commits not working properly
> > on IVB?
> 
> Not yet it seems. Something seems to be off in the timing, but has so
> far eluded capture.

Fyi we reverted this for now to fix things up:

commit 527b6abe5fd2d24fba69e9564a2d608e1796ca8d
Author: Chris Wilson 
Date:   Fri Jun 24 13:44:03 2016 +0100

Revert "drm/i915: Use atomic commits for legacy page_flips"

Kudos to Chris for handling this in my absence.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Daniel Vetter]

On Fri, Jun 24, 2016 at 01:42:06PM +0100, Chris Wilson wrote:
> On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote:
> > On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> > > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > > > On Thu, 23 Jun 2016, Steven Newbury 
> > > > > wrote:
> > > > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > > > here
> > > > > > too, to see if it's the same issue.
> > > > > 
> > > > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > > > it's a
> > > > > different failure mode.
> > > > > 
> > > > It must be something else then.  Actually, in my case linus/master
> > > > is
> > > > okay.  I saw the subject and though it must be the same issue.  I'm
> > > > seeing it with drm-intel nightly/next branches.  Shall I try to
> > > > bisect
> > > > it?  Symptoms are similar, although I would describe it more like
> > > > flashes of a different buffer across parts of the screen.
> > > 
> > > Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> > > -Chris
> > > 
> > 
> > Yes, thanks, that "fixed" it.  So atomic commits not working properly
> > on IVB?
> 
> Not yet it seems. Something seems to be off in the timing, but has so
> far eluded capture.

Fyi we reverted this for now to fix things up:

commit 527b6abe5fd2d24fba69e9564a2d608e1796ca8d
Author: Chris Wilson 
Date:   Fri Jun 24 13:44:03 2016 +0100

Revert "drm/i915: Use atomic commits for legacy page_flips"

Kudos to Chris for handling this in my absence.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Fri, Jul 08, 2016 at 07:48:29AM -0700, James Bottomley wrote:
> On Fri, 2016-07-08 at 13:19 +0300, Ville Syrjälä wrote:
> > On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote:
> > > On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> > > > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > > > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley
> > > > > > wrote:
> > > > > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > > > > Cc: Ville
> > > > > > > > 
> > > > > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > > > OK, my candidate bad commit is this one:
> > > > > > > > > 
> > > > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > > > > Author: Ville Syrjälä 
> > > > > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > > > > 
> > > > > > > > > drm/i915: Get panel_type from OpRegion panel
> > > > > > > > > details
> > > > > > > > > 
> > > > > > > > > After being more careful about waiting to identify
> > > > > > > > > flicker,
> > > > > > > > > this one seems to be the one the bisect finds.  I'm now
> > > > > > > > > running v4.7-rc3 with this one reverted and am
> > > > > > > > > currently 
> > > > > > > > > seeing no flicker problems.   It is, however, early
> > > > > > > > > days 
> > > > > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > > > > wait 
> > > > > > > > > until Monday evening and a few reboots before declaring
> > > > > > > > > victory.
> > > > > > > > 
> > > > > > > > If that turns out to be the bad commit, it doesn't really
> > > > > > > > surprise me, and that in itself is depressing.
> > > > > > > 
> > > > > > > As far as I can tell, after running for a day with this
> > > > > > > reverted, 
> > > > > > > this is the problem.  The flicker hasn't appeared with it 
> > > > > > > reverted.  It's pretty noticeable with this commit
> > > > > > > included.
> > > > > > 
> > > > > > Hmm. The only difference I can see is low vs. normal vswing.
> > > > > > Panel 
> > > > > > 0 has low, panel 2 has normal. So either the VBT or opregion
> > > > > > is 
> > > > > > telling utter lies, or there's some other bug in our low
> > > > > > vswing
> > > > > > support.
> > > > > 
> > > > > I did a quick once over of out DDI vswing stuff and didn't find
> > > > > anything too serious. There were some buglets in the iboost
> > > > > handling, 
> > > > > but I'm not very hopeful that fixing those would help with your
> > > > > machine. 
> > > > > 
> > > > > Here's a branch anyway in case you want to give it a go:
> > > > > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > > > > 
> > > > > Actually, I think the only patch in there that might make a 
> > > > > difference is 15d887855180 ("drm/i915: Fix iboost setting for
> > > > > DDI 
> > > > > with 4 lanes on SKL")
> > > > 
> > > > Running with it now (the entire branch).  So far it looks OK, but
> > > > I'll give it a couple of days to see if anything manifests before
> > > > declaring victory.
> > > 
> > > Bad news, I'm afraid: after a couple of hours of run time, there is
> > > now
> > > noticeable flicker on the display, so although the iboost fixes may
> > > have lessened it, it's still present.
> > 
> > Oh well, I suspected as much. Which BIOS version did you have 
> > exactly?
> 
> As mentioned upthread, now 1.4.3 since skylake microcode was
> potentially implicated in the problem:
> 
> http://mid.gmane.org/1466179729.2271.33.ca...@hansenpartnership.com
> 
> > If I'm reading the Dell website correctly there's a new one (1.4.4)
> > released on Jun 30, which is after you reported the issue. Might be
> > I'm reading the wrong thing though. Can you double check this?
> 
> New bios doesn't change the microcode:
> 
> [2.390172] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

I was hoping it would have fixed the VBT, but seems that was not the case
if the symptoms didn't change :(

-- 
Ville Syrjälä
Intel OTC
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Fri, Jul 08, 2016 at 07:48:29AM -0700, James Bottomley wrote:
> On Fri, 2016-07-08 at 13:19 +0300, Ville Syrjälä wrote:
> > On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote:
> > > On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> > > > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > > > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley
> > > > > > wrote:
> > > > > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > > > > Cc: Ville
> > > > > > > > 
> > > > > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > > > OK, my candidate bad commit is this one:
> > > > > > > > > 
> > > > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > > > > Author: Ville Syrjälä 
> > > > > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > > > > 
> > > > > > > > > drm/i915: Get panel_type from OpRegion panel
> > > > > > > > > details
> > > > > > > > > 
> > > > > > > > > After being more careful about waiting to identify
> > > > > > > > > flicker,
> > > > > > > > > this one seems to be the one the bisect finds.  I'm now
> > > > > > > > > running v4.7-rc3 with this one reverted and am
> > > > > > > > > currently 
> > > > > > > > > seeing no flicker problems.   It is, however, early
> > > > > > > > > days 
> > > > > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > > > > wait 
> > > > > > > > > until Monday evening and a few reboots before declaring
> > > > > > > > > victory.
> > > > > > > > 
> > > > > > > > If that turns out to be the bad commit, it doesn't really
> > > > > > > > surprise me, and that in itself is depressing.
> > > > > > > 
> > > > > > > As far as I can tell, after running for a day with this
> > > > > > > reverted, 
> > > > > > > this is the problem.  The flicker hasn't appeared with it 
> > > > > > > reverted.  It's pretty noticeable with this commit
> > > > > > > included.
> > > > > > 
> > > > > > Hmm. The only difference I can see is low vs. normal vswing.
> > > > > > Panel 
> > > > > > 0 has low, panel 2 has normal. So either the VBT or opregion
> > > > > > is 
> > > > > > telling utter lies, or there's some other bug in our low
> > > > > > vswing
> > > > > > support.
> > > > > 
> > > > > I did a quick once over of out DDI vswing stuff and didn't find
> > > > > anything too serious. There were some buglets in the iboost
> > > > > handling, 
> > > > > but I'm not very hopeful that fixing those would help with your
> > > > > machine. 
> > > > > 
> > > > > Here's a branch anyway in case you want to give it a go:
> > > > > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > > > > 
> > > > > Actually, I think the only patch in there that might make a 
> > > > > difference is 15d887855180 ("drm/i915: Fix iboost setting for
> > > > > DDI 
> > > > > with 4 lanes on SKL")
> > > > 
> > > > Running with it now (the entire branch).  So far it looks OK, but
> > > > I'll give it a couple of days to see if anything manifests before
> > > > declaring victory.
> > > 
> > > Bad news, I'm afraid: after a couple of hours of run time, there is
> > > now
> > > noticeable flicker on the display, so although the iboost fixes may
> > > have lessened it, it's still present.
> > 
> > Oh well, I suspected as much. Which BIOS version did you have 
> > exactly?
> 
> As mentioned upthread, now 1.4.3 since skylake microcode was
> potentially implicated in the problem:
> 
> http://mid.gmane.org/1466179729.2271.33.ca...@hansenpartnership.com
> 
> > If I'm reading the Dell website correctly there's a new one (1.4.4)
> > released on Jun 30, which is after you reported the issue. Might be
> > I'm reading the wrong thing though. Can you double check this?
> 
> New bios doesn't change the microcode:
> 
> [2.390172] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

I was hoping it would have fixed the VBT, but seems that was not the case
if the symptoms didn't change :(

-- 
Ville Syrjälä
Intel OTC
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-07-08 at 13:19 +0300, Ville Syrjälä wrote:
> On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote:
> > On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> > > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley
> > > > > wrote:
> > > > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > > > Cc: Ville
> > > > > > > 
> > > > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > > OK, my candidate bad commit is this one:
> > > > > > > > 
> > > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > > > Author: Ville Syrjälä 
> > > > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > > > 
> > > > > > > > drm/i915: Get panel_type from OpRegion panel
> > > > > > > > details
> > > > > > > > 
> > > > > > > > After being more careful about waiting to identify
> > > > > > > > flicker,
> > > > > > > > this one seems to be the one the bisect finds.  I'm now
> > > > > > > > running v4.7-rc3 with this one reverted and am
> > > > > > > > currently 
> > > > > > > > seeing no flicker problems.   It is, however, early
> > > > > > > > days 
> > > > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > > > wait 
> > > > > > > > until Monday evening and a few reboots before declaring
> > > > > > > > victory.
> > > > > > > 
> > > > > > > If that turns out to be the bad commit, it doesn't really
> > > > > > > surprise me, and that in itself is depressing.
> > > > > > 
> > > > > > As far as I can tell, after running for a day with this
> > > > > > reverted, 
> > > > > > this is the problem.  The flicker hasn't appeared with it 
> > > > > > reverted.  It's pretty noticeable with this commit
> > > > > > included.
> > > > > 
> > > > > Hmm. The only difference I can see is low vs. normal vswing.
> > > > > Panel 
> > > > > 0 has low, panel 2 has normal. So either the VBT or opregion
> > > > > is 
> > > > > telling utter lies, or there's some other bug in our low
> > > > > vswing
> > > > > support.
> > > > 
> > > > I did a quick once over of out DDI vswing stuff and didn't find
> > > > anything too serious. There were some buglets in the iboost
> > > > handling, 
> > > > but I'm not very hopeful that fixing those would help with your
> > > > machine. 
> > > > 
> > > > Here's a branch anyway in case you want to give it a go:
> > > > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > > > 
> > > > Actually, I think the only patch in there that might make a 
> > > > difference is 15d887855180 ("drm/i915: Fix iboost setting for
> > > > DDI 
> > > > with 4 lanes on SKL")
> > > 
> > > Running with it now (the entire branch).  So far it looks OK, but
> > > I'll give it a couple of days to see if anything manifests before
> > > declaring victory.
> > 
> > Bad news, I'm afraid: after a couple of hours of run time, there is
> > now
> > noticeable flicker on the display, so although the iboost fixes may
> > have lessened it, it's still present.
> 
> Oh well, I suspected as much. Which BIOS version did you have 
> exactly?

As mentioned upthread, now 1.4.3 since skylake microcode was
potentially implicated in the problem:

http://mid.gmane.org/1466179729.2271.33.ca...@hansenpartnership.com

> If I'm reading the Dell website correctly there's a new one (1.4.4)
> released on Jun 30, which is after you reported the issue. Might be
> I'm reading the wrong thing though. Can you double check this?

New bios doesn't change the microcode:

[2.390172] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

And the flicker is still present.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-07-08 at 13:19 +0300, Ville Syrjälä wrote:
> On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote:
> > On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> > > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley
> > > > > wrote:
> > > > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > > > Cc: Ville
> > > > > > > 
> > > > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > > OK, my candidate bad commit is this one:
> > > > > > > > 
> > > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > > > Author: Ville Syrjälä 
> > > > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > > > 
> > > > > > > > drm/i915: Get panel_type from OpRegion panel
> > > > > > > > details
> > > > > > > > 
> > > > > > > > After being more careful about waiting to identify
> > > > > > > > flicker,
> > > > > > > > this one seems to be the one the bisect finds.  I'm now
> > > > > > > > running v4.7-rc3 with this one reverted and am
> > > > > > > > currently 
> > > > > > > > seeing no flicker problems.   It is, however, early
> > > > > > > > days 
> > > > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > > > wait 
> > > > > > > > until Monday evening and a few reboots before declaring
> > > > > > > > victory.
> > > > > > > 
> > > > > > > If that turns out to be the bad commit, it doesn't really
> > > > > > > surprise me, and that in itself is depressing.
> > > > > > 
> > > > > > As far as I can tell, after running for a day with this
> > > > > > reverted, 
> > > > > > this is the problem.  The flicker hasn't appeared with it 
> > > > > > reverted.  It's pretty noticeable with this commit
> > > > > > included.
> > > > > 
> > > > > Hmm. The only difference I can see is low vs. normal vswing.
> > > > > Panel 
> > > > > 0 has low, panel 2 has normal. So either the VBT or opregion
> > > > > is 
> > > > > telling utter lies, or there's some other bug in our low
> > > > > vswing
> > > > > support.
> > > > 
> > > > I did a quick once over of out DDI vswing stuff and didn't find
> > > > anything too serious. There were some buglets in the iboost
> > > > handling, 
> > > > but I'm not very hopeful that fixing those would help with your
> > > > machine. 
> > > > 
> > > > Here's a branch anyway in case you want to give it a go:
> > > > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > > > 
> > > > Actually, I think the only patch in there that might make a 
> > > > difference is 15d887855180 ("drm/i915: Fix iboost setting for
> > > > DDI 
> > > > with 4 lanes on SKL")
> > > 
> > > Running with it now (the entire branch).  So far it looks OK, but
> > > I'll give it a couple of days to see if anything manifests before
> > > declaring victory.
> > 
> > Bad news, I'm afraid: after a couple of hours of run time, there is
> > now
> > noticeable flicker on the display, so although the iboost fixes may
> > have lessened it, it's still present.
> 
> Oh well, I suspected as much. Which BIOS version did you have 
> exactly?

As mentioned upthread, now 1.4.3 since skylake microcode was
potentially implicated in the problem:

http://mid.gmane.org/1466179729.2271.33.ca...@hansenpartnership.com

> If I'm reading the Dell website correctly there's a new one (1.4.4)
> released on Jun 30, which is after you reported the issue. Might be
> I'm reading the wrong thing though. Can you double check this?

New bios doesn't change the microcode:

[2.390172] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

And the flicker is still present.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote:
> On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > > Cc: Ville
> > > > > > 
> > > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > OK, my candidate bad commit is this one:
> > > > > > > 
> > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > > Author: Ville Syrjälä 
> > > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > > 
> > > > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > > > 
> > > > > > > After being more careful about waiting to identify flicker,
> > > > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > > > seeing no flicker problems.   It is, however, early days 
> > > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > > wait 
> > > > > > > until Monday evening and a few reboots before declaring
> > > > > > > victory.
> > > > > > 
> > > > > > If that turns out to be the bad commit, it doesn't really 
> > > > > > surprise me, and that in itself is depressing.
> > > > > 
> > > > > As far as I can tell, after running for a day with this
> > > > > reverted, 
> > > > > this is the problem.  The flicker hasn't appeared with it 
> > > > > reverted.  It's pretty noticeable with this commit included.
> > > > 
> > > > Hmm. The only difference I can see is low vs. normal vswing.
> > > > Panel 
> > > > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > > > telling utter lies, or there's some other bug in our low vswing
> > > > support.
> > > 
> > > I did a quick once over of out DDI vswing stuff and didn't find 
> > > anything too serious. There were some buglets in the iboost
> > > handling, 
> > > but I'm not very hopeful that fixing those would help with your 
> > > machine. 
> > > 
> > > Here's a branch anyway in case you want to give it a go:
> > > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > > 
> > > Actually, I think the only patch in there that might make a 
> > > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> > > with 4 lanes on SKL")
> > 
> > Running with it now (the entire branch).  So far it looks OK, but 
> > I'll give it a couple of days to see if anything manifests before
> > declaring victory.
> 
> Bad news, I'm afraid: after a couple of hours of run time, there is now
> noticeable flicker on the display, so although the iboost fixes may
> have lessened it, it's still present.

Oh well, I suspected as much. Which BIOS version did you have exactly?
If I'm reading the Dell website correctly there's a new one (1.4.4)
released on Jun 30, which is after you reported the issue. Might be
I'm reading the wrong thing though. Can you double check this?

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Thu, Jul 07, 2016 at 12:19:36PM -0700, James Bottomley wrote:
> On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> > On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > > Cc: Ville
> > > > > > 
> > > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > OK, my candidate bad commit is this one:
> > > > > > > 
> > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > > Author: Ville Syrjälä 
> > > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > > 
> > > > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > > > 
> > > > > > > After being more careful about waiting to identify flicker,
> > > > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > > > seeing no flicker problems.   It is, however, early days 
> > > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > > wait 
> > > > > > > until Monday evening and a few reboots before declaring
> > > > > > > victory.
> > > > > > 
> > > > > > If that turns out to be the bad commit, it doesn't really 
> > > > > > surprise me, and that in itself is depressing.
> > > > > 
> > > > > As far as I can tell, after running for a day with this
> > > > > reverted, 
> > > > > this is the problem.  The flicker hasn't appeared with it 
> > > > > reverted.  It's pretty noticeable with this commit included.
> > > > 
> > > > Hmm. The only difference I can see is low vs. normal vswing.
> > > > Panel 
> > > > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > > > telling utter lies, or there's some other bug in our low vswing
> > > > support.
> > > 
> > > I did a quick once over of out DDI vswing stuff and didn't find 
> > > anything too serious. There were some buglets in the iboost
> > > handling, 
> > > but I'm not very hopeful that fixing those would help with your 
> > > machine. 
> > > 
> > > Here's a branch anyway in case you want to give it a go:
> > > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > > 
> > > Actually, I think the only patch in there that might make a 
> > > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> > > with 4 lanes on SKL")
> > 
> > Running with it now (the entire branch).  So far it looks OK, but 
> > I'll give it a couple of days to see if anything manifests before
> > declaring victory.
> 
> Bad news, I'm afraid: after a couple of hours of run time, there is now
> noticeable flicker on the display, so although the iboost fixes may
> have lessened it, it's still present.

Oh well, I suspected as much. Which BIOS version did you have exactly?
If I'm reading the Dell website correctly there's a new one (1.4.4)
released on Jun 30, which is after you reported the issue. Might be
I'm reading the wrong thing though. Can you double check this?

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > Cc: Ville
> > > > > 
> > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > OK, my candidate bad commit is this one:
> > > > > > 
> > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > Author: Ville Syrjälä 
> > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > 
> > > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > > 
> > > > > > After being more careful about waiting to identify flicker,
> > > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > > seeing no flicker problems.   It is, however, early days 
> > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > wait 
> > > > > > until Monday evening and a few reboots before declaring
> > > > > > victory.
> > > > > 
> > > > > If that turns out to be the bad commit, it doesn't really 
> > > > > surprise me, and that in itself is depressing.
> > > > 
> > > > As far as I can tell, after running for a day with this
> > > > reverted, 
> > > > this is the problem.  The flicker hasn't appeared with it 
> > > > reverted.  It's pretty noticeable with this commit included.
> > > 
> > > Hmm. The only difference I can see is low vs. normal vswing.
> > > Panel 
> > > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > > telling utter lies, or there's some other bug in our low vswing
> > > support.
> > 
> > I did a quick once over of out DDI vswing stuff and didn't find 
> > anything too serious. There were some buglets in the iboost
> > handling, 
> > but I'm not very hopeful that fixing those would help with your 
> > machine. 
> > 
> > Here's a branch anyway in case you want to give it a go:
> > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > 
> > Actually, I think the only patch in there that might make a 
> > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> > with 4 lanes on SKL")
> 
> Running with it now (the entire branch).  So far it looks OK, but 
> I'll give it a couple of days to see if anything manifests before
> declaring victory.

Bad news, I'm afraid: after a couple of hours of run time, there is now
noticeable flicker on the display, so although the iboost fixes may
have lessened it, it's still present.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-07-07 at 09:55 -0700, James Bottomley wrote:
> On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > > Cc: Ville
> > > > > 
> > > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > OK, my candidate bad commit is this one:
> > > > > > 
> > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > > Author: Ville Syrjälä 
> > > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > > 
> > > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > > 
> > > > > > After being more careful about waiting to identify flicker,
> > > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > > seeing no flicker problems.   It is, however, early days 
> > > > > > because the flicker can hide for long periods, so I 'll
> > > > > > wait 
> > > > > > until Monday evening and a few reboots before declaring
> > > > > > victory.
> > > > > 
> > > > > If that turns out to be the bad commit, it doesn't really 
> > > > > surprise me, and that in itself is depressing.
> > > > 
> > > > As far as I can tell, after running for a day with this
> > > > reverted, 
> > > > this is the problem.  The flicker hasn't appeared with it 
> > > > reverted.  It's pretty noticeable with this commit included.
> > > 
> > > Hmm. The only difference I can see is low vs. normal vswing.
> > > Panel 
> > > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > > telling utter lies, or there's some other bug in our low vswing
> > > support.
> > 
> > I did a quick once over of out DDI vswing stuff and didn't find 
> > anything too serious. There were some buglets in the iboost
> > handling, 
> > but I'm not very hopeful that fixing those would help with your 
> > machine. 
> > 
> > Here's a branch anyway in case you want to give it a go:
> > git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> > 
> > Actually, I think the only patch in there that might make a 
> > difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> > with 4 lanes on SKL")
> 
> Running with it now (the entire branch).  So far it looks OK, but 
> I'll give it a couple of days to see if anything manifests before
> declaring victory.

Bad news, I'm afraid: after a couple of hours of run time, there is now
noticeable flicker on the display, so although the iboost fixes may
have lessened it, it's still present.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > Cc: Ville
> > > > 
> > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > OK, my candidate bad commit is this one:
> > > > > 
> > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > Author: Ville Syrjälä 
> > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > 
> > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > 
> > > > > After being more careful about waiting to identify flicker, 
> > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > seeing no flicker problems.   It is, however, early days 
> > > > > because the flicker can hide for long periods, so I 'll wait 
> > > > > until Monday evening and a few reboots before declaring
> > > > > victory.
> > > > 
> > > > If that turns out to be the bad commit, it doesn't really 
> > > > surprise me, and that in itself is depressing.
> > > 
> > > As far as I can tell, after running for a day with this reverted, 
> > > this is the problem.  The flicker hasn't appeared with it 
> > > reverted.  It's pretty noticeable with this commit included.
> > 
> > Hmm. The only difference I can see is low vs. normal vswing. Panel 
> > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > telling utter lies, or there's some other bug in our low vswing
> > support.
> 
> I did a quick once over of out DDI vswing stuff and didn't find 
> anything too serious. There were some buglets in the iboost handling, 
> but I'm not very hopeful that fixing those would help with your 
> machine. 
> 
> Here's a branch anyway in case you want to give it a go:
> git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> 
> Actually, I think the only patch in there that might make a 
> difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> with 4 lanes on SKL")

Running with it now (the entire branch).  So far it looks OK, but I'll
give it a couple of days to see if anything manifests before declaring
victory.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-07-07 at 19:14 +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > Cc: Ville
> > > > 
> > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > OK, my candidate bad commit is this one:
> > > > > 
> > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > Author: Ville Syrjälä 
> > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > 
> > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > 
> > > > > After being more careful about waiting to identify flicker, 
> > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > seeing no flicker problems.   It is, however, early days 
> > > > > because the flicker can hide for long periods, so I 'll wait 
> > > > > until Monday evening and a few reboots before declaring
> > > > > victory.
> > > > 
> > > > If that turns out to be the bad commit, it doesn't really 
> > > > surprise me, and that in itself is depressing.
> > > 
> > > As far as I can tell, after running for a day with this reverted, 
> > > this is the problem.  The flicker hasn't appeared with it 
> > > reverted.  It's pretty noticeable with this commit included.
> > 
> > Hmm. The only difference I can see is low vs. normal vswing. Panel 
> > 0 has low, panel 2 has normal. So either the VBT or opregion is 
> > telling utter lies, or there's some other bug in our low vswing
> > support.
> 
> I did a quick once over of out DDI vswing stuff and didn't find 
> anything too serious. There were some buglets in the iboost handling, 
> but I'm not very hopeful that fixing those would help with your 
> machine. 
> 
> Here's a branch anyway in case you want to give it a go:
> git://github.com/vsyrjala/linux.git ddi_iboost_fixes
> 
> Actually, I think the only patch in there that might make a 
> difference is 15d887855180 ("drm/i915: Fix iboost setting for DDI 
> with 4 lanes on SKL")

Running with it now (the entire branch).  So far it looks OK, but I'll
give it a couple of days to see if anything manifests before declaring
victory.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > Cc: Ville
> > > 
> > > On Mon, 20 Jun 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > OK, my candidate bad commit is this one:
> > > > 
> > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > Author: Ville Syrjälä 
> > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > 
> > > > drm/i915: Get panel_type from OpRegion panel details
> > > > 
> > > > After being more careful about waiting to identify flicker, this 
> > > > one seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > > with this one reverted and am currently seeing no flicker problems.
> > > >   It is, however, early days because the flicker can hide for long 
> > > > periods, so I 'll wait until Monday evening and a few reboots 
> > > > before declaring victory.
> > > 
> > > If that turns out to be the bad commit, it doesn't really surprise 
> > > me, and that in itself is depressing.
> > 
> > As far as I can tell, after running for a day with this reverted, this
> > is the problem.  The flicker hasn't appeared with it reverted.  It's
> > pretty noticeable with this commit included.
> 
> Hmm. The only difference I can see is low vs. normal vswing. Panel 0 has
> low, panel 2 has normal. So either the VBT or opregion is telling utter
> lies, or there's some other bug in our low vswing support.

I did a quick once over of out DDI vswing stuff and didn't find anything
too serious. There were some buglets in the iboost handling, but I'm not
very hopeful that fixing those would help with your machine.

Here's a branch anyway in case you want to give it a go:
git://github.com/vsyrjala/linux.git ddi_iboost_fixes

Actually, I think the only patch in there that might make a difference is
15d887855180 ("drm/i915: Fix iboost setting for DDI with 4 lanes on SKL")

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Tue, Jun 21, 2016 at 06:44:34PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > Cc: Ville
> > > 
> > > On Mon, 20 Jun 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > OK, my candidate bad commit is this one:
> > > > 
> > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > Author: Ville Syrjälä 
> > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > 
> > > > drm/i915: Get panel_type from OpRegion panel details
> > > > 
> > > > After being more careful about waiting to identify flicker, this 
> > > > one seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > > with this one reverted and am currently seeing no flicker problems.
> > > >   It is, however, early days because the flicker can hide for long 
> > > > periods, so I 'll wait until Monday evening and a few reboots 
> > > > before declaring victory.
> > > 
> > > If that turns out to be the bad commit, it doesn't really surprise 
> > > me, and that in itself is depressing.
> > 
> > As far as I can tell, after running for a day with this reverted, this
> > is the problem.  The flicker hasn't appeared with it reverted.  It's
> > pretty noticeable with this commit included.
> 
> Hmm. The only difference I can see is low vs. normal vswing. Panel 0 has
> low, panel 2 has normal. So either the VBT or opregion is telling utter
> lies, or there's some other bug in our low vswing support.

I did a quick once over of out DDI vswing stuff and didn't find anything
too serious. There were some buglets in the iboost handling, but I'm not
very hopeful that fixing those would help with your machine.

Here's a branch anyway in case you want to give it a go:
git://github.com/vsyrjala/linux.git ddi_iboost_fixes

Actually, I think the only patch in there that might make a difference is
15d887855180 ("drm/i915: Fix iboost setting for DDI with 4 lanes on SKL")

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Thorsten Leemhuis]

On 23.06.2016 13:25, James Bottomley wrote:
> On Tue, 2016-06-21 at 17:00 -0400, James Bottomley wrote:
>> On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
>>> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
 On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> Cc: Ville
>
> On Mon, 20 Jun 2016, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
>> OK, my candidate bad commit is this one:
>>
>> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> Author: Ville Syrjälä 
>> Date:   Mon Apr 11 10:23:51 2016 +0300
>>
>> drm/i915: Get panel_type from OpRegion panel details
>>
>> After being more careful about waiting to identify flicker, 
>> this one seems to be the one the bisect finds.  I'm now 
>> running v4.7-rc3 with this one reverted and am currently 
>> seeing no flicker problems.   It is, however, early days 
>> because the flicker can hide for long periods, so I 'll wait 
>> until Monday evening and a few reboots before declaring
>> victory.
>
> If that turns out to be the bad commit, it doesn't really 
> surprise me, and that in itself is depressing.

 As far as I can tell, after running for a day with this reverted,
 this is the problem.  The flicker hasn't appeared with it 
 reverted.  It's pretty noticeable with this commit included.
>>>
>>> Hmm. The only difference I can see is low vs. normal vswing. Panel 
>>> 0 has low, panel 2 has normal. So either the VBT or opregion is
>>> telling utter lies, or there's some other bug in our low vswing
>>> support.
>>>
>>> To confirm it's really a vswing issue, you should be able to run 
>>> with i915.edp_vswing=2 without flickers on the broken kernel.
>>
>> Preliminary boot indicates no flicker with the bad commit included 
>> and this option, but I'll have to run for quite a bit longer to 
>> verify, since it can sometimes be elusive.
> 
> Two days of runtime seems to confirm this is the problem (still no
> flicker issues).

This issue is listed in my regression reports for 4.7 and I wonder what
the status is. It seems nothing happened for more then a week now, which
is a bad sign as 4.7 final seems only a week or two away.

CU, Thorsten

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Thorsten Leemhuis]

On 23.06.2016 13:25, James Bottomley wrote:
> On Tue, 2016-06-21 at 17:00 -0400, James Bottomley wrote:
>> On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
>>> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
 On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> Cc: Ville
>
> On Mon, 20 Jun 2016, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
>> OK, my candidate bad commit is this one:
>>
>> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> Author: Ville Syrjälä 
>> Date:   Mon Apr 11 10:23:51 2016 +0300
>>
>> drm/i915: Get panel_type from OpRegion panel details
>>
>> After being more careful about waiting to identify flicker, 
>> this one seems to be the one the bisect finds.  I'm now 
>> running v4.7-rc3 with this one reverted and am currently 
>> seeing no flicker problems.   It is, however, early days 
>> because the flicker can hide for long periods, so I 'll wait 
>> until Monday evening and a few reboots before declaring
>> victory.
>
> If that turns out to be the bad commit, it doesn't really 
> surprise me, and that in itself is depressing.

 As far as I can tell, after running for a day with this reverted,
 this is the problem.  The flicker hasn't appeared with it 
 reverted.  It's pretty noticeable with this commit included.
>>>
>>> Hmm. The only difference I can see is low vs. normal vswing. Panel 
>>> 0 has low, panel 2 has normal. So either the VBT or opregion is
>>> telling utter lies, or there's some other bug in our low vswing
>>> support.
>>>
>>> To confirm it's really a vswing issue, you should be able to run 
>>> with i915.edp_vswing=2 without flickers on the broken kernel.
>>
>> Preliminary boot indicates no flicker with the bad commit included 
>> and this option, but I'll have to run for quite a bit longer to 
>> verify, since it can sometimes be elusive.
> 
> Two days of runtime seems to confirm this is the problem (still no
> flicker issues).

This issue is listed in my regression reports for 4.7 and I wonder what
the status is. It seems nothing happened for more then a week now, which
is a bad sign as 4.7 final seems only a week or two away.

CU, Thorsten

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Chris Wilson]

On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote:
> On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > > On Thu, 23 Jun 2016, Steven Newbury 
> > > > wrote:
> > > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > > here
> > > > > too, to see if it's the same issue.
> > > > 
> > > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > > it's a
> > > > different failure mode.
> > > > 
> > > It must be something else then.  Actually, in my case linus/master
> > > is
> > > okay.  I saw the subject and though it must be the same issue.  I'm
> > > seeing it with drm-intel nightly/next branches.  Shall I try to
> > > bisect
> > > it?  Symptoms are similar, although I would describe it more like
> > > flashes of a different buffer across parts of the screen.
> > 
> > Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> > -Chris
> > 
> 
> Yes, thanks, that "fixed" it.  So atomic commits not working properly
> on IVB?

Not yet it seems. Something seems to be off in the timing, but has so
far eluded capture.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Chris Wilson]

On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote:
> On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > > On Thu, 23 Jun 2016, Steven Newbury 
> > > > wrote:
> > > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > > here
> > > > > too, to see if it's the same issue.
> > > > 
> > > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > > it's a
> > > > different failure mode.
> > > > 
> > > It must be something else then.  Actually, in my case linus/master
> > > is
> > > okay.  I saw the subject and though it must be the same issue.  I'm
> > > seeing it with drm-intel nightly/next branches.  Shall I try to
> > > bisect
> > > it?  Symptoms are similar, although I would describe it more like
> > > flashes of a different buffer across parts of the screen.
> > 
> > Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> > -Chris
> > 
> 
> Yes, thanks, that "fixed" it.  So atomic commits not working properly
> on IVB?

Not yet it seems. Something seems to be off in the timing, but has so
far eluded capture.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > On Thu, 23 Jun 2016, Steven Newbury 
> > > wrote:
> > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > here
> > > > too, to see if it's the same issue.
> > > 
> > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > it's a
> > > different failure mode.
> > > 
> > It must be something else then.  Actually, in my case linus/master
> > is
> > okay.  I saw the subject and though it must be the same issue.  I'm
> > seeing it with drm-intel nightly/next branches.  Shall I try to
> > bisect
> > it?  Symptoms are similar, although I would describe it more like
> > flashes of a different buffer across parts of the screen.
> 
> Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> -Chris
> 

Yes, thanks, that "fixed" it.  So atomic commits not working properly
on IVB?


signature.asc
Description: This is a digitally signed message part

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > On Thu, 23 Jun 2016, Steven Newbury 
> > > wrote:
> > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > > here
> > > > too, to see if it's the same issue.
> > > 
> > > IvyBridge doesn't have low vswing for eDP. If reverting helps,
> > > it's a
> > > different failure mode.
> > > 
> > It must be something else then.  Actually, in my case linus/master
> > is
> > okay.  I saw the subject and though it must be the same issue.  I'm
> > seeing it with drm-intel nightly/next branches.  Shall I try to
> > bisect
> > it?  Symptoms are similar, although I would describe it more like
> > flashes of a different buffer across parts of the screen.
> 
> Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
> -Chris
> 

Yes, thanks, that "fixed" it.  So atomic commits not working properly
on IVB?


signature.asc
Description: This is a digitally signed message part

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Chris Wilson]

On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > On Thu, 23 Jun 2016, Steven Newbury  wrote:
> > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > here
> > > too, to see if it's the same issue.
> > 
> > IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
> > different failure mode.
> > 
> It must be something else then.  Actually, in my case linus/master is
> okay.  I saw the subject and though it must be the same issue.  I'm
> seeing it with drm-intel nightly/next branches.  Shall I try to bisect
> it?  Symptoms are similar, although I would describe it more like
> flashes of a different buffer across parts of the screen.

Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Chris Wilson]

On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > On Thu, 23 Jun 2016, Steven Newbury  wrote:
> > > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > > here
> > > too, to see if it's the same issue.
> > 
> > IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
> > different failure mode.
> > 
> It must be something else then.  Actually, in my case linus/master is
> okay.  I saw the subject and though it must be the same issue.  I'm
> seeing it with drm-intel nightly/next branches.  Shall I try to bisect
> it?  Symptoms are similar, although I would describe it more like
> flashes of a different buffer across parts of the screen.

Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> On Thu, 23 Jun 2016, Steven Newbury  wrote:
> > [ Unknown signature status ]
> > On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
> > > On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> > > > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > > > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
> > > > > > wrote:
> > > > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > > > > I guess we'll need the bisect on this one to make
> > > > > > > > > progress.
> > > > > > > > 
> > > > > > > > Sigh, I was afraid that might be the next step.
> > > > > > > 
> > > > > > > OK, I have a curious data point.  I assumed the problem
> > > > > > > would
> > > > > > > be
> > > > > > > somewhere in the drm update, so I started bisecting that
> > > > > > > at
> > > > > > > the
> > > > > > > top. 
> > > > > > >  However, the top most commit:
> > > > > > > 
> > > > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > > > > Merge: 1f40c49 a39ed68
> > > > > > > Author: Linus Torvalds 
> > > > > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > > > > 
> > > > > > > Merge branch 'drm-next' of
> > > > > > > git://people.freedesktop.org/~airlied/linux
> > > > > > > 
> > > > > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > > > > caused
> > > > > > > the
> > > > > > > problem came from some update after this.
> > > > > > 
> > > > > > There was a fixes pull after this. Might be worth it to
> > > > > > restrict
> > > > > > to
> > > > > > just
> > > > > > the i915 changes, which are just
> > > > > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > > > > 
> > > > > > Looking at those nothing seems to stick out which might
> > > > > > explain
> > > > > > what's
> > > > > > happening for you.
> > > > 
> > > > OK, so just on the firmware, the system seems less flickery
> > > > with
> > > > the
> > > > new 1.4.3 UEFI, so I'm starting to think it is a Skylake
> > > > errata 
> > > > issue.  The flicker isn't gone for good, but seems to be
> > > > reboot 
> > > > dependent (it's there in some boots, but gone on a reboot).
> > > > 
> > > > > This should be easy enough to try before bisecting:
> > > > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042
> > > > > -1-g
> > > > > it
> > > > > -s
> > > > > end-email-mika.kah...@intel.com
> > > > 
> > > > Applying this didn't seem to make a difference: still there on
> > > > some 
> > > > and gone on other reboots.
> > > 
> > > OK, my candidate bad commit is this one:
> > > 
> > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > Author: Ville Syrjälä 
> > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > 
> > > drm/i915: Get panel_type from OpRegion panel details
> > > 
> > > After being more careful about waiting to identify flicker, this
> > > one
> > > seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with
> > > this one reverted and am currently seeing no flicker
> > > problems.  It
> > > is,
> > > however, early days because the flicker can hide for long
> > > periods, so
> > > I
> > > 'll wait until Monday evening and a few reboots before declaring
> > > victory.
> > > 
> > >  
> > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > here
> > too, to see if it's the same issue.
> 
> IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
> different failure mode.
> 
It must be something else then.  Actually, in my case linus/master is
okay.  I saw the subject and though it must be the same issue.  I'm
seeing it with drm-intel nightly/next branches.  Shall I try to bisect
it?  Symptoms are similar, although I would describe it more like
flashes of a different buffer across parts of the screen.




signature.asc
Description: This is a digitally signed message part

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> On Thu, 23 Jun 2016, Steven Newbury  wrote:
> > [ Unknown signature status ]
> > On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
> > > On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> > > > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > > > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
> > > > > > wrote:
> > > > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > > > > I guess we'll need the bisect on this one to make
> > > > > > > > > progress.
> > > > > > > > 
> > > > > > > > Sigh, I was afraid that might be the next step.
> > > > > > > 
> > > > > > > OK, I have a curious data point.  I assumed the problem
> > > > > > > would
> > > > > > > be
> > > > > > > somewhere in the drm update, so I started bisecting that
> > > > > > > at
> > > > > > > the
> > > > > > > top. 
> > > > > > >  However, the top most commit:
> > > > > > > 
> > > > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > > > > Merge: 1f40c49 a39ed68
> > > > > > > Author: Linus Torvalds 
> > > > > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > > > > 
> > > > > > > Merge branch 'drm-next' of
> > > > > > > git://people.freedesktop.org/~airlied/linux
> > > > > > > 
> > > > > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > > > > caused
> > > > > > > the
> > > > > > > problem came from some update after this.
> > > > > > 
> > > > > > There was a fixes pull after this. Might be worth it to
> > > > > > restrict
> > > > > > to
> > > > > > just
> > > > > > the i915 changes, which are just
> > > > > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > > > > 
> > > > > > Looking at those nothing seems to stick out which might
> > > > > > explain
> > > > > > what's
> > > > > > happening for you.
> > > > 
> > > > OK, so just on the firmware, the system seems less flickery
> > > > with
> > > > the
> > > > new 1.4.3 UEFI, so I'm starting to think it is a Skylake
> > > > errata 
> > > > issue.  The flicker isn't gone for good, but seems to be
> > > > reboot 
> > > > dependent (it's there in some boots, but gone on a reboot).
> > > > 
> > > > > This should be easy enough to try before bisecting:
> > > > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042
> > > > > -1-g
> > > > > it
> > > > > -s
> > > > > end-email-mika.kah...@intel.com
> > > > 
> > > > Applying this didn't seem to make a difference: still there on
> > > > some 
> > > > and gone on other reboots.
> > > 
> > > OK, my candidate bad commit is this one:
> > > 
> > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > Author: Ville Syrjälä 
> > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > 
> > > drm/i915: Get panel_type from OpRegion panel details
> > > 
> > > After being more careful about waiting to identify flicker, this
> > > one
> > > seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with
> > > this one reverted and am currently seeing no flicker
> > > problems.  It
> > > is,
> > > however, early days because the flicker can hide for long
> > > periods, so
> > > I
> > > 'll wait until Monday evening and a few reboots before declaring
> > > victory.
> > > 
> > >  
> > I'm seeing this on my IvyBridge.  I'll try reverting the commit
> > here
> > too, to see if it's the same issue.
> 
> IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
> different failure mode.
> 
It must be something else then.  Actually, in my case linus/master is
okay.  I saw the subject and though it must be the same issue.  I'm
seeing it with drm-intel nightly/next branches.  Shall I try to bisect
it?  Symptoms are similar, although I would describe it more like
flashes of a different buffer across parts of the screen.




signature.asc
Description: This is a digitally signed message part

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Thu, 23 Jun 2016, Steven Newbury  wrote:
> [ Unknown signature status ]
> On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
>> > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
>> > > > wrote:
>> > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > > > > > I guess we'll need the bisect on this one to make
>> > > > > > > progress.
>> > > > > > 
>> > > > > > Sigh, I was afraid that might be the next step.
>> > > > > 
>> > > > > OK, I have a curious data point.  I assumed the problem would
>> > > > > be
>> > > > > somewhere in the drm update, so I started bisecting that at
>> > > > > the
>> > > > > top. 
>> > > > >  However, the top most commit:
>> > > > > 
>> > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> > > > > Merge: 1f40c49 a39ed68
>> > > > > Author: Linus Torvalds 
>> > > > > Date:   Mon May 23 11:48:48 2016 -0700
>> > > > > 
>> > > > > Merge branch 'drm-next' of
>> > > > > git://people.freedesktop.org/~airlied/linux
>> > > > > 
>> > > > > Isn't actually bad.  There's no flicker here, so whatever
>> > > > > caused
>> > > > > the
>> > > > > problem came from some update after this.
>> > > > 
>> > > > There was a fixes pull after this. Might be worth it to
>> > > > restrict
>> > > > to
>> > > > just
>> > > > the i915 changes, which are just
>> > > > 5b4fd5bb1230cd037..157d2c7fad0863222
>> > > > 
>> > > > Looking at those nothing seems to stick out which might explain
>> > > > what's
>> > > > happening for you.
>> > 
>> > OK, so just on the firmware, the system seems less flickery with
>> > the
>> > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
>> > issue.  The flicker isn't gone for good, but seems to be reboot 
>> > dependent (it's there in some boots, but gone on a reboot).
>> > 
>> > > This should be easy enough to try before bisecting:
>> > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-g
>> > > it
>> > > -s
>> > > end-email-mika.kah...@intel.com
>> > 
>> > Applying this didn't seem to make a difference: still there on
>> > some 
>> > and gone on other reboots.
>> 
>> OK, my candidate bad commit is this one:
>> 
>> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> Author: Ville Syrjälä 
>> Date:   Mon Apr 11 10:23:51 2016 +0300
>> 
>> drm/i915: Get panel_type from OpRegion panel details
>> 
>> After being more careful about waiting to identify flicker, this one
>> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
>> this one reverted and am currently seeing no flicker problems.  It
>> is,
>> however, early days because the flicker can hide for long periods, so
>> I
>> 'll wait until Monday evening and a few reboots before declaring
>> victory.
>> 
>> 
> I'm seeing this on my IvyBridge.  I'll try reverting the commit here
> too, to see if it's the same issue.

IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
different failure mode.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Thu, 23 Jun 2016, Steven Newbury  wrote:
> [ Unknown signature status ]
> On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
>> > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
>> > > > wrote:
>> > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > > > > > I guess we'll need the bisect on this one to make
>> > > > > > > progress.
>> > > > > > 
>> > > > > > Sigh, I was afraid that might be the next step.
>> > > > > 
>> > > > > OK, I have a curious data point.  I assumed the problem would
>> > > > > be
>> > > > > somewhere in the drm update, so I started bisecting that at
>> > > > > the
>> > > > > top. 
>> > > > >  However, the top most commit:
>> > > > > 
>> > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> > > > > Merge: 1f40c49 a39ed68
>> > > > > Author: Linus Torvalds 
>> > > > > Date:   Mon May 23 11:48:48 2016 -0700
>> > > > > 
>> > > > > Merge branch 'drm-next' of
>> > > > > git://people.freedesktop.org/~airlied/linux
>> > > > > 
>> > > > > Isn't actually bad.  There's no flicker here, so whatever
>> > > > > caused
>> > > > > the
>> > > > > problem came from some update after this.
>> > > > 
>> > > > There was a fixes pull after this. Might be worth it to
>> > > > restrict
>> > > > to
>> > > > just
>> > > > the i915 changes, which are just
>> > > > 5b4fd5bb1230cd037..157d2c7fad0863222
>> > > > 
>> > > > Looking at those nothing seems to stick out which might explain
>> > > > what's
>> > > > happening for you.
>> > 
>> > OK, so just on the firmware, the system seems less flickery with
>> > the
>> > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
>> > issue.  The flicker isn't gone for good, but seems to be reboot 
>> > dependent (it's there in some boots, but gone on a reboot).
>> > 
>> > > This should be easy enough to try before bisecting:
>> > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-g
>> > > it
>> > > -s
>> > > end-email-mika.kah...@intel.com
>> > 
>> > Applying this didn't seem to make a difference: still there on
>> > some 
>> > and gone on other reboots.
>> 
>> OK, my candidate bad commit is this one:
>> 
>> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
>> Author: Ville Syrjälä 
>> Date:   Mon Apr 11 10:23:51 2016 +0300
>> 
>> drm/i915: Get panel_type from OpRegion panel details
>> 
>> After being more careful about waiting to identify flicker, this one
>> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
>> this one reverted and am currently seeing no flicker problems.  It
>> is,
>> however, early days because the flicker can hide for long periods, so
>> I
>> 'll wait until Monday evening and a few reboots before declaring
>> victory.
>> 
>> 
> I'm seeing this on my IvyBridge.  I'll try reverting the commit here
> too, to see if it's the same issue.

IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a
different failure mode.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
> > > > wrote:
> > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > > I guess we'll need the bisect on this one to make
> > > > > > > progress.
> > > > > > 
> > > > > > Sigh, I was afraid that might be the next step.
> > > > > 
> > > > > OK, I have a curious data point.  I assumed the problem would
> > > > > be
> > > > > somewhere in the drm update, so I started bisecting that at
> > > > > the
> > > > > top. 
> > > > >  However, the top most commit:
> > > > > 
> > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > > Merge: 1f40c49 a39ed68
> > > > > Author: Linus Torvalds 
> > > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > > 
> > > > > Merge branch 'drm-next' of
> > > > > git://people.freedesktop.org/~airlied/linux
> > > > > 
> > > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > > caused
> > > > > the
> > > > > problem came from some update after this.
> > > > 
> > > > There was a fixes pull after this. Might be worth it to
> > > > restrict
> > > > to
> > > > just
> > > > the i915 changes, which are just
> > > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > > 
> > > > Looking at those nothing seems to stick out which might explain
> > > > what's
> > > > happening for you.
> > 
> > OK, so just on the firmware, the system seems less flickery with
> > the
> > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
> > issue.  The flicker isn't gone for good, but seems to be reboot 
> > dependent (it's there in some boots, but gone on a reboot).
> > 
> > > This should be easy enough to try before bisecting:
> > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-g
> > > it
> > > -s
> > > end-email-mika.kah...@intel.com
> > 
> > Applying this didn't seem to make a difference: still there on
> > some 
> > and gone on other reboots.
> 
> OK, my candidate bad commit is this one:
> 
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
> 
> drm/i915: Get panel_type from OpRegion panel details
> 
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It
> is,
> however, early days because the flicker can hide for long periods, so
> I
> 'll wait until Monday evening and a few reboots before declaring
> victory.
> 
> 
I'm seeing this on my IvyBridge.  I'll try reverting the commit here
too, to see if it's the same issue.


signature.asc
Description: This is a digitally signed message part

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Steven Newbury]

On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley
> > > > wrote:
> > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > > I guess we'll need the bisect on this one to make
> > > > > > > progress.
> > > > > > 
> > > > > > Sigh, I was afraid that might be the next step.
> > > > > 
> > > > > OK, I have a curious data point.  I assumed the problem would
> > > > > be
> > > > > somewhere in the drm update, so I started bisecting that at
> > > > > the
> > > > > top. 
> > > > >  However, the top most commit:
> > > > > 
> > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > > Merge: 1f40c49 a39ed68
> > > > > Author: Linus Torvalds 
> > > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > > 
> > > > > Merge branch 'drm-next' of
> > > > > git://people.freedesktop.org/~airlied/linux
> > > > > 
> > > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > > caused
> > > > > the
> > > > > problem came from some update after this.
> > > > 
> > > > There was a fixes pull after this. Might be worth it to
> > > > restrict
> > > > to
> > > > just
> > > > the i915 changes, which are just
> > > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > > 
> > > > Looking at those nothing seems to stick out which might explain
> > > > what's
> > > > happening for you.
> > 
> > OK, so just on the firmware, the system seems less flickery with
> > the
> > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
> > issue.  The flicker isn't gone for good, but seems to be reboot 
> > dependent (it's there in some boots, but gone on a reboot).
> > 
> > > This should be easy enough to try before bisecting:
> > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-g
> > > it
> > > -s
> > > end-email-mika.kah...@intel.com
> > 
> > Applying this didn't seem to make a difference: still there on
> > some 
> > and gone on other reboots.
> 
> OK, my candidate bad commit is this one:
> 
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
> 
> drm/i915: Get panel_type from OpRegion panel details
> 
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It
> is,
> however, early days because the flicker can hide for long periods, so
> I
> 'll wait until Monday evening and a few reboots before declaring
> victory.
> 
> 
I'm seeing this on my IvyBridge.  I'll try reverting the commit here
too, to see if it's the same issue.


signature.asc
Description: This is a digitally signed message part

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Tue, 2016-06-21 at 17:00 -0400, James Bottomley wrote:
> On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > Cc: Ville
> > > > 
> > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > OK, my candidate bad commit is this one:
> > > > > 
> > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > Author: Ville Syrjälä 
> > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > 
> > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > 
> > > > > After being more careful about waiting to identify flicker, 
> > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > seeing no flicker problems.   It is, however, early days 
> > > > > because the flicker can hide for long periods, so I 'll wait 
> > > > > until Monday evening and a few reboots before declaring
> > > > > victory.
> > > > 
> > > > If that turns out to be the bad commit, it doesn't really 
> > > > surprise me, and that in itself is depressing.
> > > 
> > > As far as I can tell, after running for a day with this reverted,
> > > this is the problem.  The flicker hasn't appeared with it 
> > > reverted.  It's pretty noticeable with this commit included.
> > 
> > Hmm. The only difference I can see is low vs. normal vswing. Panel 
> > 0 has low, panel 2 has normal. So either the VBT or opregion is
> > telling utter lies, or there's some other bug in our low vswing
> > support.
> > 
> > To confirm it's really a vswing issue, you should be able to run 
> > with i915.edp_vswing=2 without flickers on the broken kernel.
> 
> Preliminary boot indicates no flicker with the bad commit included 
> and this option, but I'll have to run for quite a bit longer to 
> verify, since it can sometimes be elusive.

Two days of runtime seems to confirm this is the problem (still no
flicker issues).

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Tue, 2016-06-21 at 17:00 -0400, James Bottomley wrote:
> On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
> > On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > > Cc: Ville
> > > > 
> > > > On Mon, 20 Jun 2016, James Bottomley <
> > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > OK, my candidate bad commit is this one:
> > > > > 
> > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > > Author: Ville Syrjälä 
> > > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > > 
> > > > > drm/i915: Get panel_type from OpRegion panel details
> > > > > 
> > > > > After being more careful about waiting to identify flicker, 
> > > > > this one seems to be the one the bisect finds.  I'm now 
> > > > > running v4.7-rc3 with this one reverted and am currently 
> > > > > seeing no flicker problems.   It is, however, early days 
> > > > > because the flicker can hide for long periods, so I 'll wait 
> > > > > until Monday evening and a few reboots before declaring
> > > > > victory.
> > > > 
> > > > If that turns out to be the bad commit, it doesn't really 
> > > > surprise me, and that in itself is depressing.
> > > 
> > > As far as I can tell, after running for a day with this reverted,
> > > this is the problem.  The flicker hasn't appeared with it 
> > > reverted.  It's pretty noticeable with this commit included.
> > 
> > Hmm. The only difference I can see is low vs. normal vswing. Panel 
> > 0 has low, panel 2 has normal. So either the VBT or opregion is
> > telling utter lies, or there's some other bug in our low vswing
> > support.
> > 
> > To confirm it's really a vswing issue, you should be able to run 
> > with i915.edp_vswing=2 without flickers on the broken kernel.
> 
> Preliminary boot indicates no flicker with the bad commit included 
> and this option, but I'll have to run for quite a bit longer to 
> verify, since it can sometimes be elusive.

Two days of runtime seems to confirm this is the problem (still no
flicker issues).

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > Cc: Ville
> > > 
> > > On Mon, 20 Jun 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > OK, my candidate bad commit is this one:
> > > > 
> > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > Author: Ville Syrjälä 
> > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > 
> > > > drm/i915: Get panel_type from OpRegion panel details
> > > > 
> > > > After being more careful about waiting to identify flicker, 
> > > > this one seems to be the one the bisect finds.  I'm now running 
> > > > v4.7-rc3 with this one reverted and am currently seeing no 
> > > > flicker problems.   It is, however, early days because the 
> > > > flicker can hide for long periods, so I 'll wait until Monday 
> > > > evening and a few reboots before declaring victory.
> > > 
> > > If that turns out to be the bad commit, it doesn't really 
> > > surprise me, and that in itself is depressing.
> > 
> > As far as I can tell, after running for a day with this reverted, 
> > this is the problem.  The flicker hasn't appeared with it reverted.
> >  It's pretty noticeable with this commit included.
> 
> Hmm. The only difference I can see is low vs. normal vswing. Panel 0 
> has low, panel 2 has normal. So either the VBT or opregion is telling
> utter lies, or there's some other bug in our low vswing support.
> 
> To confirm it's really a vswing issue, you should be able to run with
> i915.edp_vswing=2 without flickers on the broken kernel.

Preliminary boot indicates no flicker with the bad commit included and
this option, but I'll have to run for quite a bit longer to verify,
since it can sometimes be elusive.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > Cc: Ville
> > > 
> > > On Mon, 20 Jun 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > OK, my candidate bad commit is this one:
> > > > 
> > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > Author: Ville Syrjälä 
> > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > 
> > > > drm/i915: Get panel_type from OpRegion panel details
> > > > 
> > > > After being more careful about waiting to identify flicker, 
> > > > this one seems to be the one the bisect finds.  I'm now running 
> > > > v4.7-rc3 with this one reverted and am currently seeing no 
> > > > flicker problems.   It is, however, early days because the 
> > > > flicker can hide for long periods, so I 'll wait until Monday 
> > > > evening and a few reboots before declaring victory.
> > > 
> > > If that turns out to be the bad commit, it doesn't really 
> > > surprise me, and that in itself is depressing.
> > 
> > As far as I can tell, after running for a day with this reverted, 
> > this is the problem.  The flicker hasn't appeared with it reverted.
> >  It's pretty noticeable with this commit included.
> 
> Hmm. The only difference I can see is low vs. normal vswing. Panel 0 
> has low, panel 2 has normal. So either the VBT or opregion is telling
> utter lies, or there's some other bug in our low vswing support.
> 
> To confirm it's really a vswing issue, you should be able to run with
> i915.edp_vswing=2 without flickers on the broken kernel.

Preliminary boot indicates no flicker with the bad commit included and
this option, but I'll have to run for quite a bit longer to verify,
since it can sometimes be elusive.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > Cc: Ville
> > 
> > On Mon, 20 Jun 2016, James Bottomley <
> > james.bottom...@hansenpartnership.com> wrote:
> > > OK, my candidate bad commit is this one:
> > > 
> > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > Author: Ville Syrjälä 
> > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > 
> > > drm/i915: Get panel_type from OpRegion panel details
> > > 
> > > After being more careful about waiting to identify flicker, this 
> > > one seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with this one reverted and am currently seeing no flicker problems.
> > >   It is, however, early days because the flicker can hide for long 
> > > periods, so I 'll wait until Monday evening and a few reboots 
> > > before declaring victory.
> > 
> > If that turns out to be the bad commit, it doesn't really surprise 
> > me, and that in itself is depressing.
> 
> As far as I can tell, after running for a day with this reverted, this
> is the problem.  The flicker hasn't appeared with it reverted.  It's
> pretty noticeable with this commit included.

Hmm. The only difference I can see is low vs. normal vswing. Panel 0 has
low, panel 2 has normal. So either the VBT or opregion is telling utter
lies, or there's some other bug in our low vswing support.

To confirm it's really a vswing issue, you should be able to run with
i915.edp_vswing=2 without flickers on the broken kernel.

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > Cc: Ville
> > 
> > On Mon, 20 Jun 2016, James Bottomley <
> > james.bottom...@hansenpartnership.com> wrote:
> > > OK, my candidate bad commit is this one:
> > > 
> > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > Author: Ville Syrjälä 
> > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > 
> > > drm/i915: Get panel_type from OpRegion panel details
> > > 
> > > After being more careful about waiting to identify flicker, this 
> > > one seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with this one reverted and am currently seeing no flicker problems.
> > >   It is, however, early days because the flicker can hide for long 
> > > periods, so I 'll wait until Monday evening and a few reboots 
> > > before declaring victory.
> > 
> > If that turns out to be the bad commit, it doesn't really surprise 
> > me, and that in itself is depressing.
> 
> As far as I can tell, after running for a day with this reverted, this
> is the problem.  The flicker hasn't appeared with it reverted.  It's
> pretty noticeable with this commit included.

Hmm. The only difference I can see is low vs. normal vswing. Panel 0 has
low, panel 2 has normal. So either the VBT or opregion is telling utter
lies, or there's some other bug in our low vswing support.

To confirm it's really a vswing issue, you should be able to run with
i915.edp_vswing=2 without flickers on the broken kernel.

-- 
Ville Syrjälä
Intel OTC

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

Cc: Ville

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

If that turns out to be the bad commit, it doesn't really surprise me,
and that in itself is depressing.

It might be helpful if you could add drm.debug=14 module parameter, and
provide dmesgs from boot both with and without the above commit (it's
enough to see i915 load). Please also provide
/sys/kernel/debug/dri/0/i915_opregion.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

Cc: Ville

On Mon, 20 Jun 2016, James Bottomley  
wrote:
> OK, my candidate bad commit is this one:
>
> commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> Author: Ville Syrjälä 
> Date:   Mon Apr 11 10:23:51 2016 +0300
>
> drm/i915: Get panel_type from OpRegion panel details
>
> After being more careful about waiting to identify flicker, this one
> seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
> this one reverted and am currently seeing no flicker problems.  It is,
> however, early days because the flicker can hide for long periods, so I
> 'll wait until Monday evening and a few reboots before declaring
> victory.

If that turns out to be the bad commit, it doesn't really surprise me,
and that in itself is depressing.

It might be helpful if you could add drm.debug=14 module parameter, and
provide dmesgs from boot both with and without the above commit (it's
enough to see i915 load). Please also provide
/sys/kernel/debug/dri/0/i915_opregion.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > I guess we'll need the bisect on this one to make progress.
> > > > > 
> > > > > Sigh, I was afraid that might be the next step.
> > > > 
> > > > OK, I have a curious data point.  I assumed the problem would
> > > > be
> > > > somewhere in the drm update, so I started bisecting that at the
> > > > top. 
> > > >  However, the top most commit:
> > > > 
> > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > Merge: 1f40c49 a39ed68
> > > > Author: Linus Torvalds 
> > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > 
> > > > Merge branch 'drm-next' of
> > > > git://people.freedesktop.org/~airlied/linux
> > > > 
> > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > caused
> > > > the
> > > > problem came from some update after this.
> > > 
> > > There was a fixes pull after this. Might be worth it to restrict
> > > to
> > > just
> > > the i915 changes, which are just
> > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > 
> > > Looking at those nothing seems to stick out which might explain
> > > what's
> > > happening for you.
> 
> OK, so just on the firmware, the system seems less flickery with the
> new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
> issue.  The flicker isn't gone for good, but seems to be reboot 
> dependent (it's there in some boots, but gone on a reboot).
> 
> > This should be easy enough to try before bisecting:
> > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git
> > -s
> > end-email-mika.kah...@intel.com
> 
> Applying this didn't seem to make a difference: still there on some 
> and gone on other reboots.

OK, my candidate bad commit is this one:

commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä 
Date:   Mon Apr 11 10:23:51 2016 +0300

drm/i915: Get panel_type from OpRegion panel details

After being more careful about waiting to identify flicker, this one
seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
this one reverted and am currently seeing no flicker problems.  It is,
however, early days because the flicker can hide for long periods, so I
'll wait until Monday evening and a few reboots before declaring
victory.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> > On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > > I guess we'll need the bisect on this one to make progress.
> > > > > 
> > > > > Sigh, I was afraid that might be the next step.
> > > > 
> > > > OK, I have a curious data point.  I assumed the problem would
> > > > be
> > > > somewhere in the drm update, so I started bisecting that at the
> > > > top. 
> > > >  However, the top most commit:
> > > > 
> > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > > Merge: 1f40c49 a39ed68
> > > > Author: Linus Torvalds 
> > > > Date:   Mon May 23 11:48:48 2016 -0700
> > > > 
> > > > Merge branch 'drm-next' of
> > > > git://people.freedesktop.org/~airlied/linux
> > > > 
> > > > Isn't actually bad.  There's no flicker here, so whatever
> > > > caused
> > > > the
> > > > problem came from some update after this.
> > > 
> > > There was a fixes pull after this. Might be worth it to restrict
> > > to
> > > just
> > > the i915 changes, which are just
> > > 5b4fd5bb1230cd037..157d2c7fad0863222
> > > 
> > > Looking at those nothing seems to stick out which might explain
> > > what's
> > > happening for you.
> 
> OK, so just on the firmware, the system seems less flickery with the
> new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata 
> issue.  The flicker isn't gone for good, but seems to be reboot 
> dependent (it's there in some boots, but gone on a reboot).
> 
> > This should be easy enough to try before bisecting:
> > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git
> > -s
> > end-email-mika.kah...@intel.com
> 
> Applying this didn't seem to make a difference: still there on some 
> and gone on other reboots.

OK, my candidate bad commit is this one:

commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä 
Date:   Mon Apr 11 10:23:51 2016 +0300

drm/i915: Get panel_type from OpRegion panel details

After being more careful about waiting to identify flicker, this one
seems to be the one the bisect finds.  I'm now running v4.7-rc3 with
this one reverted and am currently seeing no flicker problems.  It is,
however, early days because the flicker can hide for long periods, so I
'll wait until Monday evening and a few reboots before declaring
victory.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > I guess we'll need the bisect on this one to make progress.
> > > > 
> > > > Sigh, I was afraid that might be the next step.
> > > 
> > > OK, I have a curious data point.  I assumed the problem would be
> > > somewhere in the drm update, so I started bisecting that at the
> > > top. 
> > >  However, the top most commit:
> > > 
> > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > Merge: 1f40c49 a39ed68
> > > Author: Linus Torvalds 
> > > Date:   Mon May 23 11:48:48 2016 -0700
> > > 
> > > Merge branch 'drm-next' of
> > > git://people.freedesktop.org/~airlied/linux
> > > 
> > > Isn't actually bad.  There's no flicker here, so whatever caused
> > > the
> > > problem came from some update after this.
> > 
> > There was a fixes pull after this. Might be worth it to restrict to
> > just
> > the i915 changes, which are just
> > 5b4fd5bb1230cd037..157d2c7fad0863222
> > 
> > Looking at those nothing seems to stick out which might explain
> > what's
> > happening for you.

OK, so just on the firmware, the system seems less flickery with the
new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata issue. 
 The flicker isn't gone for good, but seems to be reboot dependent
(it's there in some boots, but gone on a reboot).

> This should be easy enough to try before bisecting:
> http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-s
> end-email-mika.kah...@intel.com

Applying this didn't seem to make a difference: still there on some and
gone on other reboots.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > I guess we'll need the bisect on this one to make progress.
> > > > 
> > > > Sigh, I was afraid that might be the next step.
> > > 
> > > OK, I have a curious data point.  I assumed the problem would be
> > > somewhere in the drm update, so I started bisecting that at the
> > > top. 
> > >  However, the top most commit:
> > > 
> > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > Merge: 1f40c49 a39ed68
> > > Author: Linus Torvalds 
> > > Date:   Mon May 23 11:48:48 2016 -0700
> > > 
> > > Merge branch 'drm-next' of
> > > git://people.freedesktop.org/~airlied/linux
> > > 
> > > Isn't actually bad.  There's no flicker here, so whatever caused
> > > the
> > > problem came from some update after this.
> > 
> > There was a fixes pull after this. Might be worth it to restrict to
> > just
> > the i915 changes, which are just
> > 5b4fd5bb1230cd037..157d2c7fad0863222
> > 
> > Looking at those nothing seems to stick out which might explain
> > what's
> > happening for you.

OK, so just on the firmware, the system seems less flickery with the
new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata issue. 
 The flicker isn't gone for good, but seems to be reboot dependent
(it's there in some boots, but gone on a reboot).

> This should be easy enough to try before bisecting:
> http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-s
> end-email-mika.kah...@intel.com

Applying this didn't seem to make a difference: still there on some and
gone on other reboots.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > I guess we'll need the bisect on this one to make progress.
> > > > 
> > > > Sigh, I was afraid that might be the next step.
> > > 
> > > OK, I have a curious data point.  I assumed the problem would be
> > > somewhere in the drm update, so I started bisecting that at the
> > > top. 
> > >  However, the top most commit:
> > > 
> > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > Merge: 1f40c49 a39ed68
> > > Author: Linus Torvalds 
> > > Date:   Mon May 23 11:48:48 2016 -0700
> > > 
> > > Merge branch 'drm-next' of
> > > git://people.freedesktop.org/~airlied/linux
> > > 
> > > Isn't actually bad.  There's no flicker here, so whatever caused
> > > the
> > > problem came from some update after this.
> > 
> > There was a fixes pull after this. Might be worth it to restrict to
> > just
> > the i915 changes, which are just
> > 5b4fd5bb1230cd037..157d2c7fad0863222
> > 
> > Looking at those nothing seems to stick out which might explain
> > what's
> > happening for you.
> 
> This should be easy enough to try before bisecting:
> http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-s
> end-email-mika.kah...@intel.com

I'll try that.  You should know this platform has a firmware bug in the
digital signals across the display port ... some problem with the mux
in the thunderbolt.  Unfortunately the microcode update for this (the
thunderbolt firmware) can't be applied from Linux or even the usual
FreeDOS, so I'm a bit stuck.

It's also been pointed out to me off list that there's a lot of Skylake
errata that have display flicker due to non-graphics issues:

http://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html

My system is a Dell XPS 9350 and I have updated it with the just released 
firmware:

http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=VNT5J

Which causes my cpu microcode version to go from

> [2.314472] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x82

to

> [2.264669] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

But thanks to the completely opaque microcode update process via the
OEMs it's not clear whether this is sufficient to fix the errata that
are listed as causing flicker (the reported revision on current skylake
lenovos seems to be 0x94)

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
> On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > > > I guess we'll need the bisect on this one to make progress.
> > > > 
> > > > Sigh, I was afraid that might be the next step.
> > > 
> > > OK, I have a curious data point.  I assumed the problem would be
> > > somewhere in the drm update, so I started bisecting that at the
> > > top. 
> > >  However, the top most commit:
> > > 
> > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> > > Merge: 1f40c49 a39ed68
> > > Author: Linus Torvalds 
> > > Date:   Mon May 23 11:48:48 2016 -0700
> > > 
> > > Merge branch 'drm-next' of
> > > git://people.freedesktop.org/~airlied/linux
> > > 
> > > Isn't actually bad.  There's no flicker here, so whatever caused
> > > the
> > > problem came from some update after this.
> > 
> > There was a fixes pull after this. Might be worth it to restrict to
> > just
> > the i915 changes, which are just
> > 5b4fd5bb1230cd037..157d2c7fad0863222
> > 
> > Looking at those nothing seems to stick out which might explain
> > what's
> > happening for you.
> 
> This should be easy enough to try before bisecting:
> http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-s
> end-email-mika.kah...@intel.com

I'll try that.  You should know this platform has a firmware bug in the
digital signals across the display port ... some problem with the mux
in the thunderbolt.  Unfortunately the microcode update for this (the
thunderbolt firmware) can't be applied from Linux or even the usual
FreeDOS, so I'm a bit stuck.

It's also been pointed out to me off list that there's a lot of Skylake
errata that have display flicker due to non-graphics issues:

http://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html

My system is a Dell XPS 9350 and I have updated it with the just released 
firmware:

http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=VNT5J

Which causes my cpu microcode version to go from

> [2.314472] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x82

to

> [2.264669] microcode: CPU0 sig=0x406e3, pf=0x80, revision=0x8a

But thanks to the completely opaque microcode update process via the
OEMs it's not clear whether this is sufficient to fix the errata that
are listed as causing flicker (the reported revision on current skylake
lenovos seems to be 0x94)

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > I guess we'll need the bisect on this one to make progress.
>> > 
>> > Sigh, I was afraid that might be the next step.
>> 
>> OK, I have a curious data point.  I assumed the problem would be
>> somewhere in the drm update, so I started bisecting that at the top. 
>>  However, the top most commit:
>> 
>> commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> Merge: 1f40c49 a39ed68
>> Author: Linus Torvalds 
>> Date:   Mon May 23 11:48:48 2016 -0700
>> 
>> Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
>> 
>> Isn't actually bad.  There's no flicker here, so whatever caused the
>> problem came from some update after this.
>
> There was a fixes pull after this. Might be worth it to restrict to just
> the i915 changes, which are just 5b4fd5bb1230cd037..157d2c7fad0863222
>
> Looking at those nothing seems to stick out which might explain what's
> happening for you.

This should be easy enough to try before bisecting:
http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-send-email-mika.kah...@intel.com

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Jani Nikula]

On Fri, 17 Jun 2016, Daniel Vetter  wrote:
> On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
>> > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
>> > > I guess we'll need the bisect on this one to make progress.
>> > 
>> > Sigh, I was afraid that might be the next step.
>> 
>> OK, I have a curious data point.  I assumed the problem would be
>> somewhere in the drm update, so I started bisecting that at the top. 
>>  However, the top most commit:
>> 
>> commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
>> Merge: 1f40c49 a39ed68
>> Author: Linus Torvalds 
>> Date:   Mon May 23 11:48:48 2016 -0700
>> 
>> Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
>> 
>> Isn't actually bad.  There's no flicker here, so whatever caused the
>> problem came from some update after this.
>
> There was a fixes pull after this. Might be worth it to restrict to just
> the i915 changes, which are just 5b4fd5bb1230cd037..157d2c7fad0863222
>
> Looking at those nothing seems to stick out which might explain what's
> happening for you.

This should be easy enough to try before bisecting:
http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-git-send-email-mika.kah...@intel.com

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Chris Wilson]

On Thu, Jun 16, 2016 at 02:29:07PM -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
> >  wrote:
> > > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> > > > On Tue, 31 May 2016, James Bottomley <
> > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > > > > On Mon, 30 May 2016, James Bottomley <
> > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > I've tested a pristine 4.6.0 system, so it's definitely
> > > > > > > something
> > > > > > > that
> > > > > > > went in during the merge window.  The flicker isn't
> > > > > > > continuous,
> > > > > > > it's
> > > > > > > periodic, with an interval of something like 2-5 seconds. 
> > > > > > >  It
> > > > > > > looks
> > > > > > > like an old analogue TV going out of sync and then
> > > > > > > resyncing.
> > > > > > >  I've
> > > > > > > attached the dmesg and X.org log below just in case they
> > > > > > > can
> > > > > > > help.
> > > > > > >  I
> > > > > > > might be able to bisect this next week, but, unfortunately,
> > > > > > > this is
> > > > > > > my
> > > > > > > current laptop and I'm travelling this week.
> > > > > > 
> > > > > > Please try i915.enable_psr=0 module parameter.
> > > > > 
> > > > > Makes no discernable difference.  Current parameter settings
> > > > > are:
> > > > 
> > > > Sorry for the silence. Would you mind trying out drm-intel
> > > > -nightly
> > > > branch of [1]?
> > > > 
> > > > BR,
> > > > Jani.
> > > > 
> > > > [1] http://cgit.freedesktop.org/drm-intel
> > > 
> > > No, flicker is still there (and in fact seems worse) with the tree
> > > with
> > > this commit at the top:
> > > 
> > > commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> > > Author: Daniel Vetter 
> > > Date:   Thu Jun 16 14:38:54 2016 +0200
> > > 
> > > drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> > > manifest
> > 
> > Strange indeed, I hoped the improved watermark code in -nightly would
> > help. I assume nothing in dmesg about underruns or something similar?
> 
> Not that I can tell.  I've attached the full dmesg just in case.

It is worth using drm.debug=0xe to get the full atomic modesetting
splat. There may be a tell-tale in there that we don't yet have a
warning for.
-Chris
>
-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Chris Wilson]

On Thu, Jun 16, 2016 at 02:29:07PM -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
> >  wrote:
> > > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> > > > On Tue, 31 May 2016, James Bottomley <
> > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > > > > On Mon, 30 May 2016, James Bottomley <
> > > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > > I've tested a pristine 4.6.0 system, so it's definitely
> > > > > > > something
> > > > > > > that
> > > > > > > went in during the merge window.  The flicker isn't
> > > > > > > continuous,
> > > > > > > it's
> > > > > > > periodic, with an interval of something like 2-5 seconds. 
> > > > > > >  It
> > > > > > > looks
> > > > > > > like an old analogue TV going out of sync and then
> > > > > > > resyncing.
> > > > > > >  I've
> > > > > > > attached the dmesg and X.org log below just in case they
> > > > > > > can
> > > > > > > help.
> > > > > > >  I
> > > > > > > might be able to bisect this next week, but, unfortunately,
> > > > > > > this is
> > > > > > > my
> > > > > > > current laptop and I'm travelling this week.
> > > > > > 
> > > > > > Please try i915.enable_psr=0 module parameter.
> > > > > 
> > > > > Makes no discernable difference.  Current parameter settings
> > > > > are:
> > > > 
> > > > Sorry for the silence. Would you mind trying out drm-intel
> > > > -nightly
> > > > branch of [1]?
> > > > 
> > > > BR,
> > > > Jani.
> > > > 
> > > > [1] http://cgit.freedesktop.org/drm-intel
> > > 
> > > No, flicker is still there (and in fact seems worse) with the tree
> > > with
> > > this commit at the top:
> > > 
> > > commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> > > Author: Daniel Vetter 
> > > Date:   Thu Jun 16 14:38:54 2016 +0200
> > > 
> > > drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> > > manifest
> > 
> > Strange indeed, I hoped the improved watermark code in -nightly would
> > help. I assume nothing in dmesg about underruns or something similar?
> 
> Not that I can tell.  I've attached the full dmesg just in case.

It is worth using drm.debug=0xe to get the full atomic modesetting
splat. There may be a tell-tale in there that we don't yet have a
warning for.
-Chris
>
-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Daniel Vetter]

On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > I guess we'll need the bisect on this one to make progress.
> > 
> > Sigh, I was afraid that might be the next step.
> 
> OK, I have a curious data point.  I assumed the problem would be
> somewhere in the drm update, so I started bisecting that at the top. 
>  However, the top most commit:
> 
> commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> Merge: 1f40c49 a39ed68
> Author: Linus Torvalds 
> Date:   Mon May 23 11:48:48 2016 -0700
> 
> Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
> 
> Isn't actually bad.  There's no flicker here, so whatever caused the
> problem came from some update after this.

There was a fixes pull after this. Might be worth it to restrict to just
the i915 changes, which are just 5b4fd5bb1230cd037..157d2c7fad0863222

Looking at those nothing seems to stick out which might explain what's
happening for you.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Daniel Vetter]

On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > > I guess we'll need the bisect on this one to make progress.
> > 
> > Sigh, I was afraid that might be the next step.
> 
> OK, I have a curious data point.  I assumed the problem would be
> somewhere in the drm update, so I started bisecting that at the top. 
>  However, the top most commit:
> 
> commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
> Merge: 1f40c49 a39ed68
> Author: Linus Torvalds 
> Date:   Mon May 23 11:48:48 2016 -0700
> 
> Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
> 
> Isn't actually bad.  There's no flicker here, so whatever caused the
> problem came from some update after this.

There was a fixes pull after this. Might be worth it to restrict to just
the i915 changes, which are just 5b4fd5bb1230cd037..157d2c7fad0863222

Looking at those nothing seems to stick out which might explain what's
happening for you.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > I guess we'll need the bisect on this one to make progress.
> 
> Sigh, I was afraid that might be the next step.

OK, I have a curious data point.  I assumed the problem would be
somewhere in the drm update, so I started bisecting that at the top. 
 However, the top most commit:

commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
Merge: 1f40c49 a39ed68
Author: Linus Torvalds 
Date:   Mon May 23 11:48:48 2016 -0700

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

Isn't actually bad.  There's no flicker here, so whatever caused the
problem came from some update after this.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > I guess we'll need the bisect on this one to make progress.
> 
> Sigh, I was afraid that might be the next step.

OK, I have a curious data point.  I assumed the problem would be
somewhere in the drm update, so I started bisecting that at the top. 
 However, the top most commit:

commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
Merge: 1f40c49 a39ed68
Author: Linus Torvalds 
Date:   Mon May 23 11:48:48 2016 -0700

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

Isn't actually bad.  There's no flicker here, so whatever caused the
problem came from some update after this.

James

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
>  wrote:
> > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> > > On Tue, 31 May 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > > > On Mon, 30 May 2016, James Bottomley <
> > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > I've tested a pristine 4.6.0 system, so it's definitely
> > > > > > something
> > > > > > that
> > > > > > went in during the merge window.  The flicker isn't
> > > > > > continuous,
> > > > > > it's
> > > > > > periodic, with an interval of something like 2-5 seconds. 
> > > > > >  It
> > > > > > looks
> > > > > > like an old analogue TV going out of sync and then
> > > > > > resyncing.
> > > > > >  I've
> > > > > > attached the dmesg and X.org log below just in case they
> > > > > > can
> > > > > > help.
> > > > > >  I
> > > > > > might be able to bisect this next week, but, unfortunately,
> > > > > > this is
> > > > > > my
> > > > > > current laptop and I'm travelling this week.
> > > > > 
> > > > > Please try i915.enable_psr=0 module parameter.
> > > > 
> > > > Makes no discernable difference.  Current parameter settings
> > > > are:
> > > 
> > > Sorry for the silence. Would you mind trying out drm-intel
> > > -nightly
> > > branch of [1]?
> > > 
> > > BR,
> > > Jani.
> > > 
> > > [1] http://cgit.freedesktop.org/drm-intel
> > 
> > No, flicker is still there (and in fact seems worse) with the tree
> > with
> > this commit at the top:
> > 
> > commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> > Author: Daniel Vetter 
> > Date:   Thu Jun 16 14:38:54 2016 +0200
> > 
> > drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> > manifest
> 
> Strange indeed, I hoped the improved watermark code in -nightly would
> help. I assume nothing in dmesg about underruns or something similar?

Not that I can tell.  I've attached the full dmesg just in case.

> I guess we'll need the bisect on this one to make progress.

Sigh, I was afraid that might be the next step.

James

[0.00] Linux version 4.7.0-rc3+ (jejb@jarvis) (gcc version 4.8.5 (SUSE 
Linux) ) #4 SMP PREEMPT Thu Jun 16 13:57:07 PDT 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-test 
root=UUID=994363fd-c12c-4c6c-92e9-85e8ac695cf9 ro resume=/dev/nvme0n1p2 
splash=silent quiet showopts pcie_aspm=force
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  960, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]: 1024, xstate_sizes[4]:   64
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 1088 
bytes, using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x69537fff] usable
[0.00] BIOS-e820: [mem 0x69538000-0x69538fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x69539000-0x69562fff] reserved
[0.00] BIOS-e820: [mem 0x69563000-0x695bdfff] usable
[0.00] BIOS-e820: [mem 0x695be000-0x69daefff] reserved
[0.00] BIOS-e820: [mem 0x69daf000-0x7907dfff] usable
[0.00] BIOS-e820: [mem 0x7907e000-0x793f8fff] reserved
[0.00] BIOS-e820: [mem 0x793f9000-0x79448fff] ACPI data
[0.00] BIOS-e820: [mem 0x79449000-0x79c00fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79c01000-0x7a4fefff] reserved
[0.00] BIOS-e820: [mem 0x7a4ff000-0x7a4f] usable
[0.00] BIOS-e820: [mem 0x7a50-0x7a5f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] 

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
>  wrote:
> > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> > > On Tue, 31 May 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > > > On Mon, 30 May 2016, James Bottomley <
> > > > > james.bottom...@hansenpartnership.com> wrote:
> > > > > > I've tested a pristine 4.6.0 system, so it's definitely
> > > > > > something
> > > > > > that
> > > > > > went in during the merge window.  The flicker isn't
> > > > > > continuous,
> > > > > > it's
> > > > > > periodic, with an interval of something like 2-5 seconds. 
> > > > > >  It
> > > > > > looks
> > > > > > like an old analogue TV going out of sync and then
> > > > > > resyncing.
> > > > > >  I've
> > > > > > attached the dmesg and X.org log below just in case they
> > > > > > can
> > > > > > help.
> > > > > >  I
> > > > > > might be able to bisect this next week, but, unfortunately,
> > > > > > this is
> > > > > > my
> > > > > > current laptop and I'm travelling this week.
> > > > > 
> > > > > Please try i915.enable_psr=0 module parameter.
> > > > 
> > > > Makes no discernable difference.  Current parameter settings
> > > > are:
> > > 
> > > Sorry for the silence. Would you mind trying out drm-intel
> > > -nightly
> > > branch of [1]?
> > > 
> > > BR,
> > > Jani.
> > > 
> > > [1] http://cgit.freedesktop.org/drm-intel
> > 
> > No, flicker is still there (and in fact seems worse) with the tree
> > with
> > this commit at the top:
> > 
> > commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> > Author: Daniel Vetter 
> > Date:   Thu Jun 16 14:38:54 2016 +0200
> > 
> > drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> > manifest
> 
> Strange indeed, I hoped the improved watermark code in -nightly would
> help. I assume nothing in dmesg about underruns or something similar?

Not that I can tell.  I've attached the full dmesg just in case.

> I guess we'll need the bisect on this one to make progress.

Sigh, I was afraid that might be the next step.

James

[0.00] Linux version 4.7.0-rc3+ (jejb@jarvis) (gcc version 4.8.5 (SUSE 
Linux) ) #4 SMP PREEMPT Thu Jun 16 13:57:07 PDT 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-test 
root=UUID=994363fd-c12c-4c6c-92e9-85e8ac695cf9 ro resume=/dev/nvme0n1p2 
splash=silent quiet showopts pcie_aspm=force
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  960, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]: 1024, xstate_sizes[4]:   64
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 1088 
bytes, using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x69537fff] usable
[0.00] BIOS-e820: [mem 0x69538000-0x69538fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x69539000-0x69562fff] reserved
[0.00] BIOS-e820: [mem 0x69563000-0x695bdfff] usable
[0.00] BIOS-e820: [mem 0x695be000-0x69daefff] reserved
[0.00] BIOS-e820: [mem 0x69daf000-0x7907dfff] usable
[0.00] BIOS-e820: [mem 0x7907e000-0x793f8fff] reserved
[0.00] BIOS-e820: [mem 0x793f9000-0x79448fff] ACPI data
[0.00] BIOS-e820: [mem 0x79449000-0x79c00fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79c01000-0x7a4fefff] reserved
[0.00] BIOS-e820: [mem 0x7a4ff000-0x7a4f] usable
[0.00] BIOS-e820: [mem 0x7a50-0x7a5f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] 

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Daniel Vetter]

On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
 wrote:
> On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
>> On Tue, 31 May 2016, James Bottomley <
>> james.bottom...@hansenpartnership.com> wrote:
>> > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
>> > > On Mon, 30 May 2016, James Bottomley <
>> > > james.bottom...@hansenpartnership.com> wrote:
>> > > > I've tested a pristine 4.6.0 system, so it's definitely
>> > > > something
>> > > > that
>> > > > went in during the merge window.  The flicker isn't continuous,
>> > > > it's
>> > > > periodic, with an interval of something like 2-5 seconds.  It
>> > > > looks
>> > > > like an old analogue TV going out of sync and then resyncing.
>> > > >  I've
>> > > > attached the dmesg and X.org log below just in case they can
>> > > > help.
>> > > >  I
>> > > > might be able to bisect this next week, but, unfortunately,
>> > > > this is
>> > > > my
>> > > > current laptop and I'm travelling this week.
>> > >
>> > > Please try i915.enable_psr=0 module parameter.
>> >
>> > Makes no discernable difference.  Current parameter settings are:
>>
>> Sorry for the silence. Would you mind trying out drm-intel-nightly
>> branch of [1]?
>>
>> BR,
>> Jani.
>>
>> [1] http://cgit.freedesktop.org/drm-intel
>
> No, flicker is still there (and in fact seems worse) with the tree with
> this commit at the top:
>
> commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> Author: Daniel Vetter 
> Date:   Thu Jun 16 14:38:54 2016 +0200
>
> drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> manifest

Strange indeed, I hoped the improved watermark code in -nightly would
help. I assume nothing in dmesg about underruns or something similar?
I guess we'll need the bisect on this one to make progress.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Daniel Vetter]

On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
 wrote:
> On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
>> On Tue, 31 May 2016, James Bottomley <
>> james.bottom...@hansenpartnership.com> wrote:
>> > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
>> > > On Mon, 30 May 2016, James Bottomley <
>> > > james.bottom...@hansenpartnership.com> wrote:
>> > > > I've tested a pristine 4.6.0 system, so it's definitely
>> > > > something
>> > > > that
>> > > > went in during the merge window.  The flicker isn't continuous,
>> > > > it's
>> > > > periodic, with an interval of something like 2-5 seconds.  It
>> > > > looks
>> > > > like an old analogue TV going out of sync and then resyncing.
>> > > >  I've
>> > > > attached the dmesg and X.org log below just in case they can
>> > > > help.
>> > > >  I
>> > > > might be able to bisect this next week, but, unfortunately,
>> > > > this is
>> > > > my
>> > > > current laptop and I'm travelling this week.
>> > >
>> > > Please try i915.enable_psr=0 module parameter.
>> >
>> > Makes no discernable difference.  Current parameter settings are:
>>
>> Sorry for the silence. Would you mind trying out drm-intel-nightly
>> branch of [1]?
>>
>> BR,
>> Jani.
>>
>> [1] http://cgit.freedesktop.org/drm-intel
>
> No, flicker is still there (and in fact seems worse) with the tree with
> this commit at the top:
>
> commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> Author: Daniel Vetter 
> Date:   Thu Jun 16 14:38:54 2016 +0200
>
> drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> manifest

Strange indeed, I hoped the improved watermark code in -nightly would
help. I assume nothing in dmesg about underruns or something similar?
I guess we'll need the bisect on this one to make progress.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch