24.05.2021 21:50, Jon Hunter пишет:
>
> On 24/05/2021 14:40, Dmitry Osipenko wrote:
>> 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.
>
> What downstream branch are you referring to? I still don't think that
> that is a good reason to make this 'FIXME' the standard going forward
> and hence I would prefer that it is kept specific the wm8903. Otherwise
> people will keep using this code without understanding if this is
> needed/correct.
This is the original RT5631 driver from ASUS [1].
[1]
https://github.com/clamor-s/morpheus_kernel_asus_tf201/blob/a0b45b7e27976313c68cfbd8c7b8db021ee47ad1/sound/soc/tegra/tegra_rt5631.c#L72
I briefly looked at the RT5631 datasheet and don't see it saying
anything about the clk rate requirement >=6MHz. There are PLL tables
with the MCLK for the reference clock. For now I'm not sure what
downstream kernel tries to achieve, perhaps we should try to check
whether all audio rates work for RT5631.
>> 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 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?
>> 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.
