Re: [alsa-devel] Timing issues between ALSA and i915 drivers

[Takashi Iwai <tiwai@suse.de>]

On Thu, 17 Jan 2019 21:47:05 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> >> I tried to narrow down the issue further and my current understanding
> >> is that the Skylake driver performs link reset operations without the
> >> display power turned on - which does not look like a very smart thing
> >> to do in hindsight.
> >>
> >> In other words, it's not really when snd_hdac_i915_init() is called
> >> that matters as I assumed initially, but more when
> >> snd_hdac_display_power() is invoked. There are two cases where this
> >> happens, and for each of them turning the display power on results in
> >> HDMI detection. The attached diffs split the initialization from the
> >> power on, which provides a better understanding of the issue.
> > OK, this makes some sense, and that's the very reason we have
> > HDA_CODEC_IDX_CONTROLLER for snd_hdac_display_power().  IIRC, we
> > needed to power on the display for probing of the legacy HDA, too.
> > Once after that, for the normal operation, the display power is needed
> > only when you output the HDMI stream.
> >
> >
> >> What would be really useful at this point is a confirmation that
> >> snd_hdac_i915_init() cannot be called in the initial probe but does
> >> need to be executed in a work queue. That would really impact the way
> >> the initialization sequence is reworked on the Skylake side as well as
> >> modify the way the SOF driver deals with i915 initialization.
> > It's needed to be called in a work queue, yes.
> >
> > Basically you shouldn't call request_module() in the driver's probe
> > callback.  When the probe callback is called from the module loading,
> > it blocks the module loading itself, hence loading yet another module
> > can't work.  A situation might be easier than the past (which
> > deadlocked), but still it's advised to use either the
> > request_module_nowait() with the callback or call request_module()
> > asynchronously from probe.
> 
> Thanks Takashi, this is very useful. I guess that will require a
> complete rework of the Skylake initialization sequence then, my simple
> code translation isn't enough indeed and the current partition between
> probe/work queue can't comply with both requirements (request module
> asynchronously from probe, display turned on before mucking with
> links).
> 
> We also need this changed for SOF, the i915_init is done in the probe.

Well, snd_hdac_i915_init() itself also calls already request_module()
if i915 is missing, so this should be done in the async code, too...

The complication comes from the fact that HD-audio driver doesn't
necessarily bind with i915 graphics.  Otherwise we could have a fixed
hard dependency that assures more or less i915 probing before
HD-audio (though, i915 probing became async, so it's now harder).


thanks,

Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx