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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
