At Wed, 16 Nov 2011 07:51:28 -0800, Stephen Warren wrote: > > > > 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. Note that this bit isn't from GET_PIN_SENSE verb but the bit in the unsol event argument. Takashi
