[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54E681A8.6040702@suse.de>
Date: Fri, 20 Feb 2015 01:36:56 +0100
From: Andreas Färber <afaerber@...e.de>
To: Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
Doug Anderson <dianders@...omium.org>
CC: alsa-devel@...a-project.org,
linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
Sangbeom Kim <sbkim73@...sung.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Vincent Palatin <vpalatin@...omium.org>,
Tomasz Figa <tomasz.figa@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
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:
https://github.com/afaerber/u-boot/blob/spring/drivers/sound/max98088.c
Regards,
Andreas
--
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists