Bug 105887 (ford) - [GLK] no signal after switch resolution from 1080p@23.98
Summary: [GLK] no signal after switch resolution from 1080p@23.98
Status: CLOSED FIXED
Alias: ford
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Radhakrishna Sripada
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-04 16:37 UTC by Piotr Kasp.
Modified: 2018-10-24 07:49 UTC (History)
7 users (show)

See Also:
i915 platform: GLK
i915 features: display/HDMI


Attachments
drm-Print-HDMI-2.0-support-from-monitor (2.59 KB, application/mbox)
2018-04-04 16:40 UTC, Piotr Kasp.
no flags Details
drm-i915-debug-Allow-4-2-0-also-modes-too (1.10 KB, application/mbox)
2018-04-04 16:41 UTC, Piotr Kasp.
no flags Details
dmesg log booting Ubuntu 18.04 Server (2.13 MB, text/plain)
2018-05-07 12:00 UTC, Brunnis
no flags Details
Ubuntu 18.04 Linux kodi 4.17.0-994-generic #201805072200 SMP (422.91 KB, text/plain)
2018-05-08 21:08 UTC, Erik Sandlund
no flags Details
Log when TV is switched off and on (56.83 KB, text/plain)
2018-05-08 21:15 UTC, Erik Sandlund
no flags Details
Scope shot of input and output of level shifter (26.54 KB, image/png)
2018-05-25 23:14 UTC, Clinton Taylor
no flags Details
kern.log_Patch_v4_Kernel_v4.18-rc3 (155.03 MB, text/plain)
2018-07-05 05:42 UTC, fatez
no flags Details
syslog_Patch_v4_Kernel_v4.18-rc3 (366.45 KB, text/plain)
2018-07-05 05:43 UTC, fatez
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kasp. 2018-04-04 16:37:33 UTC
Hi 
Im owner of NUC Gemini Lake - NUC7CJY

Im used latest dam-tip kernel, mesa 18.0 and xorg rc1.19.99.903

My and others users problem is when I play some movies at 1080p@23.98
then stop and picture will back to default 1080p@50 or 2180@50 then i experienced no signal and TV or monitor :(

Here log just after boot system
http://ix.io/16yg

Here after play movie at 1080p@23.98 and stop (after that no signal at TV)
http://ix.io/16yk
Comment 1 Piotr Kasp. 2018-04-04 16:40:29 UTC
Created attachment 138595 [details]
drm-Print-HDMI-2.0-support-from-monitor
Comment 2 Piotr Kasp. 2018-04-04 16:41:36 UTC
Created attachment 138597 [details]
drm-i915-debug-Allow-4-2-0-also-modes-too
Comment 3 Piotr Kasp. 2018-04-04 16:42:54 UTC
I attached 2 patches from shashank.sharma which I got and applied for this kernel
Comment 4 Piotr Kasp. 2018-04-22 11:25:42 UTC
after some investigation, same issue exist on both port HDMI1, HDMI2

what is discovered - when signal gone after switch framerate - enough unplug HDMI cable and connect back - then signal/picture BACK

please fix that ASAP - now GEMINI lake NUC is on market and more and more people struggling with this issue which is very annoying

(same issue still exist on latest drm-tip kernel from yesterday)
Comment 5 Piotr Kasp. 2018-04-22 12:06:46 UTC
here latest log - what is interesting HDMI on boot is probing couple of times

somewhere on start showing

_add_display_info] *ERROR* YCBCR420 (also) supported =N
[    1.278596] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =N
[    1.278600] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N

later


[   88.809058] [drm:drm_add_display_info] *ERROR* ======== Shashank: Monitor 420  =============
[   88.809059] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =Y
[   88.809061] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =Y
[   88.809062] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N

i dont know if that help

here fresh log just after boot
http://ix.io/18qB

here after play file with refreshrate 23.98 and stop - signal gone
http://ix.io/18qE


andf here after reconnect HDMI cable - signal back
http://ix.io/18qF

if you neeed any more test, logs etc let me know.
Comment 6 Jani Saarinen 2018-04-22 15:21:03 UTC
Shashank, Ville, any commments?
Comment 7 Jani Saarinen 2018-04-22 15:22:10 UTC
So was this series tested on top of drm-tip? 
https://patchwork.freedesktop.org/series/36068/
Comment 8 Piotr Kasp. 2018-04-22 17:21:47 UTC
that for LSPCON - Gemini has native HDMI 2.0 ;) 
and i did tested this also nothing help.
Comment 9 ford prefect 2018-04-23 05:42:12 UTC
I have the same issue.
Comment 10 shashank.sharma@intel.com 2018-04-23 08:19:45 UTC
(In reply to Jani Saarinen from comment #6)
> Shashank, Ville, any commments?

There is something fishy with the EDID's extension blocks for this monitor. 
first probe, EDID says neither 420_only nor 420_also supported:
=============
[    1.278592] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =N
[    1.278596] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =N
[    1.278600] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N
[    1.278604] [drm:drm_add_display_info] *ERROR* ======== ====================================

second probe says 420_also modes supported but no 420_only mode:
=============
[    1.278673] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =Y
[    1.278678] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =N
[    1.278682] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N
[    1.278686] [drm:drm_add_display_info] *ERROR* ======== ====================================

and the third probe says both 420_also as well as 420_only supported:
=============
[    1.460456] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =Y
[    1.460564] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =Y
[    1.460566] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N
[    1.460567] [drm:drm_add_display_info] *ERROR* ======== ====================================

I am not sure how HF-VSDB block is changing every probe, that to in an incremental supported way :)

- Shashank
Comment 11 Piotr Kasp. 2018-04-23 14:40:25 UTC
yeah but when you look closer to logs only first probing is wrong - next few are correct.

but question is why during boot probing HDMI 3-4 or more times until system start ?

and second, why after switch refreshrate signal gone ? after reconnect HDMI cable back.


Compare to kaby lake - I saw in logs HDMI is probing only once .... 
and everything is good, also on AMLogic box - all good - same TV ...


And same problems with gemini lake has a lot people on forum kodi/Ubuntu
Comment 12 shashank.sharma@intel.com 2018-04-24 02:26:14 UTC
Can you please share your KBL logs, with these two patches and same monitor ? 

- Shashank
Comment 13 Piotr Kasp. 2018-04-26 21:42:07 UTC
here log
http://ix.io/18OA

and yes probing also few times, but at least after swithing framerate, no any issue. Only Kaby lake is affected
Comment 14 Piotr Kasp. 2018-04-26 21:47:08 UTC
And here more - slighty older kernel but also with your 2 patches
Diffrent 4K TV (OLED) and also one more log connected over AVR


(tested on kaby lake)
here connected direcly to TV
http://ix.io/WHa

here to AVR 
http://ix.io/WH8

Also EDID changing on fly - at least on first probing 
so 2 different vendors of TV: Samsung, LG and same problem
over AVR same story
Comment 15 ford prefect 2018-04-27 17:31:00 UTC
For me it is also a problem on gemini lake. I loose HDMI output while switching back to full HD at 60HZ from various frequencies.
I have an Asrock J4105-ITX and at the moment it is not really usable.
Comment 16 Brunnis 2018-05-03 07:19:32 UTC
I have this issue on my NUC7PJYH (Gemini Lake Pentium J5005) with a completely stock Ubuntu 18.04 Server installation using a Samsung 22" 1080p TV (I'll come back with the exact model number). Here's what happens:

1. When you boot the system, the boot screen ("Intel NUC") is shown, as it should be.
2. Ubuntu starts to boot up and you get to see the first lines of console print-outs.
3. However, as soon as the system loads i915 and switches mode the screen goes black. The TV reports HDMI signal lost.
4. There are two ways to recover: disconnect and reconnect the HDMI plug OR power off and then on the TV.

This TV has no such issues with the following hardware:

- Apollo Lake Pentium J4205 (using the native HDMI 1.4 output), running Ubuntu 16.10 Server or 17.10 Server
- Skylake Core i3-6100U (NUC6i3SYK) running Ubuntu 17.10 (desktop)
- Raspberry Pi 3 running Raspbian

The fact that this issue seems to be a more general one (one which you'll be able to run into just booting one of the most popular Linux distributions) makes it pretty severe.

Check the comments on this article for more people reporting this issue: http://nucblog.net/2018/04/first-major-bios-update-for-nuc7cjyh-gemini-lake-nuc/

Running DVI, i.e. a HDMI to DVI cable, to a computer monitor seems to work fine. I've not run into any black screen issues with the DVI monitors I've tried.
Comment 17 Brunnis 2018-05-03 11:21:04 UTC
I should add that this issue occurs during almost 100% of boot attempts (at least on this TV). I've booted the system many times during the past week and I believe that HDMI was lost during all boots except one.
Comment 18 fatez 2018-05-05 17:26:14 UTC
Same issue here !

Xorg Log : http://paste.ubuntu.com/p/nvBJwBp3cN/
dmesg Log : http://paste.ubuntu.com/p/Yd9crdcznH/

It is an NUCP7PJYH(2) connected to an Onkyo TX-NR676E

If i Switch from htpc to tv and from tv to HTPC i lost the signal.

is there a solutions?
Comment 19 Erik Sandlund 2018-05-05 23:10:33 UTC
Same problem for me on Ubuntu 18.04. Signal lost when xorg is loading driver. However I was able to get the signal back by running "xset s off -dpms", not been able to reproduce that though. Messed around a bit with xrandr and sometimes got signal back by lowering resolution and framerate but not consistently.
Comment 20 fatez 2018-05-06 16:30:14 UTC
guys,
I installed the kernel 4.17-rc3 and "seems" to keep the signal.
Can you give me some feedback?
Comment 21 fatez 2018-05-06 17:34:11 UTC
I spoke too soon ... not working ...
Comment 22 Piotr Kasp. 2018-05-06 22:26:22 UTC
latest drm-tip even worst no signal at all !
Comment 23 Jani Saarinen 2018-05-07 07:16:34 UTC
Ville, Imre, any help here?
Comment 24 Jani Saarinen 2018-05-07 09:58:18 UTC
Reporters, please send also dmesg with drm.debug=0x1e log_buf_len=4M?
Comment 25 Brunnis 2018-05-07 12:00:37 UTC
Created attachment 139404 [details]
dmesg log booting Ubuntu 18.04 Server

Log taken after booting Ubuntu 18.04 Server on NUC7PJYH using Samsung UE22H5005 (22" 1080p TV) as monitor. The HDMI signal was lost very shortly (1-2 seconds) after the Ubuntu boot process started (I get to see a few of the boot log printouts before the screen goes black).

Note: I turned the TV off and then on again to regain the picture after Ubuntu had booted.
Comment 26 Jani Saarinen 2018-05-07 13:15:16 UTC
Ville, Shashank, Imre, anything obvious from log provided?
Comment 27 Piotr Kasp. 2018-05-07 13:34:40 UTC
on latest drm-tip from yesterday
http://ix.io/19FW


here when i tried inject EDID
http://ix.io/19FZ


in both case no picture at all :( 
NUC updated to latest bios from 30/04/2018
and connected to TV QLED SAMSUNG 55` 4K Q7
Comment 28 Piotr Kasp. 2018-05-07 13:59:40 UTC
maybe here is problem ?

[    6.777476] [drm:drm_scdc_set_high_tmds_clock_ratio] Failed to set TMDS clock ratio: -6
[    6.777483] [drm:intel_enable_ddi] *ERROR* [CONNECTOR:101:HDMI-A-1] Failed to configure sink scrambling/TMDS bit clock ratio
[    6.777507] [drm:intel_audio_codec_enable] ELD on [CONNECTOR:101:HDMI-A-1], [ENCODER:100:DDI B]
[    6.777511] [drm:hsw_audio_codec_enable] Enable audio codec on pipe A, 40 bytes ELD
[    6.777520] [drm:audio_config_hdmi_pixel_clock] HDMI audio pixel clock setting for 594000 not found, falling back to defaults
[    6.777523] [drm:audio_config_hdmi_pixel_clock] Configuring HDMI audio for pixel clock 25200 (0x00010000)
Comment 29 Jani Saarinen 2018-05-07 14:04:03 UTC
Please look bug: https://bugs.freedesktop.org/show_bug.cgi?id=105655 as it was fixed on drm-tip already. Please try to use drm-tip.
Comment 30 Piotr Kasp. 2018-05-07 14:12:59 UTC
so not fully ;) that from log when I tried inject EDID just to check if there is any difference ... that issue not appear when I just normal boot without injecting EDID
Comment 31 Piotr Kasp. 2018-05-07 14:19:11 UTC
(In reply to Jani Saarinen from comment #29)
> Please look bug: https://bugs.freedesktop.org/show_bug.cgi?id=105655 as it
> was fixed on drm-tip already. Please try to use drm-tip.

drm-tip from yesterday  52cc80146d935aa902a3e0fc54268a99fcf68ccf
Comment 32 Ville Syrjala 2018-05-07 14:41:50 UTC
Please _attach_ the logs to the bug. Otherwise we're likely to lose them at some point.
Comment 33 fatez 2018-05-07 16:37:15 UTC
how can i do this : dmesg with drm.debug=0x1e log_buf_len=4M? ?

it's a grub parameter?
Comment 34 Brunnis 2018-05-08 07:08:54 UTC
fatez: For some reason, I could not get to the Grub menu on my installation. So, here's what I did:

1. sudo nano /etc/default/grub
2. Find the line that says GRUB_CMDLINE_LINUX="". Add the following between the quotes: drm.debug=0x1e log_buf_len=4M
   NOTE: If there's already text between the quotation marks, just add the text at the end of the quote, with a space separating it from the existing text.
3. sudo update-grub
4. Reboot and dump log to file: dmesg > dmesg.txt
Comment 35 fatez 2018-05-08 16:30:41 UTC
(In reply to Brunnis from comment #34)
> fatez: For some reason, I could not get to the Grub menu on my installation.
> So, here's what I did:
> 
> 1. sudo nano /etc/default/grub
> 2. Find the line that says GRUB_CMDLINE_LINUX="". Add the following between
> the quotes: drm.debug=0x1e log_buf_len=4M
>    NOTE: If there's already text between the quotation marks, just add the
> text at the end of the quote, with a space separating it from the existing
> text.
> 3. sudo update-grub
> 4. Reboot and dump log to file: dmesg > dmesg.txt

Here the log's whit the latest kernel (4.17-rc4)

Dmesg log : http://paste.ubuntu.com/p/HCwbkXMC42/
Xorg.0.log http://paste.ubuntu.com/p/zgQH5hKcXt/
syslog http://paste.ubuntu.com/p/ngm7Dsnkjq/
Comment 36 fatez 2018-05-08 16:34:02 UTC
(In reply to fatez from comment #35)
> (In reply to Brunnis from comment #34)
> > fatez: For some reason, I could not get to the Grub menu on my installation.
> > So, here's what I did:
> > 
> > 1. sudo nano /etc/default/grub
> > 2. Find the line that says GRUB_CMDLINE_LINUX="". Add the following between
> > the quotes: drm.debug=0x1e log_buf_len=4M
> >    NOTE: If there's already text between the quotation marks, just add the
> > text at the end of the quote, with a space separating it from the existing
> > text.
> > 3. sudo update-grub
> > 4. Reboot and dump log to file: dmesg > dmesg.txt
> 
> Here the log's whit the latest kernel (4.17-rc4)
> 
> Dmesg log : http://paste.ubuntu.com/p/HCwbkXMC42/
> Xorg.0.log http://paste.ubuntu.com/p/zgQH5hKcXt/
> syslog http://paste.ubuntu.com/p/ngm7Dsnkjq/

just to be clear : I have an NUC7PJHH(2) with 2 hdmi port;
The first HDMI is connected directly to my Samsung KS8000 (4K)
The second HDMI is connected into an SyntoAV (Onkyo that) just only for audio reason (kodi htpc)
Comment 37 Erik Sandlund 2018-05-08 21:08:00 UTC
Created attachment 139432 [details]
Ubuntu 18.04 Linux kodi 4.17.0-994-generic #201805072200 SMP
Comment 38 Erik Sandlund 2018-05-08 21:15:49 UTC
Created attachment 139433 [details]
Log when TV is switched off and on

Signal returns when switching on/off the TV.
Comment 39 fatez 2018-05-09 20:51:12 UTC
Any news? ;)
Comment 40 ford prefect 2018-05-12 06:09:10 UTC
If it helps I can try to provide more info too. But I would need some explanation how to do this, since I am a noob regarding this logs.
Again I am using an Asrock J4105-ITX with libreELEC. It is an custom build with latest Kernel by the opener Piotr Kasp.
Comment 41 Lourens 2018-05-12 21:17:46 UTC
Hi,
Another NUC7CJYH buyer/user here.

I'm having the same issue as the rest of you, but I experience it somewhat different.

My setup:
NUC7CJYH, Ubuntu 18.04 (up-to-date), Kodi 17.6.

In my case it somehow seems related to the skin:
Default skin (estuary); switching back from 24hz back to 60hz => OK!
Aeon Nox or Arctic; switching back from 24hz back to 60hz => NOT OK!

And the video type (HD/SD):
Aeon Nox or Arctic & SD content; switching back from 24hz to 60 => OK!


Maybe I somehow got lucky in those 'okay' situations, but who knows. It might be something to go on.

I'll do some more testing as soon as I can (hopefully somewhere next week)
Comment 42 fatez 2018-05-13 08:53:20 UTC
(In reply to Lourens from comment #41)
> Hi,
> Another NUC7CJYH buyer/user here.
> 
> I'm having the same issue as the rest of you, but I experience it somewhat
> different.
> 
> My setup:
> NUC7CJYH, Ubuntu 18.04 (up-to-date), Kodi 17.6.
> 
> In my case it somehow seems related to the skin:
> Default skin (estuary); switching back from 24hz back to 60hz => OK!
> Aeon Nox or Arctic; switching back from 24hz back to 60hz => NOT OK!
> 
> And the video type (HD/SD):
> Aeon Nox or Arctic & SD content; switching back from 24hz to 60 => OK!
> 
> 
> Maybe I somehow got lucky in those 'okay' situations, but who knows. It
> might be something to go on.
> 
> I'll do some more testing as soon as I can (hopefully somewhere next week)

I have the nuc7pjyh and this problem does me every time I step from HDM1 (Kodi) to HDM2 (Sky) then go back to Kodi
It's not the skin, it goes even if I stay in bash
Comment 43 Lourens 2018-05-13 14:26:36 UTC
(In reply to fatez from comment #42)
> (In reply to Lourens from comment #41)
> > Hi,
> > Another NUC7CJYH buyer/user here.
> > 
> > I'm having the same issue as the rest of you, but I experience it somewhat
> > different.
> > 
> > My setup:
> > NUC7CJYH, Ubuntu 18.04 (up-to-date), Kodi 17.6.
> > 
> > In my case it somehow seems related to the skin:
> > Default skin (estuary); switching back from 24hz back to 60hz => OK!
> > Aeon Nox or Arctic; switching back from 24hz back to 60hz => NOT OK!
> > 
> > And the video type (HD/SD):
> > Aeon Nox or Arctic & SD content; switching back from 24hz to 60 => OK!
> > 
> > 
> > Maybe I somehow got lucky in those 'okay' situations, but who knows. It
> > might be something to go on.
> > 
> > I'll do some more testing as soon as I can (hopefully somewhere next week)
> 
> I have the nuc7pjyh and this problem does me every time I step from HDM1
> (Kodi) to HDM2 (Sky) then go back to Kodi
> It's not the skin, it goes even if I stay in bash

Also here, your problem and mine (if I understand correctly) are different.
Your switching HDMI ports, again of I understand correctly, I am not switching from HDMI 1 to HDMI 2 and back. My issue is that the TV blanks when the output goes from 24hz back to 60hz.
Comment 44 fatez 2018-05-14 17:41:58 UTC
@dev 

Do you have any news for us?

:)
Comment 45 Imre Deak 2018-05-17 15:10:54 UTC
Could you all provide the followings found on the back of NUC (some may be missing):
- Product code
- Project code
- Date of manufacture

Thanks.
Comment 46 Erik Sandlund 2018-05-17 17:38:49 UTC
Product Code: BOXNUC7PJYH
Regulatory model: NUC7JY
Date of Manufacture: 03/18
(no project code)
Comment 47 Clinton Taylor 2018-05-17 20:42:04 UTC
Notes from debug: 

Issue appears to occur anytime the display switches from a 74.xxx MHz mode (23.98, 24, 29.97, 30 Hz) to a higher clock frequency (148 Mhz and 296 Mhz at 50, 59.94, and 60 Hz).

Long HPD pulse restores output at the selected resolution.

PLL programming during failure is correct based on dpll_hw_state in the logs during success and failure.

CDCLK remains constant at 316MHz.

i915_power_domain_info shows identical "Use counts" during working and non-working cases.

Reviewed GLK workaround database for similar issue. Nothing Found.
Comment 48 Piotr Kasp. 2018-05-17 21:02:16 UTC
Product Code: BOXNUC7CJYH1
Regulatory model: NUC7JY
Date of Manufacture: 02/18
(no project code)


but i think doesn't matter same problem is on asrock, MSI etc.
its looks like mess arround HDMI 2.0, i tested coffe Lake with LSPCON and there is eveything perfect.
Comment 49 Clinton Taylor 2018-05-17 21:55:05 UTC
 (In reply to Piotr Kasp. from comment #48)
> Product Code: BOXNUC7CJYH1
> Regulatory model: NUC7JY
> Date of Manufacture: 02/18
> (no project code)
> 
> 
> but i think doesn't matter same problem is on asrock, MSI etc.
> its looks like mess arround HDMI 2.0, i tested coffe Lake with LSPCON and
> there is eveything perfect.

CoffeeLake and GeminiLake use a different clock implementation. This issue appears to be a PLL enable sequence issue when switching for lower to higher clock rates. 
 
Issue does not occur if I disable 12 bpc support in the driver.

For a quick test:

In intel_hdmi.c  mothod hdmi_12bpc_possible()

add 
   return false;
Comment 50 Clinton Taylor 2018-05-17 23:04:24 UTC
(In reply to Clinton Taylor from comment #49)
>  (In reply to Piotr Kasp. from comment #48)
> > Product Code: BOXNUC7CJYH1
> > Regulatory model: NUC7JY
> > Date of Manufacture: 02/18
> > (no project code)
> > 
> > 
> > but i think doesn't matter same problem is on asrock, MSI etc.
> > its looks like mess arround HDMI 2.0, i tested coffe Lake with LSPCON and
> > there is eveything perfect.
> 
> CoffeeLake and GeminiLake use a different clock implementation. This issue

Correction, both CoffeeLake and GeminiLake use the BXT PLL code. 

> appears to be a PLL enable sequence issue when switching for lower to higher
> clock rates. 
>  
> Issue does not occur if I disable 12 bpc support in the driver.
> 
> For a quick test:
> 
> In intel_hdmi.c  mothod hdmi_12bpc_possible()
> 
> add 
>    return false;
Comment 51 Daniel Scheller 2018-05-19 13:51:28 UTC
(In reply to Clinton Taylor from comment #49)

> Issue does not occur if I disable 12 bpc support in the driver.
> 
> For a quick test:
> 
> In intel_hdmi.c  mothod hdmi_12bpc_possible()
> 
> add 
>    return false;

Using an ASRock J5005-ITX on stock Ubuntu 18.04 w/Kernel 4.15, connected to an Onkyo TX-NR509 AV receiver, which shows similar sympthoms (ie. if the resolution goes up (pixel clock rate increases) from the boot res to 1080p50 or 1080p60, the TV picture goes away/blue and the receiver says "No signal". The receiver must be power-cycled to get a picture again).

Tried the above (modified Ubuntu kernel sources accordingly, repackaged, installed and booted) - makes the issue go away with this workaround, switching from 50p/60p to 24p and back works, no "No signal". Everything else video-related remains working normally.
Comment 52 fatez 2018-05-19 18:47:18 UTC
(In reply to Daniel Scheller from comment #51)
> (In reply to Clinton Taylor from comment #49)
> 
> > Issue does not occur if I disable 12 bpc support in the driver.
> > 
> > For a quick test:
> > 
> > In intel_hdmi.c  mothod hdmi_12bpc_possible()
> > 
> > add 
> >    return false;
> 
> Using an ASRock J5005-ITX on stock Ubuntu 18.04 w/Kernel 4.15, connected to
> an Onkyo TX-NR509 AV receiver, which shows similar sympthoms (ie. if the
> resolution goes up (pixel clock rate increases) from the boot res to 1080p50
> or 1080p60, the TV picture goes away/blue and the receiver says "No signal".
> The receiver must be power-cycled to get a picture again).
> 
> Tried the above (modified Ubuntu kernel sources accordingly, repackaged,
> installed and booted) - makes the issue go away with this workaround,
> switching from 50p/60p to 24p and back works, no "No signal". Everything
> else video-related remains working normally.

Could you explain exactly how to do it? Also I use Ubuntu 18.04
Comment 53 fatez 2018-05-19 20:42:23 UTC
static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state)
{
        struct drm_i915_private *dev_priv =
                to_i915(crtc_state->base.crtc->dev);
        struct drm_atomic_state *state = crtc_state->base.state;
        struct drm_connector_state *connector_state;
        struct drm_connector *connector;
        int i;
                return false;
        if (HAS_GMCH_DISPLAY(dev_priv))
                return false;




Is this correct?
Comment 54 fatez 2018-05-19 21:39:01 UTC
(In reply to Daniel Scheller from comment #51)

I managed to compile from 0 kernel, can I ask you just the courtesy to attach here your
intel_hdmi.c patched?
Comment 55 Daniel Scheller 2018-05-20 10:25:09 UTC
(In reply to fatez from comment #52)

> Could you explain exactly how to do it? Also I use Ubuntu 18.04

As I've been asked by a few people, I've put the repo up at GitHub. The exact change I applied to intel_hdmi.c is at [1], and you can build a kernel image right from the 4.15.0-21.22-glktesting branch (see [2]).

NB: Whenever something gets added to this issue, I'll keep on adding that to that branch for testing purposes.

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/3d664ae3c8831a51139efbb5298fc27a1bee4950
[2] https://github.com/herrnst/ubuntu-bionic-kernel/commits/4.15.0-21.22-glktesting
Comment 56 fatez 2018-05-20 10:48:48 UTC
(In reply to Daniel Scheller from comment #55)
> (In reply to fatez from comment #52)
> 
> > Could you explain exactly how to do it? Also I use Ubuntu 18.04
> 
> As I've been asked by a few people, I've put the repo up at GitHub. The
> exact change I applied to intel_hdmi.c is at [1], and you can build a kernel
> image right from the 4.15.0-21.22-glktesting branch (see [2]).
> 
> NB: Whenever something gets added to this issue, I'll keep on adding that to
> that branch for testing purposes.
> 
> [1]
> https://github.com/herrnst/ubuntu-bionic-kernel/commit/
> 3d664ae3c8831a51139efbb5298fc27a1bee4950
> [2]
> https://github.com/herrnst/ubuntu-bionic-kernel/commits/4.15.0-21.22-
> glktesting

Hello, I asked you exactly how to do to see if I was wrong something, unfortunately for me does not go

I leave the logs of DMESG and Xorg and the compiled kernel (4.16.10)

dmesg -> http://paste.ubuntu.com/p/9CKhZbCMhK/
Xorg.0.log -> http://paste.ubuntu.com/p/QHmWjTTZmN/

Kernel 4.16.10 -> https://mega.nz/#!8tRHnYKY!-y4jc8-mpwe1vVqG5JmRjva6m9RX4j88q8h4bGmIhks

At this point I don't know what to do anymore!
Comment 57 Daniel Scheller 2018-05-20 11:12:07 UTC
For convenience, installable kernel-image/headers et al debs at [1] (clone the repo, checkout the branch and then just do "dpkg -i <package>.deb", install whatever is needed). No responsibility of any kind, use at your own risk etc.

[1] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-21.22-glktesting-deb
Comment 58 fatez 2018-05-20 14:54:47 UTC
I tried your but from me it does not work.
I compiled the kernel 4.17-rc5 manually inserting the fix and not even this works, here are the logs and the kernel .deb

dmesg -> http://paste.ubuntu.com/p/VBnyzYzC7d/
Xorg.0.log -> http://paste.ubuntu.com/p/67gnqNvZ9H/
Kernel 4.17-rc5 -> https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY
Comment 59 Erik Sandlund 2018-05-20 16:29:34 UTC
(In reply to Daniel Scheller from comment #57)
> For convenience, installable kernel-image/headers et al debs at [1] (clone
> the repo, checkout the branch and then just do "dpkg -i <package>.deb",
> install whatever is needed). No responsibility of any kind, use at your own
> risk etc.
> 
> [1]
> https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-21.22-glktesting-
> deb

Thanks, works great!
Comment 60 fatez 2018-05-20 17:31:35 UTC
@Erik Sandlund @Daniel Scheller 
But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then return to HDMI1?

Can you try the kernel I compiled myself and see if it works for you?

Kernel 4.17-rc5 -> https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY
Comment 61 Clinton Taylor 2018-05-21 17:54:07 UTC
(In reply to Daniel Scheller from comment #51)
> (In reply to Clinton Taylor from comment #49)
> 
> > Issue does not occur if I disable 12 bpc support in the driver.
> > 
> > For a quick test:
> > 
> > In intel_hdmi.c  mothod hdmi_12bpc_possible()
> > 
> > add 
> >    return false;
> 
> Using an ASRock J5005-ITX on stock Ubuntu 18.04 w/Kernel 4.15, connected to
> an Onkyo TX-NR509 AV receiver, which shows similar sympthoms (ie. if the
> resolution goes up (pixel clock rate increases) from the boot res to 1080p50
> or 1080p60, the TV picture goes away/blue and the receiver says "No signal".
> The receiver must be power-cycled to get a picture again).
> 
> Tried the above (modified Ubuntu kernel sources accordingly, repackaged,
> installed and booted) - makes the issue go away with this workaround,
> switching from 50p/60p to 24p and back works, no "No signal". Everything
> else video-related remains working normally.

Thanks for testing the workaround. We will work on the permanent fix for the upstream driver.
Comment 62 Lourens 2018-05-23 18:47:40 UTC
(In reply to fatez from comment #60)
> @Erik Sandlund @Daniel Scheller 
> But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then
> return to HDMI1?
> 
> Can you try the kernel I compiled myself and see if it works for you?
> 
> Kernel 4.17-rc5 ->
> https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY

@fatez;
I still believe your issue is different than the one that this bug report is about.
Therefore the work-around presented above will not fix your HDMI switching issue.

Maybe you should create a new (if it's not already there) bug report about it?
Comment 63 fatez 2018-05-24 08:49:09 UTC
(In reply to Lourens from comment #62)
> (In reply to fatez from comment #60)
> > @Erik Sandlund @Daniel Scheller 
> > But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then
> > return to HDMI1?
> > 
> > Can you try the kernel I compiled myself and see if it works for you?
> > 
> > Kernel 4.17-rc5 ->
> > https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY
> 
> @fatez;
> I still believe your issue is different than the one that this bug report is
> about.
> Therefore the work-around presented above will not fix your HDMI switching
> issue.
> 
> Maybe you should create a new (if it's not already there) bug report about
> it?

You're right! For me it is the first time, can you help me in what section should I write?
Comment 64 user.forums 2018-05-24 19:19:14 UTC
> I have this issue on my NUC7PJYH (Gemini Lake Pentium J5005) with a
> completely stock Ubuntu 18.04 Server installation using a Samsung 22" 1080p
> TV (I'll come back with the exact model number). Here's what happens:
> 
> 1. When you boot the system, the boot screen ("Intel NUC") is shown, as it
> should be.
> 2. Ubuntu starts to boot up and you get to see the first lines of console
> print-outs.
> 3. However, as soon as the system loads i915 and switches mode the screen
> goes black. The TV reports HDMI signal lost.
> 4. There are two ways to recover: disconnect and reconnect the HDMI plug OR
> power off and then on the TV.

My experience is identical to the above. I also have a NUC7PJYH with HDMI1 plugged into a Sony STR-DH810, which is plugged into a Panasonic VIERA TC-P54V10 plasma TV. I'm running Debian sid/unstable. This problem only happens with the NUC. If I swap out the NUC with any of my other boxes, it's fine.

I can confirm that applying https://github.com/herrnst/ubuntu-bionic-kernel/commit/3d664ae3c8831a51139efbb5298fc27a1bee4950 "i915/glk: effectively disable hdmi_12bps_possible()" does in fact solve the problem for me. It's my understanding this is a workaround rather than a proper fix. If I can supply logging, edid, or something that would be helpful towards a proper fix, please let me know.

Considering this problem does seem to be wide-spread, thank you to everyone contributing to get it resolved! I just got this NUC and was really disappointed to find this kind of bug.
Comment 65 Clinton Taylor 2018-05-24 23:55:39 UTC
> I can confirm that applying
> https://github.com/herrnst/ubuntu-bionic-kernel/commit/
> 3d664ae3c8831a51139efbb5298fc27a1bee4950 "i915/glk: effectively disable
> hdmi_12bps_possible()" does in fact solve the problem for me. It's my
> understanding this is a workaround rather than a proper fix. If I can supply
> logging, edid, or something that would be helpful towards a proper fix,
> please let me know.
> 

Thanks for the offer, however the failure doesn't actually show up in the logs.

This appears to be a transcoder disable sequencing issue. The driver sequence has been confirmed as correct according to the Gemini Lake documentation. Why this happens only at 12bpc is still a mystery.

A simple msleep(50); at the end of intel_ddi_disable_transcoder_func() appears to resolve the issue. This is also a W/A and not the final solution.
Comment 66 fatez 2018-05-25 19:20:07 UTC
(In reply to fatez from comment #63)
> (In reply to Lourens from comment #62)
> > (In reply to fatez from comment #60)
> > > @Erik Sandlund @Daniel Scheller 
> > > But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then
> > > return to HDMI1?
> > > 
> > > Can you try the kernel I compiled myself and see if it works for you?
> > > 
> > > Kernel 4.17-rc5 ->
> > > https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY
> > 
> > @fatez;
> > I still believe your issue is different than the one that this bug report is
> > about.
> > Therefore the work-around presented above will not fix your HDMI switching
> > issue.
> > 
> > Maybe you should create a new (if it's not already there) bug report about
> > it?
> 
> You're right! For me it is the first time, can you help me in what section
> should I write?
bump
Comment 67 Clinton Taylor 2018-05-25 23:14:20 UTC
Created attachment 139778 [details]
Scope shot of input and output of level shifter
Comment 68 Clinton Taylor 2018-05-25 23:16:10 UTC
After bashing my head against he wall for several days I have finally determined that the issue is caused by the HDMI level shifter on the board and not a driver issue. 

After changing the mode from 1080p24 to 1080p50 the scope shows a valid clock into the level shifter and a very low amplitude clock on the output to the connector. Adding a short delay after the Transcoder is disabled appears to solve the issue with the level shifter.

I have attached a scope shot of the waveform into the level shifter (yellow trace) and the output to the connector (blue trace).
Comment 69 Daniel Scheller 2018-05-26 17:42:39 UTC
(In reply to Clinton Taylor from comment #68)

> After bashing my head against he wall for several days I have finally
> determined that the issue is caused by the HDMI level shifter on the board
> and not a driver issue. 
> 
> After changing the mode from 1080p24 to 1080p50 the scope shows a valid
> clock into the level shifter and a very low amplitude clock on the output to
> the connector. Adding a short delay after the Transcoder is disabled appears
> to solve the issue with the level shifter.
> 
> I have attached a scope shot of the waveform into the level shifter (yellow
> trace) and the output to the connector (blue trace).

Thanks for investigating this further and even finding a "proper" driver workaround for this hardware problem. I did a test with msleep(50) at the end of intel_ddi.c:intel_ddi_disable_transcoder_func() (see [1]) on the ASRock board, and this helps the "No signal" issue aswell.

I went a bit further and added a modparam to switch between different GLK tests, which by now are "no 12bpc" and "msleep(50)" ([2] is what everything looks like right now, esp. re patches/tests) :-)

If anyone else likes to do some testing: I've put installable kernel .debs up at  [3] for easy install (Ubuntu Bionic 4.15.0-23.25 proposed, with the patches ontop). To enable any of the workarounds, use the parameter glkhdmi (set to 1 for the 12bit disable hack, set to 2 for the msleep test). Easiest is to add i915.glkhdmi=X (replace X with 1 or 2) to /etc/default/grub into GRUB_CMDLINE_LINUX_DEFAULT, then update-grub, then reboot. Note if you don't set the option or set it to zero, you'll get stock behaviour and the "No signal" issue back.

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/f0503e843b8223a2a4572c573a120cd49a8e7134
[2] https://github.com/herrnst/ubuntu-bionic-kernel/compare/Ubuntu-4.15.0-23.25...4.15.0-23.25-glktesting
[3] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-23.25-glktesting-deb
Comment 70 user.forums 2018-05-27 00:18:49 UTC
I'll test these workarounds over the next couple days. So far the `disable 12bpc` has worked good here - no problems. I also modified the patch a little so you can select what you want the default setting to be in menuconfig (I prefer that over using custom grub commands).

Is either of these workarounds more preferable over the other? Any potential negative impacts or drawbacks each may have?

Thanks!
Comment 71 fatez 2018-05-27 09:19:49 UTC
Guys I ask you a favor, I opened a ticket here https://bugs.freedesktop.org/show_bug.cgi?id=106659 but no one probably has my same problem.

After applying the two "fix" from Clinton Taylor (msleep(50); and return false;) if i set 3840x2160@24p in kodi and shift from hdmi1 (kodi) to hdmi2 (sky) and return in hdmi i never lost the signal BUT if i in kodi set 3840x2160@60p and shift from hdmi1 to 2 and return in hdmi1 i lost the signal. 

Is there a similar solution for 24p even for 60p?
Comment 72 shashank.sharma@intel.com 2018-05-28 07:06:55 UTC
(In reply to Clinton Taylor from comment #68)
> After bashing my head against he wall for several days I have finally
> determined that the issue is caused by the HDMI level shifter on the board
> and not a driver issue. 
> 
> After changing the mode from 1080p24 to 1080p50 the scope shows a valid
> clock into the level shifter and a very low amplitude clock on the output to
> the connector. Adding a short delay after the Transcoder is disabled appears
> to solve the issue with the level shifter.
> 
> I have attached a scope shot of the waveform into the level shifter (yellow
> trace) and the output to the connector (blue trace).

Hello Clinton,
What kind of level shifter is this ? Is it DP -> HDMI passive LS or something else ? Do you have any information about it ? 

- Shashank
Comment 73 Clinton Taylor 2018-05-29 17:48:37 UTC
 
> Hello Clinton,
> What kind of level shifter is this ? Is it DP -> HDMI passive LS or
> something else ? Do you have any information about it ? 
> 

The component is a HDMI 2.0 retiming buffer. The data sheet was sent to you on 5/8 by Imre for the following issue. https://bugs.freedesktop.org/show_bug.cgi?id=106182. 

I can't attach a third party's datasheet to this issue.
Comment 74 shashank.sharma@intel.com 2018-05-29 18:07:34 UTC
Well, I could not relate that, as there are few parallel thread. Also I don't understand why we need a HDMI 2.0 retimer on GLK as it already has a HDMI 2.0 native controller, unless someone needs 2 or 3 HDMI 2.0 sources coming out of GLK NUC, and NUC was short of it, and some platform team decided to use some Paradetech dongle to convert DP 1.2 -> HDMI 2.0. 

As I don't know anything about this parade chip PS176, and also its been diagnosed that the dongle is causing low amplitude outputs on particular frequencies, I guess we should escalate to Paradetech team.

- Shashank
Comment 75 Clinton Taylor 2018-05-29 19:15:05 UTC
(In reply to shashank.sharma@intel.com from comment #74)
> Well, I could not relate that, as there are few parallel thread. Also I
> don't understand why we need a HDMI 2.0 retimer on GLK as it already has a
> HDMI 2.0 native controller, unless someone needs 2 or 3 HDMI 2.0 sources
> coming out of GLK NUC, and NUC was short of it, and some platform team
> decided to use some Paradetech dongle to convert DP 1.2 -> HDMI 2.0. 
> 

The ITE66317 retimer implementation does seem to be causing the Linux driver some difficulty. Based on what I have seen so far, the Linux driver doesn't wait long enough during mode changes for the retimer to sync correctly to the new faster clock.
Comment 76 shashank.sharma@intel.com 2018-05-30 02:39:07 UTC
(In reply to Clinton Taylor from comment #75)
> (In reply to shashank.sharma@intel.com from comment #74)
> > Well, I could not relate that, as there are few parallel thread. Also I
> > don't understand why we need a HDMI 2.0 retimer on GLK as it already has a
> > HDMI 2.0 native controller, unless someone needs 2 or 3 HDMI 2.0 sources
> > coming out of GLK NUC, and NUC was short of it, and some platform team
> > decided to use some Paradetech dongle to convert DP 1.2 -> HDMI 2.0. 
> > 
> 
> The ITE66317 retimer implementation does seem to be causing the Linux driver
> some difficulty. Based on what I have seen so far, the Linux driver doesn't
> wait long enough during mode changes for the retimer to sync correctly to
> the new faster clock.

If that's the case, in order to upstream this kind of solution in driver, we need to:
- detect if this is the specific device with re-timer, because a general purpose wait in encoder path wont be acceptable, in driver.
- we need the official sepc indicating this encoder needs this range of timing delay for these pixel clock rates.

- Shashank
Comment 77 Brunnis 2018-06-03 09:05:37 UTC
Could this issue affect Windows as well? Interesting comment from Intel’s support forums: https://communities.intel.com/message/546381#546381

”Sometimes changing the refresh rate or resolution in Windows results in a black screen as well and only pulling out and plugging back the HDMI cable resets the state and gets me picture.”

I remember getting a black screen once when I initially ran Win 10 on my NUC7PJYH and ran Passmark’s GPU tests. Anyway, I know this bug tracker doesn’t concern itself with Windows issues, but could be interesting to sync this between the driver teams (if that hasn’t already been done).
Comment 78 user.forums 2018-06-05 04:07:55 UTC
For anyone interested, this is the patch I've been using - patch from Daniel Scheller modified to allow setting the default workaround behavior via Kconfig/menuconfig in case you don't want to bother with the grub command line. 

Patch is here: https://pastebin.com/rimPf2x1
Comment 79 Brunnis 2018-06-05 10:43:42 UTC
Just thought I'd mention that the 50 ms sleep workaround is effective on my system as well, using the Samsung UE22H5005 1080p TV.
Comment 80 Jani Saarinen 2018-06-08 06:02:08 UTC
reference: https://patchwork.freedesktop.org/series/44446/
Comment 81 fatez 2018-06-08 15:47:20 UTC
(In reply to Jani Saarinen from comment #80)
> reference: https://patchwork.freedesktop.org/series/44446/

Can I apply this patch to the 4.17 kernel or i must have DRM-tip?
Comment 82 Clinton Taylor 2018-06-08 16:02:43 UTC
It will probably apply to 4.17. It's not much different than the 50ms wait you were using before. The patch just detects a GLK NUC before waiting 42ms.

I would like some tests to make sure a 42ms delay is enough. I probably ran 200 cycles in testing, but would really like more to confirm the workaround.
Comment 83 user.forums 2018-06-09 02:23:18 UTC
(In reply to Clinton Taylor from comment #82)
> It will probably apply to 4.17. It's not much different than the 50ms wait
> you were using before. The patch just detects a GLK NUC before waiting 42ms.
> 
> I would like some tests to make sure a 42ms delay is enough. I probably ran
> 200 cycles in testing, but would really like more to confirm the workaround.

The good news is your patch applies to 4.17. The bad news is it doesn't work here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV.
Comment 84 user.forums 2018-06-09 03:27:45 UTC
(In reply to user.forums from comment #83)
> (In reply to Clinton Taylor from comment #82)
> > It will probably apply to 4.17. It's not much different than the 50ms wait
> > you were using before. The patch just detects a GLK NUC before waiting 42ms.
> > 
> > I would like some tests to make sure a 42ms delay is enough. I probably ran
> > 200 cycles in testing, but would really like more to confirm the workaround.
> 
> The good news is your patch applies to 4.17. The bad news is it doesn't work
> here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV.

I tried increasing the 42 value to 45, 50, 100, 150. Nothing works. Additional, I noticed that with this patch I don't even see any of the systemd stuff pass by as I do with no patch applied.
Comment 85 Daniel Scheller 2018-06-09 09:58:33 UTC
(In reply to Jani Saarinen from comment #80)
> reference: https://patchwork.freedesktop.org/series/44446/

This patch (backported to the Ubuntu 4.15.0 kernel sources as a replacement for the "hack selection", see above) doesn't work on my J5005-ITX either. Upon boot, the "No signal" issue is back, reverting to the previous kernel with the plain 50ms wait makes it work again.
Comment 86 Daniel Scheller 2018-06-09 10:30:41 UTC
(In reply to Daniel Scheller from comment #85)
> (In reply to Jani Saarinen from comment #80)
> > reference: https://patchwork.freedesktop.org/series/44446/
> 
> This patch (backported to the Ubuntu 4.15.0 kernel sources as a replacement
> for the "hack selection", see above) doesn't work on my J5005-ITX either.
> Upon boot, the "No signal" issue is back, reverting to the previous kernel
> with the plain 50ms wait makes it work again.

Sadly can't just edit the comment. For reference, the hardware IDs for the GLK GPU on this board (lspci -vvn):

00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller])
	Subsystem: 1849:2212

Again, unconditionally waiting 50ms at the end of intel_ddi_disable_transcoder_func() works, so I suspect all GLK hardware needs this, not only the NUCs.
Comment 87 fatez 2018-06-09 16:19:51 UTC
(In reply to Clinton Taylor from comment #82)
> It will probably apply to 4.17. It's not much different than the 50ms wait
> you were using before. The patch just detects a GLK NUC before waiting 42ms.
> 
> I would like some tests to make sure a 42ms delay is enough. I probably ran
> 200 cycles in testing, but would really like more to confirm the workaround.

I confirm that you have applied the patch to the kernel 4.17 but on 10 times 4 times does not work
Comment 88 fatez 2018-06-10 07:39:10 UTC
(In reply to fatez from comment #87)
> (In reply to Clinton Taylor from comment #82)
> > It will probably apply to 4.17. It's not much different than the 50ms wait
> > you were using before. The patch just detects a GLK NUC before waiting 42ms.
> > 
> > I would like some tests to make sure a 42ms delay is enough. I probably ran
> > 200 cycles in testing, but would really like more to confirm the workaround.
> 
> I confirm that you have applied the patch to the kernel 4.17 but on 10 times
> 4 times does not work

I mean "I have applied..."
Comment 89 Clinton Taylor 2018-06-11 21:13:36 UTC
> 
> Sadly can't just edit the comment. For reference, the hardware IDs for the
> GLK GPU on this board (lspci -vvn):
> 
> 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller])
> 	Subsystem: 1849:2212
> 
> Again, unconditionally waiting 50ms at the end of
> intel_ddi_disable_transcoder_func() works, so I suspect all GLK hardware
> needs this, not only the NUCs.

Daniel,
   Could you add the following to to intel_quirks[] in intel_display.c  

     { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },

  
I really don't want to add the delay to all GLK's, but even the ASrock photo's show the ITE chip in use on the board. I don't have a guaranteed way to detect the ITE chip on the boards.

Thanks,
Clint
Comment 90 Clinton Taylor 2018-06-11 21:16:03 UTC
(In reply to user.forums from comment #84)
> (In reply to user.forums from comment #83)
> > (In reply to Clinton Taylor from comment #82)
> > > It will probably apply to 4.17. It's not much different than the 50ms wait
> > > you were using before. The patch just detects a GLK NUC before waiting 42ms.
> > > 
> > > I would like some tests to make sure a 42ms delay is enough. I probably ran
> > > 200 cycles in testing, but would really like more to confirm the workaround.
> > 
> > The good news is your patch applies to 4.17. The bad news is it doesn't work
> > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV.
> 

Could you run lspci -vvn -s00:02.0 from a console prompt and post the results?

Thanks,
Clint
Comment 91 user.forums 2018-06-12 00:07:19 UTC
(In reply to Clinton Taylor from comment #90)
> (In reply to user.forums from comment #84)
> > (In reply to user.forums from comment #83)
> > > (In reply to Clinton Taylor from comment #82)
> > > > It will probably apply to 4.17. It's not much different than the 50ms wait
> > > > you were using before. The patch just detects a GLK NUC before waiting 42ms.
> > > > 
> > > > I would like some tests to make sure a 42ms delay is enough. I probably ran
> > > > 200 cycles in testing, but would really like more to confirm the workaround.
> > > 
> > > The good news is your patch applies to 4.17. The bad news is it doesn't work
> > > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV.
> > 
> 
> Could you run lspci -vvn -s00:02.0 from a console prompt and post the
> results?
> 
> Thanks,
> Clint

Sure thing..

~$ lspci -vvn -s00:02.0
00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller])
        Subsystem: 8086:2072
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 124
        Region 0: Memory at a0000000 (64-bit, non-prefetchable) [size=16M]
        Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at f000 [size=64]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915
Comment 92 fatez 2018-06-12 11:34:03 UTC
(In reply to Clinton Taylor from comment #90)
> (In reply to user.forums from comment #84)
> > (In reply to user.forums from comment #83)
> > > (In reply to Clinton Taylor from comment #82)
> > > > It will probably apply to 4.17. It's not much different than the 50ms wait
> > > > you were using before. The patch just detects a GLK NUC before waiting 42ms.
> > > > 
> > > > I would like some tests to make sure a 42ms delay is enough. I probably ran
> > > > 200 cycles in testing, but would really like more to confirm the workaround.
> > > 
> > > The good news is your patch applies to 4.17. The bad news is it doesn't work
> > > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV.
> > 
> 
> Could you run lspci -vvn -s00:02.0 from a console prompt and post the
> results?
> 
> Thanks,
> Clint

Whit ur patch and kernel 4.17 :

sudo lspci -vvn -s00:02.0
00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller])
	Subsystem: 8086:2072
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 128
	Region 0: Memory at a0000000 (64-bit, non-prefetchable) [size=16M]
	Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at f000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [40] Vendor Specific Information: Len=0c <?>
	Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- RBE+
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
	Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee00018  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100 v1] Process Address Space ID (PASID)
		PASIDCap: Exec- Priv-, Max PASID Width: 14
		PASIDCtl: Enable- Exec- Priv-
	Capabilities: [200 v1] Address Translation Service (ATS)
		ATSCap:	Invalidate Queue Depth: 00
		ATSCtl:	Enable-, Smallest Translation Unit: 00
	Capabilities: [300 v1] Page Request Interface (PRI)
		PRICtl: Enable- Reset-
		PRISta: RF- UPRGI- Stopped+
		Page Request Capacity: 00008000, Page Request Allocation: 00000000
	Kernel driver in use: i915
	Kernel modules: i915



If I step from HDMI 1 (kodi) to HDMI 2 (Sky) and go back to Kodi, I lose the signal. If I kill Kodi and raise him, after 8-9 times he returns to live but I lose the audio
Comment 93 fatez 2018-06-12 16:52:45 UTC
And again the audio lost :

[ 4122.063172] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100
[ 4123.075186] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100
[ 4124.087207] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20bf8100
[ 4124.371430] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
Comment 94 Daniel Scheller 2018-06-12 18:15:03 UTC
(In reply to Clinton Taylor from comment #89)

Hi Clint,

> > Sadly can't just edit the comment. For reference, the hardware IDs for the
> > GLK GPU on this board (lspci -vvn):
> > 
> > 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller])
> > 	Subsystem: 1849:2212
> > 
> > Again, unconditionally waiting 50ms at the end of
> > intel_ddi_disable_transcoder_func() works, so I suspect all GLK hardware
> > needs this, not only the NUCs.
> 
> Daniel,
>    Could you add the following to to intel_quirks[] in intel_display.c  
> 
>      { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },

Done (could have tried that myself though already since it's obvious it won't do anything without matching hardware IDs). With that, your patch works well, just like with the 50ms unconditional delay. My i915.ko now carries [1] (your original patch plus unrelated fixups for the 4.15 backport) and [2] (with additional hardware IDs), please ignore any debian changelog changes.

> I really don't want to add the delay to all GLK's, but even the ASrock
> photo's show the ITE chip in use on the board. I don't have a guaranteed way
> to detect the ITE chip on the boards.

The list of hardware IDs might get long though. On another forum, one user has the same HDMI issue with an ASRock J4105-ITX with the "slower" (compared to J5005) GLK iGPU, that one identifies with

  00:02.0 0300: 8086:3185 (rev 03) (prog-if 00 [VGA controller])
          Subsystem: 1849:2212

So, same subsys vendor+id, but different PCI ID. Thats why I added more IDs in [2], the two mentioned by fatez and user.forums@gmail.com are in there aswell.

For anyone who wants to test: Ubuntu Kernel debs at [3].

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/92f7740df31c5c920d217db210594b4cd9e45413
[2] https://github.com/herrnst/ubuntu-bionic-kernel/commit/b8c66deb38c5b8020b50bfb44c71e06a0275bba3
[3] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-23.25-glktesting3-deb
Comment 95 fatez 2018-06-12 19:22:27 UTC
(In reply to Daniel Scheller from comment #94)

> For anyone who wants to test: Ubuntu Kernel debs at [3].
> 
> [1]
> https://github.com/herrnst/ubuntu-bionic-kernel/commit/
> 92f7740df31c5c920d217db210594b4cd9e45413
> [2]
> https://github.com/herrnst/ubuntu-bionic-kernel/commit/
> b8c66deb38c5b8020b50bfb44c71e06a0275bba3
> [3]
> https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-23.25-
> glktesting3-deb

Whit Your kernel i can switch from hdmi1 to hdmi2 and return in kodi without losing signal BUT i have lost audio :

Jun 12 21:00:19 NucBox kernel: [  746.347626] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100
Jun 12 21:00:20 NucBox kernel: [  747.359663] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100
Jun 12 21:00:21 NucBox kernel: [  748.371690] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20bf8100
Jun 12 21:00:21 NucBox kernel: [  748.391945] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
Jun 12 21:19:30 NucBox kernel: [ 1896.982135] azx_single_send_cmd: 246 callbacks suppressed
Jun 12 21:19:30 NucBox kernel: [ 1897.038596] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
Comment 96 fatez 2018-06-12 21:30:51 UTC
My apoligies. Was a pulse problem. Whit ur latest kernel all works fine. Now is time to watch some video and test it
Comment 97 fatez 2018-06-13 10:40:52 UTC
I spoke too soon... 
I came home from work and I turned on the TV to watch Kodi and guess what? 

Lost Signal
Comment 98 Clinton Taylor 2018-06-13 22:04:56 UTC
Version 2 of the upstream patch has been posted:

https://patchwork.freedesktop.org/patch/229363/
Comment 99 user.forums 2018-06-13 23:28:45 UTC
(In reply to Clinton Taylor from comment #98)
> Version 2 of the upstream patch has been posted:
> 
> https://patchwork.freedesktop.org/patch/229363/

Tested & working here now. Thank you Clinton, and all who contributed!
Comment 100 Daniel Scheller 2018-06-14 06:51:41 UTC
(In reply to Clinton Taylor from comment #98)
> Version 2 of the upstream patch has been posted:
> 
> https://patchwork.freedesktop.org/patch/229363/

Many thanks from me for taking care of this aswell!
Comment 101 Ingo Fischer 2018-06-19 21:30:35 UTC
I came here with the same problem (J5005 ASRock board, occasional HDMI connection problems with Ubuntu 18.04) but little to no knowhow about kernel-patching but I thought it might be a good place to start diving a bit deeper. 

Can someone explain to me how I can apply the patch from from https://patchwork.freedesktop.org/patch/229363/ right now on an up-to-date Ubuntu 18.04 system?
How can I follow progress to see when the patch will be merged into mainline (will it be merged?)?
Comment 102 fatez 2018-06-22 17:44:30 UTC
(In reply to Ingo Fischer from comment #101)
> I came here with the same problem (J5005 ASRock board, occasional HDMI
> connection problems with Ubuntu 18.04) but little to no knowhow about
> kernel-patching but I thought it might be a good place to start diving a bit
> deeper. 
> 
> Can someone explain to me how I can apply the patch from from
> https://patchwork.freedesktop.org/patch/229363/ right now on an up-to-date
> Ubuntu 18.04 system?
> How can I follow progress to see when the patch will be merged into mainline
> (will it be merged?)?

Although it is not the correct place to ask for a guide, I do so (If it's just the first time you have to install some things):

- sudo apt install git flex bison bc libssl-dev gawk libudev-dev ocl-icd-opencl-dev libpci-dev libelf-dev python2.7 libncurses-dev fakeroot kernel-wedge binfmt-support ksh lsscsi binfmt-support libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libsepol1-dev libattr1-dev libblkid-dev libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libselinux1-dev libsepol1-dev uuid-dev debugedit libarchive13 libdw1 liblua5.2-0 liblzo2-2 libnspr4 libnss3 librpm8 librpmbuild8 librpmio8 librpmsign8 rpm rpm-common rpm2cpio spl-dkms

- sudo git clone --depth 1 --single-branch --branch v4.17.2 git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack v4.17.2

- cd v4.17.2
- sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0001-base-packaging.patch
- sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0002-UBUNTU-SAUCE-add-vmlinux.strip-to-BOOT_TARGETS1-on-p.patch
- sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0003-UBUNTU-SAUCE-tools-hv-lsvmbus-add-manual-page.patch
- sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0004-UBUNTU-SAUCE-no-up-disable-pie-when-gcc-has-it-enabl.patch
- sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0005-debian-changelog.patch
- sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0006-configs-based-on-Ubuntu-4.17.0-3.4.patch
- Download the patch from https://patchwork.freedesktop.org/patch/229363/ and rename in i915.patch

- sudo patch -p1 < 0001-base-packaging.patch 
- sudo patch -p1 < 0002-UBUNTU-SAUCE-add-vmlinux.strip-to-BOOT_TARGETS1-on-p.patch
- sudo patch -p1 < 0003-UBUNTU-SAUCE-tools-hv-lsvmbus-add-manual-page.patch
- sudo patch -p1 < 0004-UBUNTU-SAUCE-no-up-disable-pie-when-gcc-has-it-enabl.patch
- sudo patch -p1 < 0005-debian-changelog.patch
- sudo patch -p1 < 0006-configs-based-on-Ubuntu-4.17.0-3.4.patch
- sudo patch -p1 < i915.patch

- sudo chmod a+x debian/rules
- sudo chmod a+x debian/scripts/*
- sudo chmod a+x debian/scripts/misc/*
- sudo fakeroot debian/rules clean
set do_zfs = false in debian.master/rules.d/amd64.mk,
- sudo fakeroot debian/rules binary-headers binary-generic binary-perarch
Comment 103 Clinton Taylor 2018-06-28 18:22:01 UTC
Version 3 of the patch has been sent to the intel-gfx mail list.

Changes:
Delay increased to 100ms based on review feedback. 
Confirm crtc_state->type is HDMI, so we don't delay for other output types.
 
https://patchwork.freedesktop.org/patch/233505/
Comment 104 fatez 2018-06-29 12:28:11 UTC
(In reply to Clinton Taylor from comment #103)
> Version 3 of the patch has been sent to the intel-gfx mail list.
> 
> Changes:
> Delay increased to 100ms based on review feedback. 
> Confirm crtc_state->type is HDMI, so we don't delay for other output types.
>  
> https://patchwork.freedesktop.org/patch/233505/

I have the same issue;
I tried several kernels (4.15.0-23; 4.17.0-041700; 4.17.1-041701; 4.17.2-041702; 4.18.0-041800rc1; 4.18.0-041800rc2) - and even the last available


[    2.744531] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    2.745155] [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
[    2.745628] [drm] Applying Increase DDI Disabled quirk
[    2.748345] [drm] Initialized i915 1.6.0 20180514 for 0000:00:02.0 on minor 0
[    2.749844] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)

See here the NO SIGNAL : https://i.imgur.com/eawe700.jpg
Comment 105 Jani Saarinen 2018-06-29 13:32:54 UTC
Please test patch that is not yet merged but today got rb from Imre.
Comment 106 fatez 2018-06-29 16:08:16 UTC
(In reply to Jani Saarinen from comment #105)
> Please test patch that is not yet merged but today got rb from Imre.

What patch are you talking about exactly?
Comment 107 Daniel Scheller 2018-06-29 19:40:32 UTC
(In reply to Clinton Taylor from comment #103)
> Version 3 of the patch has been sent to the intel-gfx mail list.
> 
> Changes:
> Delay increased to 100ms based on review feedback. 
> Confirm crtc_state->type is HDMI, so we don't delay for other output types.
>  
> https://patchwork.freedesktop.org/patch/233505/

Thanks for the updated patch. Though, this iteration brings the issue back at least during boot when i915.ko is loaded: My J5005-ITX prints it's boot messages after powering on the system. Then, when i915 first initialises the hardware and switches the FB to 1080p50 (forced via "video=HDMI-A-1:1920x1080@50" on the kernel command line), I get the "No signal" problem. Shortly after, when X and Kodi are started, the picture returns due to some "xset" commands that are run. From within Kodi, playing a 23.976p movie and stopping (thus switching to 1080p50 again), picture remains and there are no more issues. Maybe the connector check causes the initial issue here?

For reference, the backported patch is at [1] and kernel debs at [2].

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commits/4.15.0-24-26-glktesting4
[2] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-24.26-glktesting4-deb
Comment 108 Clinton Taylor 2018-06-29 21:13:01 UTC
> Thanks for the updated patch. Though, this iteration brings the issue back
> at least during boot when i915.ko is loaded: My J5005-ITX prints it's boot
> messages after powering on the system. Then, when i915 first initialises the
> hardware and switches the FB to 1080p50 (forced via
> "video=HDMI-A-1:1920x1080@50" on the kernel command line), I get the "No
> signal" problem. Shortly after, when X and Kodi are started, the picture
> returns due to some "xset" commands that are run. From within Kodi, playing
> a 23.976p movie and stopping (thus switching to 1080p50 again), picture
> remains and there are no more issues. Maybe the connector check causes the
> initial issue here?


Thanks for the test. Glad we found this early. Let me see what other connector type checks I need to add. My guess is INTEL_OUTPUT_UNUSED for the first boot issue.
Comment 109 Clinton Taylor 2018-06-29 21:32:31 UTC
> Maybe the connector check causes the
> initial issue here?

Daniel,
   Using the v3 patch could you apply the following diff? 

Thanks,-Clint

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 89bb5ce..b2ff394 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1818,15 +1818,16 @@ void intel_ddi_disable_transcoder_func(const struct inte
 
        i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
        uint32_t val = I915_READ(reg);
-
        val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK | TRANS_DDI_DP_VC_P
        val |= TRANS_DDI_PORT_NONE;
        I915_WRITE(reg, val);
 
+       DRM_ERROR(" *** connector type = %d\n", crtc_state->output_types);
        if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
-           intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
-               msleep(DDI_DISABLED_QUIRK_TIME);
+           (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) ||
+            intel_crtc_has_type(crtc_state, INTEL_OUTPUT_UNUSED))) {
                DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
+               msleep(DDI_DISABLED_QUIRK_TIME);
        }
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index ff42268..d3ad9c1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14956,7 +14956,6 @@ static int intel_dmi_reverse_brightness(const struct dmi
        /* ASRock ITX*/
        { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
        { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
-
 };
 
 static void intel_init_quirks(struct drm_device *dev)
Comment 110 Daniel Scheller 2018-06-30 09:20:32 UTC
(In reply to Clinton Taylor from comment #109)
> > Maybe the connector check causes the
> > initial issue here?
> 
> Daniel,
>    Using the v3 patch could you apply the following diff?

Did that (exact diff looks like [1] now, please ignore the debchangelog stuff). Packaged ([2]), installed, rebooted, issue still remains. The DRM_ERROR(connector_type) reveals why, though:

# dmesg | grep disable_transcoder
[    2.998161] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 1024
[   11.002233] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64
[  373.751818] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64
[  380.119446] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64
[  383.988156] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64
[  389.564144] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64
[  406.176236] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64
[  415.329143] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR*  *** connector type = 64

So, right after boot, connector type is INTEL_OUTPUT_UNKNOWN, and in all following cases it's INTEL_OUTPUT_HDMI. I did not test this yet, but adding _UNKNOWN to the if() should finally do the trick (will eventually add that somewhen today and retest).

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/38ecb48f10b4dfedc1dd190d42749cb0d93b6886
[2] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-24.26-glktesting5-deb
Comment 111 Daniel Scheller 2018-06-30 12:41:42 UTC
(In reply to Daniel Scheller from comment #110)
> (In reply to Clinton Taylor from comment #109)
> > > Maybe the connector check causes the
> > > initial issue here?
> > 
> > Daniel,
> >    Using the v3 patch could you apply the following diff?
> 
> [...]  I did not test this yet, but adding
> _UNKNOWN to the if() should finally do the trick (will eventually add that
> somewhen today and retest).

Clint,

just tested exactly that (see [1]) - with that, no "No signal" on the AV and/or TV. Installable images at [2].

Thanks,
Daniel

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/25276f577b3b1193a57a2a729d2bb8ad86b964c2
[2] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-24.26-glktesting6-deb
Comment 112 Clinton Taylor 2018-07-02 16:41:29 UTC
Current upstream code has changed INTEL_OUTPUT_UNKNOWN to INTEL_OUTPUT_DDI, and there has been a slight logic change around it. I will add INTEL_OUTPUT_DDI to the patch and submit a new version.
Comment 113 Clinton Taylor 2018-07-03 20:42:33 UTC
https://patchwork.freedesktop.org/patch/236192/

V4 of the patch has been submitted upstream. This patch will not apply cleanly to the 4.15 kernel. To apply to 4.15 change INTEL_OUTPUT_DDI to INTEL_OUTPUT_UNKNOWN
Comment 114 Daniel Scheller 2018-07-04 21:44:22 UTC
(In reply to Clinton Taylor from comment #113)
> https://patchwork.freedesktop.org/patch/236192/
> 
> V4 of the patch has been submitted upstream. This patch will not apply
> cleanly to the 4.15 kernel. To apply to 4.15 change INTEL_OUTPUT_DDI to
> INTEL_OUTPUT_UNKNOWN

Clint,

first up, sorry for the hassle regarding OUTPUT_UNKNOWN and OUTPUT_DDI with more current kernels in mind.

I applied your latest patch to 4.17.4 sources (slight conflict fixups required, see [1] for the result) and put the DRM_ERROR() back in which prints the current connector type ([2]). On 4.17, the check for _UNKNOWN or _DDI even doesn't seem to be needed anymore, the debug print will always report connector type 64, even directly after boot/hwinit/i915 load. Long story short, the patch still works well.

Test debs based on 4.17.4 at [3].

Will keep the latest 4.15 patches/branches around though, as they eventually are candidates for a possible "Ubuntu stable kernel" inclusion when your fix is merged into some linux/drm kernel tree.

[1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/c514d34616e9c54fa07efb316019d0c5fc410cf2
[2] https://github.com/herrnst/ubuntu-bionic-kernel/commit/2c00ac7bb2208f29573d6e7455126f744536d2a6
[3] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.17.4-ubuntu-glktesting7-deb
Comment 115 fatez 2018-07-05 05:41:04 UTC
(In reply to Clinton Taylor from comment #113)
> https://patchwork.freedesktop.org/patch/236192/
> 
> V4 of the patch has been submitted upstream. This patch will not apply
> cleanly to the 4.15 kernel. To apply to 4.15 change INTEL_OUTPUT_DDI to
> INTEL_OUTPUT_UNKNOWN

v4 on kernel 4.18-rc3

full log in attachments



[42751.866605] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-1 (pin 5) received hotplug event.
[42751.866716] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[42751.867000] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1)
[42751.867084] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[42751.867348] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1)
[42751.867402] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb
[42751.867491] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging
[42751.867575] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 gmbus dpb. force bit now 1
[42751.868256] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb
[42751.868342] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 gmbus dpb. force bit now 0
[42751.868609] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[42751.868693] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[42751.868947] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[42751.868978] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[42751.869069] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:101:HDMI-A-1] status updated from connected to disconnected
[42751.872045] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:101:HDMI-A-1]
[42751.872092] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[42751.872280] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1)
[42751.872306] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[42751.872490] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1)
[42751.872511] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb
[42751.872537] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging
[42751.872562] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 gmbus dpb. force bit now 1
[42751.873124] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb
[42751.873149] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 gmbus dpb. force bit now 0
[42751.873333] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[42751.873357] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[42751.873539] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[42751.873550] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[42751.873557] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:101:HDMI-A-1] disconnected
[42751.873658] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:107:HDMI-A-2]
[42751.873683] [drm:intel_hdmi_detect [i915]] [CONNECTOR:107:HDMI-A-2]
[42751.873868] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0050 w(1)
[42751.873891] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK on first message, retry
[42751.874073] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0050 w(1)
[42751.874086] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpc
[42751.874109] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging
[42751.874134] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 gmbus dpc. force bit now 1
[42751.874693] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpc
[42751.874717] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 gmbus dpc. force bit now 0
[42751.874901] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0040 w(1)
[42751.874924] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK on first message, retry
[42751.875106] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0040 w(1)
[42751.875113] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[42751.875120] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:107:HDMI-A-2] disconnected
Comment 116 fatez 2018-07-05 05:42:35 UTC
Created attachment 140467 [details]
kern.log_Patch_v4_Kernel_v4.18-rc3
Comment 117 fatez 2018-07-05 05:43:11 UTC
Created attachment 140468 [details]
syslog_Patch_v4_Kernel_v4.18-rc3
Comment 118 fatez 2018-07-16 16:36:05 UTC
Hey, do you guys have any news?
Comment 119 Radhakrishna Sripada 2018-07-16 17:27:01 UTC
The quirk patch got merged onto drm-tip. So I believe that the issue is resolved.

90c3e2198777 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
Comment 120 Imre Deak 2018-07-17 09:50:34 UTC
(In reply to fatez from comment #118)
> Hey, do you guys have any news?

(In reply to Radhakrishna Sripada from comment #119)
> The quirk patch got merged onto drm-tip. So I believe that the issue is
> resolved.
> 
> 90c3e2198777 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

Yep, sorry for not updating the bug, it can be closed now that the patch is merged.

Daniel, the patch will be backported to stable kernel releases (4.14 and 4.17), but users of 4.15  need to do the backporting/maintenance of the fix on their own.
Comment 121 fatez 2018-07-17 10:28:33 UTC
But only I still have the problem with no signal every time I change from hdmi1 to hdmi2 and back in hdmi1?
Comment 122 Imre Deak 2018-07-17 12:03:00 UTC
(In reply to fatez from comment #121)
> But only I still have the problem with no signal every time I change from
> hdmi1 to hdmi2 and back in hdmi1?

That sounds like a different issue from the one originally reported in this bug. I see you already opened a new bug [1], so let's handle it there.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=106659
Comment 123 Dhinakaran Pandiyan 2018-07-19 20:00:43 UTC
Closing this as the related but different issue of HDMI1 to HDMI2 switching is tracked under https://bugs.freedesktop.org/show_bug.cgi?id=106659.

And the merged patch has a Tested-By from Daniel Scheller.
Comment 124 fatez 2018-08-25 09:50:36 UTC
Good morning, I would like to know, how much time would you pass before the drm-tip patches are even put to the "normal kernel? Thank you
Comment 125 Jani Nikula 2018-10-24 07:49:00 UTC
(In reply to fatez from comment #124)
> Good morning, I would like to know, how much time would you pass before the
> drm-tip patches are even put to the "normal kernel? Thank you

It's now in the latest v4.14 and v4.17 stable releases at least.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.