Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1793832ybz; Thu, 30 Apr 2020 05:43:43 -0700 (PDT) X-Google-Smtp-Source: APiQypJbWttk9PUfd6nBYxQuehXagud1Yrvqi9UE47CBmxWXnYl8oCWGWfcjE66wo+gzTgRbBybQ X-Received: by 2002:a05:6402:1d09:: with SMTP id dg9mr2530359edb.118.1588250623148; Thu, 30 Apr 2020 05:43:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588250623; cv=none; d=google.com; s=arc-20160816; b=rMB3TrZz8y0KbvTq0RmsnZSf42orasa3AGXU7c+x1C9pW/LQwp5yjN/SjxKSdKlB2f q5KQBJrZRSZ1jEorRanlekS79mnsABlaD5dV1aRom23EphDMe/rUAgvkW9t+LBu+AcFV n4GnI/dWbxZmOcPyUumkFvFzR+uostJXFEHYM6Ed5fMh8BPWMl0fYyLcx3BGFa+xnKN2 KMyxheBg8uj1zNT8Jg53LJNZxL6kRAmzc0sqsAT98cxNnC8fQBTqDsPEcnXel0M/Rwht fVz5Mzbn9+j6e7Y6NynlfJ/dmbAhWKFERPNXl6/lh8ZddCL3N8VtQq6b2JRgB3nzluZQ xIGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:mime-version:message-id :date:subject:cc:to:from; bh=iOTBcDsLLgLJQNleti1NyLgN7hxMgJVLaYlGA0OF9uM=; b=oG0eAWpotKU8F9rBj71iEkxqSc9SqbDgZ4w7aAvFFA5zRVg3IBxUDQ/OO8NGq9yZ9c 6t9Ht9+smp1fch2snGVerGzm/29dQUguB7CTPeU4kHaskSLyL5NszrxwbKe7rySVg6uO 1Av3SpP7EovsbIhKUNlnTYghKLY/ijjTU4JNX1mj17h5Kx3aQWAZMuskC5oNUOyXugEt Zrqmfbhf5bCEO3c7oubLbUEczwouPJ28DkLL2Ku6lL2HRgyBENh55oss7Tu6p41j6ffz eFVsYDjh3JIcVnvzO/bt5XymKqSRFVblMZsa3h8Upp0KZ+f+2I3syCO4TVxF+sOWd4mG ilEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=MyXancF3; 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=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id di15si5026881edb.423.2020.04.30.05.43.18; Thu, 30 Apr 2020 05:43:43 -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=@nvidia.com header.s=n1 header.b=MyXancF3; 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=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726790AbgD3Mlb (ORCPT + 99 others); Thu, 30 Apr 2020 08:41:31 -0400 Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:13036 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726774AbgD3Mlb (ORCPT ); Thu, 30 Apr 2020 08:41:31 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Thu, 30 Apr 2020 05:41:18 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Thu, 30 Apr 2020 05:41:30 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Thu, 30 Apr 2020 05:41:30 -0700 Received: from HQMAIL111.nvidia.com (172.20.187.18) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 30 Apr 2020 12:41:30 +0000 Received: from rnnvemgw01.nvidia.com (10.128.109.123) by HQMAIL111.nvidia.com (172.20.187.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 30 Apr 2020 12:41:30 +0000 Received: from audio.nvidia.com (Not Verified[10.24.34.185]) by rnnvemgw01.nvidia.com with Trustwave SEG (v7,5,8,10121) id ; Thu, 30 Apr 2020 05:41:29 -0700 From: Sameer Pujar To: , , , CC: , , , , , , , , , , , , , , , Subject: [RFC] DPCM for Tegra Date: Thu, 30 Apr 2020 18:11:23 +0530 Message-ID: <1588250483-10014-1-git-send-email-spujar@nvidia.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1588250478; bh=iOTBcDsLLgLJQNleti1NyLgN7hxMgJVLaYlGA0OF9uM=; h=X-PGP-Universal:From:To:CC:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type; b=MyXancF3Zn1YW8lTjlAnrdqdJsnfZSi2IMP6aRcvGmuQldaw9Ll0QThJ9byqHBFzX 2oKXdykB2Vmd6lQ4PXYhReD3K4VqdTs/lDVnZOrNuP7sbHc9KCXXf8WT3GudVwAoot IHtQvJtDaGel/USTbevevWmyBh6i/pPFMU02akxvC8o7nLsEqkLTIQ69mwi1Ro3vhC HdD69WSlG5WNr9DCOLV4pzqNpkrQ0jSoUwEqwPOE/gsBhVyBgGuxWZwqQBvLTFPgu9 5dmqlB71yP6A8nSqrDPgTwdBtN7NIjbsLfzLbHzys6PmWfcDRtScp4YyzoCxaq8sXq TzPR4cCpSgGYQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, Earlier I had sent Tegra ASoC series [0] for review and writing back to follow up on the same. Background ========== There were following concerns on [0]: - Usage of mixer control overrides in each driver for PCM parameters. - Exposure of routing controls to the user. The comments are mostly captured in [1] and [2]. There was a suggestion to use DPCM for the Tegra audio requirements. Note: As of now, below does not cover specific solution for propogation of audio configurations or PCM parameters (like sample rate, sample size and channels). DPCM Testing ============ Since then I was looking into internals of DPCM and was trying to get it working with Tegra. I was able to get following things working. - Audio playback/capture over I2S/DMIC/DSPK. - Audio resampling use case. - Mixing of two audio streams with resampler in the path. Objective was to understand and get audio working with DPCM. Please note that I used simple-card DPCM driver for a quick testing on top of the above Tegra Audio series. I had to tweak the simple-card driver a little, but currently keeping it out of the scope of current discussion. At a high level Tegra Audio HW is depicted as below. | Front End PCMs | SoC DSP | Back End DAIs | ************* ADMAIF<0> <------------> * * <----DAI<0>-----> I2S * * ADMAIF<1> <------------> * * <----DAI<1>-----> DMIC * XBAR * ADMAIF<2> <------------> * * <----DAI<2>-----> DSPK * * ADMAIF <------------> * * <----DAI<3>-----> SFC (Resampler) * * * * <----DAI<4>-----> MIXER * * * * <----DAI-----> ... ************* Note: ----- * XBAR is just a cross bar interconnecting one component to another. Specific switch needs to be programmed for audio data to flow from one component to another. * SFC or Mixer are separate HW blocks and separate ASoC drivers are written for these. These drivers were not sent earlier as part of initial upstream series [0]. Follow up queries ================= Based on the above experience I do have few follow up queries and request for your inputs on this. a) Can I use a DAPM Mux control to activate a BE path? This in turn can program required switch in XBAR. This is needed for following reasons: - For an open platform like Jetson, we want to give maximum flexibility for a user to customize their audio paths. Number of connected components and order of these can vary depending on a use case. - Allow re-use of audio components across multiple use cases. For example, number of SFC instances are lesser than PCM playback or capture devices. b) I have modelled SFC and MIXER as backends. Is this allowed? This was done to include SFC or MIXER HW components as part of the sound card and use like below in one of the audio use cases. ADMAIF1(FE) --> SFC(BE1) --> I2S(BE2) ... OR ADMAIF2(FE) --> SFC(BE1) --> I2S(BE2) ... I used following workaround to connect multiple BE components. With this I can see PCM callbacks happen for all BE DAIs along the DAPM path. The obective was to connect multiple components together and (a) was used to connect one component to another. Each "-->" here connects two components and it is a switch in XBAR. --- sound/soc/soc-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index e256d43..ee7af55 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1494,7 +1494,7 @@ int dpcm_path_get(struct snd_soc_pcm_runtime *fe, /* get number of valid DAI paths and their widgets */ paths = snd_soc_dapm_dai_get_connected_widgets(cpu_dai, stream, list, - dpcm_end_walk_at_be); + NULL); dev_dbg(fe->dev, "ASoC: found %d audio %s paths\n", paths, stream ? "capture" : "playback"); -- c) Hostless mode did NOT work: - Following audio path was intended to be tested: I2S1 --> SFC --> I2S2 - [3] offers two options: * CODEC<->CODEC: If I were to use a separate DAI link for each BE to BE connection, then it will result in a similar design what we have currently. * Hostless: I did not come across references for this. (Any references in this regard will be helpful) May be the current Tegra ASoC design is more suitable for component model as you had previously mentioned. I wanted to understand if above, especially (a) and (b), are acceptable in this regard or if there are better options to interconnect multiple ASoC components. Looking forward for your feedback. Thanks, Sameer. References ========== [0] http://patchwork.ozlabs.org/project/linux-tegra/list/?series=159664&archive=both&state=* [1] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-6-git-send-email-spujar@nvidia.com/ [2] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-4-git-send-email-spujar@nvidia.com/ [3] https://www.kernel.org/doc/html/v5.6/sound/soc/dpcm.html