All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>,
	Jaroslav Kysela <perex@perex.cz>, Ion Agorria <ion@agorria.com>,
	Svyatoslav Ryhel <clamor95@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>
Cc: <alsa-devel@alsa-project.org>, <linux-tegra@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] ASoC: tegra: Unify ASoC machine drivers
Date: Tue, 25 May 2021 07:51:45 +0100	[thread overview]
Message-ID: <4cb563a0-8fdb-2425-57fe-633b7be51e01@nvidia.com> (raw)
In-Reply-To: <f27b931f-3f92-32cb-cdf0-d9ae001565fc@gmail.com>


On 24/05/2021 22:02, Dmitry Osipenko wrote:

...

>>> The 128*srate gives MCLK >6MHZ for 64/88/96, 256*srate gives MCLK >6MHZ
>>> for rates below 64kHZ. Looks like the goal is to get MCLK >6MHZ.
>>
>> The wm8903 supports 8kHz sample rates and 256*8000 is less than 6MHz.
>> Yes the FIXME loop corrects this, but you could also extend the case
>> statement to multiply by 512 for 8kHz.
> 
> But what benefits this extension will bring to us if the end result is
> the same?

For the wm8903, nothing, but that is not the concern really.

>>>  The WM8903 datasheet says:
>>>
>>> "The  following  operating  frequency  limits  must  be  observed  when
>>>  configuring  CLK_SYS.  Failure  to  observe   these   limits   will
>>> result   in   degraded  noise   performance   and/or   incorrect
>>> ADC/DAC  functionality.
>>>
>>> If DAC_OSR = 0 then CLK_SYS  3MHz
>>> If DAC_OSR = 1 then CLK_SYS  6MHz"
>>>
>>> Where DAC_OSR is DAC Oversampling Control
>>> 0 = Low power (normal oversample)
>>> 1 = High performance (double rate)
>>>
>>> I see that DAC_OSR=0 by default, it can be switched to 1 by userspace
>>> ALSA control.
>>>
>>
>> Yes that is all fine, but again this is specific to the wm8903.
> 
> Alright, I'll move it to the WM8903 driver in v4. It won't be a problem
> to make that function shared once will be actually needed.

Thanks, but it should only be shared if other codecs actually have this
same requirement. From what you have said about the rt5631 it is not
clear that it actually is the same or not.

Jon

-- 
nvpublic

WARNING: multiple messages have this Message-ID
From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>,
	Jaroslav Kysela <perex@perex.cz>, Ion Agorria <ion@agorria.com>,
	Svyatoslav Ryhel <clamor95@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>
Cc: linux-tegra@vger.kernel.org, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] ASoC: tegra: Unify ASoC machine drivers
Date: Tue, 25 May 2021 07:51:45 +0100	[thread overview]
Message-ID: <4cb563a0-8fdb-2425-57fe-633b7be51e01@nvidia.com> (raw)
In-Reply-To: <f27b931f-3f92-32cb-cdf0-d9ae001565fc@gmail.com>


On 24/05/2021 22:02, Dmitry Osipenko wrote:

...

>>> The 128*srate gives MCLK >6MHZ for 64/88/96, 256*srate gives MCLK >6MHZ
>>> for rates below 64kHZ. Looks like the goal is to get MCLK >6MHZ.
>>
>> The wm8903 supports 8kHz sample rates and 256*8000 is less than 6MHz.
>> Yes the FIXME loop corrects this, but you could also extend the case
>> statement to multiply by 512 for 8kHz.
> 
> But what benefits this extension will bring to us if the end result is
> the same?

For the wm8903, nothing, but that is not the concern really.

>>>  The WM8903 datasheet says:
>>>
>>> "The  following  operating  frequency  limits  must  be  observed  when
>>>  configuring  CLK_SYS.  Failure  to  observe   these   limits   will
>>> result   in   degraded  noise   performance   and/or   incorrect
>>> ADC/DAC  functionality.
>>>
>>> If DAC_OSR = 0 then CLK_SYS  3MHz
>>> If DAC_OSR = 1 then CLK_SYS  6MHz"
>>>
>>> Where DAC_OSR is DAC Oversampling Control
>>> 0 = Low power (normal oversample)
>>> 1 = High performance (double rate)
>>>
>>> I see that DAC_OSR=0 by default, it can be switched to 1 by userspace
>>> ALSA control.
>>>
>>
>> Yes that is all fine, but again this is specific to the wm8903.
> 
> Alright, I'll move it to the WM8903 driver in v4. It won't be a problem
> to make that function shared once will be actually needed.

Thanks, but it should only be shared if other codecs actually have this
same requirement. From what you have said about the rt5631 it is not
clear that it actually is the same or not.

Jon

-- 
nvpublic

  reply	other threads:[~2021-05-25  6:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 17:50 [PATCH v2 0/2] Unify NVIDIA Tegra " Dmitry Osipenko
2021-05-20 17:50 ` Dmitry Osipenko
2021-05-20 17:50 ` [PATCH v2 1/2] ASoC: tegra: Set driver_name=tegra for all " Dmitry Osipenko
2021-05-20 17:50   ` Dmitry Osipenko
2021-05-20 18:12   ` Dmitry Osipenko
2021-05-20 18:12     ` Dmitry Osipenko
2021-05-20 17:50 ` [PATCH v2 2/2] ASoC: tegra: Unify ASoC " Dmitry Osipenko
2021-05-20 17:50   ` Dmitry Osipenko
2021-05-20 19:02   ` Jaroslav Kysela
2021-05-20 19:02     ` Jaroslav Kysela
2021-05-20 19:08     ` Mark Brown
2021-05-20 19:08       ` Mark Brown
2021-05-21  8:54       ` Jaroslav Kysela
2021-05-21  8:54         ` Jaroslav Kysela
2021-05-21 18:43     ` Dmitry Osipenko
2021-05-21 18:43       ` Dmitry Osipenko
2021-05-21 13:12   ` Jon Hunter
2021-05-21 13:12     ` Jon Hunter
2021-05-21 19:05     ` Dmitry Osipenko
2021-05-21 19:05       ` Dmitry Osipenko
2021-05-24 12:22       ` Jon Hunter
2021-05-24 12:22         ` Jon Hunter
2021-05-24 13:40         ` Dmitry Osipenko
2021-05-24 13:40           ` Dmitry Osipenko
2021-05-24 18:50           ` Jon Hunter
2021-05-24 18:50             ` Jon Hunter
2021-05-24 21:02             ` Dmitry Osipenko
2021-05-24 21:02               ` Dmitry Osipenko
2021-05-25  6:51               ` Jon Hunter [this message]
2021-05-25  6:51                 ` Jon Hunter

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=4cb563a0-8fdb-2425-57fe-633b7be51e01@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=clamor95@gmail.com \
    --cc=digetx@gmail.com \
    --cc=ion@agorria.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.com \
    --subject='Re: [PATCH v2 2/2] ASoC: tegra: Unify ASoC machine drivers' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.