screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

The symptoms are really weird: the screen image is locked in place. 
The machine is still functional and if I log in over the network I can
do anything I like, including killing the X server and the display will
never alter.  It also seems that the system is accepting keyboard input
because when it freezes I can cat information to a file (if the mouse
was over an xterm) and verify over the network the file contents. 
Nothing unusual appears in dmesg when the lockup happens.

The last kernel I booted successfully on the system was 5.0, so I'll
try compiling 5.1 to narrow down the changes.

James

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Hi James,

James Bottomley schreef op za 29-06-2019 om 11:56 [-0700]:
> The symptoms are really weird: the screen image is locked in place. 
> The machine is still functional and if I log in over the network I can
> do anything I like, including killing the X server and the display will
> never alter.  It also seems that the system is accepting keyboard input
> because when it freezes I can cat information to a file (if the mouse
> was over an xterm) and verify over the network the file contents. 
> Nothing unusual appears in dmesg when the lockup happens.
> 
> The last kernel I booted successfully on the system was 5.0, so I'll
> try compiling 5.1 to narrow down the changes.

Upgrading to 5.2 (from 5.1.y) on a "Dell XPS 13 9350" (is that a skylake too?)
showed similar symptoms. There's no pattern to the freezes that I can see.
They're rather frequent too (think every few minutes). Eg, two freezes while
composing this message!

My totally silly workaround is suspending (via Fn + Insert) and resuming.

Did you manage to narrow this any further?

Thanks,


Paul Bolle

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Sat, 2019-06-29 at 11:56 -0700, James Bottomley wrote:
> The symptoms are really weird: the screen image is locked in place. 
> The machine is still functional and if I log in over the network I
> can do anything I like, including killing the X server and the
> display will never alter.  It also seems that the system is accepting
> keyboard input because when it freezes I can cat information to a
> file (if the mouse was over an xterm) and verify over the network the
> file contents. Nothing unusual appears in dmesg when the lockup
> happens.
> 
> The last kernel I booted successfully on the system was 5.0, so I'll
> try compiling 5.1 to narrow down the changes.

I've confirmed that 5.1 doesn't have the regression and I'm now trying
to bisect the 5.2 merge window, but since the problem takes quite a
while to manifest this will take some time.  Any hints about specific
patches that might be the problem would be welcome.

James

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Hi James,

James Bottomley schreef op wo 10-07-2019 om 08:01 [-0700]:
> I've confirmed that 5.1 doesn't have the regression and I'm now trying
> to bisect the 5.2 merge window, but since the problem takes quite a
> while to manifest this will take some time.  Any hints about specific
> patches that might be the problem would be welcome.

(Perhaps my message of yesterday never reached you.)

It seems I hit this problem quite easily. Bisecting v5.1..v5.2 could be a real
chore, so perhaps we could coordinate efforts (off-list)?

Thanks,


Paul Bolle

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Wed, 2019-07-10 at 18:16 +0200, Paul Bolle wrote:
> Hi James,
> 
> James Bottomley schreef op wo 10-07-2019 om 08:01 [-0700]:
> > I've confirmed that 5.1 doesn't have the regression and I'm now
> > trying to bisect the 5.2 merge window, but since the problem takes
> > quite a while to manifest this will take some time.  Any hints
> > about specific patches that might be the problem would be welcome.
> 
> (Perhaps my message of yesterday never reached you.)

No, sorry, if the list is followup to list, I'm not subscribed.  I see
it now I look in the archives, though.

---
> Upgrading to 5.2 (from 5.1.y) on a "Dell XPS 13 9350" (is that a
> skylake too?)

I believe so.  My laptop is a 9350.  I believe they're the earliest
skylake produced. 

>  showed similar symptoms. There's no pattern to the freezes that I
> can see. They're rather frequent too (think every few minutes). Eg,
> two freezes while composing this message!

You seem to be getting it to happen much more often than I can. Last
night, on the below pull request it took me a good hour to see the
freeze.

---
> It seems I hit this problem quite easily. Bisecting v5.1..v5.2 could
> be a real chore, so perhaps we could coordinate efforts (off-list)?

Sure, my current testing indicates it's somewhere inside this pull
request:

Merge: 89c3b37af87e eb85d03e01c3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 8 21:35:19 2019 -0700

    Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
    
    Pull drm updates from Dave Airlie:

So I was about to test out the i915 changes in that but since my laptop
is what I use for daily work, it's a bit hard (can't freeze up on video
calls for instance).

James

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

James Bottomley schreef op wo 10-07-2019 om 09:32 [-0700]:
> You seem to be getting it to happen much more often than I can. Last
> night, on the below pull request it took me a good hour to see the
> freeze.

Yes. Sometimes within a minute of resuming. Typing stuff into evolution seems
to help with triggering this. It's all a bit mysterious, but this message
alone frooze my laptop a few times. Seriously!

> Sure, my current testing indicates it's somewhere inside this pull
> request:
> 
> Merge: 89c3b37af87e eb85d03e01c3
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Wed May 8 21:35:19 2019 -0700
> 
>     Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
>     
>     Pull drm updates from Dave Airlie:

Lazy question: how does one determine the first and last commit inside a merge
request? Can I simply do
    good   a2d635decbfa9c1e4ae15cb05b68b2559f7f827c^
    bad    a2d635decbfa9c1e4ae15cb05b68b2559f7f827c

for git bisect?

> So I was about to test out the i915 changes in that but since my laptop
> is what I use for daily work, it's a bit hard (can't freeze up on video
> calls for instance).

I usually use one of the ThinkPads from my embarrassing pile of outdated
hardware to do nasty bisects, but I'm not about to loose any income if my much
appreciated XPS 13 is out of order for a while.

Thanks,


