[Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
tiwai at suse.de
Fri Nov 11 08:40:37 CET 2011
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...
More information about the Intel-gfx