From: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.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>
Subject: Re: [PATCH] CHROMIUM: ASoC: amd: acp: Add tdm support for codecs in machine driver
Date: Wed, 9 Nov 2022 21:49:32 +0530 [thread overview]
Message-ID: <bca8ecb7-9f3e-2916-dd23-e35d31441ea4@amd.com> (raw)
In-Reply-To: <2ac3f9c9-5fa0-1b2f-de57-0774eb0acc5e@linux.intel.com>
On 11/7/22 20:34, Pierre-Louis Bossart wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 11/7/22 09:02, Venkata Prasad Potturu wrote:
>> On 11/7/22 19:44, Pierre-Louis Bossart wrote:
>>> Caution: This message originated from an External Source. Use proper
>>> caution when opening attachments, clicking links, or responding.
>>>
>>>
>>> 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?
>> All platforms use the kernel parameter to select the I2S/TDM mode.
>> Runtime parameters are not required here, by default it is in I2S mode and
>> when the platform needs to enable TDM mode then pass tdm_mode module
>> parameter as 1.
> How would a distribution decide to set this kernel parameter, what
> criteria would be used to determine that the TDM mode is required?
> You've got to think of who uses that parameter.
> This may work for a Chrome solution given that there are per-product
> overlays but won't work in the general case IMHO.
Thanks for your time and suggestion.
We will come back with DMI quirks.
>
next prev parent reply other threads:[~2022-11-09 16:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 10:34 [PATCH] CHROMIUM: ASoC: amd: acp: Add tdm support for codecs in machine driver Venkata Prasad Potturu
2022-10-28 10:58 ` Mark Brown
[not found] ` <b384e012-31c5-8412-8b05-cd026c5d6a0f@amd.com>
2022-11-01 14:31 ` Mark Brown
[not found] ` <ca006546-9b0c-34df-2a33-a4f10b68f815@amd.com>
2022-11-02 11:32 ` Mark Brown
[not found] ` <7b97682d-5cf1-8be1-9c62-41c9fbd89018@amd.com>
2022-11-07 14:14 ` Pierre-Louis Bossart
2022-11-07 15:02 ` Venkata Prasad Potturu
2022-11-07 15:04 ` Pierre-Louis Bossart
2022-11-09 16:19 ` Venkata Prasad Potturu [this message]
2022-11-07 15:01 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bca8ecb7-9f3e-2916-dd23-e35d31441ea4@amd.com \
--to=venkataprasad.potturu@amd.com \
--cc=AjitKumar.Pandey@amd.com \
--cc=Basavaraj.Hiregoudar@amd.com \
--cc=Sunil-kumar.Dommati@amd.com \
--cc=Vijendar.Mukunda@amd.com \
--cc=akihiko.odaki@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ssabakar@amd.com \
--cc=tiwai@suse.com \
--cc=venkataprasad.potturu@amd.corp-partner.google.com \
--cc=vsujithkumar.reddy@amd.com \
--cc=ye.xingchen@zte.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox