From patchwork Thu Jul 12 07:57:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 10521159 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 4E5FC602C8 for ; Thu, 12 Jul 2018 07:55:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 106AC286C5 for ; Thu, 12 Jul 2018 07:55:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 047C229496; Thu, 12 Jul 2018 07:55:51 +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 6849C286C5 for ; Thu, 12 Jul 2018 07:55:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BF1706EE82; Thu, 12 Jul 2018 07:55:46 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id 863C26EE7C for ; Thu, 12 Jul 2018 07:55:45 +0000 (UTC) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2018 00:55:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,342,1526367600"; d="scan'208";a="239724831" Received: from shbuild888.sh.intel.com (HELO localhost) ([10.239.146.239]) by orsmga005.jf.intel.com with ESMTP; 12 Jul 2018 00:54:20 -0700 Date: Thu, 12 Jul 2018 15:57:14 +0800 From: Feng Tang To: Daniel Vetter Message-ID: <20180712075714.gsic3xirh3uiy2nq@shbuild888> References: <20180620064701.nsa4nw56ro5dirp6@shbuild888> <87bmc6vsnt.fsf@intel.com> <20180620080242.GB7186@phenom.ffwll.local> <20180625153632.GQ2958@phenom.ffwll.local> <20180626022916.3d6wceejx23zd7pl@shbuild888> <20180712012901.lxrzxtvpj3msje3k@shbuild888> <20180712065434.GD3008@phenom.ffwll.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) 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: Takashi Iwai , intel-gfx , alek.du@intel.com, Jani Nikula Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Jul 12, 2018 at 09:37:41AM +0200, Daniel Vetter wrote: > On Thu, Jul 12, 2018 at 8:56 AM, Takashi Iwai wrote: > > On Thu, 12 Jul 2018 08:54:34 +0200, > > Daniel Vetter wrote: > >> > >> On Thu, Jul 12, 2018 at 09:29:01AM +0800, Feng Tang wrote: > >> > On Tue, Jun 26, 2018 at 10:29:16AM +0800, Feng Tang wrote: > >> > > On Mon, Jun 25, 2018 at 05:36:32PM +0200, Daniel Vetter wrote: > >> > > >> > > Hi Daneil/Jani/Takashi, > >> > > > >> > > When I was testing this patch from Takashi, I further checked the kernel > >> > > module code, and found that: we may need NOT to add any new codes to > >> > > prepare for i915's async probe feature! > >> > > > >> > > Say when i915 module is being loader due to HDA's request_module() call, > >> > > in the callchain, do_init_module() has such code: > >> > > > >> > > if (!mod->async_probe_requested && (current->flags & PF_USED_ASYNC)) > >> > > async_synchronize_full(); > >> > > > >> > > This will garantee the asynced probe is done before it returns. > >> > > > >> > > I have just tested and this seems to be enough. If I am not wrong, then > >> > > we can take the i915 async patch directly. What do you think? > >> > > >> > Ping for comments, thanks! > >> > >> Ram (who's working on the hdcp2 code) just learned the hard way that if > >> i915 registration gets delayed then audio fails to load. So if you want to > >> make i915 fully async, then you _must_ fix the audio load stuff. > > > > Does my component completion patch help for that scenario? > > Hm, must have missed it. Do you have a patchwork link? > > Also adding Ram so he can test this out. Here is Iwai's patch that I found in my inbox: ----- --- 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;