From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher White Subject: Re: [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver Date: Thu, 10 Nov 2011 03:25:59 +0100 Message-ID: <4EBB3637.1070606@pulseforce.com> References: <20110905123128.GA31852@localhost> <4E64C41B.5090309@pulseforce.com> <20110905124730.GB794@localhost> <4EA82DBD.9020301@pulseforce.com> <4EA9B6EF.9040305@pulseforce.com> <20111101113645.GA19100@localhost> <4EB025B0.4000900@pulseforce.com> <20111102014541.GA16026@localhost> <4EB4813B.6060809@pulseforce.com> <20111109131233.GA13654@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060907080701020201000902" Return-path: Received: from homiemail-a54.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by gabe.freedesktop.org (Postfix) with ESMTP id 1AA0E9E7A0 for ; Wed, 9 Nov 2011 18:26:07 -0800 (PST) In-Reply-To: <20111109131233.GA13654@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Wu Fengguang Cc: Jeremy Bush , "intel-gfx@lists.freedesktop.org" , "Wang, Zhenyu Z" , "Bossart, Pierre-louis" List-Id: intel-gfx@lists.freedesktop.org This is a multi-part message in MIME format. --------------060907080701020201000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Fengguang, I am quoting both your messages below so read until the bottom. I've even found what looks to be the cause. On 11/9/11 2:01 PM, Wu Fengguang wrote: > Christopher, > > On Wed, Nov 09, 2011 at 05:30:18PM +0800, Christopher White wrote: >> Couldn't resist connecting to my machine over VNC even though I'm not home. > Thanks a lot! > >> So, I booted it with the new patch and see that while you HAVE found >> the bug, the new register addresses still seem to be wrong. Instead >> of the audio registers containing their default, pre-filled, >> standard 2-speaker configuration, > Yeah, AFAICS the BIOS may choose to pre-fill some simple ELD at boot time. Indeed, I could tell that the 2ch standard configuration was a pre-filled default. > >> it's now being overwritten - which >> is good. With garbage - which is bad. ;-) > One step forward ;-) Yes! ;-) > >> One possible cause is that >> the SandyBridge addresses shouldn't use the same register addresses >> as IvyBridge after all. This will have to be double checked. > What puzzled me is that I've been testing DisplayPort on a Sandybridge > notebook today and it is working fine. > > The other question is, why the intel_audio_dump tool goes wrong with > your hardware? It's reading the right register addresses in all the > boxes I tested... I've got good news about that further down. > >> Instead of /proc/asound/card0/eld#3.0 containing the default 2-speaker configuration, it now contains: >> monitor_present 1 >> eld_valid 1 > So at least it sets the ELD valid bit right. Hehe. That might be a side effect of incorrect writing though. We'll see. > >> monitor_name >> connection_type HDMI >> eld_version [0x0] reserved >> edid_version [0x0] no CEA EDID Timing Extension block present >> manufacture_id 0x0 >> product_id 0x0 >> port_id 0x0 >> support_hdcp 0 >> support_ai 0 >> audio_sync_delay 0 >> speakers [0x0] >> sad_count 0 >> >> You can see that the data is obviously zeroed out, and I bet it's due to a misaligned address. > Did you view *every* ELD file? > > cat /proc/asound/card0/eld* Yeah, the attached _eld.txt file shows that there is only *one* ELD file there. This is the file that used to contain the default 2ch initialization of the audio registers. At least we've come far enough that it's now being overwritten. It's being incorrectly overwritten or corrupted afterwards, but it's a start. > I verified that it's writing to the right address in the spec. And even > find direct evidence in your dmesg that the ELD contents are correctly > received and interpreted by the audio driver: > > [ 10.278612] HDMI hot plug event: Pin=7 Presence_Detect=1 ELD_Valid=1 > [ 10.278644] HDMI status: Pin=7 Presence_Detect=1 ELD_Valid=1 > > Output by snd_hdmi_show_eld(): > [ 10.282143] HDMI: detected monitor TX-SR607 at connection type HDMI > [ 10.282145] HDMI: available speakers: FL/FR LFE FC RL/RR RLC/RRC > [ 10.282147] HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200 176400 192000 384000, bits = 16 20 24 > [ 10.282149] HDMI: supports coding type LPCM: channels = 8, rates = 44100 48000 88200 176400 192000 384000, bits = 16 20 24 > [ 10.282151] HDMI: supports coding type AC-3: channels = 8, rates = 44100 48000 88200, max bitrate = 640000 > [ 10.282152] HDMI: supports coding type DTS: channels = 8, rates = 48000 88200, max bitrate = 1536000 > [ 10.282154] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 48000 > [ 10.282155] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 48000 88200 > [ 10.282157] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 88200 176400 192000 384000 > [ 10.282159] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 88200 192000 > Hmm, wow, I compared this to my older dmesg.log which I gave you a few weeks ago, and that's definitely news. It was only showing the default 2ch configuration before. Now it IS writing to the correct address. How VERY strange! So it DOES write to the correct register... It gets STRANGER though, as you'll see at the bottom of this email. >> Booting with drm.debug=6 produced the attached log file which I've included for completeness. However, there's nothing strange in it. > Thanks, the full dmesg helped a lot! > >> On 11/9/11 10:00 AM, Christopher White wrote: >> Good day, Fengguang! Great work! This sounds very promising! >> >> I went through the ELD parsing code myself (drm_edid_to_eld), as my programmer mind's curiosity killed me even though I didn't really have time for it, and I could see that it grabs the CEA extension block, grabs the monitor name string, then goes through each data block collection, copying all short descriptor data for each of the block types we're interested in. Good and clean code. >> >> So, I came to the same conclusion - that the parsing code was completely correct. I'm therefore very happy to hear that you've found the real problem; trying to write the ELD structure to the wrong audio registers on SandyBridge. Yep, that HAS to be it! >> >> I've applied the patch and the kernel is currently being re-built, but I've got to leave home so I won't report back until later today. >> >> However, I am confident that you've found the true cause of the problem. Superb work once again! >> >> You're going to make a lot of Home Theater PC owners very happy. > ...I appreciate your help a lot! > > Thanks, > Fengguang On 11/9/11 2:12 PM, Wu Fengguang wrote: > Hi Christopher, > >> 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. > What if you run it with > > export HAS_PCH_SPLIT=1 > intel_audio_dump > > I also queued a patch for the tool. Note that if the above trick > failed to work, the applied patch won't help, too. > > Thanks, > Fengguang The dump tool did not work with that environment variable either. However, it occurred to me that intel_audio_dump may be too outdated in my distro. It was built on 2010-04-01, v1.0.2+git20100324. If I look at http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ I can see that the reason for this is that the latest stable was 1.0.2 tagged nearly two years ago. I decided to build intel-gpu-tools from the latest Git source instead. That took a while to figure out as it also needed xutils-dev package for xorg-macros.m4, required by the autoconf script, and libtool (needed by the resulting configure script). So the complete list of dependencies is "autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 xutils-dev libtool". DebugFS must also be ready and mounted on /sys/kernel/debug and enabled in the kernel (kernel hacking > debug file system). Finally, building it is standard procedure with autogen.sh, configure, make and make install. (I am writing down these instructions just in case someone else reads this down the line; Google is a wonderful thing). After building, I tried running intel_audio_dump, and was first dumbfounded as it gave me the same error, "Couldn't map MMIO region". I verified with "which intel_audio_dump" that it DID point to the NEW /usr/local/bin/intel_audio_dump path, and not the OLD /usr/bin/intel_audio_dump path. However, I thought that maybe it WAS running the OLD version for some reason despite claiming it was pointing to the new one. So, I tried calling it specifically with the full path to the new binary, and... SUCCESS! You need to tag a new release version of intel-gpu-tools soon so that distros are updated, since the old 1.0.2 release does NOT support SandyBridge. I've attached the full dump here. Scroll down to the bottom and you can see that I was right in my theory that all the ELD data was zeroed out. But hey at least we're getting SOMEWHERE! ;-) So what we KNOW now: ELD parsing code = 100% correct. ELD writing to correct audio register = 100% correct, verified by looking at snd_hdmi_show_eld()'s output in dmesg log. However, SOMETIME after the boot, it seems that it gets corrupted/zeroed out. I'll replicate the relevant dump portion here: AUD_HDMIW_HDMIEDID_A HDMI ELD: 10000d00 6882004f 00000000 00000000 3dcb6508 AUD_HDMIW_HDMIEDID_B HDMI ELD: 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_HDMIEDID_C HDMI ELD: 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_INFOFR_A HDMI audio Infoframe: 84010a70 01000000 00000000 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_INFOFR_B HDMI audio Infoframe: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_INFOFR_C HDMI audio Infoframe: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 I decided to look in /sys/class/drm/card0-HDMI-A-2/edid and it's 0 bytes! This used to be 256 bytes! How freaking weird is that?! That means: System boots up, Intel driver sees 256 byte EDID, parses it into ELD, writes it to the audio register, the system dmesg log shows that it parsed all supported audio modes correctly, then the system boots and edid becomes 0 bytes, and the ELD is zeroed out. What the heck is going on here? :-O I tried "dmesg | grep "HDMI: detected monitor"" and see NOTHING later than the initial boot event, meaning I have no freaking clue why it's zeroing out the EDID. It almost looks like the act of writing ELD to the audio register is tampering with the ability of the graphics card to read the EDID itself after that point. Erhmm... This is very odd. Finally, I tried a complete power cycle of every component, turning off the outlet power on everything. I then started the Receiver, then the Projector, and finally the computer. Not that startup order matters much, but this is the optimal order. However, it still did the same thing. With one difference. /sys/class/drm/card0-HDMI-A-2/edid now contains the correct contents. Everything else was as before: /proc/asound/card0/eld#3.0 full of zeroes as shown in the attached file. Intel_Audio_Dump showing the EXACT SAME zeroed out content as I have quoted above. DMESG showing the exact same, nice list of supported codecs and rates. So, somewhere AFTER the write of correct ELD to the audio register, it all goes wrong and gets zeroed out. I'm thinking POSSIBLY some routine that runs after snd_hdmi_show_eld() could be responsible for clearing all data? This is on an ASUS P8H67-I B3 m-ITX Intel H67 motherboard, and an Intel Core i5 2500K CPU with Intel HD3000. Err... wait a minute! I think I've figured it out! My Intel H67 motherboard has ONE HDMI output. That port is connected to card0-HDMI-A-2 internally (port two, NOT port one). Now note the audio register dump again: AUD_HDMIW_HDMIEDID_A HDMI ELD: 10000d00 6882004f 00000000 00000000 3dcb6508 AUD_HDMIW_HDMIEDID_B HDMI ELD: 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_HDMIEDID_C HDMI ELD: 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_INFOFR_A HDMI audio Infoframe: 84010a70 01000000 00000000 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_INFOFR_B HDMI audio Infoframe: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 AUD_HDMIW_INFOFR_C HDMI audio Infoframe: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 It has written Port 2's ELD to Port 1, and zeroed out all other ports. So OF COURSE when the driver goes to query the ELD for port 2, it finds zeroed out data. Could this be it!? If so, this would be a bug related to the current TODO/FIXME of "needing per-port ELD parsing". --------------060907080701020201000902 Content-Type: text/plain; charset=UTF-8; name="_intel_audio_dump.txt" Content-Disposition: attachment; filename="_intel_audio_dump.txt" Content-Transfer-Encoding: quoted-printable HDMIB 0x0000001c sDVO/HDMI Port B Control HDMIC 0x00000018 HDMI Port C Control HDMID 0x80000adc HDMI Port D Control AUD_CONFIG_A 0x00000000 Audio Configuration =C2=AD Transcoder A AUD_CONFIG_B 0x00000000 Audio Configuration =C2=AD Transcoder B AUD_CONFIG_C 0x00000000 Audio Configuration =C2=AD Transcoder C AUD_CTS_ENABLE_A 0x00000000 Audio CTS Programming Enable =C2=AD Tra= nscoder A AUD_CTS_ENABLE_B 0x00000000 Audio CTS Programming Enable =C2=AD Tra= nscoder B AUD_CTS_ENABLE_C 0x00000000 Audio CTS Programming Enable =C2=AD Tra= nscoder C AUD_MISC_CTRL_A 0x00000044 Audio MISC Control for Transcoder A AUD_MISC_CTRL_B 0x00000044 Audio MISC Control for Transcoder B AUD_MISC_CTRL_C 0x00000044 Audio MISC Control for Transcoder C AUD_VID_DID 0x80862805 Audio Vendor ID / Device ID AUD_RID 0x00100000 Audio Revision ID AUD_PWRST 0x00000000 Audio Power State (Function Group, Conv= ertor, Pin Widget) AUD_PORT_EN_HD_CFG 0x00378007 Audio Port Enable HDAudio Config AUD_OUT_DIG_CNVT_A 0x00000000 Audio Digital Converter =C2=AD Conv A AUD_OUT_DIG_CNVT_B 0x00000000 Audio Digital Converter =C2=AD Conv B AUD_OUT_DIG_CNVT_C 0x00800000 Audio Digital Converter =C2=AD Conv C AUD_OUT_CH_STR 0x00f7f7f7 Audio Channel ID and Stream ID AUD_OUT_STR_DESC_A 0x00000032 Audio Stream Descriptor Format =C2=AD C= onv A AUD_OUT_STR_DESC_B 0x00000032 Audio Stream Descriptor Format =C2=AD C= onv B AUD_OUT_STR_DESC_C 0x00014011 Audio Stream Descriptor Format =C2=AD C= onv C AUD_PINW_CONNLNG_LIST 0x00030202 Audio Connection List AUD_PINW_CONNLNG_SEL 0x00030202 Audio Connection Select AUD_CNTL_ST_A 0x002354a8 Audio Control State Register =C2=AD Tra= nscoder A AUD_CNTL_ST_B 0x000054a8 Audio Control State Register =C2=AD Tra= nscoder B AUD_CNTL_ST_C 0x000054a8 Audio Control State Register =C2=AD Tra= nscoder C AUD_CNTRL_ST2 0x00000111 Audio Control State 2 AUD_CNTRL_ST3 0x00000000 Audio Control State 3 AUD_HDMIW_STATUS 0x80000000 Audio HDMI Status AUD_HDMIW_HDMIEDID_A 0x532d5854 HDMI Data EDID Block =C2=AD Transcoder = A AUD_HDMIW_HDMIEDID_B 0x00000000 HDMI Data EDID Block =C2=AD Transcoder = B AUD_HDMIW_HDMIEDID_C 0x00000000 HDMI Data EDID Block =C2=AD Transcoder = C AUD_HDMIW_INFOFR_A 0x00000000 Audio Widget Data Island Packet =C2=AD = Transcoder A AUD_HDMIW_INFOFR_B 0x00000000 Audio Widget Data Island Packet =C2=AD = Transcoder B AUD_HDMIW_INFOFR_C 0x00000000 Audio Widget Data Island Packet =C2=AD = Transcoder C Details: AUD_VID_DID vendor id 0x8086 AUD_VID_DID device id 0x2805 AUD_RID Major_Revision 0x1 AUD_RID Minor_Revision 0x0 AUD_RID Revision_Id 0x0 AUD_RID Stepping_Id 0x0 HDMIB Port_Enable 0 HDMIB Transcoder_Select [0x0] Transcoder A HDMIB sDVO_Border_Enable 0 HDMIB HDCP_Port_Select 0 HDMIB Port_Detected 1 HDMIB HDMI_or_DVI_Select DVI HDMIB Audio_Output_Enable 0 HDMIC Port_Enable 0 HDMIC Transcoder_Select [0x0] Transcoder A HDMIC sDVO_Border_Enable 0 HDMIC HDCP_Port_Select 0 HDMIC Port_Detected 0 HDMIC HDMI_or_DVI_Select DVI HDMIC Audio_Output_Enable 0 HDMID Port_Enable 1 HDMID Transcoder_Select [0x0] Transcoder A HDMID sDVO_Border_Enable 1 HDMID HDCP_Port_Select 0 HDMID Port_Detected 1 HDMID HDMI_or_DVI_Select HDMI HDMID Audio_Output_Enable 1 TRANS_DP_CTL_A DisplayPort_Enable 0 TRANS_DP_CTL_A Port_Width_Selection [0x0] x1 mode TRANS_DP_CTL_A Port_Detected 0 TRANS_DP_CTL_A HDCP_Port_Select 0 TRANS_DP_CTL_A Audio_Output_Enable 0 TRANS_DP_CTL_B DisplayPort_Enable 0 TRANS_DP_CTL_B Port_Width_Selection [0x0] x1 mode TRANS_DP_CTL_B Port_Detected 0 TRANS_DP_CTL_B HDCP_Port_Select 0 TRANS_DP_CTL_B Audio_Output_Enable 0 TRANS_DP_CTL_C DisplayPort_Enable 0 TRANS_DP_CTL_C Port_Width_Selection [0x0] x1 mode TRANS_DP_CTL_C Port_Detected 0 TRANS_DP_CTL_C HDCP_Port_Select 0 TRANS_DP_CTL_C Audio_Output_Enable 0 AUD_CONFIG_A Pixel_Clock_HDMI [0x0] 25.2 / 1.001 MHz AUD_CONFIG_B Pixel_Clock_HDMI [0x0] 25.2 / 1.001 MHz AUD_CONFIG_C Pixel_Clock_HDMI [0x0] 25.2 / 1.001 MHz AUD_CTS_ENABLE_A Enable_CTS_or_M_programming 0 AUD_CTS_ENABLE_A CTS_M value Index M AUD_CTS_ENABLE_A CTS_programming 0 AUD_CTS_ENABLE_B Enable_CTS_or_M_programming 0 AUD_CTS_ENABLE_B CTS_M value Index M AUD_CTS_ENABLE_B CTS_programming 0 AUD_CTS_ENABLE_C Enable_CTS_or_M_programming 0 AUD_CTS_ENABLE_C CTS_M value Index M AUD_CTS_ENABLE_C CTS_programming 0 AUD_MISC_CTRL_A Sample_Fabrication_EN_bit 1 AUD_MISC_CTRL_A Sample_present_Disable 0 AUD_MISC_CTRL_A Output_Delay 4 AUD_MISC_CTRL_A Pro_Allowed 0 AUD_MISC_CTRL_B Sample_Fabrication_EN_bit 1 AUD_MISC_CTRL_B Sample_present_Disable 0 AUD_MISC_CTRL_B Output_Delay 4 AUD_MISC_CTRL_B Pro_Allowed 0 AUD_MISC_CTRL_C Sample_Fabrication_EN_bit 1 AUD_MISC_CTRL_C Sample_present_Disable 0 AUD_MISC_CTRL_C Output_Delay 4 AUD_MISC_CTRL_C Pro_Allowed 0 AUD_PWRST Func_Grp_Dev_PwrSt_Curr D0 AUD_PWRST Func_Grp_Dev_PwrSt_Set D0 AUD_PWRST ConvertorA_Widget_Power_State_Current D0 AUD_PWRST ConvertorA_Widget_Power_State_Requsted D0 AUD_PWRST ConvertorB_Widget_Power_State_Current D0 AUD_PWRST ConvertorB_Widget_Power_State_Requested D0 AUD_PWRST ConvC_Widget_PwrSt_Curr D0 AUD_PWRST ConvC_Widget_PwrSt_Req D0 AUD_PWRST PinB_Widget_Power_State_Current D0 AUD_PWRST PinB_Widget_Power_State_Set D0 AUD_PWRST PinC_Widget_Power_State_Current D0 AUD_PWRST PinC_Widget_Power_State_Set D0 AUD_PWRST PinD_Widget_Power_State_Current D0 AUD_PWRST PinD_Widget_Power_State_Set D0 AUD_PORT_EN_HD_CFG Convertor_A_Digen 1 AUD_PORT_EN_HD_CFG Convertor_B_Digen 1 AUD_PORT_EN_HD_CFG Convertor_C_Digen 1 AUD_PORT_EN_HD_CFG ConvertorA_Stream_ID 0 AUD_PORT_EN_HD_CFG ConvertorB_Stream_ID 0 AUD_PORT_EN_HD_CFG ConvertorC_Stream_ID 8 AUD_PORT_EN_HD_CFG Port_B_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_C_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_D_Out_Enable 1 AUD_PORT_EN_HD_CFG Port_B_Amp_Mute_Status 1 AUD_PORT_EN_HD_CFG Port_C_Amp_Mute_Status 1 AUD_PORT_EN_HD_CFG Port_D_Amp_Mute_Status 0 AUD_OUT_DIG_CNVT_A V 0 AUD_OUT_DIG_CNVT_A VCFG 0 AUD_OUT_DIG_CNVT_A PRE 0 AUD_OUT_DIG_CNVT_A Copy 0 AUD_OUT_DIG_CNVT_A NonAudio 0x0 AUD_OUT_DIG_CNVT_A PRO 0 AUD_OUT_DIG_CNVT_A Level 0 AUD_OUT_DIG_CNVT_A Category_Code 0 AUD_OUT_DIG_CNVT_A Lowest_Channel_Number 0 AUD_OUT_DIG_CNVT_A Stream_ID 0 AUD_OUT_DIG_CNVT_B V 0 AUD_OUT_DIG_CNVT_B VCFG 0 AUD_OUT_DIG_CNVT_B PRE 0 AUD_OUT_DIG_CNVT_B Copy 0 AUD_OUT_DIG_CNVT_B NonAudio 0x0 AUD_OUT_DIG_CNVT_B PRO 0 AUD_OUT_DIG_CNVT_B Level 0 AUD_OUT_DIG_CNVT_B Category_Code 0 AUD_OUT_DIG_CNVT_B Lowest_Channel_Number 0 AUD_OUT_DIG_CNVT_B Stream_ID 0 AUD_OUT_DIG_CNVT_C V 0 AUD_OUT_DIG_CNVT_C VCFG 0 AUD_OUT_DIG_CNVT_C PRE 0 AUD_OUT_DIG_CNVT_C Copy 0 AUD_OUT_DIG_CNVT_C NonAudio 0x0 AUD_OUT_DIG_CNVT_C PRO 0 AUD_OUT_DIG_CNVT_C Level 0 AUD_OUT_DIG_CNVT_C Category_Code 0 AUD_OUT_DIG_CNVT_C Lowest_Channel_Number 0 AUD_OUT_DIG_CNVT_C Stream_ID 8 AUD_OUT_CH_STR Converter_Channel_MAP PORTB PORTC PORTD 1 1 1 1 2 2 2 2 3 16 16 16 4 16 16 16 5 16 16 16 6 16 16 16 7 16 16 16 8 16 16 16 AUD_OUT_STR_DESC_A HBR_enable 0 AUD_OUT_STR_DESC_A Convertor_Channel_Count 0 AUD_OUT_STR_DESC_A Bits_per_Sample 3 AUD_OUT_STR_DESC_A Number_of_Channels_in_a_Stream 3 AUD_OUT_STR_DESC_B HBR_enable 0 AUD_OUT_STR_DESC_B Convertor_Channel_Count 0 AUD_OUT_STR_DESC_B Bits_per_Sample 3 AUD_OUT_STR_DESC_B Number_of_Channels_in_a_Stream 3 AUD_OUT_STR_DESC_C HBR_enable 0 AUD_OUT_STR_DESC_C Convertor_Channel_Count 1 AUD_OUT_STR_DESC_C Bits_per_Sample 1 AUD_OUT_STR_DESC_C Number_of_Channels_in_a_Stream 2 AUD_PINW_CONNLNG_SEL Connection_select_Control_B 17 AUD_PINW_CONNLNG_SEL Connection_select_Control_C 64 AUD_PINW_CONNLNG_SEL Connection_select_Control_D 1 AUD_CNTL_ST_A DIP_Port_Select [0] Reserved AUD_CNTL_ST_A DIP_type_enable_status Audio DIP 1 AUD_CNTL_ST_A DIP_type_enable_status Generic 1 ACP DIP 0 AUD_CNTL_ST_A DIP_type_enable_status Generic 2 DIP 0 AUD_CNTL_ST_A DIP_transmission_frequency [0x3] best effort AUD_CNTL_ST_A ELD_ACK 0 AUD_CNTL_ST_A ELD_buffer_size 21 AUD_CNTL_ST_B DIP_Port_Select [0] Reserved AUD_CNTL_ST_B DIP_type_enable_status Audio DIP 0 AUD_CNTL_ST_B DIP_type_enable_status Generic 1 ACP DIP 0 AUD_CNTL_ST_B DIP_type_enable_status Generic 2 DIP 0 AUD_CNTL_ST_B DIP_transmission_frequency [0x0] disabled AUD_CNTL_ST_B ELD_ACK 0 AUD_CNTL_ST_B ELD_buffer_size 21 AUD_CNTL_ST_C DIP_Port_Select [0] Reserved AUD_CNTL_ST_C DIP_type_enable_status Audio DIP 0 AUD_CNTL_ST_C DIP_type_enable_status Generic 1 ACP DIP 0 AUD_CNTL_ST_C DIP_type_enable_status Generic 2 DIP 0 AUD_CNTL_ST_C DIP_transmission_frequency [0x0] disabled AUD_CNTL_ST_C ELD_ACK 0 AUD_CNTL_ST_C ELD_buffer_size 21 AUD_CNTRL_ST2 CP_ReadyB 0 AUD_CNTRL_ST2 ELD_validB 1 AUD_CNTRL_ST2 CP_ReadyC 0 AUD_CNTRL_ST2 ELD_validC 1 AUD_CNTRL_ST2 CP_ReadyD 0 AUD_CNTRL_ST2 ELD_validD 1 AUD_CNTRL_ST3 TransA_DPT_Audio_Output_En 0 AUD_CNTRL_ST3 TransA_to_Port_Sel [0] no port AUD_CNTRL_ST3 TransB_DPT_Audio_Output_En 0 AUD_CNTRL_ST3 TransB_to_Port_Sel [0] no port AUD_CNTRL_ST3 TransC_DPT_Audio_Output_En 0 AUD_CNTRL_ST3 TransC_to_Port_Sel [0] no port AUD_HDMIW_STATUS Conv_A_CDCLK/DOTCLK_FIFO_Underrun 0 AUD_HDMIW_STATUS Conv_A_CDCLK/DOTCLK_FIFO_Overrun 0 AUD_HDMIW_STATUS Conv_B_CDCLK/DOTCLK_FIFO_Underrun 0 AUD_HDMIW_STATUS Conv_B_CDCLK/DOTCLK_FIFO_Overrun 0 AUD_HDMIW_STATUS Conv_C_CDCLK/DOTCLK_FIFO_Underrun 1 AUD_HDMIW_STATUS Conv_C_CDCLK/DOTCLK_FIFO_Overrun 0 AUD_HDMIW_STATUS BCLK/CDCLK_FIFO_Overrun 0 AUD_HDMIW_STATUS Function_Reset 0 AUD_HDMIW_HDMIEDID_A HDMI ELD: 10000d00 6882004f 00000000 00000000 3dcb6508=20 AUD_HDMIW_HDMIEDID_B HDMI ELD: 00000000 00000000 00000000 00000000 00000000=20 AUD_HDMIW_HDMIEDID_C HDMI ELD: 00000000 00000000 00000000 00000000 00000000=20 AUD_HDMIW_INFOFR_A HDMI audio Infoframe: 84010a70 01000000 00000000 00000000 00000000 00000000 00000000 00000000=20 AUD_HDMIW_INFOFR_B HDMI audio Infoframe: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000=20 AUD_HDMIW_INFOFR_C HDMI audio Infoframe: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000=20 --------------060907080701020201000902 Content-Type: text/plain; name="_eld.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="_eld.txt" mediacenter@mediacenter ~ $ cat /proc/asound/cards 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xfe500000 irq 54 mediacenter@mediacenter ~ $ cat /proc/asound/card0/eld#3.0 monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x0] reserved edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x0] sad_count 0 mediacenter@mediacenter ~ $ ls /proc/asound/card0/eld* /proc/asound/card0/eld#3.0 mediacenter@mediacenter ~ $ --------------060907080701020201000902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --------------060907080701020201000902--