[Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

Christopher White c.white at pulseforce.com
Tue Nov 1 18:00:32 CET 2011


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



More information about the Intel-gfx mailing list