Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp199645ybg; Thu, 11 Jun 2020 22:07:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlAF+bhXx5U77I4IiUXfKDowFMAsveABSbP8YgYqWt8poX8SlhBthXpOoPsxAOkeSXRcXz X-Received: by 2002:a17:906:1c4a:: with SMTP id l10mr10840448ejg.499.1591938436197; Thu, 11 Jun 2020 22:07:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591938436; cv=none; d=google.com; s=arc-20160816; b=rjf2Ylc9udpdhochMtk/NLB04LlF/Cn03UPqa1NqDz60sJOPs1UFYhvijXnsamJNGD rQG3QOrWi4UNC91SEdVvFS2pSRBjnHBqt4UI2M7JJF+HB85B14c1mFaoGppCmVAsSVaN UdkvfJD6ohVaWb0GxOk1G2yyE7rZ273MhCPuIhGB8lJLqhA0lRJHmBCzlVU3T7/h8qhL mpYh2yazzxcZg2Bjo64HkqlQj3fcsVYuqAbKumtF3C5NGOXqqcAr8+vvZ95VaJ8ZHWg/ 7nQH1PssOBQzOyaMVXYib8t2wbBFkbT55GECBr8g63ubGO5jVKwxpG9fAmjBxHDX6aFD 1n0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=AQb3my+JsHlPPhTUgek4A/JfdbCiC4/wHqfCQrXHjrU=; b=JdY0pL64O2/9OaVf5RIQmSDrPMYlyn3gCv4gsFPTX6mHWgxUurjnwSWyItZjMm0p5n UD/98/0IeiZm7N5QJZzfnjNTDuUAm764TB97IToUlVPCfdXJ5CaHigHJ9+kpm11Gb5TW 38bXVCSfVSXxshPmP3rPTh3JpeyH89m/CYXlRcCrmAv4ZGa2PVSbhRHMS8701c4gTLBT W74UwBXlAdG+E/UEVoACpu0TnIajTF1eH49tLJUaEODJ+NFGySAXznT1brzKdT84QpY9 Cn7RdVId1nyDIQE5VP3Ui1W6qZvWi4tVganaLp1Qm9z2HgzbxUTEKxivPkL+bZ0Y/gt2 kc6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=q01Sv3tA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s1si2691064edw.362.2020.06.11.22.06.52; Thu, 11 Jun 2020 22:07:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=q01Sv3tA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726369AbgFLFC6 (ORCPT + 99 others); Fri, 12 Jun 2020 01:02:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725947AbgFLFC6 (ORCPT ); Fri, 12 Jun 2020 01:02:58 -0400 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D34EAC03E96F for ; Thu, 11 Jun 2020 22:02:57 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id n9so3285178plk.1 for ; Thu, 11 Jun 2020 22:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AQb3my+JsHlPPhTUgek4A/JfdbCiC4/wHqfCQrXHjrU=; b=q01Sv3tAmgbAnD8CpTMm/o03irTJ7C9U+SvSNziUnrthARWPJYAHa+QPqOIvkTh6QR no4O2hrQdkvUupP2diATC+WeE8zHFg5Z7B2bRDjTf1OHqN1lk9NsKfdNlQObU1InoXUw 2A4MuUdDhIMNhy8XZYAZb6Nedh0e7AxbreTaiJr/him4Edt1Q345hVImR/g8Kbbc+Uym u0evKTdygrq7aUwfb/rkAxmVz0ZIDw++Z3xruuZc4cwf3IzIzQAMXpLnppl51Jc40Ove kI9LCyxnPeCzAoB1Eo3kkJlxAQ6o/5/HrUpoluPDcm2kg4ysQZPTDnOHRYs4UAKmkXBw bQAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AQb3my+JsHlPPhTUgek4A/JfdbCiC4/wHqfCQrXHjrU=; b=jIm1QCInTQ5+KWtXb8oIhPvPToNUXvH+ma0bLOx4BZ4NvhavZAe2yJUn0Lm48ITBht pveVq9q8H+xvBLzULOo5yc9j5YewTFEqU6/Lvz0hKnAqbbfdcGoFhfooEYigkcyn3xvL fm0EF1SNHYNrya0cEDYQwt+mDU97R8oHSNWJ2UNfsXadLdka+NcITMcFKz3Jhx62ecCj iU4zhgIEfRnt/+NezARCNT7aMLV4CIAtCyDvpzWgWsuAtrF+fY2ANWknMiwcUQELoFg4 scHRc8Fak+VuKp9RTCmDqYj2Z8qnPH2IG0rKUeLsdvGzaFgd27c03ah1CkV/0eHEeXjp nn5Q== X-Gm-Message-State: AOAM5328cd+YfRIdU4mRyaCvF0eoR+Y9sstYVkHyOre6BVRET68zgD2U gn6wyS41qZ3Y2e+y7sn49fY= X-Received: by 2002:a17:902:9f8d:: with SMTP id g13mr9910233plq.292.1591938177195; Thu, 11 Jun 2020 22:02:57 -0700 (PDT) Received: from Asurada-Nvidia (searspoint.nvidia.com. [216.228.112.21]) by smtp.gmail.com with ESMTPSA id n4sm4088751pjt.48.2020.06.11.22.02.56 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Jun 2020 22:02:56 -0700 (PDT) Date: Thu, 11 Jun 2020 22:02:46 -0700 From: Nicolin Chen To: Shengjiu Wang Cc: Shengjiu Wang , Linux-ALSA , lars@metafoo.de, Timur Tabi , Xiubo Li , linux-kernel , linuxppc-dev@lists.ozlabs.org, Liam Girdwood , Takashi Iwai , Mark Brown , Fabio Estevam Subject: Re: [RFC PATCH v2 3/3] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End Message-ID: <20200612050245.GA18921@Asurada-Nvidia> References: <0473d4191ae04ab711d63c5c875e47f45f598137.1591783089.git.shengjiu.wang@nxp.com> <20200612003103.GA28228@Asurada-Nvidia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 12, 2020 at 10:17:08AM +0800, Shengjiu Wang wrote: > > > diff --git a/sound/soc/fsl/fsl_asrc_common.h b/sound/soc/fsl/fsl_asrc_common.h > > > + * @req_dma_chan_dev_to_dev: flag for release dev_to_dev chan > > > > Since we only have dma_request call for back-end only: > > + * @req_dma_chan: flag to release back-end dma chan > > I prefer to use the description "flag to release dev_to_dev chan" > because we won't release the dma chan of the back-end. if the chan > is from the back-end, it is owned by the back-end component. TBH, it just looks too long. But I wouldn't have problem if you insist so. > > > @@ -273,19 +299,21 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component, > > > static int fsl_asrc_dma_hw_free(struct snd_soc_component *component, > > > struct snd_pcm_substream *substream) > > > { > > > + bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK; > > > struct snd_pcm_runtime *runtime = substream->runtime; > > > struct fsl_asrc_pair *pair = runtime->private_data; > > > + u8 dir = tx ? OUT : IN; > > > > > > snd_pcm_set_runtime_buffer(substream, NULL); > > > > > > - if (pair->dma_chan[IN]) > > > - dma_release_channel(pair->dma_chan[IN]); > > > + if (pair->dma_chan[!dir]) > > > + dma_release_channel(pair->dma_chan[!dir]); > > > > > > - if (pair->dma_chan[OUT]) > > > - dma_release_channel(pair->dma_chan[OUT]); > > > + if (pair->dma_chan[dir] && pair->req_dma_chan_dev_to_dev) > > > + dma_release_channel(pair->dma_chan[dir]); > > > > Why we only apply this to one direction? > > if the chan is from the back-end, it is owned by the back-end > component, so it should be released by the back-end component, > not here. That's why I added the flag "req_dma_chan". Ah...I forgot the IN and OUT is for front-end and back-end. The naming isn't very good indeed. Probably we should add a line of comments somewhere as a reminder. Thanks