<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 11/10/11 12:53 PM, Takashi Iwai wrote: <blockquote cite="mid:s5hfwhwb3cb.wl%25tiwai@suse.de" type="cite"> <pre wrap="">At Thu, 10 Nov 2011 12:50:11 +0100, Christopher White wrote: </pre> <blockquote type="cite"> <pre wrap=""> On 11/10/11 12:22 PM, Takashi Iwai wrote: </pre> <blockquote type="cite"> <pre wrap="">At Thu, 10 Nov 2011 12:00:53 +0100, Christopher White wrote: </pre> <blockquote type="cite"> <pre wrap="">On 11/10/11 9:55 AM, Christopher White wrote: </pre> <blockquote type="cite"> <pre wrap="">On 11/10/11 8:55 AM, Wu Fengguang wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote: </pre> <blockquote type="cite"> <pre wrap="">Wow I reproduced the bug and got a very interesting dmesg: gfx => [ 4561.287980] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] gfx => [ 4561.291730] [drm:ironlake_write_eld], ELD on pipe B gfx => [ 4561.293804] [drm:ironlake_write_eld], Audio directed to unknown port gfx => [ 4561.295273] [drm:ironlake_write_eld], alsa => [ 4561.295486] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 alsa => [ 4561.295564] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 gfx => [ 4561.300020] ELD size 13 alsa => [ 4561.300697] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa => [ 4561.303322] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 alsa => [ 4561.311120] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 Hey the two parts are interleaved! But still it should work all fine, since the gfx driver does set ELD_Valid = 0 write ELD set ELD_Valid = 1 So the audio driver would read the correct ELD unless the ELD content and flag writes are somehow _reordered_ underneath. Or the ELD content writes take some time to take effect? </pre> </blockquote> <pre wrap="">Just confirmed that adding 1s delay can fix it! New dmesg is: [ 48.564923] [drm:drm_crtc_helper_set_mode], [ENCODER:11:TMDS-11] set [MODE:34:] [ 48.567481] [drm:intel_hdmi_mode_set], Enabling HDMI audio on pipe B [ 48.568975] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 48.571728] [drm:ironlake_write_eld], ELD on pipe B [ 48.572882] [drm:ironlake_write_eld], Audio directed to unknown port [ 48.575252] [drm:ironlake_write_eld], [ 48.575400] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.575487] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 48.580116] ELD size 13 [ 48.580795] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.583340] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 48.632514] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.685322] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.687438] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 48.690106] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 48.745204] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.798035] [drm:intel_wait_for_vblank], vblank wait timed out [ 48.799633] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 48.802686] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 48.805103] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 48.807246] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 48.809426] [drm:ironlake_fdi_link_train], FDI train done [ 48.813960] [drm:intel_update_fbc], [ 48.814782] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 48.818093] [drm:drm_crtc_helper_set_config], [CONNECTOR:12:HDMI-A-2] set DPMS on [ 48.828633] [drm:intel_prepare_page_flip], preparing flip with no unpin work? [ 49.618962] HDMI: detected monitor RX-V1800 at connection type HDMI [ 49.621013] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 49.622304] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.625069] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 49.628535] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 640000 [ 49.630810] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 49.633148] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 49.635039] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 49.637130] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 49.639172] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang </pre> </blockquote> <pre wrap="">Wow, you were able to reproduce it! That's the best news ever. I will be applying this patch and rebuilding now to see what happens. So it was some sort of timing issue after all. Expect me to reply within 1h, but rebuild takes some time. </pre> </blockquote> <pre wrap="">I still had the old build directory and only had to rebuild one module which only took 5 minutes. The rest of the delay was me doing an hour of tests as well as being on a 45 minute phone call. Anyway, now the result: Success! So we know it's a timing issue somewhere. Wow, real progress and near a solution. Finally! The big question now is what causes the audio driver to read the ELD while it is empty, and why the 1 second delay fixes it. Look at speakertest.txt here. It's beautiful. ;-) Playing digital multichannel sound over the HDMI PCH bus, and I can hear every channel in their proper location on my speaker system. It's beautiful. I've waited for this moment since building this Linux HTPC back in April. ;-) (I'm an astonishingly patient man hehe). Now as for why we needed a 1 second delay, any ideas? Could it be that the audio driver was reading the ELD while it wasn't written to the register yet? </pre> </blockquote> <pre wrap="">Maybe not necessarily 1 second. It could do some loop with a small delay until it reads zero-size? Or if it really can take long time like 1 second, it'd be better to be a work to self-reschdule to do in background, as it's called at the probing time and at each unsol event. Since radeon sends really zero-byte ELD when a DVI monitor without audio is connected, stalling one second there is no good choice. Hopefully this delay would fix the zero-size problem we are currently working around in an ugly way (the comment mentions about ASUS P5E-VM HDMI board), too. thanks, Takashi </pre> </blockquote> <pre wrap=""> Well yes obviously the 1 second delay is a temporary workaround until the real cause is found. Something like what you suggested should be the final fix; a real loop that proceeds only when the data is ready (with a 1 second or so maximum loop time, to avoid infinite loop if data never becomes ready). I don't think a background schedule would work, because the data needs to be available at boot BEFORE the audio layer loads. Otherwise ALSA (for example) would load while no data had yet been read into the ELD registers. If a background schedule is used, then GREAT care must be taken to make sure it finishes before the audio layer launches. </pre> </blockquote> <pre wrap=""> In theory, the delayed probe and notification can be handled just like a hotplug case. We have still no notification framework (especially in PulseAudio) yet, though :) thanks, Takashi</pre> </blockquote> Yep that is the main risk of a delayed event - a possible inability to re-configure the audio layer. I think ALSA *might* be able to re-detect audio devices and settings after the initial boot, because I know there is a MANUAL "alsa force-reload" command. I am pretty sure it doesn't run automatically when the Intel driver detects a hotplug, though. That would require some sort of notification between the Intel driver and ALSA which afaik doesn't exist. Then there's also the problem that applications could start using the audio layer in its bad state and won't like the unexpected reconfigure. This means that once the ALSA layer has loaded with a bad config, it's stuck like that. Therefore the biggest priority of the final solution will be to ensure that all ELD data is ready *before* ALSA (or any other audio layer) first queries it, so that the system boots into the proper audio state right away. We already know that it takes less than a second to have ELD ready from the point that the ELD function has been entered, so a small loop with a 1 second max execution time (to prevent infinite) could be good enough. It would be interesting to try such a loop along with a small counter, and a 10ms or so wait between iterations, and then printing the number of iterations to the debug log. That will show us how long the average wait for valid ELD is. Christopher </body> </html>