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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
