Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

[Christopher White <c.white@pulseforce.com>]

On 11/2/11 2:45 AM, Wu Fengguang wrote:
> 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've been really busy on a project (as mentioned in my last posting) and 
apologize for the 2 day delay. The project is now done and no further 
response delays will happen. Promise.

Alright, so first of all I am glad that you found the tool and 
information useful.

Now, onto the intel-gpu-tools test. I ran intel_audio_dump as requested 
and it only comes back with "Couldn't map MMIO region: No such file or 
directory". I spent 10 minutes looking around on Google to no avail. It 
seems it tries to mmap() something that doesn't exist.

I then spent some time looking in /var/log/Xorg.0.log to double-check 
what driver it's using. It says:
"Matched intel as autoconfigured driver 0
Matched vesa as autoconfigured driver 1
Matched fbdev as autoconfigured driver 2
VESA: driver for VESA chipsets: vesa
FBDEV: driver for framebuffer: fbdev
Loading: /usr/lib/xorg/modules/drivers/intel_drv.so"

All in all it looks fine, at least as far as I can tell. I mean, we 
already KNOW the driver has to be running since I see the DRM module in 
the logs.

So, the Intel driver is running, yet whatever file intel_audio_dump is 
looking for doesn't exist.

We already know that the DRM driver is reading the correct EDID, by the 
way, since we saw "[   21.061417] [drm:drm_edid_to_eld], ELD monitor 
TX-SR607".

The EDID it's reading from is the dump I linked to in the previous posting.

To go the extra mile, I just looked at the xf86-video-intel source in 
src/reg_dumper_util.c, which is where the "Couldn't map MMIO region" 
message originated. I now see that it's not trying to mmap() a physical 
file. It tries to map the graphics card's physical memory using 
pci_device_map_range(dev, dev->regions[mmio_bar].base_addr, 
dev->regions[mmio_bar].size, PCI_DEV_MAP_FLAG_WRITABLE, &mmio);

It tries that AFTER it has already found the graphics adapter and 
verified that it's from Intel.

So, why it fails to actually map the memory of the device is anyone's 
guess. Perhaps there's no support for the HD3000 in intel_audio_dump?

Anyway, with all of this out of the way: Why not instead look at the 
EDID binary dump I sent you and step through the edid_to_eld() function 
to see what it's doing?


Christopher