Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2391180ybv;
        Mon, 24 Feb 2020 04:30:00 -0800 (PST)
X-Google-Smtp-Source: APXvYqxLa0bngijmXqock/LohJ6R/T1dfT5BImzycF9GUZQP7krfQzTdjmb02s0OuFK9yS+FSDg5
X-Received: by 2002:a9d:6c8d:: with SMTP id c13mr40572096otr.277.1582547400112;
        Mon, 24 Feb 2020 04:30:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1582547400; cv=none;
        d=google.com; s=arc-20160816;
        b=UnzMqdfja7MDWqq+6ITBcBArrcYC1n+rISIsVDsp/C/QmSoLhg+JWEaeUcajGWBQxj
         AKmIJ/su1E7eM3FaSVEd6ghGjBcruHRWFikeVfzEwRFc0Wh1LLs5w+P5W5ZRlVUmQwdZ
         oHFH9NAXIgbzfHs3ixL+IciBJgyiySpHYwGhngKeqp8lyE4ZDw6IR57//QBCAcLdJeYB
         F0u1B/3zDl61wFKiOuzEKa62XCgmG3KeRX293PK8u4n6j/fNt6X2KETQuk5WFW/TgBqm
         jfG6cNeN0eMQckFqs+R+qHUUVC784IYQUC0Ujh7F5K7K5L/F508MeU0O7RfzTzR97PsT
         uqAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:sender:dkim-signature:content-language
         :content-transfer-encoding:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:to:subject:cc;
        bh=BkJlDeQ3uyXrk5Yxotr7FKq3o5UzwF+OuQbFVpldsnE=;
        b=s0LP0ZLMwg7N/LpllD1P3TX3MKhdjV887vWobs0+iE7fSryRJMANR+Ra+VOgRyTcj4
         NgVkSxkBZyInZr2vUoH9q2uXH63jYGuYBUL6xY9B8btdu4ly/Tsme8VHrx7pN4+aBNPH
         kke8aAcC71OgH8PnTaJNQPdLJ4NWM+nu6ENb6MWLBKA8MxBb3CFtoJlWsCuEjtN19s3s
         ggwHZGmhhGvqoOrNNvit8e6aQdp4JM54x0Eg72z5tUs0Ze7/o1wYlZu2ZpRyJUQqljiJ
         q7RslZeQhtNerPND0+pyEdwx7oX9duO2KwcJDd6AqBXeJi/Pp/iiogM4F/pY7pmYokXX
         9zqA==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b="m7KGt/cW";
       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id 10si4027004ois.76.2020.02.24.04.29.47;
        Mon, 24 Feb 2020 04:30:00 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b="m7KGt/cW";
       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1727348AbgBXM3o (ORCPT <rfc822;zhangckid@gmail.com> + 99 others);
        Mon, 24 Feb 2020 07:29:44 -0500
Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:1502 "EHLO
        hqnvemgate24.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726778AbgBXM3o (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 24 Feb 2020 07:29:44 -0500
Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
        id <B5e53c16a0000>; Mon, 24 Feb 2020 04:28:26 -0800
Received: from hqmail.nvidia.com ([172.20.161.6])
  by hqpgpgate101.nvidia.com (PGP Universal service);
  Mon, 24 Feb 2020 04:29:42 -0800
X-PGP-Universal: processed;
        by hqpgpgate101.nvidia.com on Mon, 24 Feb 2020 04:29:42 -0800
Received: from [10.25.72.216] (10.124.1.5) by HQMAIL107.nvidia.com
 (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Feb
 2020 12:29:36 +0000
CC:     <spujar@nvidia.com>, <perex@perex.cz>, <tiwai@suse.com>,
        <robh+dt@kernel.org>, <lgirdwood@gmail.com>,
        <thierry.reding@gmail.com>, <digetx@gmail.com>,
        <alsa-devel@alsa-project.org>, <devicetree@vger.kernel.org>,
        <linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <sharadg@nvidia.com>, <mkumard@nvidia.com>,
        <viswanathl@nvidia.com>, <rlokhande@nvidia.com>,
        <dramesh@nvidia.com>, <atalambedu@nvidia.com>
Subject: Re: Re: [PATCH v3 03/10] ASoC: tegra: add Tegra210 based DMIC driver
To:     Mark Brown <broonie@kernel.org>, Jon Hunter <jonathanh@nvidia.com>
References: <1582180492-25297-1-git-send-email-spujar@nvidia.com>
 <1582180492-25297-4-git-send-email-spujar@nvidia.com>
 <20200221130005.GD5546@sirena.org.uk>
 <316ce0d5-318d-0533-ef06-bd7e8672f893@nvidia.com>
 <20200221165535.GG5546@sirena.org.uk>
 <47f94534-e997-d56c-5793-ae832fb2add4@nvidia.com>
 <20200224114406.GB6215@sirena.org.uk>
From:   Sameer Pujar <spujar@nvidia.com>
Message-ID: <f70c7c12-dbc0-a725-f06a-86fab868e7dc@nvidia.com>
Date:   Mon, 24 Feb 2020 17:59:33 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200224114406.GB6215@sirena.org.uk>
X-Originating-IP: [10.124.1.5]
X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To
 HQMAIL107.nvidia.com (172.20.187.13)
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1582547306; bh=BkJlDeQ3uyXrk5Yxotr7FKq3o5UzwF+OuQbFVpldsnE=;
        h=X-PGP-Universal:CC:Subject:To:References:From:Message-ID:Date:
         User-Agent:MIME-Version:In-Reply-To:X-Originating-IP:
         X-ClientProxiedBy:Content-Type:Content-Transfer-Encoding:
         Content-Language;
        b=m7KGt/cW33jZxBsTvrRquBVKLgHFaOpj6cmOI1gq/8AfoWti0CfVl/UC/cKsdx2Tl
         LPR0FyGeYqObSIHNLgTpg/bnzwkiKdHynqTk0m96C/NuinqMnu0r5xDRx5dwYt6agw
         tCgQSj4p+W6tjaI5Xn8/IgyRug9t60KlWjGxqKSBvI+SyuQp8S3qvoypKpO9+glYu+
         oQyMNMxCdod4dN44ZuZmGj5aW5gUlPB3uhFx4xr1xNYQpnUlZ2ZEUzSppeWSF0JXX8
         s41KLrXdprytk/NksFqe/3VcKWs5xMpcFcJcLly5g9g2iheYHqFSBZy+BwHWFSqJDg
         XUFRvHcAR8D1A==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 2/24/2020 5:14 PM, Mark Brown wrote:
> On Mon, Feb 24, 2020 at 11:28:57AM +0000, Jon Hunter wrote:
>> On 21/02/2020 16:55, Mark Brown wrote:
>>> The ideal thing in a component model would be to represent those sample
>>> rate convertors directly to usrspace so the routing and rewriting is
>>> explicit.
>> I assume that it would be OK for the sample rate converter itself to
>> expose mixer controls to configure its input and output rates so the
>> user could configure as needed?
> I don't think so, I'd not expect the individual drivers to be doing
> anything user visible here - if we know what a digital transformation
> looks like the framework should be offering anything that's needed to
> users (and hiding controls that don't have any practical control in a
> given system).

Are you suggesting to have some alternate way of users configuring 
sample rates (and other params) and not use mixer control method?

This is a typical use case we see,
- [stream-1] Lets say high resolution audio is playing (96kHz, 24-bit, 
stereo)
- [stream-2] Randomly system notifications of small durations come 
(48kHz, 16-bit, stereo)
The requirement is, both streams should be mixed and played.

Tegra Audio HW has Mixer module for mixing multiple streams. In above 
case, stream-2 requires upsampling to 96kHz (employ SRC) and 24-bit. 
Then mix with stream1 and play. This needs to be configured at runtime. 
In another session, mixing for 192kHz and 48kHz might be required with 
the same audio path. Idea was to allow users to setup their custom path 
for specific audio applications. In the current series, I am focussing 
on I/O modules (where overrides do not demonstrate the above use case) 
and does not include other HW accelerators that Tegra Audio HW offers. 
Things would be more complicated when user wants to use multiplexers and 
demultiplexers. For simple use cases overrides are not used.

Is there a better way for user to configure custom audio paths?

>
>>> Is there any *need* for these to be user configurable?  What's normally
>>> happening at the minute is that either the external DAIs are fixed
>>> configuration and the DSP just converts everything or there's no format
>>> conversion done and things get passed through.
>> I can see that in most cases there are a finite set of configurations
>> that the end user may use. However, we would like to make the
>> configuration flexible as possible and this also allow us to test lots
>> of different configurations for verification purposes as well.
> Internal testing often requires things that can't be exposed to users,
> the extreme examples are things like battery chargers with health and
> safety issues if the full range of control is available.