From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F62FC0015E for ; Tue, 25 Jul 2023 10:37:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233719AbjGYKhe (ORCPT ); Tue, 25 Jul 2023 06:37:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233723AbjGYKh1 (ORCPT ); Tue, 25 Jul 2023 06:37:27 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37A4210E3 for ; Tue, 25 Jul 2023 03:37:22 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D808C2233B; Tue, 25 Jul 2023 10:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1690281440; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3I1WKvqsunGpCu04gF1CzawY3Z1Ke8IscFjJf/ki7zs=; b=Anmy3eLgFHbKBj2cjMNNdQbkHBEvMJcRnucHgh4tsabGpnMaq1ZeAH2r3zxZXgnqObU9wG 2KRrapITI96kHiufdxBnQfcn/Ukvib4qaMIyIshLQ0KUEI/05637FsFZH1SZsCiQ5eHMQS 3OhgFJA8HBZYVWnYvfenh8YTG3pb6W8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1690281440; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3I1WKvqsunGpCu04gF1CzawY3Z1Ke8IscFjJf/ki7zs=; b=Q7mJIHYEFRyDNOXBZljgdkx0YOncHEupc9cS+pA92vzRmqozTWVVNoKbjOgEH1s3G0IiS1 NGLaY1Gofub74vBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7F7EF13342; Tue, 25 Jul 2023 10:37:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id D7/LHeClv2SGAQAAMHmgww (envelope-from ); Tue, 25 Jul 2023 10:37:20 +0000 Date: Tue, 25 Jul 2023 12:37:20 +0200 Message-ID: <87ila8tgyn.wl-tiwai@suse.de> From: Takashi Iwai To: Maarten Lankhorst Cc: Pierre-Louis Bossart , alsa-devel@alsa-project.org, sound-open-firmware@alsa-project.org, linux-kernel@vger.kernel.org, Jaroslav Kysela , Takashi Iwai , Cezary Rojewski , Liam Girdwood , Peter Ujfalusi , Bard Liao , Ranjani Sridharan , Kai Vehmanen , Mark Brown , Daniel Baluta , Matthew Auld Subject: Re: [PATCH v2 8/9] ASoC: SOF: Intel: Remove deferred probe for SOF In-Reply-To: <1bb7858d-fab0-f3c2-b786-a93f3789b400@linux.intel.com> References: <20230719164141.228073-1-maarten.lankhorst@linux.intel.com> <20230719164141.228073-9-maarten.lankhorst@linux.intel.com> <03d5abcd-53a6-bf61-227e-d608c5fbfe70@linux.intel.com> <1bb7858d-fab0-f3c2-b786-a93f3789b400@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 25 Jul 2023 12:29:07 +0200, Maarten Lankhorst wrote: > > Hey, > > On 2023-07-24 13:32, Pierre-Louis Bossart wrote: > > > > > > On 7/19/23 18:41, Maarten Lankhorst wrote: > >> This was only used to allow modprobing i915, by converting to the > >> -EPROBE_DEFER mechanism, it can be completely removed, and is in > >> fact counterproductive since -EPROBE_DEFER otherwise won't be > >> handled correctly. > > > > I personally remember only that the request_module("i915") was the main > > motivation for the use of the workqueue, but when it comes to the > > HDaudio codec management we don't even know what we don't know. > > > > I am a bit worried that the snd-hda-intel driver keeps the workqueue for > > HDaudio codec initialization, and this patch removes the workqueue > > completely for SOF. That doesn't seem right. Either both drivers need a > > workqueue or none need a workqueue. > > > > Maybe what we need is to move the i915/xe initialization out of the > > workqueue, and see in a second pass if that workqueue can be safely > > removed from the SOF driver? > > > As I mentioned in some of the other sound driver conversions. I > believe it's possible to completely kill off most workqueues. > > However, I donīt have the hardware or knowledge to test it. I saw > that the SOF had the non-workqueue path already, so it felt less risky > to simply convert it to always use that path. > > avs/skylake drivers should be easy to convert too. This is why I left > the comment: "Removing the workqueue would simplify init even further, > but is left as exercise for the reviewer." > > HDA-intel has this retry-probe logic used on AMD's, > which makes me more hesitant to convert it. Yes, HDA-Intel requires either a workqueue or async firmware-loader callback because there is some codec module-autoload mechanism that may happen during the probe phase. It's not only on AMD, but it's required in general for all codecs. Takashi