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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Feb 23, 2016 at 05:57:40PM +0100, Takashi Iwai wrote:
> 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...

On pre-HSW there can indeed be two encoders for the same port.
And I'm planning to change HSW+ to follow that model as well,
but I've been busy with other stuff to finish off that work [1]

[1] https://lists.freedesktop.org/archives/intel-gfx/2015-December/082384.html

-- 
Ville Syrjälä
Intel OTC