Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp282086pxb; Thu, 20 Jan 2022 13:25:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxGuL1DOt3LwBG4r30BM9H7QSGqaVYDxZkeXsn6qXTRDpIIJJwUF4X7Eu04paCIK0w4Ky0P X-Received: by 2002:a17:902:b086:b0:14a:8565:642f with SMTP id p6-20020a170902b08600b0014a8565642fmr943705plr.165.1642713956092; Thu, 20 Jan 2022 13:25:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642713956; cv=none; d=google.com; s=arc-20160816; b=IHuVGYTEVpWa4htE/EijEixyfYLAt/dx+Lrd3jkXBU2UKurLgx+RcbQo/wX0Pr4mtd qpLmUeUlsDW9m9AcajYTWC525nHoneW+xaNAP8VdPH847sNIZep8RH9MHR5NrORoxVro 46iXHWLVSzlCHAGevsx0UnW5YoqrdwBv0mpJIvRJRJFa0DjhqINaPm/edKh+a3RsMrgY eAKJ/IAMPWmn4zpAL6m58mg3bpGm7eeQr7SBi6hV5QYZuVFLjcgjfHEBRPDshna3gC9X 5DvZ0YNoPdB9ShzZ+If2wjN+z2pM0dunyfmpqa+LG1mAR580Q2NKCkLop8km1nldCM/p 6MVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=4NNb0iIvZBgGyZQ4UOGRTomYdHNCz/kJcx5v8bWpRIE=; b=Z9TwCt/gHUxD44tiv5O9GkkXq3QaXgtm3aQ76+CNtnes4N+b6rnEUvZRdFbCEqKYWJ 7io3u0bspQHGVfS+s7qPZ9+jHUQnAF40gnWWhMupGNDTbPuzjjrz0u1r0Z4QVM/pbXTZ Qdji9Oj3jlhOedyzlG51f+HHvrLGXqvKJwqMtlXEPaADKWx0mFWyf1v1+uD8TV66frXH xaAJR14HUvGusvdzKNlqat7JYfaJy9m6SayHXfmjmssdF9If0SXWXROWi18kfdg2+ulP KKdIlcTmcUajNxVjhgQRJ4c/dvBcqDbfCmRqRSWpV8vmxPLJmMK4sK7ASwvuRVelVgEC x6bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=YnOSAqTE; 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 207si1373866pgh.24.2022.01.20.13.25.41; Thu, 20 Jan 2022 13:25:56 -0800 (PST) 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=20210112 header.b=YnOSAqTE; 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 S1347287AbiARR7w (ORCPT + 99 others); Tue, 18 Jan 2022 12:59:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237348AbiARR7t (ORCPT ); Tue, 18 Jan 2022 12:59:49 -0500 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED964C061574 for ; Tue, 18 Jan 2022 09:59:48 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id n8so2792049wmk.3 for ; Tue, 18 Jan 2022 09:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4NNb0iIvZBgGyZQ4UOGRTomYdHNCz/kJcx5v8bWpRIE=; b=YnOSAqTE/k+dKD+eCBKsQqpyCz6FWqm/6qUnScINkpLr/olE6LbtfBSnGaIBak++fe 6Aq3juSfmV9rjd/qhrPHAp+80r/9ltZ3byANKVGBpyIno3gTGF1AxvoUogboc0TVP4bJ XL19UT47yU4iRbZBGXKDCgcA3mskKukNZF0mVp9X65O7oUw1lwWy67X8QU41J3I2ted9 NEAzpClayKAtPGJkKow+/O9l/jCD2KnTdVjydy9QVkW8bc9/nDBKSYcR3X0TKw8f2JX/ CU5iY7OKoTCd5kjtWlv/r92+JlKaVpdsuSQtJO/AkZ3kxNYbhV6nQKcBk4ymPtdq3wUC y8CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4NNb0iIvZBgGyZQ4UOGRTomYdHNCz/kJcx5v8bWpRIE=; b=yfWXbqDX9Bzu0MoLt3YEGvaQd6rnvwKmpfC/hAWJHa+nNkdxujMlfSiq8r6+5VKtzt phKRGK9LKMeoMg6tQy37E0Z7cbEsz+Bcid8aEhqC1E1fiTcR9YDGtiGktlzD97U50MDQ K06CP1ARAs7q/dXHpl0ozrDABqDb1EM9jsSdAvF3GK157WL9W+8XkHqK8GFcqfEt0Mkj nlELJFP4r8HtQEEWuDcCwMyWnCqY77pxNI63G0hEodIZ8tCVuw9DDHQCKy+bf3tPkdCR BX6upnv47NN5XBbgTJPDnhxWFrXcwwlQHDszFGT5u+P8EHeyimDXR8M42lxEknZgQ5xR im5Q== X-Gm-Message-State: AOAM531DWGQNAMZcklvNIp9Q2zws1WOxyIOdaT0SYxyaOBLSKOeLvKWd 9kfTepN+e2znDsNkpFIzNIuUHo+zwVM4gfU/Zrs= X-Received: by 2002:a05:600c:3d12:: with SMTP id bh18mr15919791wmb.177.1642528787353; Tue, 18 Jan 2022 09:59:47 -0800 (PST) MIME-Version: 1.0 References: <20220113161341.371345-1-daniel.baluta@oss.nxp.com> In-Reply-To: From: Daniel Baluta Date: Tue, 18 Jan 2022 19:59:35 +0200 Message-ID: Subject: Re: [PATCH] ASoC: SOF: compr: Add compress ops implementation To: Cezary Rojewski Cc: Daniel Baluta , Mark Brown , Linux-ALSA , Pierre-Louis Bossart , Liam Girdwood , Ranjani Sridharan , Kai Vehmanen , Daniel Baluta , Jaroslav Kysela , Takashi Iwai , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 15, 2022 at 12:43 AM Cezary Rojewski wrote: > > On 2022-01-13 5:13 PM, Daniel Baluta wrote: > > From: Daniel Baluta > > > > Implement snd_compress_ops. There are a lot of similarities with > > PCM implementation. > > > > For now we use sof_ipc_pcm_params to transfer compress parameters to SOF > > firmware. > > > > This will be changed in the future once we either add new compress > > parameters to SOF or enhance existing sof_ipc_pcm_params structure > > to support all native compress params. > > > > Signed-off-by: Daniel Baluta > > ... > > > +static int create_page_table(struct snd_soc_component *component, > > + struct snd_compr_stream *cstream, > > + unsigned char *dma_area, size_t size) > > +{ > > + struct snd_soc_pcm_runtime *rtd = cstream->private_data; > > + struct snd_dma_buffer *dmab = cstream->runtime->dma_buffer_p; > > + int dir = cstream->direction; > > + struct snd_sof_pcm *spcm; > > The layout of this declaration block is weird - it's neither a > reversed-christmas-tree nor higher->lower complexity (e.g. structs -> > primitives). Could you explain why it is shaped as is? You are right, never put too much thought for this. Looking at SOF anyhow, it doesn't seem that all kind of styles are used including just random order. Will fix it :). > > > + > > + spcm = snd_sof_find_spcm_dai(component, rtd); > > + if (!spcm) > > + return -EINVAL; > > + > > + return snd_sof_create_page_table(component->dev, dmab, > > + spcm->stream[dir].page_table.area, size); > > +} > > + > > +int sof_compr_open(struct snd_soc_component *component, > > + struct snd_compr_stream *cstream) > > +{ > > + struct snd_soc_pcm_runtime *rtd = cstream->private_data; > > + struct snd_compr_runtime *runtime = cstream->runtime; > > Making use of 'rtd' and 'runtime' simultaneously within a function make > it less readable. I see. I will use rtd for snd_soc_pcm_runtime as usual and crtd for snd_compr_runtime. Naming is hard. > > > + struct sof_compr_stream *sstream; > > + struct snd_sof_pcm *spcm; > > + int dir; > > + > > + sstream = kzalloc(sizeof(*sstream), GFP_KERNEL); > > + if (!sstream) > > + return -ENOMEM; > > + > > + spcm = snd_sof_find_spcm_dai(component, rtd); > > + if (!spcm) { > > + kfree(sstream); > > + return -EINVAL; > > + } > > + > > + dir = cstream->direction; > > + > > + if (spcm->stream[dir].cstream) { > > + kfree(sstream); > > + return -EBUSY; > > + } > > Could you explain why this check is needed? i.e. Is is possible for > compress stream to be opened "twice"? This is needed because compress upper layers do not forbid opening the device twice but also it doesn't make much sense to open it twice. So, I just have exclusive access to Compr device and the rest of the calls to return -EBUSY. Same approach as in sound/soc/uniphier/aio-compress.c > > > + > > + spcm->stream[dir].cstream = cstream; > > + spcm->stream[dir].posn.host_posn = 0; > > + spcm->stream[dir].posn.dai_posn = 0; > > + spcm->prepared[dir] = false; > > + > > + runtime->private_data = sstream; > > + > > + return 0; > > +} > > + > > +int sof_compr_free(struct snd_soc_component *component, > > + struct snd_compr_stream *cstream) > > +{ > > + struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(component); > > + struct snd_soc_pcm_runtime *rtd = cstream->private_data; > > + struct snd_compr_runtime *runtime = cstream->runtime; > > Ditto. Thanks. Will fix. > > > + struct sof_compr_stream *sstream = runtime->private_data; > > + struct sof_ipc_stream stream; > > + struct sof_ipc_reply reply; > > + struct snd_sof_pcm *spcm; > > + int ret = 0; > > + > > + spcm = snd_sof_find_spcm_dai(component, rtd); > > + if (!spcm) > > + return -EINVAL; > > + > > + stream.hdr.size = sizeof(stream); > > + stream.hdr.cmd = SOF_IPC_GLB_STREAM_MSG | SOF_IPC_STREAM_PCM_FREE; > > + stream.comp_id = spcm->stream[cstream->direction].comp_id; > > + > > + if (spcm->prepared[cstream->direction]) { > > + ret = sof_ipc_tx_message(sdev->ipc, stream.hdr.cmd, > > + &stream, sizeof(stream), > > + &reply, sizeof(reply)); > > + if (!ret) > > + spcm->prepared[cstream->direction] = false; > > Why is the assignment conditional? If IPC fails, is the ->prepared flag > respected and addressed later on? It does not seem to happen here. > If this call fails it mean that freeing the pipeline has failed and we return an error to the upper layer. I dont think it makes sense to mark the stream as freed (prepared = false) if the IPC has failed we just return an error to the upper layers. I'm not sure if we can do anything useful with respect to failures in sof_compr_free other then report it to upper layers and keep internal error. If the upper layers decide to call again compr_open() the prepare will be set at that point to false. > > + } > > + > > + cancel_work_sync(&spcm->stream[cstream->direction].period_elapsed_work); > > + spcm->stream[cstream->direction].cstream = NULL; > > + kfree(sstream); > > + > > + return ret; > > +} > > + > > +int sof_compr_set_params(struct snd_soc_component *component, > > + struct snd_compr_stream *cstream, struct snd_compr_params *params) > > +{ > > + struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(component); > > + struct snd_soc_pcm_runtime *rtd_pcm = cstream->private_data; > > + struct snd_compr_runtime *rtd = cstream->runtime; > > + struct sof_compr_stream *sstream = rtd->private_data; > > + struct sof_ipc_pcm_params_reply ipc_params_reply; > > + struct sof_ipc_pcm_params pcm; > > + struct snd_sof_pcm *spcm; > > + int ret; > > + > > + spcm = snd_sof_find_spcm_dai(component, rtd_pcm); > > + if (!spcm) > > + return -EINVAL; > > + > > + cstream->dma_buffer.dev.type = SNDRV_DMA_TYPE_DEV_SG; > > + cstream->dma_buffer.dev.dev = sdev->dev; > > + ret = snd_compr_malloc_pages(cstream, rtd->buffer_size); > > + if (ret < 0) > > + return ret; > > + > > + create_page_table(component, cstream, rtd->dma_area, rtd->dma_bytes); > > Shouldn't the result of create_page_table() be tested before moving on? You are right. Will fix. > > > ... > > > +int sof_compr_trigger(struct snd_soc_component *component, > > + struct snd_compr_stream *cstream, int cmd) > > +{ > > + struct sof_ipc_stream stream; > > + struct sof_ipc_reply reply; > > + struct snd_soc_pcm_runtime *rtd = cstream->private_data; > > + struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(component); > > + struct snd_sof_pcm *spcm; > > Similarly to create_page_table() case, layout of this declaration block > is weird. Perhaps I'm just unaware of the convention used within this > directory. True. I just added the fields at random points while they were used. If you look at the sof directory this happens all over the place. > > > ... > > > +static int sof_compr_pointer(struct snd_soc_component *component, > > + struct snd_compr_stream *cstream, > > + struct snd_compr_tstamp *tstamp) > > +{ > > + struct snd_compr_runtime *runtime = cstream->runtime; > > + struct sof_compr_stream *sstream = runtime->private_data; > > I'd suggest declaring single local variable instead. The 'runtime' one > is unused except for the initial 'sstream' assignemnt. Will do. > > > + > > + tstamp->sampling_rate = sstream->sample_rate; > > + tstamp->copied_total = sstream->copied_total; > > + > > + return 0; > > +} > > ... > > > diff --git a/sound/soc/sof/sof-priv.h b/sound/soc/sof/sof-priv.h > > index 087935192ce8..d001a762a866 100644 > > --- a/sound/soc/sof/sof-priv.h > > +++ b/sound/soc/sof/sof-priv.h > > @@ -108,6 +108,12 @@ enum sof_debugfs_access_type { > > SOF_DEBUGFS_ACCESS_D0_ONLY, > > }; > > > > +struct sof_compr_stream { > > + unsigned int copied_total; > > + unsigned int sample_rate; > > + size_t posn_offset; > > +}; > > Some streaming-related PCM structs follow snd_sof_xxx naming pattern > instead, e.g.: snd_sof_pcm. Is the naming convention for compress > streams seen here intentional? Hmm, again naming is hard. I will think about it. > > > + > > struct snd_sof_dev; > > struct snd_sof_ipc_msg; > > struct snd_sof_ipc; > >