Hi,

Your kernel is a very old one.  Since it is provided by your distro, you are better off looking for support on their bugzilla and mailling list, unless you can reproduce it with drm-intel-nightly

Hi Sir,

We had also tested on the Fedora 24 with latest kernel 4.10.13-100, it also had the same VGA no signal issue.

I don't know what "drm-intel-nightly" is, could you provide the usage or further information to me? Thank you! 


Amy Shih
Amy.Shih@advantech.com.tw

Hi Sir,

We had downloaded & built the "drm-intel-nightly" via below commands:

# git clone git://anongit.freedesktop.org/drm-intel
# make modules_install install

We got the kernel 4.11.0-rc7+ in CentOS Linux release 7.3.1611 (Core). 
Do the VGA

Hi Sir,

We had downloaded & built the "drm-intel-nightly" via below commands:

# git clone git://anongit.freedesktop.org/drm-intel
# make modules_install install

Then we got the kernel 4.11.0-rc7+ in CentOS Linux release 7.3.1611 (Core). 
Do the VGA test, it still has the VGA no signal issue. And we remove the I915 module from initramfs from kernel 4.11.0-rc7+ then do the test again, the VGA no signal issue is gone.

We can reproduce it with drm-intel-nightly, please assist to check it, thank you!

Amy Shih
Amy.Shih@advantech.com.tw

