other info:
1. run "$ udevadm monitor" or "$ udevadm monitor --property --tag-match=HOTPLUG", and then plug off and plug on the HDMI cable, no message outputs.
2. cat /proc/interrupts, and then plug off and plug on the HDMI cable, the interrupt number of i915 increased, but the interrupt number of snd_hda_intel did not change.

(In reply to Lu, Han from comment #1)
> other info:
> 1. run "$ udevadm monitor" or "$ udevadm monitor --property
> --tag-match=HOTPLUG", and then plug off and plug on the HDMI cable, no
> message outputs.

The bug is here. Please add drm.debug=14 module parameter and attach dmesg from boot to reproducing the problem, ensuring you don't get the uevent.

See also bug 90447 about userspace responsibility of actually handling the uevents.

Created attachment 119423 [details]
dmesg with boot parameter drm.debug=14

(In reply to Jani Nikula from comment #2)
> (In reply to Lu, Han from comment #1)
> > other info:
> > 1. run "$ udevadm monitor" or "$ udevadm monitor --property
> > --tag-match=HOTPLUG", and then plug off and plug on the HDMI cable, no
> > message outputs.
> 
> The bug is here. Please add drm.debug=14 module parameter and attach dmesg
> from boot to reproducing the problem, ensuring you don't get the uevent.
> 
> See also bug 90447 about userspace responsibility of actually handling the
> uevents.

please find log attached.
my steps:
1. boot up with parameter "drm.debug=14"
2. run "udevadm monitor --property --tag-match=HOTPLUG", output is
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

3. plug off and plug on HDMI cable, no more print on shell
4. Ctrl+C to quit, run "xrandr --auto"
5. repeat step 2 and 3 and get the same result.

Hi Jani,

Update:
With latest commit on drm-nightly repo, the issue is NOT reproduced on DP, but still reproduced on HDMI.

Please try http://patchwork.freedesktop.org/patch/msgid/1447931396-19147-1-git-send-email-tiwai@suse.de

With Takashi's patch the issue is still existing. Plug off HDMI cable and /proc/asound/card0/eldelf#2.0 does not refresh.

Bug scrub:
Assigend to Jani Nikula.  Lu, Han confirmed it does not work. What the next step?

The issue still present on latest configuration :

cairo version: 1.15.2 / commit :  db8a7f1 
drm version :  libdrm-2.4.66  / commit : b38a4b2 
intel-driver : 1.6.2 / commit: 683edee
libva version : libva-1.6.2 / commit : 304bc13
mesa version : mesa-11.0.8 / commit : 261daab 
xf86-video-intel version : 2.99.917  / commit : baec802 
xserver version :xorg-server-1.18.0 / commit :7921764 

kernel drm-intel-testing:

commit 91587c722c28c4116dedbfbf08aa874377bc76f8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Dec 4 17:35:54 2015 +0100

    drm-intel-nightly: 2015y-12m-04d-16h-35m-07s UTC integration manifest


kernel version : 4.4.0-rc3
git url        : git://anongit.freedesktop.org/drm-intel
git branch     : drm-intel-testing
git describe   : drm-intel-next-2015-11-20-rebased-13721-g91587c7

While I chase down hardware, could someone please try to reproduce this with a more recent kernel?  In particular, please ensure that the following patch is present.

commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
Author: Gary Wang <gary.c.wang@intel.com>
Date:   Wed Dec 23 16:11:35 2015 +0800

    drm/i915: increase the tries for HDMI hotplug live status checking

I can still reproduce this issue using the following Kernel.

commit 8fe9e785ae04fa7c37f7935cff12d62e38054b60
    Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Date:   Thu Jan 21 11:03:06 2016 +0000
    drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest

from: git://anongit.freedesktop.org/drm-intel

Verified that I do have the patch suggested by Jim Bride

After taking a look at this, I'm pretty convinced that this is a bug in the audio driver, particularly since cat /proc/asound/card0/eld#2.0 is pointing at audio driver state.  After taking a peek at the hda driver code I found a place where the audio driver is not updating its internal ELD state when it fails to read the ELD from the i915 (via snd_hdac_acomp_get_eld(), which calls into i915.)  I believe the hda driver  should, in any case where a failure to read the ELD occurs, flag the cached ELD as invalid.  I'm going to test with the patch below and see if it restores sanity.

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 426a29a..0c48909 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1667,8 +1667,6 @@ static void sync_eld_via_acomp(struct hda_codec *codec,
        size = snd_hdac_acomp_get_eld(&codec->bus->core, per_pin->pin_nid,
                                      &eld->monitor_present, eld->eld_buffer,
                                      ELD_MAX_SIZE);
-       if (size < 0)
-               goto unlock;
        if (size > 0) {
                size = min(size, ELD_MAX_SIZE);
                if (snd_hdmi_parse_eld(codec, &eld->info,
@@ -1687,7 +1685,6 @@ static void sync_eld_via_acomp(struct hda_codec *codec,
        update_eld(codec, per_pin, eld);
        snd_jack_report(per_pin->acomp_jack,
                        eld->monitor_present ? SND_JACK_AVOUT : 0);
- unlock:
        mutex_unlock(&per_pin->lock);
 }

Yet again the BXT-P system that I have available to me to test this issue has died.  If someone could kindly add the patch in the previous comment to their tree and test this it would be a great help.  Meanwhile I'll try to chase down another HW platform.

Is this code not common to legacy platforms, as well? SKL, at minimum?

Hi Jim,

I checked on my RVP2A, with drm-intel-testing-2016-01-11 tag. With the patch, the eld is still not refreshed after plug off/on HDMI cable.
From log, the function sync_eld_via_acomp() was called 6 times during boot up (and snd_hdac_acomp_get_eld() returns: 36, 0, -22, 36, 0, -22), but was not called when plug off/on HDMI cable.
BTW, from /proc/interrupts, i915 interrupts were detected but snd_hda_intel interrupts were not detected when plug off/on HDMI cable. Not sure if it's i915 driver related.
As comparison, I checked on SKL with the same SSD, not applying the patch, and the HDMI eld can be refreshed when plug off HDMI cable.

Update the issue's priority to P1. The issue block audio's feature which is near our next milestone.

The issue is fixed with APL stepping B0, but we need to wait for the patches be upstreamed.

Issues being fixed:
1. Bug 92916 - [BXT-P APL] Can't light on HDMI monitor if boot up without monitor connected
2. Bug 92805 - [BXT-P APL] [Audio] Cannot refresh ELD information on the text mode and the UI mode

Reworks required:
1. Reverse O-03 on APL RVP1A, for APL B0 stepping Soc upgrade.
2. Apply R19 on APL RVP1A, for APL B0 stepping Soc upgrade.
3. Apply F-28C on APL RVP1A, for HDMI to use DDI-1 instead of DDI-0
(Optional 4. Apply F-27 on APL RVP1A, for DP to use DDI-0 instead of DDI-1)

Our environment to check the issue: (the patches are not applicable to latest commits since code changed, we used an commit of around March 10 instead)
Platform: Apollo lake RVP1a FabA
BIOS: APLKRVPA.X64.0125.B30.1602180044
KSC FW:1.10
BXT SOC : B0
GOP : 10.0.1025
Board ID: APL RVP 1A (01)
CPU Flavor: BXT Tablet (0)
FAB ID: FAB1
Total Memory : 8GB
Kernel:4.5.0-rc1+
Tree: git://anongit.freedesktop.org/drm-intel
Branch:drm-intel-nightly
Commit: df91a2100c05cec9323a222b97be918ccf53e378

Close it as it is fixed on APL B0 Stepping. Thanks everyone for help on this issue.