Paul Bolle

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Wed, 2019-07-10 at 18:45 +0200, Paul Bolle wrote:
> James Bottomley schreef op wo 10-07-2019 om 09:32 [-0700]:
> > You seem to be getting it to happen much more often than I can.
> > Last
> > night, on the below pull request it took me a good hour to see the
> > freeze.
> 
> Yes. Sometimes within a minute of resuming. Typing stuff into
> evolution seems to help with triggering this. It's all a bit
> mysterious, but this message alone frooze my laptop a few times.
> Seriously!
> 
> > Sure, my current testing indicates it's somewhere inside this pull
> > request:
> > 
> > Merge: 89c3b37af87e eb85d03e01c3
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Wed May 8 21:35:19 2019 -0700
> > 
> >     Merge tag 'drm-next-2019-05-09' of
> > git://anongit.freedesktop.org/drm/drm
> >     
> >     Pull drm updates from Dave Airlie:
> 
> Lazy question: how does one determine the first and last commit
> inside a merge request? Can I simply do
>     good   a2d635decbfa9c1e4ae15cb05b68b2559f7f827c^
>     bad    a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
> 
> for git bisect?

I think so.  I actually did

	bad	a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
	good	89c3b37af87ec183b666d83428cb28cc421671a6

But I think ^ steps down in the main branch.  Note, I've only done a
couple of hours run on what I think is the good commit ... and actually
I'd already marked a2d635decbfa9c1e4ae15cb05b68b2559f7f827c as good
until the screen froze just after I'd built the new bisect kernel, so
there's still some chance 89c3b37af87ec183b666d83428cb28cc421671a6 is
bad.

> > So I was about to test out the i915 changes in that but since my
> > laptop is what I use for daily work, it's a bit hard (can't freeze
> > up on video calls for instance).
> 
> I usually use one of the ThinkPads from my embarrassing pile of
> outdated hardware to do nasty bisects, but I'm not about to loose any
> income if my much appreciated XPS 13 is out of order for a while.

I can get back to it this afternoon, when I'm done with the meeting
requirements and doing other dev stuff.

James

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]:
> I can get back to it this afternoon, when I'm done with the meeting
> requirements and doing other dev stuff.

I've started bisecting using your suggestion of that drm merge:
    $ git bisect log
    git bisect start
    # good: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
    git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6
    # bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
    git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
    # bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915: Update DRIVER_DATE to 20190417
    git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217

Git told me I have nine steps after this. So at two hours per step I might
pinpoint the offending commit by Friday the 12th. If I'm lucky. (There are
other things to do than bisecting this issue.)

If you find that commit before I do, I'll be all ears.

Thanks,


Paul Bolle

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Wed, 2019-07-10 at 23:59 +0200, Paul Bolle wrote:
> James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]:
> > I can get back to it this afternoon, when I'm done with the meeting
> > requirements and doing other dev stuff.
> 
> I've started bisecting using your suggestion of that drm merge:
>     $ git bisect log
>     git bisect start
>     # good: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
>     git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6
>     # bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-
> next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
>     git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
>     # bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915:
> Update DRIVER_DATE to 20190417
>     git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217
> 
> Git told me I have nine steps after this. So at two hours per step I
> might
> pinpoint the offending commit by Friday the 12th. If I'm lucky.
> (There are
> other things to do than bisecting this issue.)
> 
> If you find that commit before I do, I'll be all ears.

Sure ... I'm doing the holistic thing and looking at the tree in that
branch.  It seems to consist of 7 i915 updates

c09d39166d8a3f3788680b32dbb0a40a70de32e2 DRIVER_DATE to 20190207
47ed55a9bb9e284d46d6f2489e32a53b59152809 DRIVER_DATE to 20190220
f4ecb8ae70de86710e85138ce49af5c689951953 DRIVER_DATE to 20190311
1284ec985572232ace4817476baeb2d82b60be7a DRIVER_DATE to 20190320
a01b2c6f47d86c7d1a9fa822b3b91ec233b61784 DRIVER_DATE to 20190328
28d618e9ab86f26a31af0b235ced55beb3e343c8 DRIVER_DATE to 20190404
ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217 DRIVER_DATE to 20190417

So I figured I'd see if I can locate the problem by bisection of those
plus inspection.

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

Hi James and Paul

Could you share a dmesg output of your system after the bug occur with
this kernel parameters "drm.debug=0x1e log_buf_len=4M"? Also the output
of /sys/kernel/debug/dri/0/i915_edp_psr_status

Thanks


On Wed, 2019-07-10 at 15:18 -0700, James Bottomley wrote:
> On Wed, 2019-07-10 at 23:59 +0200, Paul Bolle wrote:
> > James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]:
> > > I can get back to it this afternoon, when I'm done with the
> > > meeting
> > > requirements and doing other dev stuff.
> > 
> > I've started bisecting using your suggestion of that drm merge:
> >     $ git bisect log
> >     git bisect start
> >     # good: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
> >     git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6
> >     # bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag
> > 'drm-
> > next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
> >     git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
> >     # bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915:
> > Update DRIVER_DATE to 20190417
> >     git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217
> > 
> > Git told me I have nine steps after this. So at two hours per step
> > I
> > might
> > pinpoint the offending commit by Friday the 12th. If I'm lucky.
> > (There are
> > other things to do than bisecting this issue.)
> > 
> > If you find that commit before I do, I'll be all ears.
> 
> Sure ... I'm doing the holistic thing and looking at the tree in that
> branch.  It seems to consist of 7 i915 updates
> 
> c09d39166d8a3f3788680b32dbb0a40a70de32e2 DRIVER_DATE to 20190207
> 47ed55a9bb9e284d46d6f2489e32a53b59152809 DRIVER_DATE to 20190220
> f4ecb8ae70de86710e85138ce49af5c689951953 DRIVER_DATE to 20190311
> 1284ec985572232ace4817476baeb2d82b60be7a DRIVER_DATE to 20190320
> a01b2c6f47d86c7d1a9fa822b3b91ec233b61784 DRIVER_DATE to 20190328
> 28d618e9ab86f26a31af0b235ced55beb3e343c8 DRIVER_DATE to 20190404
> ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217 DRIVER_DATE to 20190417
> 
> So I figured I'd see if I can locate the problem by bisection of
> those
> plus inspection.
> 
> James
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Chris Wilson]

