Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1330022 > unrolled thread

Re: [REGRESSION] i915: No HDMI output with 4.4

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [REGRESSION] i915: No HDMI output with 4.4 Daniel Vetter <daniel@ffwll.ch> - 2016-02-09 11:20 +0100
    Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-09 17:00 +0100
    Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-11 08:50 +0100
      Re: [REGRESSION] i915: No HDMI output with 4.4 Daniel Vetter <daniel@ffwll.ch> - 2016-02-11 09:30 +0100
        Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-11 10:00 +0100
          Re: [REGRESSION] i915: No HDMI output with 4.4 Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-02-11 10:30 +0100
            Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-11 12:20 +0100
              Re: [REGRESSION] i915: No HDMI output with 4.4 Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-02-11 15:10 +0100
                Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-12 16:00 +0100
                  Re: [REGRESSION] i915: No HDMI output with 4.4 Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-02-13 00:30 +0100
                    Re: [REGRESSION] i915: No HDMI output with 4.4 Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-02-15 15:50 +0100
                      Re: [REGRESSION] i915: No HDMI output with 4.4 Daniel Vetter <daniel@ffwll.ch> - 2016-02-15 16:50 +0100
                        Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-16 12:10 +0100
                          Re: [REGRESSION] i915: No HDMI output with 4.4 Daniel Vetter <daniel@ffwll.ch> - 2016-02-16 14:00 +0100
                            Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-16 19:10 +0100
                            Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-16 19:20 +0100
                            Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-22 17:20 +0100
                    Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-15 16:10 +0100
                    Re: [REGRESSION] i915: No HDMI output with 4.4 Oleksandr Natalenko <oleksandr@natalenko.name> - 2016-02-15 17:10 +0100

#1330022 — Re: [REGRESSION] i915: No HDMI output with 4.4

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [next] | [standalone]

#1330377

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

[toc] | [prev] | [next] | [standalone]

#1331715

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

[toc] | [prev] | [next] | [standalone]

#1331728

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 Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1331742

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.

[toc] | [prev] | [next] | [standalone]

#1331780

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]
> 
> [1] https://gist.github.com/efb44b7c6bc325978b80

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 Syrjälä
Intel OTC

[toc] | [prev] | [next] | [standalone]

#1331826

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]
>> 
>> [1] https://gist.github.com/efb44b7c6bc325978b80
> 
> That's an IVB. So no wonder my patch doesn't help.
> 
> Can you grab another dmesg after disconnecting and reconnecting the
> HDMI cable?

[toc] | [prev] | [next] | [standalone]

#1331998

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.

> 
> [1] https://gist.github.com/7057ea8512b9aa7ee5bd

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.

> 
> 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]
> >> 
> >> [1] https://gist.github.com/efb44b7c6bc325978b80
> > 
> > That's an IVB. So no wonder my patch doesn't help.
> > 
> > Can you grab another dmesg after disconnecting and reconnecting the
> > HDMI cable?

-- 
Ville Syrjälä
Intel OTC

[toc] | [prev] | [next] | [standalone]

#1332795

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.
> 

[toc] | [prev] | [next] | [standalone]

#1333207

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.
> > 

-- 
Ville Syrjälä
Intel OTC

[toc] | [prev] | [next] | [standalone]

#1334501

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?
> 
> More on this.
> 
> 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.

-- 
Ville Syrjälä
Intel OTC

[toc] | [prev] | [next] | [standalone]

#1334542

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?
> > 
> > More on this.
> > 
> > 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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1335283

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?

[toc] | [prev] | [next] | [standalone]

#1335336

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?

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1335690

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).

[toc] | [prev] | [next] | [standalone]

#1335697

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?

[toc] | [prev] | [next] | [standalone]

#1339697

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?

[toc] | [prev] | [next] | [standalone]

#1334504

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.

[toc] | [prev] | [next] | [standalone]

#1334562

13.02.2016 01:23, Ville Syrjälä wrote:
> - Do you have another monitor to try?
> - Do you have another cable to try?

More on this.

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web