Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <dff6e7af-6a07-587e-79d0-706fe7ec6504@linux.intel.com>
Date:   Mon, 7 Nov 2022 08:14:47 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.2.2
Subject: Re: [PATCH] CHROMIUM: ASoC: amd: acp: Add tdm support for codecs in
 machine driver
Content-Language: en-US
To:     Venkata Prasad Potturu <venkataprasad.potturu@amd.com>,
        Mark Brown <broonie@kernel.org>
Cc:     alsa-devel@alsa-project.org, Sunil-kumar.Dommati@amd.com,
        ssabakar@amd.com, Ajit Kumar Pandey <AjitKumar.Pandey@amd.com>,
        ye xingchen <ye.xingchen@zte.com.cn>,
        Basavaraj.Hiregoudar@amd.com, Takashi Iwai <tiwai@suse.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Venkata Prasad Potturu 
        <venkataprasad.potturu@amd.corp-partner.google.com>,
        Vijendar.Mukunda@amd.com, vsujithkumar.reddy@amd.com,
        Akihiko Odaki <akihiko.odaki@gmail.com>,
        open list <linux-kernel@vger.kernel.org>
References: <20221028103443.30375-1-venkataprasad.potturu@amd.corp-partner.google.com>
 <Y1u1vj0K3m33wCTd@sirena.org.uk>
 <b384e012-31c5-8412-8b05-cd026c5d6a0f@amd.com>
 <Y2EttkwUvMReQcqg@sirena.org.uk>
 <ca006546-9b0c-34df-2a33-a4f10b68f815@amd.com>
 <Y2JVWmJsprt0xnKH@sirena.org.uk>
 <7b97682d-5cf1-8be1-9c62-41c9fbd89018@amd.com>
From:   Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <7b97682d-5cf1-8be1-9c62-41c9fbd89018@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 11/7/22 04:34, Venkata Prasad Potturu wrote:
> 
> On 11/2/22 17:02, Mark Brown wrote:
>>> On 11/1/22 20:01, Mark Brown wrote:
>>>> On Tue, Nov 01, 2022 at 03:15:08PM +0530, Venkata Prasad Potturu wrote:
>>>> Right, that's what the code does but why is this something that should
>>>> be controlled in this fashion?
>>> This machine driver is common for TDM mode and I2S mode, user can
>>> select TDM
>>> mode or I2S mode.
>> Why would the user choose one value or the other, and why would this
>> choice be something that only changes at module load time?  If this is
>> user controllable I'd really expect it to be runtime controllable.
>> You're not explaining why this is a module parameter.
> 
> Different vendors/OEM's use the same hardware as one need I2S mode and
> other need TDM mode, using common driver  to support  I2S and TDM mode
> with this parameter.
> 
> 
> static int tdm_mode = 0;
> module_param_named(tdm_mode, tdm_mode, int, 0444);
> 
> And this can be runtime controllable by setting permissions as 0644, we
> will change and send next version patch.

kernel parameters are difficult to manage for distributions using a
single-build. Either all platforms use the kernel parameter or none of
them do. That would not allow a per-platform choice of parameters.
Using DMI quirks or ACPI identifiers would be a lot less problematic, no?