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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DE09C4338F for ; Mon, 9 Aug 2021 15:13:50 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B121860F8F for ; Mon, 9 Aug 2021 15:13:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B121860F8F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 6BB711616; Mon, 9 Aug 2021 17:12:56 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 6BB711616 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1628522026; bh=sjtfmL5+Gry8+a/SegUu2XEebibWb2p8UIiJt7iLH74=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=UQsPS8liEFsLRjqfZs09p5WgxXZS/dyYAmBH3r6JneUhUZIS/0cKcGCzefQd/sJ4W fNF5ujD1hXyFZbsacLiOSKy61vkQ7D+bgVKBSzd6O/qM5XArMoDau06N5FjRXxCdT/ f4KOBNg1GTEsPA/lKmxz0ita4O/NJzfe7/JctB5g= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 0206FF80105; Mon, 9 Aug 2021 17:12:56 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 8E718F802D2; Mon, 9 Aug 2021 17:12:55 +0200 (CEST) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 2F73CF800FD for ; Mon, 9 Aug 2021 17:12:49 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 2F73CF800FD Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="bE8q2fIB"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="kqTR0OTy" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 03FBB21E9B; Mon, 9 Aug 2021 15:12:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1628521964; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ylb0jR8651PqOiJIE3wFx9D1Z3g+Dps+Qbi6+tz1S0c=; b=bE8q2fIBMIygABZQcK/HrfVaGQfHcu0wKl0q48pg2AaOXAU5nCRxhIRIZzZIeo1ZQuOzwE c/5Z8KScyNJGCXYOXI8yiIBi3Y90cG4q22rVkGcDd0VD6xjkF/WGIUfbqU5BHe+EK7CjYX lhGSE7HOZrCf1pkw5oyWbO62csRyK7g= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1628521964; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ylb0jR8651PqOiJIE3wFx9D1Z3g+Dps+Qbi6+tz1S0c=; b=kqTR0OTy5IlOKiKHnlXT13dHjPmBgrdQlT/LcPCpoErxH1E20AxZePRoX+5QDoNATcxp20 BRTF8aOtJqy+yTBQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id DB987A3B81; Mon, 9 Aug 2021 15:12:43 +0000 (UTC) Date: Mon, 09 Aug 2021 17:12:43 +0200 Message-ID: From: Takashi Iwai To: Pierre-Louis Bossart Subject: Re: [PATCH] soundwire: intel: trap TRIGGER_SUSPEND in .trigger callback In-Reply-To: References: <20210727053256.29949-1-yung-chuan.liao@linux.intel.com> <9ef7e341-13f4-69f7-964d-8e6efdd57ca7@linux.intel.com> 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") Content-Type: text/plain; charset=US-ASCII Cc: "alsa-devel@alsa-project.org" , Ranjani Sridharan , Vinod Koul , "broonie@kernel.org" , Bard Liao , "Liao, Bard" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Mon, 09 Aug 2021 16:26:51 +0200, Pierre-Louis Bossart wrote: > > > > >>> For Intel machine drivers, all BE dailinks use > >>> .no_pcm = 1 (explicit setting) > >>> .nonatomic = 0 (implicit). > >> > >> that was my question, how is it implicit? > >> Should be explicitly set, right? > > implicit behavior with C, if you don't set a field its value is zero... > > >>> All FE dailinks use > >>> .no_pcm = 0 (implicit) > >>> .nonatomic = 1 (explicit setting) > >>> > >>>>> So the question is: is there any issue with sending an IPC in a DAI > >>>>> trigger callback? > >>>> > >>>> Sorry looks like we diverged, orignal question was can we do heavy tasks > >>>> in trigger, the answer is no, unless one uses nonatomic flag which was > >>>> added so that people can do that work with DSPs like sending IPCs.. > >>>> Maybe we should add heavy slimbus/soundwire handling to it too...? > >>> > >>> I don't think the answer is as clear as you describe it Vinod. > >>> > >>> The .nonatomic field is at the BE dailink level. > >>> > >>> Unless I am missing something, I don't see anything that lets me set a > >>> .nonatomic property at the *DAI* level. > >> > >> I would say that was a miss in original design, it should have been set > >> at dai level or at least allowed to propagate from dai level setting. > >> > >> Now we are allowed to set it at dai_link but it is governed by dai > >> behaviour (DSP based DAI etc...) > > > > Actually, there was one big piece I overlooked. The whole DPCM BE > > operation is *always* tied with FE's. That is, the nonatomic flag is > > completely ignored for BE, but just follows what FE sets up. > > > > And that's the very confusing point when reviewing the code. You > > cannot know whether it's written for non-atomic context or not. This > > means that it's also error-prone; the code that assumes the operation > > in a certain mode might mismatch with the bound FE. > > > > So, ideally, both FE and BE should set the proper nonatomic flags, and > > have a consistency check with WARN_ON() at the run time. > > Sorry Takashi, I am not following. Are you asking me to add a .nonatomic > flag in all the exiting BEs along with a WARN_ON? > > I can do this, but that's a sure way to trigger massive amounts of > user-reported "regression in kernel 5.1x". Is this really what you want? That's why I wrote "ideally". We all know that the world is no perfect... So hardening in that way would be possible, but it has to be done carefully if we really go for it, and I'm not asking you to do that now. > Also I don't understand how this would help with the specific problem > raised in this patch: can we yes/no do something 'heavy' in a *DAI* > callback? What is the definition of 'heavy'? My previous comment wasn't specifically about your patch itself but rather arguing a generic problem. We have no notion or matching mechanism of the atomicity of DPCM BE. > And last, I am not sure it's always the case that a BE follows the FE > configuration. We've had cases of BE->BE loopbacks where the host > doesn't see or configured the data. Hm, how the trigger and other PCM callbacks for BE get called in that mode? Takashi