At Fri, 11 Nov 2011 10:29:25 +0800, Wu Fengguang wrote: > > On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote: > > At Thu, 10 Nov 2011 21:51:50 +0800, > > Wu Fengguang wrote: > > > > > > > > > > So maybe the hardware is in some state that is unable to provide > > > > > > > the > > > > > > > real ELD content? > > > > > > That's my guess as well. I think the hardware may still be doing > > > > > > some > > > > > > form of data negotiation with the HDMI display device at that > > > > > > stage, and > > > > > > doesn't have the copy of the EDID+ELD buffer until a tiny bit > > > > > > later. > > > > > > Possibly? > > > > > > > > > > Look at the below dmesg. The ELD seem to available immediately after > > > > > the DPMS > > > > > state setting.. > > > > > > > > Interesting. Does HDMI audio work at all while HDMI DPMS off? > > > > It clears SDVO_ENABLE bit, so this might turn off both video and > > > > audio? > > > > > > We normally see transient blank screen and silence of audio when > > > switching the video mode. > > > > Well, what I suspected is that ELD won't be transferred while > > SDVO_ENABLE is cleared. > > It's not about SDVO_ENABLE. The transient ELD invalid state I see in > dmesg is caused by the graphics driver doing > > ELD_Valid = 0 => trigger 1st unsolicited event
But why this triggers at *plugging*? Wasn't it zero beforehand? If I understand correctly, changing AUD_CNTL_ST register triggers the HD-audio codec unsol event. Writing even the same value matters? > write ELD contents > ELD_Valid = 1 => trigger 2nd unsolicited event > > The two unsolicited events are described in "Figure 72. PD and ELDV > unsolicited responses flow for digital display codecs" of the High > Definition Audio Specification Rev. 1.0a. > > [ 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 > 1st event => [ 467.586540] HDMI hot plug event: Codec=3 Pin=7 > Presence_Detect=1 ELD_Valid=0 > [ 467.599608] [drm:ironlake_write_eld], > 1st event => [ 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 > 2nd event => [ 467.612365] HDMI hot plug event: Codec=3 Pin=7 > Presence_Detect=1 ELD_Valid=1 > [ 467.620654] [drm:sandybridge_update_wm], > 2nd event => [ 467.620765] HDMI status: Codec=3 Pin=7 Presence_Detect=1 > ELD_Valid=1 > > Depending on the timing, the 1st unsolicited event may see > ELD_Valid=0 (if it's fast enough) or ELD_Valid=1 (if the event > handling is delayed after the graphics driver sets ELD_Valid=1). > > I know that because I literally saw both cases happening in dmesg. > The 1st hot plug event itself will send ELD_Valid=0, however the audio > driver is not trusting this and always do a status query (the HDMI > status line) whose result depends on the timing. The problem in this procedure is that this looks as if you are re-connecting the HDMI from the audio-codec POV. We might end up with some delayed probe with a dedicated work_struct (because it's bad to have a too long delay in unsol event handler that run on a single workq). > > And I'm not sure whether HDMI audio is played > > while DPMS is off. I haven't tested it. > > It will go silence on DPMS. I noticed this while doing long term HDMI > audio playback tests. This should better be fixed in future on the > graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
