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

[Paul Menzel]

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.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111102/b5569e31/attachment.sig>