Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1330124 > unrolled thread
| Started by | Takashi Iwai <tiwai@suse.de> |
|---|---|
| First post | 2016-02-09 12:50 +0100 |
| Last post | 2016-02-22 22:40 +0100 |
| Articles | 12 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Takashi Iwai <tiwai@suse.de> - 2016-02-09 12:50 +0100
RE: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 "Yang, Libin" <libin.yang@intel.com> - 2016-02-10 15:50 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Takashi Iwai <tiwai@suse.de> - 2016-02-11 10:10 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Martin Kepplinger <martink@posteo.de> - 2016-02-12 14:20 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Takashi Iwai <tiwai@suse.de> - 2016-02-12 14:50 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Martin Kepplinger <martink@posteo.de> - 2016-02-12 17:00 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Takashi Iwai <tiwai@suse.de> - 2016-02-12 17:20 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Martin Kepplinger <martink@posteo.de> - 2016-02-22 15:10 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Takashi Iwai <tiwai@suse.de> - 2016-02-22 15:20 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Martin Kepplinger <martink@posteo.de> - 2016-02-22 20:10 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Takashi Iwai <tiwai@suse.de> - 2016-02-22 20:20 +0100
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 Martin Kepplinger <martink@posteo.de> - 2016-02-22 22:40 +0100
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-02-09 12:50 +0100 |
| Subject | Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r0eXT-3rF-3@gated-at.bofh.it> |
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?
A simple revert of the commit is a patch like below. Does it make the
HDMI audio working again?
thanks,
Takashi
---
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -156,7 +156,7 @@ struct hdmi_spec {
bool i915_bound; /* was i915 bound in this driver? */
};
-#ifdef CONFIG_SND_HDA_I915
+#if 0
#define codec_has_acomp(codec) \
((codec)->bus->core.audio_component != NULL)
#else
[toc] | [next] | [standalone]
| From | "Yang, Libin" <libin.yang@intel.com> |
|---|---|
| Date | 2016-02-10 15:50 +0100 |
| Subject | RE: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r0EfE-3qm-17@gated-at.bofh.it> |
| In reply to | #1330124 |
It may be the audio component binding error? I met the audio component binding error in our internal kernel before. It is because the audio component name are duplicating with another i915 component and so match() function doesn't work well. But I'm not sure the ALSA kernel have the same issue. I will check it after my holiday.
Regards,
Libin
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai@suse.de]
> Sent: Tuesday, February 09, 2016 7:44 PM
> To: Martin Kepplinger
> Cc: david.henningsson@canonical.com; Lu, Han; Yang, Libin;
> treding@nvidia.com; perex@perex.cz; alsa-devel@alsa-project.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over
> HDMI for i915
>
> 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?
>
> A simple revert of the commit is a patch like below. Does it make the
> HDMI audio working again?
>
>
> thanks,
>
> Takashi
>
> ---
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -156,7 +156,7 @@ struct hdmi_spec {
> bool i915_bound; /* was i915 bound in this driver? */
> };
>
> -#ifdef CONFIG_SND_HDA_I915
> +#if 0
> #define codec_has_acomp(codec) \
> ((codec)->bus->core.audio_component != NULL)
> #else
[toc] | [prev] | [next] | [standalone]
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-02-11 10:10 +0100 |
| Message-ID | <r0Vqa-6Fe-7@gated-at.bofh.it> |
| In reply to | #1330124 |
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@laptop:/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. (Also, to be sure, check whether snd_hdac_i915_register_notifier() in sound/hda/hda_i915.c is called, too.) 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. thanks, Takashi
[toc] | [prev] | [next] | [standalone]
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-02-12 14:20 +0100 |
| Subject | Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r1lND-7uT-5@gated-at.bofh.it> |
| In reply to | #1331749 |
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@laptop:/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. > (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. > > > thanks, > > Takashi >
[toc] | [prev] | [next] | [standalone]
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-02-12 14:50 +0100 |
| Message-ID | <r1mgG-7Hp-7@gated-at.bofh.it> |
| In reply to | #1332730 |
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@laptop:/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. Takashi
[toc] | [prev] | [next] | [standalone]
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-02-12 17:00 +0100 |
| Subject | Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r1oit-ws-1@gated-at.bofh.it> |
| In reply to | #1332744 |
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@laptop:/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? > > Takashi >
[toc] | [prev] | [next] | [standalone]
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-02-12 17:20 +0100 |
| Message-ID | <r1oBQ-SL-23@gated-at.bofh.it> |
| In reply to | #1332828 |
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@laptop:/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. Takashi
[toc] | [prev] | [next] | [standalone]
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-02-22 15:10 +0100 |
| Subject | Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r4Zlw-6Vd-7@gated-at.bofh.it> |
| In reply to | #1332858 |
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@laptop:/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 >
[toc] | [prev] | [next] | [standalone]
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-02-22 15:20 +0100 |
| Message-ID | <r4Zvc-6YD-13@gated-at.bofh.it> |
| In reply to | #1339497 |
On Mon, 22 Feb 2016 15:02:56 +0100,
Martin Kepplinger wrote:
> > 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)
Interesting. The relevant code flow should be like:
intel_audio_codec_enable()
-> acomp->audio_ops->pin_eld_notify()
-> intel_pin_eld_notify()
-> check_presence_and_report()
-> hdmi_present_sense()
-> sync_eld_via_acomp()
-> snd_hdac_acomp_get_eld()
-> i915_audio_component_get_eld()
So, at first, check whether intel_dig_port in both
intel_audio_codec_enable() and i915_audio_component_get_eld() points
to the same object address. The audio_connector must be set in
intel_audio_codec_enable(), thus basically it must be non-NULL at
i915_audio_component_get_eld(), too.
thanks,
Takashi
[toc] | [prev] | [next] | [standalone]
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-02-22 20:10 +0100 |
| Subject | Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r541R-1YW-49@gated-at.bofh.it> |
| In reply to | #1339504 |
Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
> On Mon, 22 Feb 2016 15:02:56 +0100,
> Martin Kepplinger wrote:
>>> 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)
>
> Interesting. The relevant code flow should be like:
>
> intel_audio_codec_enable()
> -> acomp->audio_ops->pin_eld_notify()
> -> intel_pin_eld_notify()
> -> check_presence_and_report()
> -> hdmi_present_sense()
> -> sync_eld_via_acomp()
> -> snd_hdac_acomp_get_eld()
> -> i915_audio_component_get_eld()
>
> So, at first, check whether intel_dig_port in both
> intel_audio_codec_enable() and i915_audio_component_get_eld() points
> to the same object address. The audio_connector must be set in
> intel_audio_codec_enable(), thus basically it must be non-NULL at
> i915_audio_component_get_eld(), too.
>
intel_dig_port is *not* the same object in these 2 places. During
plugin, see:
[ 146.934091] in intel_audio_codec_enable: intel_dig_port is
ffff8800a1f54000
[ 146.934121] in i915_audio_component_get_eld: intel_dig_port is
ffff880244f7d000
sorry for the slow responses. I'll try to go back that direction unless
again someone comes up with other suggestions.
martin
[toc] | [prev] | [next] | [standalone]
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-02-22 20:20 +0100 |
| Message-ID | <r54bv-23H-5@gated-at.bofh.it> |
| In reply to | #1339846 |
On Mon, 22 Feb 2016 19:58:18 +0100, Martin Kepplinger wrote: > > Am 2016-02-22 um 15:12 schrieb Takashi Iwai: > > On Mon, 22 Feb 2016 15:02:56 +0100, > > Martin Kepplinger wrote: > >>> 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) > > > > Interesting. The relevant code flow should be like: > > > > intel_audio_codec_enable() > > -> acomp->audio_ops->pin_eld_notify() > > -> intel_pin_eld_notify() > > -> check_presence_and_report() > > -> hdmi_present_sense() > > -> sync_eld_via_acomp() > > -> snd_hdac_acomp_get_eld() > > -> i915_audio_component_get_eld() > > > > So, at first, check whether intel_dig_port in both > > intel_audio_codec_enable() and i915_audio_component_get_eld() points > > to the same object address. The audio_connector must be set in > > intel_audio_codec_enable(), thus basically it must be non-NULL at > > i915_audio_component_get_eld(), too. > > > > intel_dig_port is *not* the same object in these 2 places. During > plugin, see: > > [ 146.934091] in intel_audio_codec_enable: intel_dig_port is > ffff8800a1f54000 > [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is > ffff880244f7d000 > > sorry for the slow responses. I'll try to go back that direction unless > again someone comes up with other suggestions. Thanks, this makes sense. It implies that the digital port mapping is somehow wrong. There are three places setting dig_port_map[], one in intel_ddi_init(), one in intel_dp_init() and another in intel_hdmi_init(). Try to check which function creates which object assigned to which port number, together with drm.debug=0x0e debug messages. Takashi
[toc] | [prev] | [next] | [standalone]
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-02-22 22:40 +0100 |
| Subject | Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915 |
| Message-ID | <r56n0-3sI-15@gated-at.bofh.it> |
| In reply to | #1339848 |
Am 2016-02-22 um 20:10 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 19:58:18 +0100, > Martin Kepplinger wrote: >> >> Am 2016-02-22 um 15:12 schrieb Takashi Iwai: >>> On Mon, 22 Feb 2016 15:02:56 +0100, >>> Martin Kepplinger wrote: >>>>> 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) >>> >>> Interesting. The relevant code flow should be like: >>> >>> intel_audio_codec_enable() >>> -> acomp->audio_ops->pin_eld_notify() >>> -> intel_pin_eld_notify() >>> -> check_presence_and_report() >>> -> hdmi_present_sense() >>> -> sync_eld_via_acomp() >>> -> snd_hdac_acomp_get_eld() >>> -> i915_audio_component_get_eld() >>> >>> So, at first, check whether intel_dig_port in both >>> intel_audio_codec_enable() and i915_audio_component_get_eld() points >>> to the same object address. The audio_connector must be set in >>> intel_audio_codec_enable(), thus basically it must be non-NULL at >>> i915_audio_component_get_eld(), too. >>> >> >> intel_dig_port is *not* the same object in these 2 places. During >> plugin, see: >> >> [ 146.934091] in intel_audio_codec_enable: intel_dig_port is >> ffff8800a1f54000 >> [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is >> ffff880244f7d000 >> >> sorry for the slow responses. I'll try to go back that direction unless >> again someone comes up with other suggestions. > > Thanks, this makes sense. It implies that the digital port mapping is > somehow wrong. There are three places setting dig_port_map[], one in > intel_ddi_init(), one in intel_dp_init() and another in > intel_hdmi_init(). Try to check which function creates which object > assigned to which port number, together with drm.debug=0x0e debug > messages. > without using drm.debug=0x0e, but by printing the kmalloc'ed objects in those 3 functions with ports, I found: 2 of them are running, only during boot: [ 2.322865] intel_hdmi_init: intel_dig_port is ffff880242564000 port 1 [ 2.322999] intel_dp_init: intel_dig_port is ffff880242f30000 port 1 is is correct for them to have both port 1? Any more ideas?
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web