On Wed, 20 Jun 2018 10:02:42 +0200, Daniel Vetter wrote: > > On Wed, Jun 20, 2018 at 10:11:34AM +0300, Jani Nikula wrote: > > On Wed, 20 Jun 2018, Feng Tang <feng.tang@xxxxxxxxx> wrote: > > > Hi Takashi, > > > > > > On Wed, Jun 20, 2018 at 08:35:05AM +0200, Takashi Iwai wrote: > > >> On Wed, 20 Jun 2018 08:25:23 +0200, > > >> Feng Tang wrote: > > >> > > > >> > Hi Jani/Chris/Takashi, > > >> > > > >> > On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote: > > >> > > >> > > >> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-chris@xxxxxxxxxxxxxxxxxx > > >> > > > > > >> > > > IIUC, you are waiting for the HDA audio driver to first handle the > > >> > > > i915 sync probel case? > > >> > > > > >> > > I wouldn't hold my breath waiting. If you want to do i915 async probe, > > >> > > you'll probably have to figure hda out as well. > > >> > > > >> > I made the following patch based on 4.18-rc1, and tested on my machine, > > >> > which basically works fine with Async probe taking effect (I tried > > >> > builtin and modules way). > > >> > > > >> > Please review this initial version, and I'll separate to clean patches > > >> > if you think it's OK. thanks! > > >> > > >> When you call an i915 function from HD-audio driver, you made already > > >> a hard dependency. This is exactly what we want to avoid. > > > > > > Thanks for the info, I see your intension now. > > > > > > In previous discussion, Jani suggested to use a completion to indicate > > > the probe done, I can't figure out another way :) > > > > I suggested you do that within hdac_i915.c. Wait in snd_hdac_i915_init() > > below request_module(), complete in hdac_component_master_bind(). > > I thgouth this kind of cross-driver dependency is supposed to be handled > using EPROBE_DEFER? Why do we need to hand-roll that here? > > Or is this some other kind of synchronization need that needs a bespoke > solution? The binding with i915 from HD-audio controller is done in an async work invoked from the probe callback. It makes harder to deal with EPROBEDEFER. IMO, a saner way would be to rather wait for the component binding. The component mechanism is there just for that purpose, after all. Does a patch like below work (totally untested)? thanks, Takashi -- 8< -- --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -23,6 +23,7 @@ #include <sound/hda_register.h> static struct i915_audio_component *hdac_acomp; +static DECLARE_COMPLETION(acomp_bound); /** * snd_hdac_set_codec_wakeup - Enable / disable HDMI/DP codec wakeup @@ -284,6 +285,7 @@ static int hdac_component_master_bind(struct device *dev) goto out_unbind; } + complete_all(&acomp_bound); return 0; out_unbind: @@ -382,11 +384,8 @@ int snd_hdac_i915_init(struct hdac_bus *bus) if (ret < 0) goto out_err; - /* - * Atm, we don't support deferring the component binding, so make sure - * i915 is loaded and that the binding successfully completes. - */ request_module("i915"); + wait_for_completion_timeout(&acomp_bound, 10000); /* 10s timeout */ if (!acomp->ops) { ret = -ENODEV; _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