Quoting James Bottomley (2019-06-29 19:56:52)
> The symptoms are really weird: the screen image is locked in place. 
> The machine is still functional and if I log in over the network I can
> do anything I like, including killing the X server and the display will
> never alter.  It also seems that the system is accepting keyboard input
> because when it freezes I can cat information to a file (if the mouse
> was over an xterm) and verify over the network the file contents. 
> Nothing unusual appears in dmesg when the lockup happens.
> 
> The last kernel I booted successfully on the system was 5.0, so I'll
> try compiling 5.1 to narrow down the changes.

It's likely this is panel self-refresh going haywire.

commit 8f6e87d6d561f10cfa48a687345512419839b6d8
Author: José Roberto de Souza <jose.souza@intel.com>
Date:   Thu Mar 7 16:00:50 2019 -0800

    drm/i915: Enable PSR2 by default

    The support for PSR2 was polished, IGT tests for PSR2 was added and
    it was tested performing regular user workloads like browsing,
    editing documents and compiling Linux, so it is time to enable it by
    default and enjoy even more power-savings.

Temporary workaround would be to set i915.enable_psr=0
-Chris

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Chris Wilson schreef op do 11-07-2019 om 10:29 [+0100]:
> Temporary workaround would be to set i915.enable_psr=0

That workaround seems to work for me. Over an hour of uptime without any
screen freezes.

(I first tried fiddling with /sys/module/i915/parameters/enable_psr at
runtime, but that apparently has no effect. Should that file be read-only?)

Feel free to ask me to test a fix (or a revert) once you've figured out what
to do about this.


Paul Bolle

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Paul Bolle schreef op do 11-07-2019 om 13:20 [+0200]:
> Chris Wilson schreef op do 11-07-2019 om 10:29 [+0100]:
> > Temporary workaround would be to set i915.enable_psr=0
> 
> That workaround seems to work for me. Over an hour of uptime without any
> screen freezes.

May or may not be related: 24 hours into that session I had the machine lock
up hard. Screen frozen, no input possible, etc. I had to power cycle it (after
half an hour, behaving very patient).

But the screen freeze that we're focusing on here never occurred during this
session.


Paul Bolle

Re: screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote:
> Quoting James Bottomley (2019-06-29 19:56:52)
> > The symptoms are really weird: the screen image is locked in
> > place.  The machine is still functional and if I log in over the
> > network can do anything I like, including killing the X server and
> > the display will never alter.  It also seems that the system is
> > accepting keyboard input because when it freezes I can cat
> > information to a file (if the mouse was over an xterm) and verify
> > over the network the file contents. Nothing unusual appears in
> > dmesg when the lockup happens.
> > 
> > The last kernel I booted successfully on the system was 5.0, so
> > I'll try compiling 5.1 to narrow down the changes.
> 
> It's likely this is panel self-refresh going haywire.
> 
> commit 8f6e87d6d561f10cfa48a687345512419839b6d8
> Author: José Roberto de Souza <jose.souza@intel.com>
> Date:   Thu Mar 7 16:00:50 2019 -0800
> 
>     drm/i915: Enable PSR2 by default
> 
>     The support for PSR2 was polished, IGT tests for PSR2 was added
> and
>     it was tested performing regular user workloads like browsing,
>     editing documents and compiling Linux, so it is time to enable it
> by
>     default and enjoy even more power-savings.
> 
> Temporary workaround would be to set i915.enable_psr=0

It looks plausible.  I have to say I was just about to mark a bisect
containing this as good, but that probably reflects my difficulty
reproducing the issue.

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

On Thu, 2019-07-11 at 13:11 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote:
> > Quoting James Bottomley (2019-06-29 19:56:52)
> > > The symptoms are really weird: the screen image is locked in
> > > place.  The machine is still functional and if I log in over the
> > > network can do anything I like, including killing the X server
> > > and
> > > the display will never alter.  It also seems that the system is
> > > accepting keyboard input because when it freezes I can cat
> > > information to a file (if the mouse was over an xterm) and verify
> > > over the network the file contents. Nothing unusual appears in
> > > dmesg when the lockup happens.
> > > 
> > > The last kernel I booted successfully on the system was 5.0, so
> > > I'll try compiling 5.1 to narrow down the changes.
> > 
> > It's likely this is panel self-refresh going haywire.
> > 
> > commit 8f6e87d6d561f10cfa48a687345512419839b6d8
> > Author: José Roberto de Souza <jose.souza@intel.com>
> > Date:   Thu Mar 7 16:00:50 2019 -0800
> > 
> >     drm/i915: Enable PSR2 by default
> > 
> >     The support for PSR2 was polished, IGT tests for PSR2 was added
> > and
> >     it was tested performing regular user workloads like browsing,
> >     editing documents and compiling Linux, so it is time to enable
> > it
> > by
> >     default and enjoy even more power-savings.
> > 
> > Temporary workaround would be to set i915.enable_psr=0
> 
> It looks plausible.  I have to say I was just about to mark a bisect
> containing this as good, but that probably reflects my difficulty
> reproducing the issue.

Take at look of what PSR version is supported by your panel, it likely
that a notebook shipped with Skylake will have panel that supports only
PSR1 so that patch has no effect on your machine.

sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
Sink support: yes [0x01]

Only if you have 0x03 your panel have support for PSR2.

Or check your dmesg:
[drm:intel_psr_init_dpcd [i915]] eDP panel supports PSR version 1

> 
> James
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Thu, 2019-07-11 at 20:25 +0000, Souza, Jose wrote:
> On Thu, 2019-07-11 at 13:11 -0700, James Bottomley wrote:
> > On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote:
> > > Quoting James Bottomley (2019-06-29 19:56:52)
> > > > The symptoms are really weird: the screen image is locked in
> > > > place.  The machine is still functional and if I log in over
> > > > the network can do anything I like, including killing the X
> > > > server and the display will never alter.  It also seems that
> > > > the system is accepting keyboard input because when it freezes
> > > > I can cat information to a file (if the mouse was over an
> > > > xterm) and verify over the network the file contents. Nothing
> > > > unusual appears in dmesg when the lockup happens.
> > > > 
> > > > The last kernel I booted successfully on the system was 5.0, so
> > > > I'll try compiling 5.1 to narrow down the changes.
> > > 
> > > It's likely this is panel self-refresh going haywire.
> > > 
> > > commit 8f6e87d6d561f10cfa48a687345512419839b6d8
> > > Author: José Roberto de Souza <jose.souza@intel.com>
> > > Date:   Thu Mar 7 16:00:50 2019 -0800
> > > 
> > >     drm/i915: Enable PSR2 by default
> > > 
> > >     The support for PSR2 was polished, IGT tests for PSR2 was
> > > added and
> > >     it was tested performing regular user workloads like
> > > browsing,
> > >     editing documents and compiling Linux, so it is time to
> > > enable it by
> > >     default and enjoy even more power-savings.
> > > 
> > > Temporary workaround would be to set i915.enable_psr=0
> > 
> > It looks plausible.  I have to say I was just about to mark a
> > bisect containing this as good, but that probably reflects my
> > difficulty
> > reproducing the issue.
> 
> Take at look of what PSR version is supported by your panel, it
> likely that a notebook shipped with Skylake will have panel that
> supports only PSR1 so that patch has no effect on your machine.
> 
> sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink support: yes [0x01]

It says

Sink support: yes [0x01]
PSR mode: PSR1 enabled
Source PSR ctl: enabled [0x81f00726]
Source PSR status: IDLE [0x04010212]
Busy frontbuffer bits: 0x00000000


I've also updated to the released 5.2 kernel and am running with the
debug parameters you requested ... but so far no reproduction.

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

On Thu, 2019-07-11 at 13:28 -0700, James Bottomley wrote:
> I've also updated to the released 5.2 kernel and am running with the
> debug parameters you requested ... but so far no reproduction.

OK, it's happened.  I've attached the dmesg (it's 4MB uncompressed). 
Is there any other output you'd like from the machine?  I've got an ssh
session into it so I can try anything.

James

[-- Attachment #2: dmesg.txt.gz --]
[-- Type: application/gzip, Size: 241733 bytes --]

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

On Thu, 2019-07-11 at 14:57 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 13:28 -0700, James Bottomley wrote:
> > I've also updated to the released 5.2 kernel and am running with
> > the
> > debug parameters you requested ... but so far no reproduction.
> 
> OK, it's happened.  I've attached the dmesg (it's 4MB uncompressed). 
> Is there any other output you'd like from the machine?  I've got an
> ssh
> session into it so I can try anything.

Thanks, could you also share the output of this after the screen
freeze?

/sys/kernel/debug/dri/0/i915_edp_psr_status
/sys/kernel/debug/dri/0/i915_display_info
/sys/kernel/debug/dri/0/i915_dmc_info
/sys/kernel/debug/pmc_core/package_cstate_show

It eventually comes back from screen freeze? Like moving the mouse or
typing brings it back?

> 
> James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Thu, 2019-07-11 at 22:26 +0000, Souza, Jose wrote:
> On Thu, 2019-07-11 at 14:57 -0700, James Bottomley wrote:
> > On Thu, 2019-07-11 at 13:28 -0700, James Bottomley wrote:
> > > I've also updated to the released 5.2 kernel and am running with
> > > the
> > > debug parameters you requested ... but so far no reproduction.
> > 
> > OK, it's happened.  I've attached the dmesg (it's 4MB
> > uncompressed). 
> > Is there any other output you'd like from the machine?  I've got an
> > ssh session into it so I can try anything.
> 
> Thanks, could you also share the output of this after the screen
> freeze?
> 
> /sys/kernel/debug/dri/0/i915_edp_psr_status
> /sys/kernel/debug/dri/0/i915_display_info
> /sys/kernel/debug/dri/0/i915_dmc_info
> /sys/kernel/debug/pmc_core/package_cstate_show

jarvis:~ # for f in `cat ~/tmp.txt`; do echo $f; cat $f; done
/sys/kernel/debug/dri/0/i915_edp_psr_status
Sink support: yes [0x01]
PSR mode: PSR1 enabled
Source PSR ctl: disabled [0x01f00726]
Source PSR status: IDLE [0x04010216]
Busy frontbuffer bits: 0x00000001
/sys/kernel/debug/dri/0/i915_display_info
CRTC info
---------
CRTC 47: pipe: A, active=yes, (size=3200x1800), dither=no, bpp=24
        fb: 118, pos: 0x0, size: 3200x1800
        encoder 84: type: DDI A, connectors:
                connector 85: type: eDP-1, status: connected, mode:
                "": 0 373250 3200 3248 3280 3360 1800 1803 1808 1852
0x0 0xa
        cursor visible? yes, position (-3, 261), size 256x256, addr
0x01740000
        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no,
mode=0, scalers[1]: use=no, mode=0
        --Plane id 30: type=PRI, crtc_pos=   0x   0,
crtc_size=3200x1800, src_pos=0.0000x0.0000,
src_size=3200.0000x1800.0000, format=XR24 little-endian (0x34325258),
rotation=0 (0x00000001)
        --Plane id 37: type=OVL, crtc_pos=   0x   0,
crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000,
format=N/A, rotation=0 (0x00000001)
        --Plane id 44: type=CUR, crtc_pos=  -3x 261, crtc_size= 256x
256, src_pos=0.0000x0.0000, src_size=256.0000x256.0000, format=AR24
little-endian (0x34325241), rotation=0 (0x00000001)
        underrun reporting: cpu=yes pch=yes 
CRTC 65: pipe: B, active=yes, (size=1600x1200), dither=no, bpp=24
        fb: 118, pos: 0x0, size: 3200x1800
        encoder 90: type: DDI B, connectors:
                connector 91: type: DP-1, status: connected, mode:
                "": 0 162000 1600 1664 1856 2160 1200 1201 1204 1250
0x0 0x5
        cursor visible? yes, position (-3, 261), size 256x256, addr
0x017c0000
        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no,
mode=0, scalers[1]: use=no, mode=0
        --Plane id 48: type=PRI, crtc_pos=   0x   0,
crtc_size=1600x1200, src_pos=0.0000x0.0000,
src_size=1600.0000x1200.0000, format=XR24 little-endian (0x34325258),
rotation=0 (0x00000001)
        --Plane id 55: type=OVL, crtc_pos=   0x   0,
crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000,
format=N/A, rotation=0 (0x00000001)
        --Plane id 62: type=CUR, crtc_pos=  -3x 261, crtc_size= 256x
256, src_pos=0.0000x0.0000, src_size=256.0000x256.0000, format=AR24
little-endian (0x34325241), rotation=0 (0x00000001)
        underrun reporting: cpu=yes pch=yes 
CRTC 83: pipe: C, active=no, (size=0x0), dither=no, bpp=0
        underrun reporting: cpu=yes pch=yes 

Connector info
--------------
connector 85: type eDP-1, status: connected
        physical dimensions: 290x170mm
        subpixel order: Unknown
        CEA rev: 0
        DPCD rev: 12
        audio support: no
        fixed mode:
                "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803
1808 1852 0x48 0xa
        DP branch device present: no
        modes:
                "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803
1808 1852 0x48 0xa
                "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803
1808 1852 0x40 0xa
connector 91: type DP-1, status: connected
        physical dimensions: 430x320mm
        subpixel order: Unknown
        CEA rev: 0
        DPCD rev: 12
        audio support: no
        DP branch device present: yes
                Type: VGA
                ID: 
                HW: 0.0
                SW: 1.0
        modes:
                "1600x1200": 60 162000 1600 1664 1856 2160 1200 1201
1204 1250 0x48 0x5
                "1400x1050": 75 156000 1400 1504 1648 1896 1050 1053
1057 1099 0x40 0x6
                "1400x1050": 60 121750 1400 1488 1632 1864 1050 1053
1057 1089 0x40 0x6
                "1280x1024": 75 135000 1280 1296 1440 1688 1024 1025
1028 1066 0x40 0x5
                "1280x1024": 60 108000 1280 1328 1440 1688 1024 1025
1028 1066 0x40 0x5
                "1280x960": 60 108000 1280 1376 1488 1800 960 961 964
1000 0x40 0x5
                "1152x864": 75 108000 1152 1216 1344 1600 864 865 868
900 0x40 0x5
                "1024x768": 75 78750 1024 1040 1136 1312 768 769 772
800 0x40 0x5
                "1024x768": 70 75000 1024 1048 1184 1328 768 771 777
806 0x40 0xa
                "1024x768": 60 65000 1024 1048 1184 1344 768 771 777
806 0x40 0xa
                "832x624": 75 57284 832 864 928 1152 624 625 628 667
0x40 0xa
                "800x600": 75 49500 800 816 896 1056 600 601 604 625
0x40 0x5
                "800x600": 72 50000 800 856 976 1040 600 637 643 666
0x40 0x5
                "800x600": 60 40000 800 840 968 1056 600 601 605 628
0x40 0x5
                "800x600": 56 36000 800 824 896 1024 600 601 603 625
0x40 0x5
                "640x480": 75 31500 640 656 720 840 480 481 484 500
0x40 0xa
                "640x480": 73 31500 640 664 704 832 480 489 492 520
0x40 0xa
                "640x480": 67 30240 640 704 768 864 480 483 486 525
0x40 0xa
                "640x480": 60 25175 640 656 752 800 480 490 492 525
0x40 0xa
                "720x400": 70 28320 720 738 846 900 400 412 414 449
0x40 0x6
connector 98: type HDMI-A-1, status: disconnected
connector 105: type DP-2, status: disconnected
connector 111: type HDMI-A-2, status: disconnected
/sys/kernel/debug/dri/0/i915_dmc_info
fw loaded: yes
path: i915/skl_dmc_ver1_27.bin
version: 1.27
DC3 -> DC5 count: 1226
DC5 -> DC6 count: 0
program base: 0x09004040
ssp base: 0x00002fc0
htp: 0x00b40068
/sys/kernel/debug/pmc_core/package_cstate_show
Package C2 : 0x5055eddc7d0
Package C3 : 0xee561ada80
Package C6 : 0xb038cdcfd0
Package C7 : 0x195c61800
Package C8 : 0x8a5a9fd25a0
Package C9 : 0x0
Package C10 : 0x0

> It eventually comes back from screen freeze? Like moving the mouse or
> typing brings it back?

No, it seems to be frozen for all time (at least until I got bored
waiting, which was probably 20 minutes).  Even if I reboot the machine,
the current screen state stays until the system powers off.

I've actually got a VGA display plugged in over a USB-C to VGA
converter and that's working fine in mirrored mode even as the panel is
completely frozen.

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> On Thu, 2019-07-11 at 22:26 +0000, Souza, Jose wrote:
> > It eventually comes back from screen freeze? Like moving the mouse or
> > typing brings it back?
> 
> No, it seems to be frozen for all time (at least until I got bored
> waiting, which was probably 20 minutes).  Even if I reboot the machine,
> the current screen state stays until the system powers off.

As I mentioned earlier, a suspend/resume cycle unfreezes the screen.

And I seem to remember that, if the gnome screen-locking eventually kicks in,
unlocking the screen still works, as the screen then isn't frozen anymore.

Thanks,


Paul Bolle

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote:
> James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> > On Thu, 2019-07-11 at 22:26 +0000, Souza, Jose wrote:
> > > It eventually comes back from screen freeze? Like moving the
> > > mouse or
> > > typing brings it back?
> > 
> > No, it seems to be frozen for all time (at least until I got bored
> > waiting, which was probably 20 minutes).  Even if I reboot the
> > machine,
> > the current screen state stays until the system powers off.
> 
> As I mentioned earlier, a suspend/resume cycle unfreezes the screen.
> 
> And I seem to remember that, if the gnome screen-locking eventually
> kicks in,
> unlocking the screen still works, as the screen then isn't frozen
> anymore.
> 
> Thanks,

Thanks for all the information Paul.

Could test with the patch attached?

If the issue happens again could send the output of:

/sys/kernel/debug/dri/0/eDP-1/i915_psr_sink_status
/sys/kernel/debug/dri/0/i915_edp_psr_status

Thanks so much for all the help

> 
> 
> Paul Bolle
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-hack-drm-i915-psr-Always-set-PSR1-training-times-to-.patch --]
[-- Type: text/x-patch; name="0001-hack-drm-i915-psr-Always-set-PSR1-training-times-to-.patch", Size: 1330 bytes --]

From ee495e2e879e718183d1b65af37393b535eeb966 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Roberto=20de=20Souza?= <jose.souza@intel.com>
Date: Thu, 11 Jul 2019 16:19:12 -0700
Subject: [PATCH] hack: drm/i915/psr: Always set PSR1 training times to max
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
---
 drivers/gpu/drm/i915/intel_psr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 963663ba0edf..83ca26e119b6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -444,6 +444,7 @@ static u32 intel_psr1_get_tp_time(struct intel_dp *intel_dp)
 	if (INTEL_GEN(dev_priv) >= 11)
 		val |= EDP_PSR_TP4_TIME_0US;
 
+	/*
 	if (dev_priv->vbt.psr.tp1_wakeup_time_us == 0)
 		val |= EDP_PSR_TP1_TIME_0us;
 	else if (dev_priv->vbt.psr.tp1_wakeup_time_us <= 100)
@@ -461,6 +462,9 @@ static u32 intel_psr1_get_tp_time(struct intel_dp *intel_dp)
 		val |= EDP_PSR_TP2_TP3_TIME_500us;
 	else
 		val |= EDP_PSR_TP2_TP3_TIME_2500us;
+	*/
+	val |= EDP_PSR_TP1_TIME_2500us;
+	val |= EDP_PSR_TP2_TP3_TIME_2500us;
 
 	if (intel_dp_source_supports_hbr2(intel_dp) &&
 	    drm_dp_tps3_supported(intel_dp->dpcd))
-- 
2.22.0

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Thu, 2019-07-11 at 23:28 +0000, Souza, Jose wrote:
> On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote:
> > James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> > > On Thu, 2019-07-11 at 22:26 +0000, Souza, Jose wrote:
> > > > It eventually comes back from screen freeze? Like moving the
> > > > mouse or typing brings it back?
> > > 
> > > No, it seems to be frozen for all time (at least until I got
> > > bored waiting, which was probably 20 minutes).  Even if I reboot
> > > the machine, the current screen state stays until the system
> > > powers off.
> > 
> > As I mentioned earlier, a suspend/resume cycle unfreezes the
> > screen.
> > 
> > And I seem to remember that, if the gnome screen-locking eventually
> > kicks in, unlocking the screen still works, as the screen then
> > isn't frozen anymore.
> > 
> > Thanks,
> 
> Thanks for all the information Paul.
> 
> Could test with the patch attached?

Applied and running with it now.

> If the issue happens again could send the output of:
> 
> /sys/kernel/debug/dri/0/eDP-1/i915_psr_sink_status
> /sys/kernel/debug/dri/0/i915_edp_psr_status
> 
> Thanks so much for all the help

Sure,

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Thu, 2019-07-11 at 16:40 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 23:28 +0000, Souza, Jose wrote:
> > On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote:
> > > James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> > > > On Thu, 2019-07-11 at 22:26 +0000, Souza, Jose wrote:
> > > > > It eventually comes back from screen freeze? Like moving the
> > > > > mouse or typing brings it back?
> > > > 
> > > > No, it seems to be frozen for all time (at least until I got
> > > > bored waiting, which was probably 20 minutes).  Even if I
> > > > reboot the machine, the current screen state stays until the
> > > > system powers off.
> > > 
> > > As I mentioned earlier, a suspend/resume cycle unfreezes the
> > > screen.
> > > 
> > > And I seem to remember that, if the gnome screen-locking
> > > eventually kicks in, unlocking the screen still works, as the
> > > screen then isn't frozen anymore.
> > > 
> > > Thanks,
> > 
> > Thanks for all the information Paul.
> > 
> > Could test with the patch attached?
> 
> Applied and running with it now.

It has survived 6h without manifesting the regression.  Starting again
to try a whole day.

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

James Bottomley schreef op vr 12-07-2019 om 07:19 [-0700]:
> It has survived 6h without manifesting the regression.  Starting again
> to try a whole day.

And I'm currently at four hours without a screen freeze. Which is much, much
longer than I was able to achieve without the hack applied.


Paul Bolle

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

Hi James and Paul

So the issue did not happened again with the patch applied?

If you still have the kernel 5.1 installed could you share your
/sys/kernel/debug/dri/0/i915_edp_psr_status with the older kernel?
We want to check if training values changed between kernel versions.

On Fri, 2019-07-12 at 16:28 +0200, Paul Bolle wrote:
> James Bottomley schreef op vr 12-07-2019 om 07:19 [-0700]:
> > It has survived 6h without manifesting the regression.  Starting
> > again
> > to try a whole day.
> 
> And I'm currently at four hours without a screen freeze. Which is
> much, much
> longer than I was able to achieve without the hack applied.
> 
> 
> Paul Bolle
> 

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Hi Jose,

Souza, Jose schreef op ma 15-07-2019 om 21:03 [+0000]:
> So the issue did not happened again with the patch applied?

Not in the three days that I've been running 5.2 kernels with the hack applied
(so that should be about twelve hours of proper uptime).

> If you still have the kernel 5.1 installed could you share your
> /sys/kernel/debug/dri/0/i915_edp_psr_status with the older kernel?
> We want to check if training values changed between kernel versions.

Sure. On 5.1.17 I get:
    Sink support: yes [0x01]
    PSR mode: PSR1 enabled
    Source PSR ctl: enabled [0x81f00626]
    Source PSR status: IDLE [0x040b0001]
    Busy frontbuffer bits: 0x00000000

And, in case you need it, on 5.2.1+hack I get:
    Sink support: yes [0x01]
    PSR mode: PSR1 enabled
    Source PSR ctl: enabled [0x81f00626]
    Source PSR status: IDLE [0x04030006]
    Busy frontbuffer bits: 0x00000000

Hope this helps,


Paul

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Thanks Paul

Paul and James could you test this final solution(at least for 5.2)?
Please revert the hack patch and apply this one.

Thanks


On Mon, 2019-07-15 at 23:34 +0200, Paul Bolle wrote:
> Hi Jose,
> 
> Souza, Jose schreef op ma 15-07-2019 om 21:03 [+0000]:
> > So the issue did not happened again with the patch applied?
> 
> Not in the three days that I've been running 5.2 kernels with the
> hack applied
> (so that should be about twelve hours of proper uptime).
> 
> > If you still have the kernel 5.1 installed could you share your
> > /sys/kernel/debug/dri/0/i915_edp_psr_status with the older kernel?
> > We want to check if training values changed between kernel
> > versions.
> 
> Sure. On 5.1.17 I get:
>     Sink support: yes [0x01]
>     PSR mode: PSR1 enabled
>     Source PSR ctl: enabled [0x81f00626]
>     Source PSR status: IDLE [0x040b0001]
>     Busy frontbuffer bits: 0x00000000
> 
> And, in case you need it, on 5.2.1+hack I get:
>     Sink support: yes [0x01]
>     PSR mode: PSR1 enabled
>     Source PSR ctl: enabled [0x81f00626]
>     Source PSR status: IDLE [0x04030006]
>     Busy frontbuffer bits: 0x00000000
> 
> Hope this helps,
> 
> 
> Paul
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Revert-drm-i915-vbt-Parse-and-use-the-new-field-with.patch --]
[-- Type: text/x-patch; name="0001-Revert-drm-i915-vbt-Parse-and-use-the-new-field-with.patch", Size: 3981 bytes --]

From 5d4fce9889e25828ee35481a09929e8ee616c933 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Roberto=20de=20Souza?= <jose.souza@intel.com>
Date: Tue, 16 Jul 2019 09:26:08 -0700
Subject: [PATCH] Revert "drm/i915/vbt: Parse and use the new field with PSR2
 TP2/3 wakeup time"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This patch is causing PSR_CTL_TP2_TP3 to be set to
PSR_TP2_TP3_TIME_0us while VBT have a different value causing screen
freezing after exiting PSR.

For now lets just revert it and later I will bring it back fixed.

This reverts commit 88a0d9606aff09d2b1c5dbe95a9df9dac44e79b6.

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h       |  1 -
 drivers/gpu/drm/i915/intel_bios.c     | 25 -------------------------
 drivers/gpu/drm/i915/intel_psr.c      |  8 ++++----
 drivers/gpu/drm/i915/intel_vbt_defs.h |  3 ---
 4 files changed, 4 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 066fd2a12851..d37262aa16ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1013,7 +1013,6 @@ struct intel_vbt_data {
 		enum psr_lines_to_wait lines_to_wait;
 		int tp1_wakeup_time_us;
 		int tp2_tp3_wakeup_time_us;
-		int psr2_tp2_tp3_wakeup_time_us;
 	} psr;
 
 	struct {
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index 1dc8d03ff127..455cc07392af 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -760,31 +760,6 @@ parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
 		dev_priv->vbt.psr.tp1_wakeup_time_us = psr_table->tp1_wakeup_time * 100;
 		dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = psr_table->tp2_tp3_wakeup_time * 100;
 	}
-
-	if (bdb->version >= 226) {
-		u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
-
-		wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
-		switch (wakeup_time) {
-		case 0:
-			wakeup_time = 500;
-			break;
-		case 1:
-			wakeup_time = 100;
-			break;
-		case 3:
-			wakeup_time = 50;
-			break;
-		default:
-		case 2:
-			wakeup_time = 2500;
-			break;
-		}
-		dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us = wakeup_time;
-	} else {
-		/* Reusing PSR1 wakeup time for PSR2 in older VBTs */
-		dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us = dev_priv->vbt.psr.tp2_tp3_wakeup_time_us;
-	}
 }
 
 static void parse_dsi_backlight_ports(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 963663ba0edf..3926f4bf05f6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -523,12 +523,12 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 
 	val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
 
-	if (dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us >= 0 &&
-	    dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us <= 50)
+	if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us >= 0 &&
+	    dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 50)
 		val |= EDP_PSR2_TP2_TIME_50us;
