drm/i915: pass ELD to HDMI/DP audio driver
Subsystems (4)
At Sat, 12 Nov 2011 10:27:26 +0800,
Quoted 15 lines · Wu Fengguang
(snip)
Quoted 13 lines
Quoted 12 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
And I'm not sure whether HDMI audio is played
while DPMS is off. I haven't tested it.It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side.
Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control...
There may be some mode that can keep video off while still keep minimal signals to play HDMI sound?
Quoted 7 lines
Quoted 1 line
Let's hope :)
Looks very possible, here is the clue of hardware support:
TRANS_DP_CTL- Transcoder DisplayPort Controlbit 26: Transcoder DP Audio Only Mode
Good to know! But what about HDMI?
thanks,
Takashi
Quoted 19 lines · Takashi Iwai
At Sat, 12 Nov 2011 10:27:26 +0800,
Quoted 17 lines · Wu Fengguang
(snip)
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
And I'm not sure whether HDMI audio is played
while DPMS is off. I haven't tested it.It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side.
Quoted 5 lines
Quoted 2 lines
Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control...
There may be some mode that can keep video off while still keep minimal signals to play HDMI sound?
Let's hope :)
Quoted 7 lines
Quoted 5 lines
Looks very possible, here is the clue of hardware support:
TRANS_DP_CTL- Transcoder DisplayPort Controlbit 26: Transcoder DP Audio Only Mode
Good to know! But what about HDMI?
I'm not sure.. There are no corresponding TRANS_HDMI_CTL registers...
Thanks,
Fengguang
Quoted 18 lines
-----Original Message-----
From: intel-gfx- [email protected] [mailto:intel-gfx- [email protected]] On Behalf Of Wu Fengguang
Sent: Monday, November 14, 2011 6:56 PM
To: Takashi Iwai
Cc: Wang, Zhenyu Z; [email protected]; Barnes, Jesse; Jeremy Bush; Christopher White; Bossart, Pierre-louis
Subject: Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driverQuoted 3 lines · Takashi Iwai
At Sat, 12 Nov 2011 10:27:26 +0800,
Quoted 1 line · Wu Fengguang
Quoted 17 lines
Quoted 5 lines
Quoted 5 lines
(snip)
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
And I'm not sure whether HDMI audio is played
while DPMS is off. I haven't tested it.It will go silence on DPMS. I noticed this while doing long
term HDMI
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
audio playback tests. This should better be fixed in future on
the
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
graphics side.
Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control...
There may be some mode that can keep video off while still keep minimal signals to play HDMI sound?
Let's hope :)
You can turn off only the plane (but don't turn off the pipe & port) to achieve this.
Not much of power saving compared to DPMS though.
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines
Looks very possible, here is the clue of hardware support:
TRANS_DP_CTL- Transcoder DisplayPort Controlbit 26: Transcoder DP Audio Only Mode
Good to know! But what about HDMI?
I'm not sure.. There are no corresponding
TRANS_HDMI_CTLregisters...
Bit 26 of TRANS_DP_CTL does not work. Also there is no such bit for HDMI.
Quoted 6 lines
Thanks,
Fengguang
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Thanks,
Vijay
Christopher,
Quoted 7 lines
The dump tool did not work with that environment variable either. However, it occurred to me that
intel_audio_dumpmay 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.
Quoted 6 lines
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
Quoted 12 lines
/sys/kernel/debugand enabled in the kernel (kernel hacking > debug file system). Finally, building it is standard procedure withautogen.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 "whichintel_audio_dump" that it DID point to the NEW/usr/local/bin/intel_audio_dumppath, and not the OLD/usr/bin/intel_audio_dumppath.
Quoted 6 lines
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 :-)
Quoted 8 lines
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)?
Quoted 4 lines
relevant dump portion here:
AUD_HDMIW_HDMIEDID_AHDMI 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;Quoted 12 lines
AUD_HDMIW_HDMIEDID_BHDMI 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
Quoted 4 lines
00000000
I decided to look in
/sys/class/drm/card0-HDMI-A-2/edidand it's 0 bytes! This used to be 256 bytes! How freaking weird is that?! That
That's mysterious indeed.
Quoted 7 lines
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.
Quoted 4 lines
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.
Quoted 10 lines
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/edidnow 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_Dumpshowing 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.
Quoted 27 lines
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_AHDMI 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
Quoted 3 lines
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.
Quoted 2 lines
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