All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Jon Hunter <jonathanh@nvidia.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: Mon, 24 May 2021 16:40:30 +0300	[thread overview]
Message-ID: <f9631faa-5fc8-ecdd-709b-93b58e45a1ac@gmail.com> (raw)
In-Reply-To: <6bc26992-e136-ef6a-a956-382b5cae5db7@nvidia.com>

24.05.2021 15:22, Jon Hunter пишет:
> 
> 
> On 21/05/2021 20:05, Dmitry Osipenko wrote:
> 
> ...
> 
>>>> +unsigned int tegra_asoc_machine_mclk_rate(unsigned int srate)
>>>> +{
>>>> +	unsigned int mclk;
>>>> +
>>>> +	switch (srate) {
>>>> +	case 64000:
>>>> +	case 88200:
>>>> +	case 96000:
>>>> +		mclk = 128 * srate;
>>>> +		break;
>>>> +	default:
>>>> +		mclk = 256 * srate;
>>>> +		break;
>>>> +	}
>>>> +	/* FIXME: Codec only requires >= 3MHz if OSR==0 */
>>>> +	while (mclk < 6000000)
>>>> +		mclk *= 2;
>>>
>>> So this appears to be specific to the wm8903 codec or at least this is
>>> where it came from. And given that the switch statement is not complete
>>> in terms of the sample rates (ie. only has a subset), I am wondering if
>>> set should keep this specific to the wm8903 codec?
>>
>> The RT5631 codec of Asus Transformers will re-use this function.
> 
> OK, but does it need this FIXME part? That appears to be codec specific.

Downstream RT5631 Tegra driver has exactly the same FIXME.

Although, I now see that downstream RT5631 uses 384*srate for the
default cases.

I also see that WM8994 driver that we have in grate-kernel for Galaxy
Tab and SGH-I927 also re-uses that mclk_rate function.

>> IIUC, the default switch-case works properly for all rates below 64KHz,
>> at least I haven't had any problems with it. Could you please clarify
>> why you are saying that the switch statement appears to be incomplete?
> 
> It looks a bit weird because less than 64kHz and greater than 96kHz we
> use 256 and for only 64kHz, 88.2kHz and 96kHz we use 128. So it is not
> clear to me which sample rates have actually been tested with this and
> if this is complete or not?
> 
> Is it intended that we use 256 for sample rates greater than 96kHz?

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 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.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Jon Hunter <jonathanh@nvidia.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: Mon, 24 May 2021 16:40:30 +0300	[thread overview]
Message-ID: <f9631faa-5fc8-ecdd-709b-93b58e45a1ac@gmail.com> (raw)
In-Reply-To: <6bc26992-e136-ef6a-a956-382b5cae5db7@nvidia.com>

24.05.2021 15:22, Jon Hunter пишет:
> 
> 
> On 21/05/2021 20:05, Dmitry Osipenko wrote:
> 
> ...
> 
>>>> +unsigned int tegra_asoc_machine_mclk_rate(unsigned int srate)
>>>> +{
>>>> +	unsigned int mclk;
>>>> +
>>>> +	switch (srate) {
>>>> +	case 64000:
>>>> +	case 88200:
>>>> +	case 96000:
>>>> +		mclk = 128 * srate;
>>>> +		break;
>>>> +	default:
>>>> +		mclk = 256 * srate;
>>>> +		break;
>>>> +	}
>>>> +	/* FIXME: Codec only requires >= 3MHz if OSR==0 */
>>>> +	while (mclk < 6000000)
>>>> +		mclk *= 2;
>>>
>>> So this appears to be specific to the wm8903 codec or at least this is
>>> where it came from. And given that the switch statement is not complete
>>> in terms of the sample rates (ie. only has a subset), I am wondering if
>>> set should keep this specific to the wm8903 codec?
>>
>> The RT5631 codec of Asus Transformers will re-use this function.
> 
> OK, but does it need this FIXME part? That appears to be codec specific.

Downstream RT5631 Tegra driver has exactly the same FIXME.

Although, I now see that downstream RT5631 uses 384*srate for the
default cases.

I also see that WM8994 driver that we have in grate-kernel for Galaxy
Tab and SGH-I927 also re-uses that mclk_rate function.

>> IIUC, the default switch-case works properly for all rates below 64KHz,
>> at least I haven't had any problems with it. Could you please clarify
>> why you are saying that the switch statement appears to be incomplete?
> 
> It looks a bit weird because less than 64kHz and greater than 96kHz we
> use 256 and for only 64kHz, 88.2kHz and 96kHz we use 128. So it is not
> clear to me which sample rates have actually been tested with this and
> if this is complete or not?
> 
> Is it intended that we use 256 for sample rates greater than 96kHz?

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 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.

  reply	other threads:[~2021-05-24 13:40 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 ASoC machine drivers 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 [this message]
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
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=f9631faa-5fc8-ecdd-709b-93b58e45a1ac@gmail.com \
    --to=digetx@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=clamor95@gmail.com \
    --cc=ion@agorria.com \
    --cc=jonathanh@nvidia.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 \
    /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 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.