From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher White Subject: Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver Date: Wed, 09 Nov 2011 10:00:32 +0100 Message-ID: <4EBA4130.7010401@pulseforce.com> 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> <20111109065953.GB28238@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0947530231==" Return-path: Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by gabe.freedesktop.org (Postfix) with ESMTP id 1166C9E7F3 for ; Wed, 9 Nov 2011 01:00:42 -0800 (PST) Received: from homiemail-a53.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 9594C1B7008 for ; Wed, 9 Nov 2011 01:00:41 -0800 (PST) In-Reply-To: <20111109065953.GB28238@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: Jeremy Bush , "intel-gfx@lists.freedesktop.org" , "Wang, Zhenyu Z" , "Bossart, Pierre-louis" List-Id: intel-gfx@lists.freedesktop.org This is a multi-part message in MIME format. --===============0947530231== Content-Type: multipart/alternative; boundary="------------010805090502030604040204" This is a multi-part message in MIME format. --------------010805090502030604040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Good day, Fengguang! Great work! This sounds very promising! I went through the ELD parsing code myself (drm_edid_to_eld), as my programmer mind's curiosity killed me even though I didn't really have time for it, and I could see that it grabs the CEA extension block, grabs the monitor name string, then goes through each data block collection, copying all short descriptor data for each of the block types we're interested in. Good and clean code. So, I came to the same conclusion - that the parsing code was completely correct. I'm therefore very happy to hear that you've found the real problem; trying to write the ELD structure to the wrong audio registers on SandyBridge. Yep, that HAS to be it! I've applied the patch and the kernel is currently being re-built, but I've got to leave home so I won't report back until later today. However, I am confident that you've found the true cause of the problem. Superb work once again! You're going to make a lot of Home Theater PC owners very happy. Christopher White On 11/9/11 7:59 AM, Wu Fengguang wrote: > 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 --------------010805090502030604040204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Good day, Fengguang! Great work! This sounds very promising!

I went through the ELD parsing code myself (drm_edid_to_eld), as my programmer mind's curiosity killed me even though I didn't really have time for it, and I could see that it grabs the CEA extension block, grabs the monitor name string, then goes through each data block collection, copying all short descriptor data for each of the block types we're interested in. Good and clean code.

So, I came to the same conclusion - that the parsing code was completely correct. I'm therefore very happy to hear that you've found the real problem; trying to write the ELD structure to the wrong audio registers on SandyBridge. Yep, that HAS to be it!

I've applied the patch and the kernel is currently being re-built, but I've got to leave home so I won't report back until later today.

However, I am confident that you've found the true cause of the problem. Superb work once again!

You're going to make a lot of Home Theater PC owners very happy.


Christopher White

On 11/9/11 7:59 AM, Wu Fengguang wrote: 
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
--------------010805090502030604040204-- --===============0947530231== 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 --===============0947530231==--