linux-kernel - Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56CB1510.4010503@posteo.de>
Date:	Mon, 22 Feb 2016 15:02:56 +0100
From:	Martin Kepplinger <martink@...teo.de>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	david.henningsson@...onical.com, han.lu@...el.com,
	libin.yang@...el.com, treding@...dia.com, perex@...ex.cz,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for
 i915

Am 2016-02-22 um 11:34 schrieb Takashi Iwai:
> On Mon, 22 Feb 2016 11:24:05 +0100,
> Martin Kepplinger wrote:
>>
>> Am 2016-02-12 um 17:16 schrieb Takashi Iwai:
>>> On Fri, 12 Feb 2016 16:54:44 +0100,
>>> Martin Kepplinger wrote:
>>>>
>>>> Am 2016-02-12 um 14:49 schrieb Takashi Iwai:
>>>>> On Fri, 12 Feb 2016 14:09:36 +0100,
>>>>> Martin Kepplinger wrote:
>>>>>>
>>>>>> Am 2016-02-11 um 10:06 schrieb Takashi Iwai:
>>>>>>> On Wed, 10 Feb 2016 18:21:11 +0100,
>>>>>>> Martin Kepplinger wrote:
>>>>>>>>
>>>>>>>> Am 2016-02-09 um 12:44 schrieb Takashi Iwai:
>>>>>>>>> On Tue, 09 Feb 2016 07:34:48 +0100,
>>>>>>>>> Martin Kepplinger wrote:
>>>>>>>>>>
>>>>>>>>>> The following change:
>>>>>>>>>>
>>>>>>>>>> 788d441 ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling
>>>>>>>>>>
>>>>>>>>>> breaks audio over HDMI on my snd_hda_intel laptop. It is the first bad
>>>>>>>>>> commit.
>>>>>>>>>>
>>>>>>>>>> This was merged for -rc1 and isn't fixed until now, so I got nervous.
>>>>>>>>>> There are
>>>>>>>>>> no errors in the log that stand out. I'm no sound or alsa developer, and
>>>>>>>>>> just reverting it isn't easy since there is stuff depending on this.
>>>>>>>>>>
>>>>>>>>>> I'm happy to test possible fixes and hope v4.5 not to ship with such a big
>>>>>>>>>> regression ;)
>>>>>>>>>
>>>>>>>>> Could you give a bit more detail about your hardware?  At best, give
>>>>>>>>> alsa-info.sh output (run with --no-upload option).  Also, give the
>>>>>>>>> output of dmesg, too.
>>>>>>>>>
>>>>>>>>> In addition, what shows /proc/asound/card*/eld#*.* files?  Does any of
>>>>>>>>> it show the proper connection state and ELD?
>>>>>>>>
>>>>>>>> alsa-info and dmesg are appended, and
>>>>>>>>
>>>>>>>> root@...top:/home/martin/dev# cat /proc/asound/card*/eld#*
>>>>>>>> monitor_present		0
>>>>>>>> eld_valid		0
>>>>>>>
>>>>>>> OK, then could you put some debug print in intel_pin_eld_notify() in
>>>>>>> sound/pci/hda/patch_hdmi.c?  This is the callback to be called by i915
>>>>>>> driver at enabling / disabling HDMI/DP audio.
>>>>>>
>>>>>> intel_pin_eld_notify() is called during HDMI plugin with
>>>>>>
>>>>>> audio_ptr: ffff880242ea8800, port 1
>>>>>>
>>>>>> and doesn't return early.
>>>>>
>>>>> OK, so it was processed but the ELD wasn't updated by some reason.
>>>>>
>>>>>>> (Also, to be sure, check whether snd_hdac_i915_register_notifier() in
>>>>>>>  sound/hda/hda_i915.c is called, too.)
>>>>>>
>>>>>> snd_hdac_i915_register_notifier() is called during boot.
>>>>>>
>>>>>>>
>>>>>>> If intel_pin_eld_notify() is registered but never called, it implies
>>>>>>> something wrong in i915 driver side.  If it gets called, we need to
>>>>>>> track down: what port value was passed there, and how
>>>>>>> hdmi_present_sense() and sync_eld_via_acomp() behave there.
>>>>>>
>>>>>> I'll try to look at said path, if you have no other idea in the meantime.
>>>>>
>>>>> Put some debug prints in sync_eld_via_acomp(), e.g. check whether
>>>>> snd_hdac_acomp_get_eld() returns an error or snd_hdmi_parse_eld()
>>>>> returns an error.  If you got an error, track down more deeply.
>>>>>
>>>>> For example, the former function is defined in sound/hda/hdac_i915.c,
>>>>> and it calls the function i915_audio_component_get_eld() in
>>>>> drivers/gpu/drm/i915/intel_audio.c.  You can follow what returns an
>>>>> error.
>>>>>
>>>>> Similarly, the latter function is defined in sound/pci/hda/hda_eld.c.
>>>>> Usually you see a kernel message for parse errors, so I guess this
>>>>> isn't the case, though.
>>>>>
>>>>
>>>> no error in either of the functions. size is always 0, after boot and
>>>> after HDMI plugin. is that normal?
>>>
>>> No, it means that no connection is reported back.  Check the call of
>>> i915_audio_component_get_eld() as mentioned in the above.
>>> Does it return 0?  Also I suppose monitor_present is set to false?
>>> If so, it implies that intel_audio_codec_enable() isn't called.
>>>
>>> When the above is true, boot with drm.debug=0x0e, and give the kernel
>>> messages.
>>>
>>
>> The above is true and -rc5 didn't fix the problem. I append "dmesg|grep
>> drm" with drm.debug=0x0e. HDMI is plugged in at about 90 seconds in.
> 
> And how about my questions in the previous mail?  Does
> i915_audio_component_get_eld() is called and returns 0?
> And is monitor_present set true or false?

i915_audio_component_get_eld() returns 0 and monitor_present is 0.
> 
> If i915_audio_component_get_eld() is called but returns zero, track
> the code flow there.  It means either intel_encoder is NULL or
> intel_dig_port->audio_connector is NULL.

intel_dig_port->audio_connector is NULL!

(when called during boot and during HDMI plugin)

I'll follow it more, but I'm just posting in case anyone finds the
mistake early.

thanks!

> 
> 
> Takashi
>