Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp71984ybg; Thu, 11 Jun 2020 17:33:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyb6P2nY+6GjkM6wg+Wtld4nliG2030ag+WT4Wp1oWdNOi6MXoKdDn4HNyA+oITwMzMJOE7 X-Received: by 2002:a17:906:1d1a:: with SMTP id n26mr10387546ejh.351.1591922018123; Thu, 11 Jun 2020 17:33:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591922018; cv=none; d=google.com; s=arc-20160816; b=RGu1Zn1sE9sxqigWkd56N6vyvJ8PV8sqnJo7kfp0eQ3KtV8TW5mJ0wrbcbWQp+ed5H Pwkj8LYGIapTNiC9ciNw9g51Tf63KFQjteTy5aI2IIq0ROJiWM61CG8g1V1vrpMJoFXD 3reoV8guMz2ukqiBFxAyRYTwdgLS0/51xYUZ9LCAFh9A9D14pqv2/eeUIaSsLZfwURjQ UTJZJS4YxmsSXuo4SQUTZHsmGEsKLKYoWTQmXAeTYHwvbm0HEB1ZRcR7XzulOWNwglkK e/2UNQ5wCvOoAlO2pbaknAZiAlDC8bDvKKCIhvkOusofs3UyZhB9JWk6cpP+OqG1iKDs Oq7g== 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=Ynp2Ywh0TeTSOhhf2AKkRBib7Iyqqnx9iZi2CH+BUCI=; b=09n2bAX8gXTJALAqrc9/TEq06iUX7jhXKUjta/I+KUBI9VZRWOR3zXgmRpMZAviGGU eTjz5ETt9AhMjE0T7BNkP0jXQASVhlCVtPHdRK04Lw8cOCnnf5mpATpSfz8LzmLMOFaZ f21u2PiQLTjyDC+XcRrLOQb5SMD7uIDGvgq/MVj7onSm9uNp1QFUWDzJ0KyM3OtwiBcg Iyjps5UoEAJAQ0zGSq9PZp6eKPWZa7Z7U4v5m77WSSXp7hlM97n6B4jmQTGatKf4xIR0 N5/Cif+k2G1AJ1jmcgLzMccmSC0pk/C80OiPtO4JjYPD+Oju2KZXfjFUh8cwkO3hmcbq MKOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oqqdgIag; 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 o27si768656edz.331.2020.06.11.17.33.14; Thu, 11 Jun 2020 17:33:38 -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=oqqdgIag; 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 S1726380AbgFLAbR (ORCPT + 99 others); Thu, 11 Jun 2020 20:31:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726285AbgFLAbQ (ORCPT ); Thu, 11 Jun 2020 20:31:16 -0400 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6632BC03E96F for ; Thu, 11 Jun 2020 17:31:16 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id z63so2523136pfb.1 for ; Thu, 11 Jun 2020 17:31:16 -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=Ynp2Ywh0TeTSOhhf2AKkRBib7Iyqqnx9iZi2CH+BUCI=; b=oqqdgIagHUplXQwh3jjLPuNuFgwozom5py97t6fCsmiZOq8/fv4dP9+MJgxl43mXvr QaX6sN+IZnyzFc/n3w+Y7KKijtlKv2vLa9Jk+9BADSe83oALF69CYmhRFvO3r0pvAaK5 qsD4pvbeEv4nN5OUfK22rP8jHN3WfhXBXtQNbXVXUoc5FfH9bceomRRBmOhYXUCaxIwn BuL6sJI8UF0bawkkdFJGigJ2F4NzmjCaXTvz9d4SmoPVC6wIV38tgWV8r1tBMk/QHi3i d9dGsyvL/zcNmOYFWhaR3UMpfSqfPJc9M7gOCVOEBWsl6LCfm+fmzlgqKYktAvasOsIl h6ig== 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=Ynp2Ywh0TeTSOhhf2AKkRBib7Iyqqnx9iZi2CH+BUCI=; b=XC0/sh4Og3kIDbUofXvzZRCe00MbI2iaW0DWVMisKlpCcFTQzk2ozRU1dKF1S/H+Q0 uUhFfgJiXRQLzRIcDe6bbeIc2J4C6Zj8bBI8bnrSn0J9+ByCL65cuMeAk0DbwqYpHA8r /ebB+WmB4iEmNbCoCmowiy4b+NCCcrpuM4NJir16iv/Udy+Xoh8wK9228bkCF8OiXG1u vrBM2TCVM6gTUJBD5ppoYBuvDGs3hUEey4T5dqTIrmSQ1e7NMI2tj5VHbZSWUcGmrBLA +Rr7RPAvVSegT5JBdiZJCloc8vCeMjIM+hEXvK9xUcGgPr8djH0nf4KkPZB9vngI8J3O /Elg== X-Gm-Message-State: AOAM533cN8AJUs01Fc340Moc6VmP0AjEZkpsMva8Uw+EqPCVJkw6frRP Gn7/dfb7WY6qB3akvf6Zj0Q= X-Received: by 2002:a62:fc86:: with SMTP id e128mr9855537pfh.133.1591921875669; Thu, 11 Jun 2020 17:31:15 -0700 (PDT) Received: from Asurada-Nvidia (searspoint.nvidia.com. [216.228.112.21]) by smtp.gmail.com with ESMTPSA id y6sm4433379pfp.144.2020.06.11.17.31.14 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Jun 2020 17:31:15 -0700 (PDT) Date: Thu, 11 Jun 2020 17:31:04 -0700 From: Nicolin Chen To: Shengjiu Wang Cc: lars@metafoo.de, perex@perex.cz, tiwai@suse.com, lgirdwood@gmail.com, broonie@kernel.org, timur@kernel.org, Xiubo.Lee@gmail.com, festevam@gmail.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH v2 3/3] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End Message-ID: <20200612003103.GA28228@Asurada-Nvidia> References: <0473d4191ae04ab711d63c5c875e47f45f598137.1591783089.git.shengjiu.wang@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0473d4191ae04ab711d63c5c875e47f45f598137.1591783089.git.shengjiu.wang@nxp.com> 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 Wed, Jun 10, 2020 at 06:05:49PM +0800, Shengjiu Wang wrote: > The dma channel has been requested by Back-End cpu dai driver already. > If fsl_asrc_dma requests dma chan with same dma:tx symlink, then > there will be below warning with SDMA. > > [ 48.174236] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink > > or with EDMA the request operation will fail for EDMA channel > can only be requested once. > > So If we can reuse the dma channel of Back-End, then the issue can be > fixed. > > In order to get the dma channel which is already requested in Back-End. > we use the exported two functions (snd_soc_lookup_component_nolocked > and soc_component_to_pcm). If we can get the dma channel, then reuse it, > if can't, then request a new one. > > Signed-off-by: Shengjiu Wang > --- > sound/soc/fsl/fsl_asrc_common.h | 2 ++ > sound/soc/fsl/fsl_asrc_dma.c | 52 +++++++++++++++++++++++++-------- > 2 files changed, 42 insertions(+), 12 deletions(-) > diff --git a/sound/soc/fsl/fsl_asrc_common.h b/sound/soc/fsl/fsl_asrc_common.h > index 77665b15c8db..09512bc79b80 100644 > --- a/sound/soc/fsl/fsl_asrc_common.h > +++ b/sound/soc/fsl/fsl_asrc_common.h > @@ -32,6 +32,7 @@ enum asrc_pair_index { > * @dma_chan: inputer and output DMA channels > * @dma_data: private dma data > * @pos: hardware pointer position > + * @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 > diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c > index d6a3fc5f87e5..5ecb77d466d3 100644 > --- a/sound/soc/fsl/fsl_asrc_dma.c > +++ b/sound/soc/fsl/fsl_asrc_dma.c > @@ -160,6 +161,9 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component, > substream_be = snd_soc_dpcm_get_substream(be, stream); > dma_params_be = snd_soc_dai_get_dma_data(dai, substream_be); > dev_be = dai->dev; > + component_be = snd_soc_lookup_component_nolocked(dev_be, SND_DMAENGINE_PCM_DRV_NAME); > + if (component_be) > + tmp_chan = soc_component_to_pcm(component_be)->chan[substream->stream]; Should we use substream_be->stream or just substream->stream? And would be better to add these lines right before we really use tmp_chan because there's still some distance till it reaches that point. And would be better to have a line of comments too. > @@ -205,10 +209,14 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component, > */ > if (!asrc->use_edma) { > /* Get DMA request of Back-End */ > - tmp_chan = dma_request_slave_channel(dev_be, tx ? "tx" : "rx"); > + if (!tmp_chan) { > + tmp_chan_new = dma_request_slave_channel(dev_be, tx ? "tx" : "rx"); > + tmp_chan = tmp_chan_new; This is a bit confusing...though I finally got it :) So probably better to have a line of comments. > @@ -220,9 +228,26 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component, > > pair->dma_chan[dir] = > dma_request_channel(mask, filter, &pair->dma_data); > + pair->req_dma_chan_dev_to_dev = true; > } else { > - pair->dma_chan[dir] = > - asrc->get_dma_channel(pair, dir); > + /* > + * With EDMA, there is two dma channels can be used for p2p, > + * one is from ASRC, one is from another peripheral > + * (ESAI or SAI). Previously we select the dma channel of ASRC, > + * but find an issue for ideal ratio case, there is no control > + * for data copy speed, the speed is faster than sample > + * frequency. > + * > + * So we switch to use dma channel of peripheral (ESAI or SAI), > + * that copy speed of DMA is controlled by data consumption > + * speed in the peripheral FIFO. > + */ This sounds like a different issue and should be fixed separately? If you prefer not to, better to move this one to commit log, other than having a changelog here, in my opinion. Since it no longer uses get_dma_channel() for EDMA case, we should update the comments at the top as well. > + pair->req_dma_chan_dev_to_dev = false; > + pair->dma_chan[dir] = tmp_chan; > + if (!pair->dma_chan[dir]) { > + pair->dma_chan[dir] = dma_request_slave_channel(dev_be, tx ? "tx" : "rx"); > + pair->req_dma_chan_dev_to_dev = true; > + } > } Now there are some duplicated lines between these if-else routines, so combining my previous comments, we can do (sample change, not tested): @@ -197,18 +199,29 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component, dma_cap_set(DMA_SLAVE, mask); dma_cap_set(DMA_CYCLIC, mask); + /* + * The Back-End device might have already requested a DMA channel, + * so try to reuse it first, and then request a new one upon NULL. + */ + component_be = snd_soc_lookup_component_nolocked(dev_be, SND_DMAENGINE_PCM_DRV_NAME); + if (component_be) // should probably error out if !component_be? + tmp_chan = be_chan = soc_component_to_pcm(component_be)->chan[substream->stream]; + if (!tmp_chan) + tmp_chan = dma_request_slave_channel(dev_be, tx ? "tx" : "rx"); + /* * An EDMA DEV_TO_DEV channel is fixed and bound with DMA event of each * peripheral, unlike SDMA channel that is allocated dynamically. So no - * need to configure dma_request and dma_request2, but get dma_chan via - * dma_request_slave_channel directly with dma name of Front-End device + * need to configure dma_request and dma_request2, but get dma_chan of + * Back-End device directly via dma_request_slave_channel. */ if (!asrc->use_edma) { /* Get DMA request of Back-End */ - tmp_chan = dma_request_slave_channel(dev_be, tx ? "tx" : "rx"); tmp_data = tmp_chan->private; pair->dma_data.dma_request = tmp_data->dma_request; - dma_release_channel(tmp_chan); + /* Do not release tmp_chan if we are reusing the Back-End one */ + if (!be_chan) + dma_release_channel(tmp_chan); /* Get DMA request of Front-End */ tmp_chan = asrc->get_dma_channel(pair, dir); @@ -220,9 +233,11 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component, pair->dma_chan[dir] = dma_request_channel(mask, filter, &pair->dma_data); + pair->req_dma_chan = true; } else { - pair->dma_chan[dir] = - asrc->get_dma_channel(pair, dir); + pair->dma_chan[dir] = tmp_chan; + /* Do not flag to release if we are reusing the Back-End one */ + pair->req_dma_chan = !be_chan; } if (!pair->dma_chan[dir]) { > @@ -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?