Re: [PATCH 1/6] ASoC: max98088: Document DT bindings

From: Andreas FÃrber
Date: Thu Feb 19 2015 - 19:37:20 EST

Am 19.02.2015 um 21:48 schrieb Javier Martinez Canillas:
> On 02/19/2015 07:54 PM, Andreas FÃrber wrote:
>> Am 19.02.2015 um 19:40 schrieb Andreas FÃrber:
>>> I updated max98088 and had it working on first boot, but on
>>> second boot it complained about the frequency:
>>> [ 7.896834] max98088 7-0010: revision A
>>> [ 7.912776] snow-audio sound: HiFi <-> 3830000.i2s mapping ok
>>> [ 7.919367] max98088 7-0010: Invalid master clock frequency
>>> [ 7.919429] snow-audio sound: ASoC: Spring-I2S-MAX98089 late_probe()
>>> failed: -22
>>> [ 7.920019] snow-audio sound: snd_soc_register_card failed (-22)
>>> [ 7.920109] snow-audio: probe of sound failed with error -22
> I had the same error on Snow but even on the first boot and after doing some
> code archeology, I found the following commit [0] in a Samsung downstream
> tree that solves the issue.
> The problem is that clk_round_rate(max98095->mclk, freq) returns 0 as the
> rounded rate if XCLOUT is not allowed to be re-parented on rate change.

Same on Spring:

diff --git a/sound/soc/codecs/max98088.c b/sound/soc/codecs/max98088.c
index 1aa81321afba..46dc64675c26 100644
--- a/sound/soc/codecs/max98088.c
+++ b/sound/soc/codecs/max98088.c
@@ -1365,6 +1365,7 @@ static int max98088_dai_set_sysclk(struct
snd_soc_dai *dai,

if (!IS_ERR(max98088->mclk)) {
freq = clk_round_rate(max98088->mclk, freq);
+ dev_warn(codec->dev, "freq = %u\n", freq);
clk_set_rate(max98088->mclk, freq);

> With Tushar's patch I see that clk_round_rate() returns 24000000 (24MHz)
> so the codec driver setups the correct PLL clock.

Ditto. With the clkout reparenting patch, clk_round_rate() returns 24MHz
just like when double-beep-initialized. However when not
double-beep-initialized, the driver initializes, but no audible output,
so there must be another missing puzzle piece.

>> On a suspicion, the fourth boot I waited for the double-beep of the
>> firmware (waiting for Ctrl+d/u), and then it did work.
>> So it seems the mclk is not always set up properly by the kernel,
>> relying on firmware. Who's in charge of setting that clock up?
> Right, it seems audio is only working due the firmware doing some previous
> setup. Probably it works on every boot if you have "sound init" as a part of
> the u-boot boot commands?

Indeed it does, 24 MHz without the reparenting patch, and sound working.

'sound init' code:


SUSE Linux GmbH, Maxfeldstr. 5, 90409 NÃrnberg, Germany
GF: Felix ImendÃrffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG NÃrnberg)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at