| Message ID | 20190831162650.19822-1-katsuhiro@katsuster.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/3] ASoC: es8316: judge PCM rate at later timing | expand |
On Sun, Sep 01, 2019 at 01:26:48AM +0900, Katsuhiro Suzuki wrote: > This patch change the judge timing about playing/capturing PCM rate. > > Original code set constraints list of PCM rate limits at set_sysclk. > This strategy works well if system is using fixed rate clock. > > But some boards and SoC (such as RockPro64 and RockChip I2S) has > connected SoC MCLK out to ES8316 MCLK in. In this case, SoC side I2S > will choose suitable frequency of MCLK such as fs * mclk-fs when > user starts playing or capturing. The best way to handle this is to try to support both fixed and variable clock rates, some other drivers do this by setting constraints based on MCLK only if the MCLK has been set to a non-zero value. They have the machine drivers reset the clock rate to 0 when it goes idle so that no constraints are applied then. This means that if the machine has a fixed clock there will be constraints, and that constraints get applied if one direction has started and fixed the clock, but still allows the clock to be varied where possible.
Hello Mark, Thanks a lot for your comments. On 2019/09/02 21:02, Mark Brown wrote: > On Sun, Sep 01, 2019 at 01:26:48AM +0900, Katsuhiro Suzuki wrote: >> This patch change the judge timing about playing/capturing PCM rate. >> >> Original code set constraints list of PCM rate limits at set_sysclk. >> This strategy works well if system is using fixed rate clock. >> >> But some boards and SoC (such as RockPro64 and RockChip I2S) has >> connected SoC MCLK out to ES8316 MCLK in. In this case, SoC side I2S >> will choose suitable frequency of MCLK such as fs * mclk-fs when >> user starts playing or capturing. > > The best way to handle this is to try to support both fixed and variable > clock rates, some other drivers do this by setting constraints based on > MCLK only if the MCLK has been set to a non-zero value. They have the > machine drivers reset the clock rate to 0 when it goes idle so that no > constraints are applied then. This means that if the machine has a > fixed clock there will be constraints, and that constraints get applied > if one direction has started and fixed the clock, but still allows the > clock to be varied where possible. > In my understanding, fixed and variable clock both use set_sysclk() for telling their MCLK to codec driver. For fixed MCLK cases we need to apply constraint but for variable MCLK cases we should not set constraints at set_sysclk(). How can we identify these two cases...? For example, if machine sets very low MCLK once, the driver applies low Fs constraints which I2S driver cannot support to. After that this sound card cannot play/capture any Fs rate. It seems set_sysclk() is not called if Fs does not match constraints. So we have no chance to reconfigure MCLK by set_sysclk(). Best Regards, Katsuhiro Suzuki
On Tue, Sep 03, 2019 at 04:19:10AM +0900, Katsuhiro Suzuki wrote: > On 2019/09/02 21:02, Mark Brown wrote: > > The best way to handle this is to try to support both fixed and variable > > clock rates, some other drivers do this by setting constraints based on > > MCLK only if the MCLK has been set to a non-zero value. They have the > > machine drivers reset the clock rate to 0 when it goes idle so that no > > constraints are applied then. This means that if the machine has a > In my understanding, fixed and variable clock both use set_sysclk() for > telling their MCLK to codec driver. For fixed MCLK cases we need to > apply constraint but for variable MCLK cases we should not set > constraints at set_sysclk(). How can we identify these two cases...? Like I say it's usually done by settingthe MCLK to 0 when not in use and then not applying any constraints if there's no MCLK set.
Hello Mark, On 2019/09/03 20:11, Mark Brown wrote: > On Tue, Sep 03, 2019 at 04:19:10AM +0900, Katsuhiro Suzuki wrote: >> On 2019/09/02 21:02, Mark Brown wrote: > >>> The best way to handle this is to try to support both fixed and variable >>> clock rates, some other drivers do this by setting constraints based on >>> MCLK only if the MCLK has been set to a non-zero value. They have the >>> machine drivers reset the clock rate to 0 when it goes idle so that no >>> constraints are applied then. This means that if the machine has a > >> In my understanding, fixed and variable clock both use set_sysclk() for >> telling their MCLK to codec driver. For fixed MCLK cases we need to >> apply constraint but for variable MCLK cases we should not set >> constraints at set_sysclk(). How can we identify these two cases...? > > Like I say it's usually done by settingthe MCLK to 0 when not in use and > then not applying any constraints if there's no MCLK set. > Ah... I understand. Current implementation refuses MCLK == 0. I'll change to accept MCLK == 0 for fixed clock users and send v3 patch. Best Regards, Katsuhiro Suzuki
diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c index ed2959dbe1fb..229808fa627c 100644 --- a/sound/soc/codecs/es8316.c +++ b/sound/soc/codecs/es8316.c @@ -363,27 +363,12 @@ static int es8316_set_dai_sysclk(struct snd_soc_dai *codec_dai, { struct snd_soc_component *component = codec_dai->component; struct es8316_priv *es8316 = snd_soc_component_get_drvdata(component); - int i; - int count = 0; es8316->sysclk = freq; if (freq == 0) return 0; - /* Limit supported sample rates to ones that can be autodetected - * by the codec running in slave mode. - */ - for (i = 0; i < NR_SUPPORTED_MCLK_LRCK_RATIOS; i++) { - const unsigned int ratio = supported_mclk_lrck_ratios[i]; - - if (freq % ratio == 0) - es8316->allowed_rates[count++] = freq / ratio; - } - - es8316->sysclk_constraints.list = es8316->allowed_rates; - es8316->sysclk_constraints.count = count; - return 0; } @@ -449,13 +434,6 @@ static int es8316_pcm_startup(struct snd_pcm_substream *substream, return -EINVAL; } - /* The set of sample rates that can be supported depends on the - * MCLK supplied to the CODEC. - */ - snd_pcm_hw_constraint_list(substream->runtime, 0, - SNDRV_PCM_HW_PARAM_RATE, - &es8316->sysclk_constraints); - return 0; } @@ -466,12 +444,27 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream, struct snd_soc_component *component = dai->component; struct es8316_priv *es8316 = snd_soc_component_get_drvdata(component); u8 wordlen = 0; + int i; if (!es8316->sysclk) { dev_err(component->dev, "No MCLK configured\n"); return -EINVAL; } + /* Limit supported sample rates to ones that can be autodetected + * by the codec running in slave mode. + */ + for (i = 0; i < NR_SUPPORTED_MCLK_LRCK_RATIOS; i++) { + const unsigned int ratio = supported_mclk_lrck_ratios[i]; + + if (es8316->sysclk % ratio != 0) + continue; + if (es8316->sysclk / ratio == params_rate(params)) + break; + } + if (i == NR_SUPPORTED_MCLK_LRCK_RATIOS) + return -EINVAL; + switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: wordlen = ES8316_SERDATA2_LEN_16;
This patch change the judge timing about playing/capturing PCM rate. Original code set constraints list of PCM rate limits at set_sysclk. This strategy works well if system is using fixed rate clock. But some boards and SoC (such as RockPro64 and RockChip I2S) has connected SoC MCLK out to ES8316 MCLK in. In this case, SoC side I2S will choose suitable frequency of MCLK such as fs * mclk-fs when user starts playing or capturing. Bad scenario as follows (mclk-fs = 256): - Initialize sysclk by correct value (Ex. 12.288MHz) - ES8316 set constraints of PCM rate by sysclk 48kHz (1/256), 32kHz (1/384), 30.720kHz (1/400), 24kHz (1/512), 16kHz (1/768), 12kHz (1/1024) - Play 48kHz sound, it's acceptable - Sysclk is not changed - Play 32kHz sound, it's acceptable - Set sysclk by 8.192MHz (= fs * mclk-fs = 32k * 256) - ES8316 set constraints of PCM rate by sysclk 32kHz (1/256), 21.33kHz (1/384), 20.48kHz (1/400), 16kHz (1/512), 10.66kHz (1/768), 8kHz (1/1024) - Play 48kHz again, but it's NOT acceptable because constraints list does not allow 48kHz Root cause of this strange behavior is changing constraints list at set_sysclk timing. It seems that is too early to determine. So this patch does not use constraints list and check PCM rate limit more later timing at hw_params. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> --- sound/soc/codecs/es8316.c | 37 +++++++++++++++---------------------- 1 file changed, 15 insertions(+), 22 deletions(-)