<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Couldn't
resist connecting to my machine over VNC even though I'm not
home.<br>
<br>
So, I booted it with the new patch and see that while you HAVE
found the bug, the new register addresses still seem to be
wrong. Instead of the audio registers containing their default,
pre-filled, standard 2-speaker configuration, it's now being
overwritten - which is good. With garbage - which is bad. ;-)
One possible cause is that the SandyBridge addresses shouldn't
use the same register addresses as IvyBridge after all. This
will have to be double checked.<br>
<br>
Instead of /proc/asound/card0/eld#3.0 containing the default
2-speaker configuration, it now contains:<br>
monitor_present 1<br>
eld_valid 1<br>
monitor_name <br>
connection_type HDMI<br>
eld_version [0x0] reserved<br>
edid_version [0x0] no CEA EDID Timing Extension block
present<br>
manufacture_id 0x0<br>
product_id 0x0<br>
port_id 0x0<br>
support_hdcp 0<br>
support_ai 0<br>
audio_sync_delay 0<br>
speakers [0x0]<br>
sad_count 0<br>
<br>
You can see that the data is obviously zeroed out, and I bet
it's due to a misaligned address.<br>
<br>
Booting with drm.debug=6 produced the attached log file which
I've included for completeness. However, there's nothing strange
in it.<br>
<br>
<br>
Christopher<br>
<br>
</font></font>On 11/9/11 10:00 AM, Christopher White wrote:
<blockquote cite="mid:4EBA4130.7010401@pulseforce.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Good
day, Fengguang! Great work! This sounds very promising!<br>
<br>
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.<br>
<br>
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!<br>
<br>
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.<br>
<br>
However, I am confident that you've found the true cause of
the problem. Superb work once again!<br>
<br>
You're going to make a lot of Home Theater PC owners very
happy.<br>
<br>
<br>
Christopher White</font></font><br>
<br>
On 11/9/11 7:59 AM, Wu Fengguang wrote:
<blockquote cite="mid:20111109065953.GB28238@localhost"
type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://kernel.ubuntu.com/%7Ekernel-ppa/mainline/drm-intel-next/current/">http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/</a> 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:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.pulseforce.com/node/edid.dump">http://www.pulseforce.com/node/edid.dump</a>
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</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>