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: Tue, 01 Nov 2011 18:00:32 +0100 Message-ID: <4EB025B0.4000900@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> <4EA9B6EF.9040305@pulseforce.com> <20111101113645.GA19100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by gabe.freedesktop.org (Postfix) with ESMTP id 55D0E9E752 for ; Tue, 1 Nov 2011 10:01:00 -0700 (PDT) Received: from homiemail-a40.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id DF6FD17F3EF for ; Tue, 1 Nov 2011 10:00:58 -0700 (PDT) In-Reply-To: <20111101113645.GA19100@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 On 11/1/11 12:36 PM, Wu Fengguang wrote: > Hi Christopher, > > Sorry I'm just back from traveling.. No worries, I am not in any hurry, and I hope you had a great holiday! :-) > > On Fri, Oct 28, 2011 at 03:54: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: > Would you boot the kernel with drm.debug=6 and post the dmesg? > That will show more details. > > One possible problem is the hardware reports small ELD buffer size > which truncates the additional 8-channel information. > > Thanks, > Fengguang Done. Sorry for the delay, didn't see your message until now, and also had to re-build the kernel. The log does confirm that the drm_edid_to_eld function is running, and that we're not far from a solution: [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free "Monitor Asset Manager" by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Christopher > >> 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