Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
Am 2016-02-23 um 17:57 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 22:37:28 +0100, > Martin Kepplinger wrote: >> >> 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 8800a1f54000 [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is 880244f7d000 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 880242564000 port 1 >> [2.322999] intel_dp_init: intel_dig_port is 880242f3 port 1 >> >> is is correct for them to have both port 1? Any more ideas? > > Adding intel-gfx ML to Cc. yes thanks, maybe people there have noticed this too. I can't be the only one. > > Martin, is the machine SandyBridge or IvyBridge? SandyBridge. > > In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and > intel_dp_init() for the same port although both functions map > intel_dig_port[]. The assumption of intel_dig_port[] reverse mapping > is that there is only a single intel_dig_port assigned to a port, but > this doesn't look correct... > > > Takashi >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
Am 2016-02-23 um 17:57 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 22:37:28 +0100, > Martin Kepplinger wrote: >> >> 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 8800a1f54000 [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is 880244f7d000 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 880242564000 port 1 >> [2.322999] intel_dp_init: intel_dig_port is 880242f3 port 1 >> >> is is correct for them to have both port 1? Any more ideas? > > Adding intel-gfx ML to Cc. yes thanks, maybe people there have noticed this too. I can't be the only one. > > Martin, is the machine SandyBridge or IvyBridge? SandyBridge. > > In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and > intel_dp_init() for the same port although both functions map > intel_dig_port[]. The assumption of intel_dig_port[] reverse mapping > is that there is only a single intel_dig_port assigned to a port, but > this doesn't look correct... > > > Takashi >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
On Mon, 22 Feb 2016 22:37:28 +0100, Martin Kepplinger wrote: > > 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 > >> 8800a1f54000 > >> [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is > >> 880244f7d000 > >> > >> 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 880242564000 port 1 > [2.322999] intel_dp_init: intel_dig_port is 880242f3 port 1 > > is is correct for them to have both port 1? Any more ideas? Adding intel-gfx ML to Cc. Martin, is the machine SandyBridge or IvyBridge? In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and intel_dp_init() for the same port although both functions map intel_dig_port[]. The assumption of intel_dig_port[] reverse mapping is that there is only a single intel_dig_port assigned to a port, but this doesn't look correct... Takashi
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
On Mon, 22 Feb 2016 22:37:28 +0100, Martin Kepplinger wrote: > > 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 > >> 8800a1f54000 > >> [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is > >> 880244f7d000 > >> > >> 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 880242564000 port 1 > [2.322999] intel_dp_init: intel_dig_port is 880242f3 port 1 > > is is correct for them to have both port 1? Any more ideas? Adding intel-gfx ML to Cc. Martin, is the machine SandyBridge or IvyBridge? In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and intel_dp_init() for the same port although both functions map intel_dig_port[]. The assumption of intel_dig_port[] reverse mapping is that there is only a single intel_dig_port assigned to a port, but this doesn't look correct... Takashi
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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 >> 8800a1f54000 >> [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is >> 880244f7d000 >> >> 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 880242564000 port 1 [2.322999] intel_dp_init: intel_dig_port is 880242f3 port 1 is is correct for them to have both port 1? Any more ideas?
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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 >> 8800a1f54000 >> [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is >> 880244f7d000 >> >> 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 880242564000 port 1 [2.322999] intel_dp_init: intel_dig_port is 880242f3 port 1 is is correct for them to have both port 1? Any more ideas?
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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 > 8800a1f54000 > [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is > 880244f7d000 > > 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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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 > 8800a1f54000 > [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is > 880244f7d000 > > 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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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 8800a1f54000 [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is 880244f7d000 sorry for the slow responses. I'll try to go back that direction unless again someone comes up with other suggestions. martin
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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 8800a1f54000 [ 146.934121] in i915_audio_component_get_eld: intel_dig_port is 880244f7d000 sorry for the slow responses. I'll try to go back that direction unless again someone comes up with other suggestions. martin
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
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@laptop:/home/martin/dev# cat /proc/asound/card*/eld#* monitor_present0 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: 880242ea8800, 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 >
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@laptop:/home/martin/dev# cat /proc/asound/card*/eld#* monitor_present0 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: 880242ea8800, 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 >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_present0 > >> 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: 880242ea8800, 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? 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. Takashi > > martin > > > [2.385845] [drm:intel_opregion_setup] graphic opregion physical addr: > 0xa6fb2018 > [2.385860] [drm:intel_opregion_setup] Public ACPI methods supported > [2.385862] [drm:intel_opregion_setup] SWSCI supported > [2.392036] [drm:swsci_setup] SWSCI GBDA callbacks 0cf3, SBCB > callbacks 0241 > [2.392041] [drm:intel_opregion_setup] ASLE supported > [2.392051] [drm:intel_opregion_setup] ASLE extension
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_present0 > >> 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: 880242ea8800, 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? 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. Takashi > > martin > > > [2.385845] [drm:intel_opregion_setup] graphic opregion physical addr: > 0xa6fb2018 > [2.385860] [drm:intel_opregion_setup] Public ACPI methods supported > [2.385862] [drm:intel_opregion_setup] SWSCI supported > [2.392036] [drm:swsci_setup] SWSCI GBDA callbacks 0cf3, SBCB > callbacks 0241 > [2.392041] [drm:intel_opregion_setup] ASLE supported > [2.392051] [drm:intel_opregion_setup] ASLE extension
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_valid0 > > 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: 880242ea8800, 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. martin [2.385845] [drm:intel_opregion_setup] graphic opregion physical addr: 0xa6fb2018 [2.385860] [drm:intel_opregion_setup] Public ACPI methods supported [2.385862] [drm:intel_opregion_setup] SWSCI supported [2.392036] [drm:swsci_setup] SWSCI GBDA callbacks 0cf3, SBCB callbacks 0241 [2.392041] [drm:intel_opregion_setup] ASLE supported [2.392051] [drm:intel_opregion_setup] ASLE extension supported [2.392058] [drm:intel_opregion_setup] Found valid VBT in ACPI OpRegion (Mailbox #4) [2.392341] [drm:intel_device_info_runtime_init] slice total: 0 [2.392345] [drm:intel_device_info_runtime_init] subslice total: 0 [2.392348] [drm:intel_device_info_runtime_init] subslice per slice: 0 [2.392351] [drm:intel_device_info_runtime_init] EU total: 0 [2.392355] [drm:intel_device_info_runtime_init] EU per subslice: 0 [2.392358] [drm:intel_device_info_runtime_init] has slice power gating: n [2.392361] [drm:intel_device_info_runtime_init] has subslice power gating: n [2.392364]
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_valid0 > > 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: 880242ea8800, 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. martin [2.385845] [drm:intel_opregion_setup] graphic opregion physical addr: 0xa6fb2018 [2.385860] [drm:intel_opregion_setup] Public ACPI methods supported [2.385862] [drm:intel_opregion_setup] SWSCI supported [2.392036] [drm:swsci_setup] SWSCI GBDA callbacks 0cf3, SBCB callbacks 0241 [2.392041] [drm:intel_opregion_setup] ASLE supported [2.392051] [drm:intel_opregion_setup] ASLE extension supported [2.392058] [drm:intel_opregion_setup] Found valid VBT in ACPI OpRegion (Mailbox #4) [2.392341] [drm:intel_device_info_runtime_init] slice total: 0 [2.392345] [drm:intel_device_info_runtime_init] subslice total: 0 [2.392348] [drm:intel_device_info_runtime_init] subslice per slice: 0 [2.392351] [drm:intel_device_info_runtime_init] EU total: 0 [2.392355] [drm:intel_device_info_runtime_init] EU per subslice: 0 [2.392358] [drm:intel_device_info_runtime_init] has slice power gating: n [2.392361] [drm:intel_device_info_runtime_init] has subslice power gating: n [2.392364]
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_valid0 > >>> > >>> 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: 880242ea8800, 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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_present0 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: 880242ea8800, 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 >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_present0 > >> 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: 880242ea8800, 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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_valid0 > > 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: 880242ea8800, 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 >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_valid0 > > 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: 880242ea8800, 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 >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_present0 > >> 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: 880242ea8800, 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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_valid0 > >>> > >>> 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: 880242ea8800, 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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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_present0 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: 880242ea8800, 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 >
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
>
> A simple revert of the commit is a patch like below. Does it make the
> HDMI audio working again?
>
It does! Everything back to normal in this case. Any idea for a proper
fix? Again, I'm happy to test.
martin
>
> 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
>
upload=true=true=
!!
!!ALSA Information Script v 0.4.64
!!
!!Script ran on: Wed Feb 10 14:56:37 UTC 2016
!!Linux Distribution
!!--
Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian
GNU/Linux" ID=debian HOME_URL="http://www.debian.org/;
SUPPORT_URL="http://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
!!DMI Information
!!---
Manufacturer: Acer
Product Name: TravelMate B113
Product Version: V1.09
Firmware Version: V1.09
!!Kernel Information
!!--
Kernel release:4.5.0-rc3
Operating System: GNU/Linux
Architecture: x86_64
Processor: unknown
SMP Enabled: Yes
!!ALSA Version
!!
Driver version: k4.5.0-rc3
Library version:1.0.28
Utilities version: 1.0.28
!!Loaded ALSA modules
!!---
snd_hda_intel
!!Sound Servers on this system
!!
Pulseaudio:
Installed - Yes (/usr/bin/pulseaudio)
Running - Yes
!!Soundcards recognised by ALSA
!!-
0 [PCH]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xc061 irq 29
!!PCI Soundcards installed in the system
!!--
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller (rev 04)
!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!---
00:1b.0 0403: 8086:1e20 (rev 04)
Subsystem: 1025:0748
!!Modprobe options (Sound related)
!!
snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2
!!Loaded sound module options
!!---
!!Module: snd_hda_intel
align_buffer_size : -1
bdl_pos_adj :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
beep_mode :
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable_msi : -1
id :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
index :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
jackpoll_ms :
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
model :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
patch :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
position_fix :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
RE: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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:ti...@suse.de]
> Sent: Tuesday, February 09, 2016 7:44 PM
> To: Martin Kepplinger
> Cc: david.hennings...@canonical.com; Lu, Han; Yang, Libin;
> tred...@nvidia.com; pe...@perex.cz; alsa-de...@alsa-project.org; linux-
> ker...@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
RE: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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:ti...@suse.de]
> Sent: Tuesday, February 09, 2016 7:44 PM
> To: Martin Kepplinger
> Cc: david.hennings...@canonical.com; Lu, Han; Yang, Libin;
> tred...@nvidia.com; pe...@perex.cz; alsa-de...@alsa-project.org; linux-
> ker...@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
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
>
> A simple revert of the commit is a patch like below. Does it make the
> HDMI audio working again?
>
It does! Everything back to normal in this case. Any idea for a proper
fix? Again, I'm happy to test.
martin
>
> 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
>
upload=true=true=
!!
!!ALSA Information Script v 0.4.64
!!
!!Script ran on: Wed Feb 10 14:56:37 UTC 2016
!!Linux Distribution
!!--
Debian GNU/Linux 8 \n \l PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian
GNU/Linux" ID=debian HOME_URL="http://www.debian.org/;
SUPPORT_URL="http://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
!!DMI Information
!!---
Manufacturer: Acer
Product Name: TravelMate B113
Product Version: V1.09
Firmware Version: V1.09
!!Kernel Information
!!--
Kernel release:4.5.0-rc3
Operating System: GNU/Linux
Architecture: x86_64
Processor: unknown
SMP Enabled: Yes
!!ALSA Version
!!
Driver version: k4.5.0-rc3
Library version:1.0.28
Utilities version: 1.0.28
!!Loaded ALSA modules
!!---
snd_hda_intel
!!Sound Servers on this system
!!
Pulseaudio:
Installed - Yes (/usr/bin/pulseaudio)
Running - Yes
!!Soundcards recognised by ALSA
!!-
0 [PCH]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xc061 irq 29
!!PCI Soundcards installed in the system
!!--
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller (rev 04)
!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!---
00:1b.0 0403: 8086:1e20 (rev 04)
Subsystem: 1025:0748
!!Modprobe options (Sound related)
!!
snd_pcsp: index=-2
snd_usb_audio: index=-2
snd_atiixp_modem: index=-2
snd_intel8x0m: index=-2
snd_via82xx_modem: index=-2
!!Loaded sound module options
!!---
!!Module: snd_hda_intel
align_buffer_size : -1
bdl_pos_adj :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
beep_mode :
Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable_msi : -1
id :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
index :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
jackpoll_ms :
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
model :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
patch :
(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
position_fix :
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
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
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
