Bug 58405

Any more info you need, please ask for it.

I can recompile, apply patches or whatever is needed, and test the path in 3 different machines.

Thanks :)

Please attach your Xorg.0.log and dmesg.

Created attachment 71661 [details]
Xorg.log

Thanks, that was useful to check everything that needed to be enabled was. So the likely cause is simply that the hotplug event is not being generated.

What we will need now is a dmesg with drm.debug=6 (echo 6 > /sys/modules/drm/parameters/debug) over the course of you unplugging the HDMI.

Created attachment 71664 [details]
dmesg with debug 6

I added some comments (look for //) indicating where I had to execute xrandr to get the event, and a case where it worked (sent the event at the right time).

During the testing of our xrandr integration in KDE, at least 4 more users had this issue, one of them with a VGA1 port.

Is there any more debug information I can provide? maybe logs from other computers? or you have enough?

Thanks !

Kernel 3.8 fixes a bug in the hotplug handling where a userspace request for the current output status could inadvertently eat the respective hpd event. So retesting on a 3.8-rc kernel highly recommended.

Tested with 3.8-rc4, everything continues as described plus now no event is mitted when plugging the HDMI output (I have to execute xrandr to trigger it).

Will attach info running rc4 kernel.

Created attachment 73299 [details]
dmesg since HDMI is plugged

Created attachment 73300 [details]
dmesg since HDMI is unplug

Created attachment 73301 [details]
dmesg plugging  HDMI and executing xrandr

Created attachment 73302 [details]
dmesg since unplugging HDMI and executing xrandr

Added 4 dmesg logs with debug at 6 doing:

-Plugging HDMI output and waiting for a while
-Unplugging that HDMI output and waiting for a while
-Plugging HDMI and execute xrandr (this triggers the event)
-Unplugging HDMI and execute xrandr (triggers event as well)

If you need me to test anything more, please say so.

Did this get fixed by

commit 202adf4b9f5957b26a1cb97267d78e0edb319c5e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Feb 22 00:53:04 2013 +0100

    drm/i915: Revert hdmi HDP pin checks
?

Unlikely, since nowadays the output poll work ignores connectors with the HPD poll flag set. I wonder whether we need to quirk something or whether we just get something wrong, since hpd looks pretty non-optional in the hdmi spec.

Just tested with Kernel 3.9 (the patch got into RC3, right?) and behavior is exactly the same.

Tomorrow I will be able to test it with 2 other systems, in the one I tried the GPU is 965GM

I have been doing some digging to try to figure out this bug. I have found something that perhaps will help you to find where the error is.

In i915_hpd_irq_setup when the encoder_list is iterated  none of the encoders has HPD_SDVO_B which apparently is where my HDMI port is hooked.

If I add:
hotplug_en |= SDVOB_HOTPLUG_INT_EN;

Then at least I can see some reaction from the drm driver in dmesg:
[drm:i965_irq_handler], hotplug event received, stat 0x00008040

Then, If in: i965_irq_handler I force hotplug_trigger
if (hotplug_trigger) {

I get this dmesg:
[drm:i965_irq_handler], not triggered
[drm:i915_hotplug_work_func], running encoder hotplug functions
[drm:intel_sdvo_debug_write], SDVOB: W: 0D 01 00                   (SDVO_CMD_SET_ACTIVE_HOT_PLUG)
[drm:intel_crt_detect], CRT not detected via hotplug
[drm:gmbus_xfer], GMBUS [i915 gmbus vga] NAK for addr: 0050 r(1)
[drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga
[drm:intel_crt_get_edid], CRT GMBUS EDID read failed, retry using GPIO bit-banging
[drm:intel_gmbus_force_bit], enabling bit-banging on i915 gmbus vga. force bit now 1
[drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga
[drm:intel_gmbus_force_bit], disabling bit-banging on i915 gmbus vga. force bit now 0
[drm:intel_crt_detect_ddc], CRT not detected via DDC:0x50 [no valid EDID found]
[drm:drm_helper_hpd_irq_event], [CONNECTOR:11:VGA-1] status updated from disconnected to disconnected.

Then in intel_setup_outputs I'm getting in:
if (I915_READ(GEN3_SDVOB) & SDVO_DETECTED) {
    DRM_DEBUG_KMS("probing SDVOB\n");
    found = intel_sdvo_init(dev, GEN3_SDVOB, true);
    found = false;
    if (!found && SUPPORTS_INTEGRATED_HDMI(dev)) {
        DRM_DEBUG_KMS("probing HDMI on SDVOB\n");
	intel_hdmi_init(dev, GEN4_HDMIB, PORT_B);
    }
}

If I force found to false, I'm getting an extra encoder with port HPD_PORT_B, but still it is not working.

Any pointers?

Thanks.

Note that your i965gm and i7 are completely different wrt hotplug handling for hdmi. I'll restrict this bug here for your i965gm machine, please file a new one for the i7.

Now can you please retest with latest drm-intel-nightly git branch from

http://cgit.freedesktop.org/~danvet/drm-intel/

We've massively overhauled the hotplug handling, so any older testing isn't really valid any more.

Does not seem to help, but maybe I'm doing something wrong because at least the code of i915_hpd_irq_setup looks the same.

Is there something I can check to make completely sure I'm using the right branch?

This is the last commit I have: 4f9e7cfb

It's the right commit. And I've just rechecked the documentation and the hotplug bits /should/ be the right ones. So I'm confused.

Can you please check whether SDVOB_HOTPLUG_INT_EN is set for your system with the new fancy code? If you can indeed get an interrupt this way, then we have a bug somewhere in our code ... When testing please make sure that whatever dmesg dumps does indeed correlate with you plugging/unplugging the cable. Unfortunately it wouldn't be the first case where the hpd stuff simply isn't wired up though.

The second hack with the intel_hdmi_init is broken. i965GM does not have native HDMI ports, but only supports hdmi through the multi-purpose sdvo encoder.

SDVOB_HOTPLUG_INT_EN is NOT set in i915_hpd_irq_setup, if I add it then I get the following on dmesg every time I plug the HDMI (but not when I unplug):

hotplug event received, stat 0x00008040

As in the current kernel, HPD_SDVO_B does not seem to be within the encoders.

Can you attach a drm.debug=6 dmesg from boot with the latest kernel?

Created attachment 80528 [details]
dmesg drm.debug=6 drm-intel-nightly commit: 4f9e7cfb09a

Today's silly code:

  if (intel_sdvo->hotplug_active)
                intel_encoder->hpd_pin = HPD_SDVO_B ? HPD_SDVO_B : HPD_SDVO_C;

and the hotplug_mask is dead.

Also note that test to enable hpd_pin is before we query the hw and initialize hotplug_active. Mystery solved.

Tried removing the conditional but I guess it will take more than that :p

Created attachment 80562 [details] [review]
fix sdvo hotplug init sequence

This should help. Patch totally untested though ;-)

With the patch applied I'm getting one hotplug event, but only once (instead of every time I plug/unplug the hdmi)

[drm:i965_irq_handler], hotplug event received, stat 0x00008040

It is progress though :p

Hm, that's strange. Can you please add a bit of printk debugging on top to figure out where the interrput might get killed, like this:

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0aa2ef0..ca937e3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2874,6 +2874,7 @@ static void i915_hpd_irq_setup(struct drm_device *dev)
 
        if (I915_HAS_HOTPLUG(dev)) {
                hotplug_en = I915_READ(PORT_HOTPLUG_EN);
+               printk("hotplug_en old 0x%08x\n", hotplug_en);
                hotplug_en &= ~HOTPLUG_INT_EN_MASK;
                /* Note HDMI and DP share hotplug bits */
                /* enable bits are the same for all generations */
@@ -2891,6 +2892,7 @@ static void i915_hpd_irq_setup(struct drm_device *dev)
 
                /* Ignore TV since it's buggy */
                I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
+               printk("hotplug_en new 0x%08x\n", hotplug_en);
        }
 }
 
Then please attach debug dmesg.

Created attachment 80572 [details]
dmesg with printk

Output of the new printk:
[   10.631841] hotplug_en old 0x00000000
[   10.631843] hotplug_en new 0x04000220

Additionally, in i965_irq_handler this conditional is failing:
if (hotplug_trigger) {

So dev_priv->hotplug_work is NOT getting Queued.

hotplug_status is 0x00008040
after the &
hotplug_trigger is 0

If I comment the conditional, then the _work function is executed but still nothing works :p

Created attachment 80578 [details] [review]
use gen3 hotplug register definitions

Docs are consistently of a differen opinion, but this wouldn't be the first time around docs are full of lies. Please test.

Finally ! it is working like a charm now !

Created attachment 80579 [details]
Patch needed to make it work

Attaching combined patch with the changes needed to make it work.

Can this patch be backported? would be really nice to push this patches into current distributions.

Thanks for everything!

Can you please plug/unplug your hdmi output a few times and attach dmesg? I just want to check that no other relevant hotplug bits are set (so if you bored you could filter right away for that message ;-).

Created attachment 80586 [details]
dmesg since hdmi plug/unplug

Gentle poke for Chris to corroborate this story about Bspec being wrong for SDVO hpd bits on i965g/gm ...

No hotplug event before patch; after patch every single connector was reprobed by the kernel. I'll take the no hotplug event thanks.

(965gm with sDVO DVI)

I don't understand last two comments, anything more I can test? I can call for tests within the KDE community if needed.

(In reply to comment #41)
> I don't understand last two comments, anything more I can test? I can call
> for tests within the KDE community if needed.

Just confirmation to Daniel that the patch also do the right thing on my 965gm (i.e. hotplug interrupts are being only generated after the patch). The rest is a dig that the current behaviour of then reprobing every output after the hotplug notification is broken by design.

Oooh ok :p 

So, do you think guys this can be backported somehow? I'd really like current distros to apply needed patch. If it can't, will it make it to 3.10?

Created attachment 81358 [details] [review]
fixup sdvo hpd bits on gen4.0

Final (hopefully) patch that I've submitted for merging. Please check whether it still works on latest drm-intel-nightly, thanks.

commit a4ad7c1a468f99e23da0376fa6e883a38ee08070
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Jun 24 21:33:28 2013 +0200

    drm/i915: Fix up sdvo hpd pins for i965g/gm
    
    Bspec seems to be full of lies, at least it disagress with reality:
    Two systems corrobated that SDVO hpd bits are the same as on gen3.