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

[Takashi Iwai]

At Fri, 11 Nov 2011 16:22:41 +0800,
Wu Fengguang wrote:
> 
> 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.

Ah, I see.  But this could be suppressed by your patch
   drm/i915: don't trigger hotplug events on unchanged ELD
no?

(snip)
> > > 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.

Hm, OK, so the codec driver can simply ignore (or postpone) the case
when the connection is kept but ELD is invalidated.

> Here is one hot removal event (I just wrote a patch to trigger this),
> with Presence_Detect=0:

One note that we don't rely on PD bit because not all (non-Intel)
hardware report it correctly.

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

Yeah, this sounds like the workaround for such a case.

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

Or, we can introduce a dirty flag, and set it when ELD is changed,
but don't prase ELD contents yet.  First upon the next access, the
driver updates the status, and clear the dirty flag.  We may put a
small delay at this update, too.


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

Let's hope :)


thanks,

Takashi