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

[Tony Olivo]

Wu Fengguang <fengguang.wu <at> intel.com> writes:

> 
> Hi Christopher,
> 
> > 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.
> 
> Thanks,
> Fengguang
> 

I have a similar receiver to Christopher, an Onkyo TX-SR507, which is the same
model year, but fewer speaker outputs (5.1 instead of his I think 7.2). I had
been having trouble getting ELD data to read properly, but was able to play
sound (for the most part, I'll touch on that below). I have an ECS H55H-I, so
the H55 chipset. The alsa generated file /proc/asound/card0/eld#3.0 used to say
there was no valid ELD data and just had zeroes in all fields.

Following Keith Packard's suggestion, I checked out rev
43672a0784707d795556b1f93925da8b8e797d03 (I forget how much you can truncate a
git rev number and still be safe) from Linus's kernel git.
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . I compiled
and restarted and then I did get good ELD. There is a peculiar error at the end
of dmesg that says "[73093.946346] [drm:drm_edid_block_valid] *ERROR* EDID
checksum is invalid, remainder is 29", but the proc eld file still looks good.

Despite all of that, speaker-test only gives good results with the rate set to
44100 or its multiples 88200 and 176400. 32000, 48000, 96000, 192000 do play the
pink noise, but drop out intermittently. The problem seems to either cause or be
an effect of the receiver losing its mind about what the incoming stream is.
While it plays the 44100 speaker-test the front panel lights are locked in to
"PCM MULTICHANNEL HDMI". When I play 48000 the same lights come on, but every
few seconds PCM and MULTICHANNEL will go off at the same time, followed by HDMI.
This is when the sound cuts out, the video however remains on screen untouched.
The HDMI light will come back on shortly after, followed by the PCM MULTICHANNEL
and sound will resume. 

This was a problem before the patched kernel that I was hoping proper ELD info
would clear up. I see no messages in dmesg while the skipping is occurring, nor
anything interesting from HDAAnalyzer.

Here are some dumps:
proc/asound/card0/eld#3.0 http://pastebin.com/d3FsG8fn
intel-audio-dump http://pastebin.com/f6M915Ui
alsa-info http://pastebin.com/ddwNcLVL
Entech output http://pastebin.com/7ENTiBrb

Thanks,
-Tony Olivo