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

[Sander Jansen]

On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> Dear Sander,
>
>
> Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen:
>> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang <fengguang.wu at intel.com> wrote:
>
>> >> 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
>> >
>> > It looks all sane to this point.
>> >
>> >> 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
>> >
>> > Agreed.
>> >
>> >> 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
>> >
>> > Thanks! It's great tool and information!
>> >
>> >> 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.
>> >
>> > Would you install the "intel-gpu-tools" package and run its
>> > intel_audio_dump utility? If not shipped with your distribution, the
>> > source code is also available in
>> >
>> > git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools
>> >
>> > You'll need to install packages "autotools-dev pkg-config
>> > libpciaccess-dev libdrm-dev libdrm-intel1" in order to build it from
>> > source.
>> >
>> > intel_audio_dump will dump the ELD data in the hardware buffer for use
>> > by the audio driver. By verifying if that data is correct, we are able
>> > to analyze whether and how the audio driver goes wrong.
>> >
>>
>> I think I experience similar issues. In my case the multi-channel pcm
>> playback through HDMI doesn't work. Stereo and passthrough seem to
>> work fine though !? It's hookedup  to my TV via a yamaha receiver.
>>
>> I'm currently running Linux 3.1 with a G45 chipset.
>>
>> libdrm 2.4.27-1
>> xf86-video-intel 2.16.0-1
>
> do you have Fengguang’s patch applied? This thread is about testing that
> patch.
>
>> The eld seems be incorrectly parsed, though the kernel log didn't give
>> much info. The eld info from alsa is rather empty:
>>
>> cat /proc/asound/Intel/eld#3.0
>> monitor_present               1
>> eld_valid             0
>>
>> Using the same Monitor Asset Manager I was able to verify that the edid from
>> (/sys/devices/pci0000\:00/0000\:00\:02.0/drm/card0/card0-HDMI-A-1/edid
>> ) does seem to contain the correct information.
>>
>> I've attached both the edid and the output of Monitor Asset Manager.In
>> addition I also run the intel_audio_dump.
>>
>> Let me know if you need anymore information.
>
> It would be great if you could test the patch.


Ah, that explains. I was under the impression this was already in 3.1
(but then again, it was rather late for me :) )
I will give the patch a try and report back.
.
Thanks,

Sander