(In reply to amy.shih from comment #4)
> Hi Sir,
> 
> We had downloaded & built the "drm-intel-nightly" via below commands:
> 
> # git clone git://anongit.freedesktop.org/drm-intel
> # make modules_install install
> 
> Then we got the kernel 4.11.0-rc7+ in CentOS Linux release 7.3.1611 (Core). 
> Do the VGA test, it still has the VGA no signal issue. And we remove the
> I915 module from initramfs from kernel 4.11.0-rc7+ then do the test again,
> the VGA no signal issue is gone.
> 
> We can reproduce it with drm-intel-nightly, please assist to check it, thank

Thanks for checking.  Can you run your kernel with drm.debug=0xf, reproduce the problem and provide the dmesg?

Hi Sir,

We added kernel with drm.debug=0xf, reproduce the problem and recorded the dmesg log as shown in attachments.

[dmesg_after_booting_up.log]:

dmesg after booting up the OS with VGA cable connected.


[dmesg_after_pull_out_VGA.log]:

dmesg after pull out then pull in the VGA cable (VGA got no signal issue).


Amy Shih
Amy.Shih@advantech.com.tw

Created attachment 131397 [details]
dmesg after booting up the OS with VGA cable connected.

Created attachment 131398 [details]
dmesg after pull out then pull in the VGA cable (VGA got no signal issue).

Hi Sir,

Any update on this issue? Thank you!

Amy Shih
Amy.Shih@advantech.com.tw

Hi, unfortunately we do not have a Xeon Processor to check this issue. 
However this issue is not seen on an APL NuC on Fedora25 OS with the following kernel:
4.10.15-200.fc25.x86_64

Hi Sir,

Did you find any valuable information or the root cause on the demsg log? Thank you!

Amy Shih
Amy.Shih@advantech.com.tw

The hardware in question does not have VGA natively. There's a DP-to-VGA branch adapter. The unplug can be seen in the logs, but there's no hotplug event for the re-plug.

Please try this:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1ae9de5cf39c..0d28b6dc4153 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2468,6 +2468,8 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
 {
 	int ret, i;
 
+	return;
+
 	/* Should have a valid DPCD by this point */
 	if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
 		return;

Hi Sir,

We added the function "intel_dp_sink_dpmspatch" patch on "drm-intel-nightly" source code & rebuild the kernel, the VGA no signal issue is gone.

We also test the patch on CentOS 7.3.1611 with kernel 3.10.0-514.10.2, the VGA no signal issue is also gone.

Enclosed dmesg logs are for patch on "drm-intel-nightly" source code.

[patch_dmesg_after_boot_up.log]:

dmesg after booting up the OS with VGA cable connected.


[patch_dmesg_after_pull_out_VGA_cable.log]:

dmesg after pull out VGA cable.

[patch_dmesg_after_pull_in_VGA_cable.log]

dmesg after pull in VGA cable.

Could you explain why we need to add this patch to make VGA work & does this patch have any side effect? 

Thank you!

Amy Shih
Amy.Shih@advantech.com.tw

Created attachment 131498 [details]
dmesg after booting up the OS with VGA cable connected.

Created attachment 131499 [details]
with patch dmesg after pull out VGA cable.

Created attachment 131500 [details]
with patch dmesg after pull in VGA cable.

(In reply to amy.shih from comment #13)
> Could you explain why we need to add this patch to make VGA work & does this
> patch have any side effect?

Without the patch, we tell the DP sink (or, in this case, the DP branch device, the DP-to-VGA converter) to go to power save mode when we disable it. Apparently the branch device in question doesn't wake up like other devices, and sleeps forever instead of waking up on hotplug.

If the logs in comment #8 are to be trusted, we really don't get a hotplug event from the branch device anymore, so we won't even try to talk to it to wake it up.

The drawback with the patch is that it'll potentially waste power.

For upstream the options are to disable power savings everywhere because of some misbehaving sink/branch devices, or to add a sink specific quirk. Unfortunately in this case, the branch device doesn't support DPCD OUI, so I'm not sure what we could base the identification for the quirk on. :(

Long ago I came up with this to fix my dongle:
https://lists.freedesktop.org/archives/intel-gfx/2015-July/070788.html
I'll have to re-test to see if my dongle still needs that or not.

Also there's a BRANCH_DEVICE_CTRL register in DPCD which supposedly allows you to select whether short or long pulses are used for HPD notifications. It should default to long pulse, but at least my dongle used to do short pulses by default back when I came up with that patch. I don't think I ever tried to play around with BRANCH_DEVICE_CTRL on my dongle to see if it made any difference. I should do that as well.

Any updates to this bug?

Hi Sir,

Does this patch can be use on any kernel & distribution? Thank you!


Amy Shih
Amy.Shih@advantech.com.tw

Could a solution here be that if we have a branch device that doesn't support DPCD OUI we set DPMS OFF in that case as Ville's patch suggests?

(In reply to Mika Kahola from comment #22)
> Could a solution here be that if we have a branch device that doesn't
> support DPCD OUI we set DPMS OFF in that case as Ville's patch suggests?

We might want to limit this to DPCD 1.1 devices as those don't have the BRANCH_DEVICE_CTRL register, and for DPCD 1.2+ we should perhaps just try to frob BRANCH_DEVICE_CTRL to use long pulses instead. In fact long pulse should be the default, but I'm not sure I'd trust these things that far. Not sure we can even trust that they respect the setting in BRANCH_DEVICE_CTRL at all, but at least we could try it and see.

Created attachment 132114 [details] [review]
DP branch device quirk

I had something like this patch in mind. As Ville suggested, let's limit this DP branch device quirk only for DPCD 1.1 devices.

As I can't replicate this issue with my Xeon, I would need Amy's support to test this patch if it fixes the issue.

Reporter, please respond back if patch done by Mika solves your issue?

As no response in timely manner, will close now. 
If this is still issue please check patch attached and report back.

Hi Sir,

We will test this patch before September, thank you!


Amy Shih
Amy.Shih@advantech.com.tw

Hi Sir,

We want to test the patch on CentOS 7.3.1611 with kernel 3.10.0-514.10.2, but the codes are not matching. We can't find "dpcd_quirk dpcd_quirk_list" & "enum drm_dp_quirk" in CentOS 7.3.1611 source code. Does the patch you provide need to add on special kernel source? Thank you!

Amy Shih
Amy.Shih@advantech.com.tw

Thanks for trying it. The patch should apply on top of the drm-tip kernel. You can clone the kernel from

https://anongit.freedesktop.org/git/drm-tip.git

Hi Sir,

If the patch fix the issue on drm-tip kernel. How about other kernel & distribution? Thank you!

Amy Shih
Amy.Shih@advantech.com.tw

If it turns out that the patch fixes the issue on drm-tip it will eventually be merged upstream and later on to distributions. Of course, this will take some time until it surfaces to distribution. 

Of course, there is always a possibility to backport it to earlier kernels.

Hi Sir,

Got it. We will test the patch on drm-tip kernel once the board is available and feedback the testing result in here. Thank you!

Amy Shih
Amy.Shih@advantech.com.tw

Hi Sir,

We add the patch on drm-tip kernel, and execute below commands:


1. make menuconfig
2. make -j8

Got below errors:

/tmp/ccKOCfDx.o: In function `main':
sign-file.c:(.text.startup+0x40): undefined reference to `OPENSSL_init_crypto'
sign-file.c:(.text.startup+0x4c): undefined reference to `OPENSSL_init_crypto'
sign-file.c:(.text.startup+0x652): undefined reference to `OPENSSL_init_crypto'
collect2: error: ld returned 1 exit status
make[1]: *** [scripts/sign-file] Error 1
make[1]: *** Waiting for unfinished jobs....
  CHK     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  CC      arch/x86/kernel/asm-offsets.s
/tmp/cciUZYQG.o: In function `main':
extract-cert.c:(.text.startup+0x15): undefined reference to `OPENSSL_init_crypto'
extract-cert.c:(.text.startup+0x21): undefined reference to `OPENSSL_init_crypto'
collect2: error: ld returned 1 exit status
make[1]: *** [scripts/extract-cert] Error 1
make: *** [scripts] Error 2
make: *** Waiting for unfinished jobs....
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh

We had tried different versions of openssl as listed in below, but all got the same error. Our building environment is CentOS Linux release 7.3.1611 (Core) with kernel 3.10.0-514.10.2.el7.x86_64.

openssl-1.0.2a
openssl-1.0.2l
openssl-1.0.1g
openssl-1.1.0f
openssl-1.0.1 


Amy Shih
Amy.Shih@advantech.com.tw

(In reply to amy.shih from comment #33)
> Hi Sir,
> 
> We add the patch on drm-tip kernel, and execute below commands:
> 
> 
> 1. make menuconfig
> 2. make -j8
> 
> Got below errors:

The errors are unrelated to drm/i915.