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 <[email protected]>
---
sound/soc/codecs/es8316.c | 37 +++++++++++++++----------------------
1 file changed, 15 insertions(+), 22 deletions(-)
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;
--
2.23.0.rc1
This patch adds missing DT-bindings document for Everest ES8316.
Signed-off-by: Katsuhiro Suzuki <[email protected]>
---
.../bindings/sound/everest,es8316.txt | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/everest,es8316.txt
diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.txt b/Documentation/devicetree/bindings/sound/everest,es8316.txt
new file mode 100644
index 000000000000..aefcff9c48a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es8316.txt
@@ -0,0 +1,20 @@
+Everest ES8316 audio CODEC
+
+This device supports both I2C and SPI.
+
+Required properties:
+
+ - compatible : should be "everest,es8316"
+ - reg : the I2C address of the device for I2C
+ - clocks : a list of phandle, should contain entries for clock-names
+ - clock-names : should include as follows:
+ "mclk" : master clock (MCLK) of the device
+
+Example:
+
+es8316: codec@11 {
+ compatible = "everest,es8316";
+ reg = <0x11>;
+ clocks = <&clks 10>;
+ clock-names = "mclk";
+};
--
2.23.0.rc1
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