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

[Wu Fengguang]

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
        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.

> 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.

> Unfortunately I can't test it right now since my colleague is using a
> desk where the HDMI monitor is on...

I'm always borrowing HDMI/DP monitors and test boxes, too ;-)

Thanks,
Fengguang