-	else if (dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us <= 100)
+	else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
 		val |= EDP_PSR2_TP2_TIME_100us;
-	else if (dev_priv->vbt.psr.psr2_tp2_tp3_wakeup_time_us <= 500)
+	else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
 		val |= EDP_PSR2_TP2_TIME_500us;
 	else
 		val |= EDP_PSR2_TP2_TIME_2500us;
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h
index fdbbb9a53804..bf3662ad5fed 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -772,9 +772,6 @@ struct psr_table {
 	/* TP wake up time in multiple of 100 */
 	u16 tp1_wakeup_time;
 	u16 tp2_tp3_wakeup_time;
-
-	/* PSR2 TP2/TP3 wakeup time for 16 panels */
-	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 struct bdb_psr {
-- 
2.22.0

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Hi Jose,

Souza, Jose schreef op di 16-07-2019 om 16:32 [+0000]:
> Paul and James could you test this final solution(at least for 5.2)?
> Please revert the hack patch and apply this one.

I've just reached a day of uptime with your revert. (The proper uptime is just
a fraction of a day, this being a laptop.) Anyhow, no screen freezes occurred
during this day.

So feel free to add my Tested-by tag to your revert. But please don't forget
that James earned a Reported-by tag.

Thanks,


Paul Bolle

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[James Bottomley]

On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> Hi Jose,
> 
> Souza, Jose schreef op di 16-07-2019 om 16:32 [+0000]:
> > Paul and James could you test this final solution(at least for
> > 5.2)? Please revert the hack patch and apply this one.
> 
> I've just reached a day of uptime with your revert. (The proper
> uptime is just a fraction of a day, this being a laptop.) Anyhow, no
> screen freezes occurred during this day.

