[Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[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
> >> ffff8800a1f54000
> >> [  146.934121] in i915_audio_component_get_eld: intel_dig_port is
> >> ffff880244f7d000
> >>
> >> sorry for the slow responses. I'll try to go back that direction unless
> >> again someone comes up with other suggestions.
> > 
> > Thanks, this makes sense.  It implies that the digital port mapping is
> > somehow wrong.  There are three places setting dig_port_map[], one in
> > intel_ddi_init(), one in intel_dp_init() and another in
> > intel_hdmi_init().  Try to check which function creates which object
> > assigned to which port number, together with drm.debug=0x0e debug
> > messages.
> > 
> without using drm.debug=0x0e, but by printing the kmalloc'ed objects in
> those 3 functions with ports, I found:
> 
> 2 of them are running, only during boot:
> 
> [    2.322865] intel_hdmi_init: intel_dig_port is ffff880242564000  port 1
> [    2.322999] intel_dp_init: intel_dig_port is ffff880242f30000  port 1
> 
> is is correct for them to have both port 1? Any more ideas?

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