Bug 95141 - [BYT] Displayport signals stay on after monitor is unplugged
Summary: [BYT] Displayport signals stay on after monitor is unplugged
Status: CLOSED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Manasi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-26 00:11 UTC by roberth
Modified: 2016-05-13 14:56 UTC (History)
6 users (show)

See Also:
i915 platform: BYT
i915 features: display/DP


Attachments
lspci -vvnn (9.26 KB, text/plain)
2016-04-26 00:11 UTC, roberth
no flags Details
dmesg and register dump before plugging in (1.02 MB, text/plain)
2016-04-26 00:11 UTC, roberth
no flags Details
dmesg and register dumpafter plugging in DP (1.02 MB, text/plain)
2016-04-26 00:11 UTC, roberth
no flags Details
dmesg and register dump after unplugging DP (1.02 MB, text/plain)
2016-04-26 00:12 UTC, roberth
no flags Details
4530.displayport.bmp-344x509.jpg (32.37 KB, text/plain)
2016-04-27 01:59 UTC, XiongZhang
no flags Details
after boot, before plugging DP in (109.10 KB, text/plain)
2016-05-03 00:56 UTC, roberth
no flags Details
after plugging in DP (14.29 KB, text/plain)
2016-05-03 00:56 UTC, roberth
no flags Details
after unplugging DP (4.16 KB, text/plain)
2016-05-03 00:56 UTC, roberth
no flags Details

Description roberth 2016-04-26 00:11:00 UTC
Created attachment 123258 [details]
lspci -vvnn

System environment:
-- chipset: 00:02.0 VGA compatible controller [0300]: Intel Corporation ValleyView Gen7 [8086:0f31] (rev 11) (prog-if 00 [VGA controller])
-- system architecture: 64-bit
-- xf86-video-intel: 2:2.99.910-0ubuntu1.6
-- xserver: 1.15.1-0ubuntu2.7
-- mesa: 10.1.3-0ubuntu0.4
-- libdrm: 2.4.56-1~ubuntu2
-- kernel: 3.13, with drm from 4.2-rc5 backported
-- Linux distribution: Ubuntu 14.04
-- Display connector: DP, eDP


Forwarding this from a Boston Scientific bug on launchpad:

"The electrical testing of the (baytrail) system has indicated that there are very high noise levels when an external monitor is connected via the display port. These levels remain the same even after the monitor is disconnected. Note, when no monitor is ever connected the noise levels are much lower and acceptable. This points to active data signals as the issue.

My request is to have the active data signals stop once a monitor is disconnected. They should return when a monitor is connected as we can't break hot plug. At a high level, we want all display port activity/signals to look the same as when no monitor is ever connected.

So two states of display port:

Inactive and Active. Right now the state remains in "active" when the external monitor is disconnected. We want the state to change to "inactive" when the external monitor is disconnected."

Also a followup response

"We are measuring the EMC at an external test house. It is 60601 standards testing which is required for any medical device submission. Right now we fail with display port active. That is the primary reason for this bug. We don't have a product if we can't pass this test."

Are there any ways around this for BYT?
Comment 1 roberth 2016-04-26 00:11:27 UTC
Created attachment 123259 [details]
dmesg and register dump before plugging in
Comment 2 roberth 2016-04-26 00:11:54 UTC
Created attachment 123260 [details]
dmesg and register dumpafter plugging in DP
Comment 3 roberth 2016-04-26 00:12:18 UTC
Created attachment 123261 [details]
dmesg and register dump after unplugging DP
Comment 4 XiongZhang 2016-04-27 01:59:48 UTC
Created attachment 123288 [details]
4530.displayport.bmp-344x509.jpg

So on the 4.2 drm/i915 that the laramie image is using, it is getting 50-70mv on most pins (except 3.29v on HPD) on boot, then it is clear the lines stay on after hooking up a dp monitor and unplugging it. I'm using the attached diagram to know which pin is which.

One thing I noticed is ML_Lane3 is off when its never been plugged in but it stays on also after plugging in and unplugging also.

some examples on 4.2:

on boot
50mv-70 on pin 1
50mv-70 on pin 3
0 on on pin 5
20mv on on pin 7
70mv on on pin 9
0 on pin 12
120 on pin 15
3.29v on 18 (HPD)

after plugging and unplugging a dp monitor
240mv on pin 1
130mv on pin 3
230mv on pin 4
220mv on pin 6
40mv on pin 7
130mv on pin 9
120mv on pin 10
214mv on pin 12
3.29V on pin 18 (HPD)

