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

[Takashi Iwai]

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