I'm afraid my status is that I'm in Tokyo doing conference
presentations (and kernel demos) so I'm a bit reluctant to mess with my
setup until I finish everything on Friday, but I will test it after
then, promise.

> So feel free to add my Tested-by tag to your revert. But please don't
> forget that James earned a Reported-by tag.

Thanks,

James

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Hi Jose,

James Bottomley schreef op do 18-07-2019 om 06:29 [+0900]:
> On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> > I've just reached a day of uptime with your revert. (The proper
> > uptime is just a fraction of a day, this being a laptop.) Anyhow, no
> > screen freezes occurred during this day.
> 
> I'm afraid my status is that I'm in Tokyo doing conference
> presentations (and kernel demos) so I'm a bit reluctant to mess with my
> setup until I finish everything on Friday, but I will test it after
> then, promise.

By now I'm testing this for a week (currently on top of 5.2.2). Still no
freezes whatsoever. 

So what's the status of this revert? Unless this is something pretty obscure
that for some odd reason only James and I are able to hit it would be nice to
get this into stable before the main distros switch over to 5.2.y.

Thanks,


Paul Bolle

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

Hi Paul

We fixed the patch instead of revert it, it is merged on drm-tip and on
his way to linux-stable.

Huge thanks again

On Wed, 2019-07-24 at 21:23 +0200, Paul Bolle wrote:
> Hi Jose,
> 
> James Bottomley schreef op do 18-07-2019 om 06:29 [+0900]:
> > On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> > > I've just reached a day of uptime with your revert. (The proper
> > > uptime is just a fraction of a day, this being a laptop.) Anyhow,
> > > no
> > > screen freezes occurred during this day.
> > 
> > I'm afraid my status is that I'm in Tokyo doing conference
> > presentations (and kernel demos) so I'm a bit reluctant to mess
> > with my
> > setup until I finish everything on Friday, but I will test it after
> > then, promise.
> 
> By now I'm testing this for a week (currently on top of 5.2.2). Still
> no
> freezes whatsoever. 
> 
> So what's the status of this revert? Unless this is something pretty
> obscure
> that for some odd reason only James and I are able to hit it would be
> nice to
> get this into stable before the main distros switch over to 5.2.y.
> 
> Thanks,
> 
> 
> Paul Bolle
> 

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Hi Jose,

