[Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Christopher White
c.white at pulseforce.com
Thu Nov 10 13:39:00 CET 2011
On 11/10/11 12:53 PM, Takashi Iwai wrote:
> At Thu, 10 Nov 2011 12:50:11 +0100,
> Christopher White wrote:
>> On 11/10/11 12:22 PM, Takashi Iwai wrote:
>>> At Thu, 10 Nov 2011 12:00:53 +0100,
>>> Christopher White wrote:
>>>> On 11/10/11 9:55 AM, Christopher White wrote:
>>>>> On 11/10/11 8:55 AM, Wu Fengguang wrote:
>>>>>> On Thu, Nov 10, 2011 at 03:33:50PM +0800, Wu Fengguang wrote:
>>>>>>> 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?
>>>>>> 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
>>>>> 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.
>>>> 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?
>>> 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
>> 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.
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111110/10fee6b3/attachment.html>
More information about the Intel-gfx
mailing list