On the Xenial stock 4.4 kernel the lines are powered up all of the time after boot and have similar values to the above post unplugging values. The same is true on 20160426 drm-intel-nightly. The eDP internal monitor does not work on that drm-intel-nightly but the DP still works and it is obvious the ports are powered on all of the time. I tried with an ivybridge system and the lines are powered all of the time there too on a 4.4 kernel.
Comment 5 Jani Nikula 2016-04-27 07:41:32 UTC
Do you have a userspace responding to hotpug uevents from the kernel?
Comment 6 roberth 2016-04-27 15:35:08 UTC
(In reply to Jani Nikula from comment #5)
> Do you have a userspace responding to hotpug uevents from the kernel?

yeah, the 4.2 environment is a bare openbox uses a udev rule that calls http://paste.ubuntu.com/16082580/ to handle it, the 4.4 and drm-intel-nightly testing was done on stock ubuntu 16.04
Comment 7 Manasi 2016-04-28 19:40:49 UTC
In order to reproduce the bug, I did some PHY testing here on my system with drm-intel-nightly (kernel 4.6.0-rc4). I hooked up the HPD and data lines to  the oscilloscope to see the signal levels after the DP monitor is disconnected. And I saw that signal levels were as low as -1mv after the DP monitor is disconnected. Also the HPD signal is 0V DC on the DP disconnect. So I am not able to reproduce the issue that you are seeing.
For me to root cause this bug, I would need the following information from you:
- Could you also hook up the data signals to the oscilloscope and verify if there is any signal on those lines after the DP monitor is disconnected.
- From the data you provided, it is strange that the HPD signal is 3.29V on  boot. Was this system booted with DP connected? How did you measure this electrical signal level? 
- If the DP is not connected on boot and you plug it in later, does the DP monitor display it properly and it works?
- Could you send separate dmesg logs for :
     Boot without DP connected
     Then dmesg -c to clear dmesg
     Plug in DP cable and collect logs
     dmesg -c
     Unplug and collect logs
- Please send the picture of the motherboard to see the connections of the HPD pin on the motherboard. Also send us the schematics of the same if you have.
Comment 8 roberth 2016-05-03 00:54:38 UTC
(In reply to Manasi from comment #7)
> In order to reproduce the bug, I did some PHY testing here on my system with
> drm-intel-nightly (kernel 4.6.0-rc4). I hooked up the HPD and data lines to 
> the oscilloscope to see the signal levels after the DP monitor is
> disconnected. And I saw that signal levels were as low as -1mv after the DP
> monitor is disconnected. Also the HPD signal is 0V DC on the DP disconnect.
> So I am not able to reproduce the issue that you are seeing.
> For me to root cause this bug, I would need the following information from
> you:
> - Could you also hook up the data signals to the oscilloscope and verify if
> there is any signal on those lines after the DP monitor is disconnected.

I do not have an oscilloscope to verify, I'm just using a voltmeter and it was showing signals on after unplugging DP from what I saw. I can see if the customer does if that would help though? 

> - From the data you provided, it is strange that the HPD signal is 3.29V on 
> boot. Was this system booted with DP connected? How did you measure this
> electrical signal level? 


I am plugging in a dp cord and measuring it on the pins there with a voltmeter with one end on the plug case and the other on the pin. Would that make it give false results? I have been unable to measure directly on the displayport connector on the machine because it is so small, but I will try again if so.


> - If the DP is not connected on boot and you plug it in later, does the DP
> monitor display it properly and it works?


Yeah that works fine, and there are no excess emissions in that case according to their testing also.


> - Could you send separate dmesg logs for :
>      Boot without DP connected
>      Then dmesg -c to clear dmesg
>      Plug in DP cable and collect logs
>      dmesg -c
>      Unplug and collect logs


This is what I posted in comments 1-3, but I did it again on 4.4.0 and will attach those. drm-intel-nightly and drm-intel-next both do not work on this machine, no displays ever get brought up including the internal one. Would logs from 4.6.0-rc6 be acceptable? What drm.debug level would be most helpful?


> - Please send the picture of the motherboard to see the connections of the
> HPD pin on the motherboard. Also send us the schematics of the same if you
> have.


Will do ASAP, I will ask for schematics as well to forward them.
Comment 9 roberth 2016-05-03 00:56:02 UTC
Created attachment 123425 [details]
after boot, before plugging DP in
Comment 10 roberth 2016-05-03 00:56:28 UTC
Created attachment 123426 [details]
after plugging in DP
Comment 11 roberth 2016-05-03 00:56:42 UTC
Created attachment 123427 [details]
after unplugging DP
Comment 12 roberth 2016-05-03 01:03:06 UTC
as a side note, I did notice the DPCD rev and size for the CRTC do seem to stay around in /sys/kernel/debug/dri/0/i915_display_info after you unplug it, not sure if that is normal.
Comment 13 Jani Nikula 2016-05-03 07:55:25 UTC
(In reply to roberth from comment #12)
> as a side note, I did notice the DPCD rev and size for the CRTC do seem to
> stay around in /sys/kernel/debug/dri/0/i915_display_info after you unplug
> it, not sure if that is normal.

Does it say the CRTC is active?
Comment 14 roberth 2016-05-12 17:37:44 UTC
It turns out this was caused by an adapter they were using during testing in the end so I'm closing this. Thank you


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.