Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp125279ybg; Thu, 11 Jun 2020 19:21:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiyt+qQncNyEqM41JFJPdONCI9NNUsbL/a1oNAYoG1M5KCZrNGlyCQoBa2fLjLxHKjKXYG X-Received: by 2002:a17:906:35ca:: with SMTP id p10mr10791410ejb.392.1591928511529; Thu, 11 Jun 2020 19:21:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591928511; cv=none; d=google.com; s=arc-20160816; b=ESh7mgGGV8XArp6TcCyWv3NLrv6qTAMAsmOAJFaLQ0kdOxlDUPJ9NKkxFSiDEr7s5p 2WOO+maUpLErCgPgLijCT9B2d2KLzK9isl1/vPGVZvnIOweaoHzAkke610nOJ98sEOc0 LnsBkc4HZCW4Qou2UbxuRfnfAELQalRk1lQwnbkpRyNRdaLaZle7boSP6ip2tzvbErFz jCGyHZ7Jj1F/VTn7ZscxEByuMQEAqwK8w2U71Oz6fttPGmSbIYEVKoQvCW6K5GIz3WQV PKciPF5EPg8viGcAkSo2i+ZGrbL0UvjkJFeqsBPzwigyawrnFhkwh4nFshFZZepCMR2T a2tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9AwsOvFeGYp6NGCe8GmFLKt3hED/xVphzYjoNYXlY+g=; b=dEChAGRdSZVi7LHU1oC0nZGaC5Y8QWm/6/hqtOO7om3gcSbd15mTa0trJOU5D6xMzX 8TwMHxPPqzh3kaUzc/2XfNhBA5/iqldomIPcuj1PY2yRCGG8nvPiyyF1tV+K9DfebODX ZSc9YuC8Vk9YTFfAJMVHW1PJVTrdDNO2bkqliMV0Zb/AD+6hwiyREkxrY/M/3nDwLoZl Bp5VzjkV85ODtlQVKD7YzfZUdZUssbcyoDsSf+ol4FJj36+v+CW+btxBddAowE8N9UCY eCjLX2tl77BZhMuncVUbrFt5+oBZehhL5U/g8Oza4KKdArM4d3zg03CDQQnv/8kaEfAo 5fqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m3NBZX4Q; 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 gh6si2993810ejb.689.2020.06.11.19.21.28; Thu, 11 Jun 2020 19:21:51 -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=m3NBZX4Q; 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 S1726603AbgFLCRW (ORCPT + 99 others); Thu, 11 Jun 2020 22:17:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726332AbgFLCRV (ORCPT ); Thu, 11 Jun 2020 22:17:21 -0400 Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CC3BC03E96F for ; Thu, 11 Jun 2020 19:17:20 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id c14so7643414qka.11 for ; Thu, 11 Jun 2020 19:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9AwsOvFeGYp6NGCe8GmFLKt3hED/xVphzYjoNYXlY+g=; b=m3NBZX4QtxOhokB1FZa/N7cxSs25LTtNV0th3cvTDIxZNMKZN51g2bguF6oKSZBN4A uPMFdPlUCQ5BkifwcFVuc2jsiI5+/yjB5loVdoVczD96/3NT3YczROG6TqTcGOZKKzp0 er2q4kt40pUZVJwOpGPeVSLmYhbLVzEj0U0yeriYN4cDyb3R9AXTQQ98BYqrMNQCKWRu doxIDPHBbFxBroV3GdMYjTOI84piB8V80PGl1B6FkhIR5mV1Jdofw9GVG8xpQ0PHkXDM 1JQZa4JAk0ADOSBOhQhoc40ua80bT2ktQ+NjpXPlBlUZh7dsSgSvEPjrOu8IE6xqwUSC ch+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9AwsOvFeGYp6NGCe8GmFLKt3hED/xVphzYjoNYXlY+g=; b=obJjQtlVTt51KHgZRVXw6islLDWmtGEHHNF1T/FSJ+7//fK2aCxrBDjImxQZ1QlWpH g2FGzDQ/3ZJmW342JErcE8SXYERBxGNn8LqRGvq9x5wsFT+5NLM1UBy6N6Mp/I++2XM6 0wwjCoZhUTpHghS+aSIDLr9KgCSSUA2iDc7aGhQzL+yjx5Tz31s1UWrAYfAw/dhBStiS jELeemv7qebU2wP6o6P5QW/MxoDyzVlrg2/TH9DdPmncum2iEc46aSCvcMAGeUsPhKWT G6hm30n8fXRz8BM5/T2TDHEp6SwQd5hPUwEccpPBQU4q9vWEtms9vWUNchvL2v/Kt1st i4lg== X-Gm-Message-State: AOAM530YSc7cqbde7g+KCSBTKe6F7kAGnSsHMEI2sFs+HFxpXEMN2JDr oKUmCVqa1Bx7E+uhibAhyRaCFgusppm6V/2vZ94= X-Received: by 2002:a37:9f44:: with SMTP id i65mr930286qke.103.1591928239341; Thu, 11 Jun 2020 19:17:19 -0700 (PDT) MIME-Version: 1.0 References: <0473d4191ae04ab711d63c5c875e47f45f598137.1591783089.git.shengjiu.wang@nxp.com> <20200612003103.GA28228@Asurada-Nvidia> In-Reply-To: <20200612003103.GA28228@Asurada-Nvidia> From: Shengjiu Wang Date: Fri, 12 Jun 2020 10:17:08 +0800 Message-ID: Subject: Re: [RFC PATCH v2 3/3] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End To: Nicolin Chen 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 Content-Type: text/plain; charset="UTF-8" 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 8:33 AM Nicolin Chen wrote: > > 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 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. > > > 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? substream_be->stream should be better. > > 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. ok. > > > @@ -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. ok. > > > @@ -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. ok, will move it in commit log. > > 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): ok, will try yours. > > @@ -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? 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".