On Wed, Nov 16, 2011 at 11:51:28PM +0800, Stephen Warren wrote: > Wu Fengguang wrote at Tuesday, November 15, 2011 7:48 PM: > > On Wed, Nov 16, 2011 at 02:25:00AM +0800, Stephen Warren wrote: > > > Wu Fengguang wrote at Tuesday, November 15, 2011 7:33 AM: > > > > The Intel HDMI chips (ironlake at least) are found to have ~250ms delay > > > > between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes > > > > actually readable. During the time the ELD buffer is mysteriously all 0. > > > > > > > > Fix it by scheduling a delayed work to re-read ELD buffer after 300ms. > > > > > > Any idea why; is the graphics driver writing the ELD data to the audio HW > > > after triggering the unsolicited even rather than before, or something > > > like that? > > > > Nope. The graphics driver is doing > > > > eld_valid = 0 > > write to eld buffer > > eld_valid = 1 > > OK, that sounds fine. > > > > 250mS almost sounds like it's setting ELDV in the audio HW, > > > then going and reading the EDID, then writing the EDID to the audio HW; > > > perhaps the graphics driver is accidentally setting PRESENT+ELDV when it's > > > meant to be setting just PRESENT, and later setting ELDV? > > > > From the debug dmesg, I'm pretty sure that the ELDV events are > > triggered exactly by the "eld_valid = 0" and "eld_valid = 1" register > > writes. Since the ELD data is already prepared, there is no EDID read > > in between. > > > > Below is the dmesg representing a video mode set. > > > > ELD writes from the graphics driver > > > > [ 424.254958] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], > > [ENCODER:11:TMDS-11] > > [ 424.257670] [drm:ironlake_write_eld], ELD on pipe B > > [ 424.259833] [drm:ironlake_write_eld], Audio directed to unknown port > > [ 424.262156] [drm:ironlake_write_eld], ELD size 13 > > > > ELD events received by audio driver (eld reads 0) > > > > [ 424.263258] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 > > ELD_Valid=0 > > That line makes sense. > > > [ 424.265877] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 > > I don't /think/ it's related to this issue, but I wonder why ELDV==1 in > that message; it seems that the unsolicited response contains the correct > data, but AC_VERB_GET_PIN_SENSE contains ELDV==1 all the time. That's odd.
It depends on timing. When audio driver receives the unsolicited event, graphics driver has finished with "eld_valid = 1", hence AC_VERB_GET_PIN_SENSE returns ELDV=1. It's not happening /all the time/ though. For example here is another dmesg showing a different timing on the same test box. [ 467.561516] [drm:intel_dp_mode_set], Enabling DP audio on pipe B [ 467.567503] [drm:intel_write_eld], ELD on [CONNECTOR:26:DP-3], [ENCODER:27:TMDS-27] [ 467.574207] [drm:ironlake_write_eld], ELD on pipe B [ 467.579346] [drm:ironlake_write_eld], Audio directed to unknown port [ 467.584724] [drm:ironlake_write_eld], ELD: DisplayPort detected [ 467.586540] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.599608] [drm:ironlake_write_eld], [ 467.599922] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=0 [ 467.605834] ELD size 9 [ 467.610434] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 7, cursor: 6 [ 467.612365] HDMI hot plug event: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 [ 467.620654] [drm:sandybridge_update_wm], [ 467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 ELD_Valid=1 > > [ 424.272415] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 > > [ 424.274566] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 > > ELD_Valid=1 > > [ 424.277027] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 > > [ 424.283157] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 > > > > graphics driver go on with its job > > > > [ 424.314331] [drm:intel_wait_for_vblank], vblank wait timed out > > [ 424.367183] [drm:intel_wait_for_vblank], vblank wait timed out > > [ 424.368960] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane > > 5, cursor: 6 > > [ 424.370700] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane > > 42, cursor: 6 > > [ 424.424056] [drm:intel_wait_for_vblank], vblank wait timed out > > [ 424.476906] [drm:intel_wait_for_vblank], vblank wait timed out > > [ 424.479169] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 > > [ 424.481084] [drm:ironlake_fdi_link_train], FDI train 1 done. > > [ 424.483452] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 > > [ 424.485444] [drm:ironlake_fdi_link_train], FDI train 2 done. > > [ 424.486765] [drm:ironlake_fdi_link_train], FDI train done > > [ 424.490820] [drm:intel_update_fbc], > > [ 424.491841] [drm:drm_crtc_helper_set_config], Setting connector DPMS > > state to on > > [ 424.494449] [drm:drm_crtc_helper_set_config], > > [CONNECTOR:12:HDMI-A-2] set DPMS on > > [ 424.505904] [drm:intel_prepare_page_flip], preparing flip with no unpin > > work? > > > > audio driver repoll the ELD after 300ms (eld data readable now) > > > > [ 424.574763] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 > > [ 424.580867] HDMI: detected monitor RX-V1800 at connection type HDMI > > [ 424.582413] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC > ... > > OK, well I guess this make it work, and I don't think the patch will cause > any issues on HW without this issue, so the patch is fine. I'd still love > to understand why this is happening though. I'd like to know the root cause, too... However enabling drm debugging does not show any co-related event that turns the ELD into readable state, and I cannot find clues in the spec, too... Thanks, Fengguang _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