Souza, Jose schreef op wo 24-07-2019 om 20:27 [+0000]:
> We fixed the patch instead of revert it, it is merged on drm-tip and on
> his way to linux-stable.

That should be (drm-tip) commit b5ea9c933700 ("drm/i915/vbt: Fix VBT parsing
for the PSR section"). Correct?

> Huge thanks again

You're welcome.


Paul Bolle

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

On Wed, 2019-07-24 at 22:39 +0200, Paul Bolle wrote:
> Hi Jose,
> 
> Souza, Jose schreef op wo 24-07-2019 om 20:27 [+0000]:
> > We fixed the patch instead of revert it, it is merged on drm-tip
> > and on
> > his way to linux-stable.
> 
> That should be (drm-tip) commit b5ea9c933700 ("drm/i915/vbt: Fix VBT
> parsing
> for the PSR section"). Correct?

Exactly

> 
> > Huge thanks again
> 
> You're welcome.
> 
> 
> Paul Bolle
> 

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Souza, Jose]

Fix released on Linux 5.2.8

On Wed, 2019-07-24 at 22:39 +0200, Paul Bolle wrote:
> Hi Jose,
> 
> Souza, Jose schreef op wo 24-07-2019 om 20:27 [+0000]:
> > We fixed the patch instead of revert it, it is merged on drm-tip
> > and on
> > his way to linux-stable.
> 
> That should be (drm-tip) commit b5ea9c933700 ("drm/i915/vbt: Fix VBT
> parsing
> for the PSR section"). Correct?
> 
> > Huge thanks again
> 
> You're welcome.
> 
> 
> Paul Bolle
> 

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

[Paul Bolle]

Souza, Jose schreef op vr 09-08-2019 om 17:16 [+0000]:
> Fix released on Linux 5.2.8

Linux 5.2.8 doesn't have the pretty obvious freezes so this fix works for me
too. Thanks for letting me know!


Paul Bolle