On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote: > 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?
Sorry I assumed the "mode switching" context. On hot plugging, clearing the already 0 ELD_Valid won't trigger the 1st unsolicited event. Just confirmed this with dmesg: [ 162.336366] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 162.341163] [drm:ironlake_write_eld], ELD on pipe B [ 162.344661] [drm:ironlake_write_eld], Audio directed to unknown port [ 162.348073] [drm:ironlake_write_eld], ELD size 13 [ 162.351146] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 162.354346] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 162.402418] [drm:intel_wait_for_vblank], vblank wait timed out [ 162.457250] [drm:intel_wait_for_vblank], vblank wait timed out [ 162.460924] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 162.464816] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 162.519147] [drm:intel_wait_for_vblank], vblank wait timed out [ 162.572962] [drm:intel_wait_for_vblank], vblank wait timed out [ 162.576121] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 162.579206] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 162.581578] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 162.584281] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 162.586499] [drm:ironlake_fdi_link_train], FDI train done [ 162.591908] [drm:intel_update_fbc], [ 162.593395] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 162.596638] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 162.599386] [drm:intel_fb_output_poll_changed], [ 162.605467] HDMI: detected monitor RX-V1800 at connection type HDMI [ 162.607773] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC > > > 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. The re-connecting events can be distinguished from the video-mode-switching events by the Presence_Detect bit. Here is one hot removal event (I just wrote a patch to trigger this), with Presence_Detect=0: [ 91.777028] [drm:ironlake_write_eld], ELD on pipe B [ 91.778561] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=1 [ 91.783078] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 91.783083] [drm:ironlake_write_eld], Audio directed to unknown port [ 91.783095] [drm:output_poll_execute], [CONNECTOR:12:HDMI-A-2] status updated from 1 to 2 The HDA spec even mentioned doing some timeout mechanism for the "Presence_Detect=1 ELD_Valid=0" state. Well it may help some corner cases, but perhaps not an urgent feature. > 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). Understand. What if the graphics driver can delay the ELD writing (I can try that), so that the audio driver only need to wait for something like 10ms? > > > 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... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Thanks, Fengguang _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx