[Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

[Wu Fengguang]

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