From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver Date: Wed, 9 Nov 2011 14:59:53 +0800 Message-ID: <20111109065953.GB28238@localhost> References: <20110902081428.GA19621@localhost> <20110903211510.GA11600@localhost> <20110905011400.GB24561@localhost> <20110905123128.GA31852@localhost> <4E64C41B.5090309@pulseforce.com> <20110905124730.GB794@localhost> <4EA82DBD.9020301@pulseforce.com> <4EA9B7A3.6060008@pulseforce.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 9A597A0A73 for ; Tue, 8 Nov 2011 22:59:56 -0800 (PST) Content-Disposition: inline In-Reply-To: <4EA9B7A3.6060008@pulseforce.com> 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: Christopher White Cc: Jeremy Bush , "intel-gfx@lists.freedesktop.org" , "Wang, Zhenyu Z" , "Bossart, Pierre-louis" List-Id: intel-gfx@lists.freedesktop.org --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Christopher, I don't find anything wrong with the ELD parsing code, however I do find a bug that prevented ELD from being passed to the audio driver on SandyBridge. I just posted the fix. For your convenience, it's attached in this email too. Thanks, Fengguang On Fri, Oct 28, 2011 at 03:57:23AM +0800, Christopher White wrote: > There appears to be some issues with the patch? I'm on SandyBridge and > using the HD3000's HDMI. > > I've now tried manually merging the ELD patch (both files Wu Fengguang > submitted) and compiling Kernel 3.0.4. I've also tried drm-intel-next > Kernel 3.1 pre-built from > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ as > I knew it was built from keithp's latest drm-intel-next repository. > > Both of these methods had the patch applied, yet neither were able to > read the ELD correctly from my Onkyo TX-SR607 receiver. > > If I manually dump the EDID from my receiver and analyze it with Monitor > Asset Manager (by EnTech Taiwan), it shows that the ELD contains an 8 > channel specification up to 192 kHz, and that's what's being exposed > over HDMI to the Intel graphics adapter, yet this isn't detected. It > just plain isn't being read, and is falling back to the default 2ch > 16kHz configuration. It's exactly as it was in the past, before this > patch attempt. > > You can see my 256 byte EDID dump, straight from the receiver, over at: > http://www.pulseforce.com/node/edid.dump > > It shows exactly what the receiver is exposing over HDMI, proving that > it's not the device that's at fault. > > Any ideas what's wrong? Here's the HDMI messages from the startup log: > > HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 > HDMI: detected monitor at connection type HDMI > HDMI: available speakers: FL/FR > HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 > 88200, bits = 16 > HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 > HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 > input: HDA Intel PCH HDMI/DP as > /devices/pci0000:00/0000:00:1b.0/sound/card0/input9 > HDMI: detected monitor at connection type HDMI > HDMI: available speakers: FL/FR > HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 > 88200, bits = 16 > HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 > HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 > HDMI: detected monitor at connection type HDMI > HDMI: available speakers: FL/FR > HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 > 88200, bits = 16 > > > > Christopher White --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=sandybridge-eld-fix Subject: drm/i915: fix ELD writing for SandyBridge Date: Wed Nov 09 13:17:14 CST 2011 SandyBridge should be using the same register addresses as IvyBridge. Signed-off-by: Wu Fengguang --- drivers/gpu/drm/i915/i915_reg.h | 6 +++--- drivers/gpu/drm/i915/intel_display.c | 10 +++++----- 2 files changed, 8 insertions(+), 8 deletions(-) --- linux.orig/drivers/gpu/drm/i915/i915_reg.h 2011-11-09 13:17:19.000000000 +0800 +++ linux/drivers/gpu/drm/i915/i915_reg.h 2011-11-09 13:18:39.000000000 +0800 @@ -3543,8 +3543,8 @@ #define GEN5_ELD_VALIDB (1 << 0) #define GEN5_CP_READYB (1 << 1) -#define GEN7_HDMIW_HDMIEDID_A 0xE5050 -#define GEN7_AUD_CNTRL_ST_A 0xE50B4 -#define GEN7_AUD_CNTRL_ST2 0xE50C0 +#define GEN6_HDMIW_HDMIEDID_A 0xE5050 +#define GEN6_AUD_CNTL_ST_A 0xE50B4 +#define GEN6_AUD_CNTRL_ST2 0xE50C0 #endif /* _I915_REG_H_ */ --- linux.orig/drivers/gpu/drm/i915/intel_display.c 2011-11-09 13:19:28.000000000 +0800 +++ linux/drivers/gpu/drm/i915/intel_display.c 2011-11-09 13:20:02.000000000 +0800 @@ -5857,14 +5857,14 @@ static void ironlake_write_eld(struct dr int aud_cntl_st; int aud_cntrl_st2; - if (IS_IVYBRIDGE(connector->dev)) { - hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A; - aud_cntl_st = GEN7_AUD_CNTRL_ST_A; - aud_cntrl_st2 = GEN7_AUD_CNTRL_ST2; - } else { + if (IS_GEN5(connector->dev)) { hdmiw_hdmiedid = GEN5_HDMIW_HDMIEDID_A; aud_cntl_st = GEN5_AUD_CNTL_ST_A; aud_cntrl_st2 = GEN5_AUD_CNTL_ST2; + } else { + hdmiw_hdmiedid = GEN6_HDMIW_HDMIEDID_A; + aud_cntl_st = GEN6_AUD_CNTL_ST_A; + aud_cntrl_st2 = GEN6_AUD_CNTRL_ST2; } i = to_intel_crtc(crtc)->pipe; --wac7ysb48OaltWcw Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --wac7ysb48OaltWcw--