Bug 110511

and happens with current nightly too

Stan, any help here? I see hotplug events in dmesg.

Ping? With 5.0 and up PSR seems to be messing with the results, but disabling it doesn't fix the original issue.

If I can help at all sorting this one out let me know. logs, ssh access to the machine, you name it.

Created attachment 144287 [details] [review]
[PATCH] drm/i915: Dump the full ESI register block on short pulse

This patch might help us figure out what the sink is trying to tell us.

thanks Ville, here's a kernel deb based on drm-intel-next-fixes-2019-05-15 plus this patch

http://aaltoset.kapsi.fi/xps13-flicker/

Paulo, please install, boot with drm.debug=14 and attach dmesg

Created attachment 144318 [details]
Timo rc5+ kernel dmesg

Timo, I have attached the dmesg with rc5+ kernel you asked me to test.

[    4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00 00 00 00 00 81 01

According to that the sink thinks everything is fine, so no idea why generates short hpds.

Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the kernel cmdline.

(In reply to Ville Syrjala from comment #9)
> [    4.550517] [drm:intel_dp_hpd_pulse [i915]] ESI: 41 00 00 00 00 00 00 00
> 00 00 00 00 81 01
> 
> According to that the sink thinks everything is fine, so no idea why
> generates short hpds.
> 
> Could be some kind of PSR fail. Please try passing i915.enable_psr=0 to the
> kernel cmdline.

enable_psr=0 does not help. Posting dmesg with enable_psr=0.

Created attachment 144319 [details]
rc5+ kernel with enable_psr=0

In https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1826125/comments/53 it is mentioned that the same laptop with PCLinuxOS with 5.0.2 doesn't flicker. Is it worth it getting some data from there perhaps?

(In reply to Paulo J. Matos from comment #11)
> Created attachment 144319 [details]
> rc5+ kernel with enable_psr=0

The log was cut off so couldn't see that PSR was in fact disabled. You can fix that by passing eg. log_buf_len=2M to the kernel cmdline.

Anyways, after a second glance at the logs I see the sink does sometimes indicate that the receiver port was not synchronized. Not sure why the failure manifests at that level with the link otherwise being reported as stable. Looks like we could try to reduce the link rate a bit and still have enough bandwidth for the 4k@60 mode. I'll attach something to that effect.

Created attachment 144325 [details] [review]
[PATCH] hack: Disable 5.4ghz link rate for skl

This should drop the link rate to 4.32ghz, which is the lowest we can go with this panel. Please test.

Hmm, yes 4.32 is what the BIOS uses, so this might even help:
[    1.391106] [drm:intel_dump_pipe_config [i915]] port clock: 432000, pipe src size: 3840x2160, pixel rate 533299

Hmm. That probably means this is a victim of commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"), which I think would have picked the lower link rate for us.

Yes, eDP revision seems to be 1.4a:
[    1.385017] [drm:intel_dp_init_connector [i915]] eDP DPCD: 04 92 a5
so I believe that is indeed what would have happened.

new kernel build with the hack in

http://aaltoset.kapsi.fi/xps13-flicker/

I can confirm that with Timo's kernel, with Ville's patch it all works smoothly.
Great job guys! Thanks so much for the support. I will keep using this kernel until upstream is fixed. Can you please update this bug once a proper fix hits upstream?

Can we get a test with just 'git revert f11cb1c19ad0' ?

kernel -10 with the revert availabe behind the same url

but reverting it would reopen 109959

Paulo, please test kernel build -10

Apologies, I dropped the ball on this one. I will do that today.

I can confirm that the kernel with the reverted commit works. Apologies for the delay.

Hi all,

I have been following this bug report for a while - I just wanted to check in on status. Will the fix be rolled out now that Paulo has confirmed the working kernel version?

Created attachment 144765 [details] [review]
[PATCH] drm/i915: Try to use fast+narrow link on eDP again and fall  back to the old max strategy on failure

Here's an attempt at fixing this without horribly breaking a bunch of other eDP panels. Would appreciate if people can test this.

Also available here in git form:
git://github.com/vsyrjala/linux.git dp_retry_max_vs_optim

Timo isn't around, please test this kernel:
https://people.canonical.com/~khfeng/bfo110511/

I will take a look a this later. Apologies but I am on and off summer holidays these days.

According to 
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1827790/comments/19

This issue is fixed by "dp_retry_max_vs_optim" branch.

(In reply to Paulo J. Matos from comment #26)
> I will take a look a this later. Apologies but I am on and off summer
> holidays these days.

Paulo, is this issue still reproducible? any updates here?

(In reply to Kai-Heng Feng from comment #25)
> Timo isn't around, please test this kernel:
> https://people.canonical.com/~khfeng/bfo110511/

This kernel works.

(In reply to Paulo J. Matos from comment #29)
> (In reply to Kai-Heng Feng from comment #25)
> > Timo isn't around, please test this kernel:
> > https://people.canonical.com/~khfeng/bfo110511/
> 
> This kernel works.

Can we close this bug?

Created attachment 145270 [details]
attachment-3420-0.html

It depends if the fix in the kernel I tested is upstream, I guess. Kai? 

On 5 September 2019 19:58:19 CEST, bugzilla-daemon@freedesktop.org wrote:
>https://bugs.freedesktop.org/show_bug.cgi?id=110511
>
>--- Comment #30 from Lakshmi <lakshminarayana.vudum@intel.com> ---
>(In reply to Paulo J. Matos from comment #29)
>> (In reply to Kai-Heng Feng from comment #25)
>> > Timo isn't around, please test this kernel:
>> > https://people.canonical.com/~khfeng/bfo110511/
>> 
>> This kernel works.
>
>Can we close this bug?
>
>-- 
>You are receiving this mail because:
>You reported the bug.

The fix is nowhere yet. And judging from the ubuntu bug it may not even work :(

I've built a kernel here based on 5.3 plus the patch:

https://aaltoset.kapsi.fi/lp1826125 

and it was tested on the LP bug and found to be working

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/272.