[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