Hi.
With Linux 4.4 external HDMI-attached monitor in not discovered by i915 driver. Here is boot log related to drm and i915 for Linux 4.4/4.4.1 kernel:
=== kernel: [drm] Initialized drm 1.1.0 20060810 kernel: [drm] Memory usable by graphics device = 2048M kernel: [drm] Replacing VGA console driver kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). kernel: [drm] Driver supports precise vblank timestamp query. kernel: [drm] Initialized i915 1.6.0 20151010 for 0000:00:02.0 on minor 0 kernel: i915 0000:00:02.0: No connectors reported connected with modes kernel: [drm] Cannot find any crtc or sizes - going 1024x768 kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ===
i915 is unable to find any connectors. Reattaching HDMI cable does not help. Note, we are talking about in-kernel i915 drm with no X involved (launching X does not change anything, though).
Linux 4.3 worked OK. Here is boot log for 4.3 kernel:
=== kernel: [drm] Initialized drm 1.1.0 20060810 kernel: [drm] Memory usable by graphics device = 2048M kernel: [drm] Replacing VGA console driver kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). kernel: [drm] Driver supports precise vblank timestamp query. kernel: [drm] Initialized i915 1.6.0 20150731 for 0000:00:02.0 on minor 0 kernel: [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ===
Hardware:
=== [~]$ lscpu | grep "Model name" Model name: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz
[~]$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) ===
and xrandr output (with 4.3 kernel):
=== [~]$ xrandr --listproviders Providers: number : 1 Provider 0: id: 0x47 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:Intel
[~]$ xrandr Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 290mm 1920x1080 60.00*+ 50.00 59.94 1920x1080i 60.00 50.00 59.94 1680x1050 59.88 1400x1050 59.95 1600x900 60.00 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1152x864 59.97 1280x720 60.00 50.00 59.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.00 59.94 640x480 60.00 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) ===
Ideas?
On Mon, Feb 08, 2016 at 12:17:07PM +0200, Oleksandr Natalenko wrote:
Hi.
With Linux 4.4 external HDMI-attached monitor in not discovered by i915 driver. Here is boot log related to drm and i915 for Linux 4.4/4.4.1 kernel:
=== kernel: [drm] Initialized drm 1.1.0 20060810 kernel: [drm] Memory usable by graphics device = 2048M kernel: [drm] Replacing VGA console driver kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). kernel: [drm] Driver supports precise vblank timestamp query. kernel: [drm] Initialized i915 1.6.0 20151010 for 0000:00:02.0 on minor 0 kernel: i915 0000:00:02.0: No connectors reported connected with modes kernel: [drm] Cannot find any crtc or sizes - going 1024x768 kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ===
i915 is unable to find any connectors. Reattaching HDMI cable does not help. Note, we are talking about in-kernel i915 drm with no X involved (launching X does not change anything, though).
Linux 4.3 worked OK. Here is boot log for 4.3 kernel:
=== kernel: [drm] Initialized drm 1.1.0 20060810 kernel: [drm] Memory usable by graphics device = 2048M kernel: [drm] Replacing VGA console driver kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). kernel: [drm] Driver supports precise vblank timestamp query. kernel: [drm] Initialized i915 1.6.0 20150731 for 0000:00:02.0 on minor 0 kernel: [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ===
Hardware:
=== [~]$ lscpu | grep "Model name" Model name: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz
[~]$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) ===
and xrandr output (with 4.3 kernel):
=== [~]$ xrandr --listproviders Providers: number : 1 Provider 0: id: 0x47 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:Intel
[~]$ xrandr Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 290mm 1920x1080 60.00*+ 50.00 59.94 1920x1080i 60.00 50.00 59.94 1680x1050 59.88 1400x1050 59.95 1600x900 60.00 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1152x864 59.97 1280x720 60.00 50.00 59.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.00 59.94 640x480 60.00 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) ===
Ideas?
Can you please retest with latest -rc? There's been some bugs in the HDMI detection changes, which should be fixed now.
If that doesn't help please try to bisect which exact change caused the regression.
Thanks, Daniel
4.5-rc3 is affected as well:
=== kernel: [drm] Initialized drm 1.1.0 20060810 kernel: [drm] Memory usable by graphics device = 2048M kernel: [drm] Replacing VGA console driver kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). kernel: [drm] Driver supports precise vblank timestamp query. kernel: [drm] Initialized i915 1.6.0 20151218 for 0000:00:02.0 on minor 0 kernel: i915 0000:00:02.0: No connectors reported connected with modes kernel: [drm] Cannot find any crtc or sizes - going 1024x768 kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ===
Will try to apply the following dirty workaround:
https://lkml.org/lkml/2016/1/19/637
I guess the problem described via the link above is not fixed yet:
This issue is still present in 4.5-rc1.
Stay tuned.
09.02.2016 12:11, Daniel Vetter написав:
Can you please retest with latest -rc? There's been some bugs in the HDMI detection changes, which should be fixed now.
If that doesn't help please try to bisect which exact change caused the regression.
Thanks, Daniel
Daniel,
I do confirm that this hacky patch:
https://lkml.org/lkml/2016/1/19/637
works around my issue. I understand that this is improper fix, so let me know how could I debug my issue further.
Thanks.
09.02.2016 12:11, Daniel Vetter wrote:
Can you please retest with latest -rc? There's been some bugs in the HDMI detection changes, which should be fixed now.
If that doesn't help please try to bisect which exact change caused the regression.
Thanks, Daniel
On Thu, Feb 11, 2016 at 09:45:17AM +0200, Oleksandr Natalenko wrote:
Daniel,
I do confirm that this hacky patch:
https://lkml.org/lkml/2016/1/19/637
works around my issue. I understand that this is improper fix, so let me know how could I debug my issue further.
Please boot with drm.debug=0xe and attach the dmesg. Also please test the patch later on in this thread:
https://lkml.org/lkml/2016/2/9/587
Ville is working on a proper fix for this specific case. But could be that you're hitting yet another issue.
Thanks, Daniel
Thanks.
09.02.2016 12:11, Daniel Vetter wrote:
Can you please retest with latest -rc? There's been some bugs in the HDMI detection changes, which should be fixed now.
If that doesn't help please try to bisect which exact change caused the regression.
Thanks, Daniel
Daniel,
I've already tried Ville's patch you've mentioned with no luck.
Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1]
[1] https://gist.github.com/efb44b7c6bc325978b80
11.02.2016 10:21, Daniel Vetter wrote:
Please boot with drm.debug=0xe and attach the dmesg. Also please test the patch later on in this thread:
https://lkml.org/lkml/2016/2/9/587
Ville is working on a proper fix for this specific case. But could be that you're hitting yet another issue.
On Thu, Feb 11, 2016 at 10:54:08AM +0200, Oleksandr Natalenko wrote:
Daniel,
I've already tried Ville's patch you've mentioned with no luck.
Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1]
That's an IVB. So no wonder my patch doesn't help.
Can you grab another dmesg after disconnecting and reconnecting the HDMI cable?
11.02.2016 10:21, Daniel Vetter wrote:
Please boot with drm.debug=0xe and attach the dmesg. Also please test the patch later on in this thread:
https://lkml.org/lkml/2016/2/9/587
Ville is working on a proper fix for this specific case. But could be that you're hitting yet another issue.
Ville,
here is another dmesg: [1]
I've reconnected HDMI cable three times.
Forgot to note, it is HDMI monitor plugged into machine's DVI with HDMI-DVI cable. I guess this should matter as well.
[1] https://gist.github.com/7057ea8512b9aa7ee5bd
11.02.2016 11:26, Ville Syrjälä написав:
On Thu, Feb 11, 2016 at 10:54:08AM +0200, Oleksandr Natalenko wrote:
Daniel,
I've already tried Ville's patch you've mentioned with no luck.
Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1]
That's an IVB. So no wonder my patch doesn't help.
Can you grab another dmesg after disconnecting and reconnecting the HDMI cable?
On Thu, Feb 11, 2016 at 01:16:53PM +0200, Oleksandr Natalenko wrote:
Ville,
here is another dmesg: [1]
I've reconnected HDMI cable three times.
Forgot to note, it is HDMI monitor plugged into machine's DVI with HDMI-DVI cable. I guess this should matter as well.
Shouldn't really matter. HDMI and DVI are identical at this level.
OK, so the hpd interrupt does happen, and yet the live status supposedly claims that nothing is there. Port C live status definitely works here on my IVB, so not sure what the deal is.
Can you grab intel-gpu-tools and run intel_reg read 0xc4000 0xc4004 0xc4008 0xc400c 0xc4030 a couple of times after plugging the monitor in, and also run it when nothing is plugged in.
Also you could try something like the following patch so we might observe the live status with a bit more detail. Though the fact that it doesn't seem to work for you even when the monitor was already plugged in is somewhat troubling:
--- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1392,12 +1392,17 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
- for (try = 0; !live_status && try < 9; try++) { - if (try) - msleep(10); - live_status = intel_digital_port_connected(dev_priv, + printk("port %c live status\n ", port_name(hdmi_to_dig_port(intel_hdmi)->port)); + for (try = 0; try < 250; try++) { + bool status = intel_digital_port_connected(dev_priv, hdmi_to_dig_port(intel_hdmi)); + live_status |= status; + printk("%c", status ? '#' : '_'); + if (try % 50 == 49) + printk("\n "); + usleep_range(1000, 1000); } + printk("\n");
if (!live_status) DRM_DEBUG_KMS("Live status not up!");
Ville,
I've applied patch you've provided and did couple of replugging with intel_reg in between. Here are the results.
I used additional VGA cable to see what actually I type in console :).
Both HDMI and VGA cables plugged: [1] Both HDMI and VGA cables unplugged: [2] Only HDMI cable plugged: [3] Only VGA cable plugged: [4]
And here goes dmesg with all the stuff logged: [5]
Hope this helps.
[1] https://gist.github.com/58a0eb50dcf84e104555 [2] https://gist.github.com/7e8749a3e2cc58ea8aac [3] https://gist.github.com/9d76930da7380634b845 [4] https://gist.github.com/c0d2e2f64242ad4f01f2 [5] https://gist.github.com/fda3b9fed3ca4d31cd20
11.02.2016 16:01, Ville Syrjälä wrote:
OK, so the hpd interrupt does happen, and yet the live status supposedly claims that nothing is there. Port C live status definitely works here on my IVB, so not sure what the deal is.
Can you grab intel-gpu-tools and run intel_reg read 0xc4000 0xc4004 0xc4008 0xc400c 0xc4030 a couple of times after plugging the monitor in, and also run it when nothing is plugged in.
Also you could try something like the following patch so we might observe the live status with a bit more detail. Though the fact that it doesn't seem to work for you even when the monitor was already plugged in is somewhat troubling:
--- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1392,12 +1392,17 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
- for (try = 0; !live_status && try < 9; try++) {
if (try)msleep(10);live_status = intel_digital_port_connected(dev_priv,
- printk("port %c live status\n ",
port_name(hdmi_to_dig_port(intel_hdmi)->port));
for (try = 0; try < 250; try++) {
bool status = intel_digital_port_connected(dev_priv, hdmi_to_dig_port(intel_hdmi));live_status |= status;printk("%c", status ? '#' : '_');if (try % 50 == 49)printk("\n ");usleep_range(1000, 1000);}
printk("\n");
if (!live_status) DRM_DEBUG_KMS("Live status not up!");
-- 2.4.10
Oh, and if you have another cable you can try, might be a good idea to see if it behaves any better.
On Fri, Feb 12, 2016 at 09:52:03AM +0200, Oleksandr Natalenko wrote:
Ville,
I've applied patch you've provided and did couple of replugging with intel_reg in between. Here are the results.
I used additional VGA cable to see what actually I type in console :).
My life would have been a bit easier if you had included the reg dumps in the mail. Copy paste manually this time.
Both HDMI and VGA cables plugged: [1]
(0x000c4000): 0x00080000 (0x000c4004): 0xf1b5ffff (0x000c4008): 0x00000000 (0x000c400c): 0xffffffff (0x000c4030): 0x00101010
Both HDMI and VGA cables unplugged: [2]
(0x000c4000): 0x00000000 (0x000c4004): 0xf1b5ffff (0x000c4008): 0x00000000 (0x000c400c): 0xffffffff (0x000c4030): 0x00101010
Only HDMI cable plugged: [3]
(0x000c4000): 0x00000000 (0x000c4004): 0xf1b5ffff (0x000c4008): 0x00000000 (0x000c400c): 0xffffffff (0x000c4030): 0x00101010
Only VGA cable plugged: [4]
(0x000c4000): 0x00080000 (0x000c4004): 0xf1b4ffff (0x000c4008): 0x00000000 (0x000c400c): 0xffffffff (0x000c4030): 0x00101010
What these show is that the live status for the digital ports never goes to 1, which is rather wtf. VGA gets reported correctly. Everything else looks normal to me.
And here goes dmesg with all the stuff logged: [5]
лют 12 09:37:01 pfactum.lanet kernel: port C live status __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________
Same deal here. The live status never indicates anything being present during the 250ms that we poll it.
Few other ideas: - Was the monitor sleeping when you tried this? Can you maybe push some button on it and then immediately run the intel_reg read command again? - Do you have another monitor to try? - Do you have another cable to try? - Maybe the pullup/down on the hpd line is misconfigured or something. Any chance of updating the BIOS on the machine? - What does 'intel_reg read 0xc2000 0xc2004 0xc2020' say? - The spec claims the TMDS vs. SDVO select has something to do with hpd generation. I can't see any difference on my IVB though, so not sure it's really true.
What does 'intel_reg read 0xe1140 0xe1150 0xe1160' tell us?
Let's try these anyway (with the cable plugged in):
intel_reg write 0xe1140 0x0 intel_reg write 0xe1150 0x0 intel_reg write 0xe1160 0x0 sleep 1 intel_reg read 0xc4000
intel_reg write 0xe1140 0x800 intel_reg write 0xe1150 0x800 intel_reg write 0xe1160 0x800 sleep 1 intel_reg read 0xc4000
intel_reg write 0xe1140 0x800800 intel_reg write 0xe1150 0x800800 intel_reg write 0xe1160 0x800800 sleep 1 intel_reg read 0xc4000
intel_reg write 0xe1140 0x800000 intel_reg write 0xe1150 0x800000 intel_reg write 0xe1160 0x800000 sleep 1 intel_reg read 0xc4000
Hope this helps.
[1] https://gist.github.com/58a0eb50dcf84e104555 [2] https://gist.github.com/7e8749a3e2cc58ea8aac [3] https://gist.github.com/9d76930da7380634b845 [4] https://gist.github.com/c0d2e2f64242ad4f01f2 [5] https://gist.github.com/fda3b9fed3ca4d31cd20
11.02.2016 16:01, Ville Syrjälä wrote:
OK, so the hpd interrupt does happen, and yet the live status supposedly claims that nothing is there. Port C live status definitely works here on my IVB, so not sure what the deal is.
Can you grab intel-gpu-tools and run intel_reg read 0xc4000 0xc4004 0xc4008 0xc400c 0xc4030 a couple of times after plugging the monitor in, and also run it when nothing is plugged in.
Also you could try something like the following patch so we might observe the live status with a bit more detail. Though the fact that it doesn't seem to work for you even when the monitor was already plugged in is somewhat troubling:
--- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1392,12 +1392,17 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
- for (try = 0; !live_status && try < 9; try++) {
if (try)msleep(10);live_status = intel_digital_port_connected(dev_priv,
- printk("port %c live status\n ",
port_name(hdmi_to_dig_port(intel_hdmi)->port));
for (try = 0; try < 250; try++) {
bool status = intel_digital_port_connected(dev_priv, hdmi_to_dig_port(intel_hdmi));live_status |= status;printk("%c", status ? '#' : '_');if (try % 50 == 49)printk("\n ");usleep_range(1000, 1000);}
printk("\n");
if (!live_status) DRM_DEBUG_KMS("Live status not up!");
-- 2.4.10
Oh, and if you have another cable you can try, might be a good idea to see if it behaves any better.
Hi, Ville.
13.02.2016 01:23, Ville Syrjälä wrote:
Few other ideas:
- Was the monitor sleeping when you tried this? Can you maybe push some button on it and then immediately run the intel_reg read command again?
Nope. It just goes to sleep mode after (I suppose) drm module is loaded. Before module gets loaded monitor displays console as it should and does not sleep. However, I've tried to switch monitor inputs as well as pushing power button with no luck.
- Do you have another monitor to try?
- Do you have another cable to try?
Will find that.
- Maybe the pullup/down on the hpd line is misconfigured or something. Any chance of updating the BIOS on the machine?
=== Base Board Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: H61M-K BIOS Information Vendor: American Megatrends Inc. Version: 0801 Release Date: 07/21/2014 ===
0801 is the latest available for this board.
- What does 'intel_reg read 0xc2000 0xc2004 0xc2020' say?
=== (0x000c2000): 0x00000000 (0x000c2004): 0x00000001 (0x000c2020): 0x60004000 ===
The spec claims the TMDS vs. SDVO select has something to do with hpd generation. I can't see any difference on my IVB though, so not sure it's really true.
What does 'intel_reg read 0xe1140 0xe1150 0xe1160' tell us?
=== HDMIB (0x000e1140): 0x00000018 (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected) HDMIC (0x000e1150): 0x00000804 (disabled pipe A 8bpc TMDS DVI audio disabled -vsync -hsync detected) HDMID (0x000e1160): 0x00000018 (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected) ===
Let's try these anyway (with the cable plugged in):
intel_reg write 0xe1140 0x0 intel_reg write 0xe1150 0x0 intel_reg write 0xe1160 0x0 sleep 1 intel_reg read 0xc4000
intel_reg write 0xe1140 0x800 intel_reg write 0xe1150 0x800 intel_reg write 0xe1160 0x800 sleep 1 intel_reg read 0xc4000
intel_reg write 0xe1140 0x800800 intel_reg write 0xe1150 0x800800 intel_reg write 0xe1160 0x800800 sleep 1 intel_reg read 0xc4000
intel_reg write 0xe1140 0x800000 intel_reg write 0xe1150 0x800000 intel_reg write 0xe1160 0x800000 sleep 1 intel_reg read 0xc4000
Same output for all 4 sets of commands:
=== (0x000c4000): 0x00000000 ===
Regards, Oleksandr.
13.02.2016 01:23, Ville Syrjälä wrote:
- Do you have another monitor to try?
- Do you have another cable to try?
Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— DVI-DVI cable —— another monitor DVI == works
So
Shouldn't really matter. HDMI and DVI are identical at this level.
Not quite, as far as I can see.
On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
13.02.2016 01:23, Ville Syrjälä wrote:
- Do you have another monitor to try?
- Do you have another cable to try?
Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— DVI-DVI cable —— another monitor DVI == works
So
Shouldn't really matter. HDMI and DVI are identical at this level.
Not quite, as far as I can see.
Well, it seems this particular monitor is just somehow funky. It's a bit strange that the hpd interrupt still works. It would seem to indicate that there's two separate voltage thresholds for detection, one for the hpd generation, and another for the live status. I did see something similar on another platforms (CHV) where it had two different hpd detection registers, and those produced different results when the pullup on the hpd pin was misconfigured.
Anyway, I'm out of ideas now :( Anyone else got something up their sleeve?
I'm starting to think this is going to be our only option: - if (intel_hdmi_set_edid(connector, live_status)) { + if (intel_hdmi_set_edid(connector, true)) {
It would more or less turn the live status check into a fixed msleep(80) for the disconnect case. For the connect case it would still break out sooner when live status works.
The downside is that if the cable is yanked slowly, we'll still succeed in the ddc communication during unplug and thus fail to notice that the monitor was actually disconnected. But the delay should make that less likely.
On Mon, Feb 15, 2016 at 04:42:35PM +0200, Ville Syrjälä wrote:
On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
13.02.2016 01:23, Ville Syrjälä wrote:
- Do you have another monitor to try?
- Do you have another cable to try?
Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— DVI-DVI cable —— another monitor DVI == works
So
Shouldn't really matter. HDMI and DVI are identical at this level.
Not quite, as far as I can see.
Well, it seems this particular monitor is just somehow funky. It's a bit strange that the hpd interrupt still works. It would seem to indicate that there's two separate voltage thresholds for detection, one for the hpd generation, and another for the live status. I did see something similar on another platforms (CHV) where it had two different hpd detection registers, and those produced different results when the pullup on the hpd pin was misconfigured.
Anyway, I'm out of ideas now :( Anyone else got something up their sleeve?
I'm starting to think this is going to be our only option:
if (intel_hdmi_set_edid(connector, live_status)) {
if (intel_hdmi_set_edid(connector, true)) {It would more or less turn the live status check into a fixed msleep(80) for the disconnect case. For the connect case it would still break out sooner when live status works.
The downside is that if the cable is yanked slowly, we'll still succeed in the ddc communication during unplug and thus fail to notice that the monitor was actually disconnected. But the delay should make that less likely.
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
Thanks, Daniel
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
16.02.2016 14:54, Daniel Vetter wrote:
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
not working
I presume the above LG screen is what you've called previously "old monitor"?
Correct.
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
OK, but will have to steal it again, as it is the only dual link cable I could find on another workplace.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
Single-link cable is enough to empower LG 23MP65HQ-P as its standard resolution is 1920×1080@60, which is supported by single-link cable.
Dual-link cable comes with 27MP55HQ-P where it is required to provide higher resolution. BTW, in my previous email one should read "27MP55HQ-P" (not "23MP55HQ-P"). It is 27" monitor. Also, this monitor works with single-link cable (but at lower resolution, I guess).
Here is full dmesg with verbose patch on 4.4.1 and dual-link DVI-HDMI cable: [1]
Dual-link works OK:
=== лют 16 17:46:38 pfactum.lanet kernel: port C live status
##################################################
##################################################
##################################################
##################################################
################################################## ===
Also:
=== [~]$ sudo intel_reg read 0xc4000 0xc4004 0xc4008 0xc400c 0xc4030 (0x000c4000): 0x00400000 (0x000c4004): 0xf1b4ffff (0x000c4008): 0x00000000 (0x000c400c): 0xffffffff (0x000c4030): 0x00101010 [~]$ sudo intel_reg read 0xc2000 0xc2004 0xc2020 (0x000c2000): 0x00000000 (0x000c2004): 0x00000001 (0x000c2020): 0x60004000 ===
Let me know if you need more info.
[1] https://gist.github.com/dfbf237e74ed6e0b1bf7
16.02.2016 14:54, Daniel Vetter wrote:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P
not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P
not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P
not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
On 2/23/2016 8:38 PM, Ville Syrjälä wrote:
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P
not working
Do you have logs for the failure with the single link hdmi cable and the register dump which you have given for the working case? If not, can you please capture the logs and register dump. Also which platform is this? If it is live status related issue, we need to see how long it is taking to set the live status, or is it not setting it at all with the single-link cable?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P
works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
24.02.2016 06:40, Jindal, Sonika написав:
Do you have logs for the failure with the single link hdmi cable and the register dump which you have given for the working case? If not, can you please capture the logs and register dump. Also which platform is this? If it is live status related issue, we need to see how long it is taking to set the live status, or is it not setting it at all with the single-link cable?
Emm, I've already posted all requested logs and dumps in this thread before.
Any additional logs/dumps needed?
Thanks, Oleksandr.
Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue.
Regards Shashank -----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 23, 2016 8:38 PM To: Oleksandr Natalenko Cc: Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
-- Ville Syrjälä Intel OTC
On Wed, Feb 24, 2016 at 06:07:25AM +0000, Sharma, Shashank wrote:
Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue.
This is an upstream regression. Either you can handle it, or your code must be reverted again. Please either assign someone for this, or send in the patch to revert.
I'll discuss this with Indranil, too.
Thanks, Daniel
Regards Shashank -----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 23, 2016 8:38 PM To: Oleksandr Natalenko Cc: Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
-- Ville Syrjälä Intel OTC
Please see the latest mail chain, Sonika has already started on it.
Regards Shashank
-----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, February 29, 2016 8:44 PM To: Sharma, Shashank Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Wed, Feb 24, 2016 at 06:07:25AM +0000, Sharma, Shashank wrote:
Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue.
This is an upstream regression. Either you can handle it, or your code must be reverted again. Please either assign someone for this, or send in the patch to revert.
I'll discuss this with Indranil, too.
Thanks, Daniel
Regards Shashank -----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 23, 2016 8:38 PM To: Oleksandr Natalenko Cc: Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
-- Ville Syrjälä Intel OTC
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Mon, Feb 29, 2016 at 03:16:08PM +0000, Sharma, Shashank wrote:
Please see the latest mail chain, Sonika has already started on it.
Ah ok, crawling through 1k mails after one week of vacation, so I'm still catching up ;-) My apologies for the confusion.
Thanks, Daniel
Regards Shashank
-----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, February 29, 2016 8:44 PM To: Sharma, Shashank Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Wed, Feb 24, 2016 at 06:07:25AM +0000, Sharma, Shashank wrote:
Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue.
This is an upstream regression. Either you can handle it, or your code must be reverted again. Please either assign someone for this, or send in the patch to revert.
I'll discuss this with Indranil, too.
Thanks, Daniel
Regards Shashank -----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 23, 2016 8:38 PM To: Oleksandr Natalenko Cc: Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
-- Ville Syrjälä Intel OTC
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
No problems, I guessed the mail situation :)
Regards Shashank -----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, February 29, 2016 9:12 PM To: Sharma, Shashank Cc: Daniel Vetter; Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 29, 2016 at 03:16:08PM +0000, Sharma, Shashank wrote:
Please see the latest mail chain, Sonika has already started on it.
Ah ok, crawling through 1k mails after one week of vacation, so I'm still catching up ;-) My apologies for the confusion.
Thanks, Daniel
Regards Shashank
-----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, February 29, 2016 8:44 PM To: Sharma, Shashank Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Wed, Feb 24, 2016 at 06:07:25AM +0000, Sharma, Shashank wrote:
Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue.
This is an upstream regression. Either you can handle it, or your code must be reverted again. Please either assign someone for this, or send in the patch to revert.
I'll discuss this with Indranil, too.
Thanks, Daniel
Regards Shashank -----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 23, 2016 8:38 PM To: Oleksandr Natalenko Cc: Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote:
The other downside is that it'll make us non-compliant, which was the point of this entire ordeal: HDMI spec forbids us from starting any i2c transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could test this on some other machine with intel gfx and latest kernel, just to make sure this really is some issue with the sink and not with the machine itself? And I guess you've tested with some other hdmi sink, and that works?
-- Ville Syrjälä Intel OTC
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Mon, Feb 29, 2016 at 03:41:59PM +0000, Sharma, Shashank wrote:
No problems, I guessed the mail situation :)
Ok, caught up now, at least on dri-devel. There's 2 bug report mail threads: - A new one from Oleksandr, still being investigated. - This one here where Sonika asked for some logs from Nick, but Nick has already provided those. Since then (24th Feb) nothing new seems to have happened.
There's also other threads in the past, but I think we have resolved them all. I guess we need to start tracking all these in some JIRA? I'll bring this up in tomorrow's display sync meeting.
Thanks, Daniel
Regards Shashank -----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, February 29, 2016 9:12 PM To: Sharma, Shashank Cc: Daniel Vetter; Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 29, 2016 at 03:16:08PM +0000, Sharma, Shashank wrote:
Please see the latest mail chain, Sonika has already started on it.
Ah ok, crawling through 1k mails after one week of vacation, so I'm still catching up ;-) My apologies for the confusion.
Thanks, Daniel
Regards Shashank
-----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, February 29, 2016 8:44 PM To: Sharma, Shashank Cc: Ville Syrjälä; Oleksandr Natalenko; Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Wed, Feb 24, 2016 at 06:07:25AM +0000, Sharma, Shashank wrote:
Hi Ville, We will look into this in sometime. Right now team is slightly loaded due to project milestone. Last time I looked into this, we dint have this HW to reproduce this issue.
This is an upstream regression. Either you can handle it, or your code must be reverted again. Please either assign someone for this, or send in the patch to revert.
I'll discuss this with Indranil, too.
Thanks, Daniel
Regards Shashank -----Original Message----- From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com] Sent: Tuesday, February 23, 2016 8:38 PM To: Oleksandr Natalenko Cc: Vetter, Daniel; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Daniel Vetter; Jindal, Sonika; Sharma, Shashank; Wang, Gary C Subject: Re: [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
any additional info I could provide? I have to return dual-link DVI cable back, so let me know if I could reveal more details if necessary.
Unfortunately I'm out of ideas for now. Daniel is on vacation. Anyone else? VPG folks should take the ball here since they broke it.
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
Regards, Oleksandr
16.02.2016 14:54, Daniel Vetter написав:
On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
Ville, Daniel,
I've just got another monitor and another DVI-HDMI cable, and here what I've got.
===Single Link DVI-D cable with 3 different monitors===
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === not working
I presume the above LG screen is what you've called previously "old monitor"?
Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P === not working Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P === works!
===Dual Link DVI-D cable with monitor that doesn't work with Single Link cable===
Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
Funky. Can you pls grab the debug logs (with the special patches from Ville) for this case? I wonder why suddenly different cable and it works.
Also: Is this one of these older-ish screens where you must have a dual-link cable to drive it at full resolution&refresh rate? -Daniel
===Laptop with HDMI output===
Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
I'd say that single link DVI cables are broken with new kernel, but one of monitors could work with such a cable. So I have no idea :(.
Regards, Oleksandr.
15.02.2016 17:42, Daniel Vetter wrote: >The other downside is that it'll make us non-compliant, which >was the point of this entire ordeal: HDMI spec forbids us from >starting any i2c transactions when the hpd isn't signalling a present screen. > >So maybe we need to buy one of these broken screens. > >Oleksandr, what exact model are you using? And any chance that >you could test this on some other machine with intel gfx and >latest kernel, just to make sure this really is some issue >with the sink and not with the machine itself? And I guess >you've tested with some other hdmi sink, and that works?
-- Ville Syrjälä Intel OTC
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
23.02.2016 17:08, Ville Syrjälä написав:
In the meantime I think as a workaround I think you could use something like video=HDMI-A-1:e on the kernel command line (not sure I got the connector name right for your system). I think that should result in the live status check to be skipped, at least when populating the mode list.
This definitely did the trick for me:
=== [ +0.000354] [drm] forcing HDMI-A-1 connector ON ===
And single-link cable works now.
Might be a good idea to collect all the information here and put in a bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that all the logs and such would be in one place.
OK.
Thanks, Oleksandr.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Jindal, Sonika -
Oleksandr Natalenko -
Sharma, Shashank -
Ville Syrjälä