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 822B7C4338F for ; Mon, 9 Aug 2021 07:26:01 +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 1962461019 for ; Mon, 9 Aug 2021 07:25:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1962461019 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 E6593950; Mon, 9 Aug 2021 09:25:07 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E6593950 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1628493958; bh=vO8xWt6aA77pd0HfmgnAcowTFwOKqSlQBHeqmF54uCs=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=lQk7IPMQMdhOk2u6fyM8zCtAUDj5X/pELzHnbWxwoA8R82oaQugcy2inEKM5hrJ2I 400gCxNB+hxB5dhha6EuXtKqz+SIiyjgw7A7GfTNbHR5TKeGY1n8EQx2vLD6/GXHJi HRMxUza79mihRvnvqE4nNakc779lutLl4cckEfXM= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 7E3EFF800FD; Mon, 9 Aug 2021 09:25:07 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id EF917F802D2; Mon, 9 Aug 2021 09:25:05 +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 A5A3FF800FD for ; Mon, 9 Aug 2021 09:24:55 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz A5A3FF800FD Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="groVSyog"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="LVeX3DcF" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 8A9F321F13; Mon, 9 Aug 2021 07:24:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1628493894; 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=zgwzLo1pz+a4PSO9fAiq/SggKM+b9nLZlLr987GkDAc=; b=groVSyogXlraiUvF2QrDF/PnFhyl6YthOeEB6SxeipogR09eR6yk5hq+d6Ko9SCpdpqbq1 LMnkfGfF2SvMukop7n9KmxSxjekkMgEnFHCHT9WpNnOroxId43KkdyljpKRbycAq+F358F /RgVklM/pWSsy/6RdYEadrgs+bm5B+k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1628493894; 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=zgwzLo1pz+a4PSO9fAiq/SggKM+b9nLZlLr987GkDAc=; b=LVeX3DcFxvonggimpT8x/p1lP+BpuNW9EJl/GmDu6U+T+VsdJS3gqDk12nJnfDOtXNeJoB xM0AgmrFa4/A05DQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 738BAA3B88; Mon, 9 Aug 2021 07:24:54 +0000 (UTC) Date: Mon, 09 Aug 2021 09:24:54 +0200 Message-ID: From: Takashi Iwai To: Vinod Koul 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" , Pierre-Louis Bossart , Ranjani Sridharan , "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 06:02:21 +0200, Vinod Koul wrote: > > On 06-08-21, 11:17, Pierre-Louis Bossart wrote: > > > > > > On 8/6/21 8:37 AM, Vinod Koul wrote: > > > On 02-08-21, 10:46, Pierre-Louis Bossart wrote: > > >> > > >>>>>>>> The trigger callback is handled in the stream lock atomically, > > >>>>>>>> and are you sure that you want to operate a possibly heavy task there? > > >>>>>>> > > >>>>>>> It's a good objection that we didn't think of. > > >>>>>> > > >>>>>> Doesn't Intel use non atomic trigger to send IPCs which anyway > > >>>>>> involve code which can sleep..? > > >>>>> > > >>>>> sof_sdw.c doesn't seem setting it? > > >>>> > > >>>> Yes I think init_dai_link() should set it. Maybe Pierre/Bard would know why. > > >>> > > >>> init_dai_link() is to assign dai link elements only. No IPC is needed. > > >> > > >> The 'nonatomic' concept is only used for an FE dailink which expose a > > >> PCM device: > > >> > > >> soc-pcm.c: pcm->nonatomic = rtd->dai_link->nonatomic; > > >> > > >> Setting a BE dailink as 'nonatomic' would not accomplish much since BEs > > >> use the 'no_pcm' option. > > > > > > are no_pcm & nonatomic supposed to be not used together? So if FE is > > > nonatomic would BE trigger be atomic or nonatomic? > > > > I don't follow the multiple negations, so let me retry: > > > > 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? > > > > > 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. thanks, Takashi