[Bug 106182] [Intel NUC] HDMI1 sometimes stops working after resuming from s3 (a single monitor setup)

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu May 10 11:45:19 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=106182

--- Comment #33 from Imre Deak <imre.deak at intel.com> ---
(In reply to Robert Liu from comment #32)
> Re-run the stress test and make the issue happens.
> Then use the commands in the comment #29.
> The commands bring the screen back.

Ok, thanks for trying. So it looks like we're seeing the same issue and we have
atm one way to recover from the stuck state. This tells me that the source DDI
port is outputting a proper video signal, but the retimer chip doesn't forward
it to the connector in the stuck state.

For a proper solution (also one that works for the second HDMI port) I'd still
like to find the root cause for how the chip gets to the stuck state in the
first place. I'll follow up if I find out anything.

> 
> root at u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
> root at u-NUC7PJYH:~# echo $v
> 3
> root at u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
> root at u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
> 11
> root at u-NUC7PJYH:~#  
> root at u-NUC7PJYH:~# sleep 0.1
> root at u-NUC7PJYH:~# 
> root at u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
> root at u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
> (screen is on)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180510/fba0c392/attachment.html>


More information about the intel-gfx-bugs mailing list