[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hio1ffjp7.wl-tiwai@suse.de>
Date: Tue, 23 Feb 2016 17:57:40 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Martin Kepplinger <martink@...teo.de>
Cc: intel-gfx@...ts.freedesktop.org, david.henningsson@...onical.com,
han.lu@...el.com, libin.yang@...el.com, treding@...dia.com,
perex@...ex.cz, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org
Subject: Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
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
Powered by blists - more mailing lists