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: Thu, 10 Nov 2011 14:59:05 +0800 Message-ID: <20111110065905.GA6676@localhost> References: <4E64C41B.5090309@pulseforce.com> <20110905124730.GB794@localhost> <4EA82DBD.9020301@pulseforce.com> <4EA9B6EF.9040305@pulseforce.com> <20111101113645.GA19100@localhost> <4EB025B0.4000900@pulseforce.com> <20111102014541.GA16026@localhost> <4EB4813B.6060809@pulseforce.com> <20111109131233.GA13654@localhost> <4EBB3637.1070606@pulseforce.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 2E2179ED14 for ; Wed, 9 Nov 2011 22:59:08 -0800 (PST) Content-Disposition: inline In-Reply-To: <4EBB3637.1070606@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 Christopher, > The dump tool did not work with that environment variable either. > However, it occurred to me that intel_audio_dump may be too outdated in > my distro. It was built on 2010-04-01, v1.0.2+git20100324. If I look at > http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ I can see that the > reason for this is that the latest stable was 1.0.2 tagged nearly two > years ago. > > I decided to build intel-gpu-tools from the latest Git source instead. > That took a while to figure out as it also needed xutils-dev package for > xorg-macros.m4, required by the autoconf script, and libtool (needed by > the resulting configure script). So the complete list of dependencies is > "autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 > xutils-dev libtool". DebugFS must also be ready and mounted on Sorry I should have reminded you of the build dependencies. I use debian and it's fairly easy for me to install the relevant packages: apt-get build-dep intel-gpu-tools > /sys/kernel/debug and enabled in the kernel (kernel hacking > debug file > system). Finally, building it is standard procedure with autogen.sh, > configure, make and make install. (I am writing down these instructions > just in case someone else reads this down the line; Google is a > wonderful thing). > > After building, I tried running intel_audio_dump, and was first > dumbfounded as it gave me the same error, "Couldn't map MMIO region". I > verified with "which intel_audio_dump" that it DID point to the NEW > /usr/local/bin/intel_audio_dump path, and not the OLD > /usr/bin/intel_audio_dump path. > > However, I thought that maybe it WAS running the OLD version for some > reason despite claiming it was pointing to the new one. So, I tried > calling it specifically with the full path to the new binary, and... > SUCCESS! You need to tag a new release version of intel-gpu-tools soon > so that distros are updated, since the old 1.0.2 release does NOT > support SandyBridge. FYI I'm preparing a bunch of patches for intel_audio_dump :-) > I've attached the full dump here. Scroll down to the bottom and you can > see that I was right in my theory that all the ELD data was zeroed out. > But hey at least we're getting SOMEWHERE! ;-) > > So what we KNOW now: ELD parsing code = 100% correct. ELD writing to > correct audio register = 100% correct, verified by looking at > snd_hdmi_show_eld()'s output in dmesg log. However, SOMETIME after the > boot, it seems that it gets corrupted/zeroed out. I'll replicate the Yes, and I'm still puzzled how come ironlake_write_eld() writes nonzero ELD to pipe A and the audio driver gets all zero. Some hw reset in between (sounds very unlikely)? > relevant dump portion here: > > AUD_HDMIW_HDMIEDID_A HDMI ELD: > 10000d00 6882004f 00000000 00000000 3dcb6508 That's written by ironlake_write_eld(), which will never write all zeros because it has an explicit test if (!eld[0]) return; > AUD_HDMIW_HDMIEDID_B HDMI ELD: > 00000000 00000000 00000000 00000000 00000000 > AUD_HDMIW_HDMIEDID_C HDMI ELD: > 00000000 00000000 00000000 00000000 00000000 > AUD_HDMIW_INFOFR_A HDMI audio Infoframe: > 84010a70 01000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > AUD_HDMIW_INFOFR_B HDMI audio Infoframe: > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > AUD_HDMIW_INFOFR_C HDMI audio Infoframe: > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > > I decided to look in /sys/class/drm/card0-HDMI-A-2/edid and it's 0 > bytes! This used to be 256 bytes! How freaking weird is that?! That That's mysterious indeed. > means: System boots up, Intel driver sees 256 byte EDID, parses it into > ELD, writes it to the audio register, the system dmesg log shows that it > parsed all supported audio modes correctly, then the system boots and > edid becomes 0 bytes, and the ELD is zeroed out. What the heck is going > on here? :-O I tried "dmesg | grep "HDMI: detected monitor"" and see > NOTHING later than the initial boot event, meaning I have no freaking > clue why it's zeroing out the EDID. I'm sure that the gfx/audio driver code I wrote won't zero out the ELD SILENTLY without any clues in dmesg. There must be something else happening. > It almost looks like the act of writing ELD to the audio register is > tampering with the ability of the graphics card to read the EDID itself > after that point. Erhmm... This is very odd. > > Finally, I tried a complete power cycle of every component, turning off > the outlet power on everything. I then started the Receiver, then the > Projector, and finally the computer. Not that startup order matters > much, but this is the optimal order. However, it still did the same > thing. With one difference. /sys/class/drm/card0-HDMI-A-2/edid now > contains the correct contents. Everything else was as before: > /proc/asound/card0/eld#3.0 full of zeroes as shown in the attached file. > Intel_Audio_Dump showing the EXACT SAME zeroed out content as I have > quoted above. DMESG showing the exact same, nice list of supported > codecs and rates. The user space is also able to zero out the ELD by writing to /proc/asound/card0/eld#3.0, however this is also very unlikely to happen. > So, somewhere AFTER the write of correct ELD to the audio register, it > all goes wrong and gets zeroed out. I'm thinking POSSIBLY some routine > that runs after snd_hdmi_show_eld() could be responsible for clearing > all data? > > This is on an ASUS P8H67-I B3 m-ITX Intel H67 motherboard, and an Intel > Core i5 2500K CPU with Intel HD3000. > > Err... wait a minute! I think I've figured it out! > > My Intel H67 motherboard has ONE HDMI output. That port is connected to > card0-HDMI-A-2 internally (port two, NOT port one). > > Now note the audio register dump again: > > AUD_HDMIW_HDMIEDID_A HDMI ELD: > 10000d00 6882004f 00000000 00000000 3dcb6508 > AUD_HDMIW_HDMIEDID_B HDMI ELD: > 00000000 00000000 00000000 00000000 00000000 > AUD_HDMIW_HDMIEDID_C HDMI ELD: > 00000000 00000000 00000000 00000000 00000000 > AUD_HDMIW_INFOFR_A HDMI audio Infoframe: > 84010a70 01000000 00000000 00000000 00000000 00000000 00000000 00000000 > AUD_HDMIW_INFOFR_B HDMI audio Infoframe: > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > AUD_HDMIW_INFOFR_C HDMI audio Infoframe: > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > > It has written Port 2's ELD to Port 1, and zeroed out all other ports. Nope. ironlake_write_eld() never writes zero ELD to hardware. > So OF COURSE when the driver goes to query the ELD for port 2, it finds > zeroed out data. It cannot explain why ironlake_write_eld() always write to pipe A and the audio driver sometimes gets the right ELD and sometimes get zero. Thanks, Fengguang