From patchwork Wed Jun 20 09:45:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Iwai X-Patchwork-Id: 10476799 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 392FA600F6 for ; Wed, 20 Jun 2018 09:45:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2A1AC284E4 for ; Wed, 20 Jun 2018 09:45:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1EAFE28DA9; Wed, 20 Jun 2018 09:45:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B4039284E4 for ; Wed, 20 Jun 2018 09:45:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3E43E6E6E3; Wed, 20 Jun 2018 09:45:28 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 03A936E6E3 for ; Wed, 20 Jun 2018 09:45:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5E1EEACC2; Wed, 20 Jun 2018 09:45:25 +0000 (UTC) Date: Wed, 20 Jun 2018 11:45:25 +0200 Message-ID: From: Takashi Iwai To: Daniel Vetter In-Reply-To: <20180620080242.GB7186@phenom.ffwll.local> References: <20180604053219.2040-1-feng.tang@intel.com> <878t7t7ka7.fsf@intel.com> <20180605075101.ipkhu57i4abpkbjn@shbuild888> <87602x7ijd.fsf@intel.com> <20180606073611.esunkbud45gddoo4@shbuild888> <87wovc5nqg.fsf@intel.com> <20180620062523.xpkqeknrklgrihpl@shbuild888> <20180620064701.nsa4nw56ro5dirp6@shbuild888> <87bmc6vsnt.fsf@intel.com> <20180620080242.GB7186@phenom.ffwll.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Subject: Re: [Intel-gfx] [RFC] i915: make the probe asynchronous X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Feng Tang , Jani Nikula , Daniel Vetter , intel-gfx@lists.freedesktop.org, alek.du@intel.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP 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 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@chris-wilson.co.uk > > >> > > > > > >> > > > 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 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;