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