Bug 110932 - [CI][RESUME]igt@kms_chamelium@dp-audio-edid - fail - Failed assertion: eld_get_igt(&eld)
Summary: [CI][RESUME]igt@kms_chamelium@dp-audio-edid - fail - Failed assertion: eld_ge...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-18 04:35 UTC by Lakshmi
Modified: 2019-09-13 13:06 UTC (History)
3 users (show)

See Also:
i915 platform: ICL
i915 features: display/Other


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lakshmi 2019-06-18 04:35:58 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6265/re-icl-u/igt@kms_chamelium@dp-audio-edid.html

Starting subtest: dp-audio-edid
(kms_chamelium:1237) CRITICAL: Test assertion failure function test_display_audio_edid, file ../tests/kms_chamelium.c:1471:
(kms_chamelium:1237) CRITICAL: Failed assertion: eld_get_igt(&eld)
(kms_chamelium:1237) CRITICAL: Last errno: 2, No such file or directory
Subtest dp-audio-edid failed.
Comment 2 Jani Saarinen 2019-06-18 05:46:00 UTC
Simon, can you comment impact of this and if this is real issue and where?
Comment 3 emersion 2019-06-18 06:00:43 UTC
This one sounds like an IGT issue, the test seems broken. Working on a fix.

Impact is no test coverage for ensuring monitors supporting audio connected via DP are supported.
Comment 4 emersion 2019-06-18 06:59:36 UTC
Bleh, I can't reproduce this bug on my setup no matter what I try. I thought that maybe IGT wasn't properly re-probing connectors after setting an EDID but that's not the case, we do it properly.

In the dmesg for both logs there is:

<4> [449.746542] snd_hda_codec_hdmi hdaudioC0D2: HDMI: pin nid 5 not registered

Might just be due to the same bug as https://bugs.freedesktop.org/show_bug.cgi?id=110879
Comment 5 emersion 2019-06-18 13:46:24 UTC
I can reproduce on re-icl-u with the mini-DP port and a real screen:

1. Unplug everything, boot the machine, run `cat /proc/asound/eld*`: no ELD present
2. Plug an external screen which supports audio
3. Run dmesg. Grep for "ELD". Notice the lines "[drm:drm_add_edid_modes] ELD monitor <monitor name>" and "[drm:drm_add_edid_modes] ELD size 36, SAD count 1"
3. Run `cat /proc/asound/eld*`: still no monitor present
4. Play a sound with aplay
5. Run dmesg. A bunch of "[drm:i915_audio_component_get_eld [i915]] Not valid for port <port>" messages appear.
5. Run `cat /proc/asound/eld*`: monitor appears

Are we supposed to start playing audio to get the correct value in /proc/asound/eld*?
Comment 6 emersion 2019-06-18 13:49:09 UTC
Additionally, disconnecting the mini-DP cable doesn't make the /proc/asound/eld* entry go away, it's still saying the monitor is connected.

I believe this is a driver bug, it's not updating /proc/asound/eld* correctly.
Comment 7 Ville Syrjala 2019-06-18 13:57:16 UTC
The eld should appear/disappear when there is a modeset. If no one is reacting ot the hpd events and doing a modesets then the eld will not change state either.
Comment 8 emersion 2019-06-18 14:01:49 UTC
We reprobe the connector and set a mode, so the ELD should definitely be updated.
Comment 9 Lakshmi 2019-08-01 09:43:45 UTC
This bug needs input from audio team.
Comment 10 emersion 2019-08-16 13:04:39 UTC
Last seen 4 weeks ago. (It used to be seen every week.)

Improved ELD logging reveals that the old ELD (coming from the default Chamelium EDID) is staying around after hotplug with a new EDID:

(kms_chamelium:1152) igt_eld-DEBUG: Skipping non-IGT ELD: /proc/asound/card0/eld#2.6 (monitor name: AthenaDP)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.