From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver Date: Fri, 11 Nov 2011 08:40:37 +0100 Message-ID: References: <4EBB917B.5010001@pulseforce.com> <4EBBAEE5.3080302@pulseforce.com> <4EBBBA73.9000604@pulseforce.com> <20111110125638.GB7194@localhost> <4EBBCB24.8090803@pulseforce.com> <20111110131753.GA14160@localhost> <20111110135150.GB17079@localhost> <20111111022925.GA10466@localhost> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTP id 524A59E748 for ; Thu, 10 Nov 2011 23:40:39 -0800 (PST) In-Reply-To: <20111111022925.GA10466@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Wu Fengguang Cc: "Wang, Zhenyu Z" , "intel-gfx@lists.freedesktop.org" , "Barnes, Jesse" , Jeremy Bush , Christopher White , "Bossart, Pierre-louis" List-Id: intel-gfx@lists.freedesktop.org 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