From patchwork Fri Feb 20 00:36:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Andreas_F=C3=A4rber?= X-Patchwork-Id: 5854241 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7F9F7BF440 for ; Fri, 20 Feb 2015 00:37:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A2AAD2035B for ; Fri, 20 Feb 2015 00:37:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CD17520351 for ; Fri, 20 Feb 2015 00:37:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753822AbbBTAhN (ORCPT ); Thu, 19 Feb 2015 19:37:13 -0500 Received: from cantor2.suse.de ([195.135.220.15]:55389 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752304AbbBTAhM (ORCPT ); Thu, 19 Feb 2015 19:37:12 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 29C7DAAD1; Fri, 20 Feb 2015 00:37:08 +0000 (UTC) Message-ID: <54E681A8.6040702@suse.de> Date: Fri, 20 Feb 2015 01:36:56 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Organization: SUSE Linux GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Javier Martinez Canillas , Doug Anderson CC: alsa-devel@alsa-project.org, linux-samsung-soc , Sangbeom Kim , Liam Girdwood , Mark Brown , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Vincent Palatin , Tomasz Figa , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala Subject: Re: [PATCH 1/6] ASoC: max98088: Document DT bindings References: <1424283959-16289-1-git-send-email-afaerber@suse.de> <1424283959-16289-2-git-send-email-afaerber@suse.de> <54E5EB36.9020007@collabora.co.uk> <54E5EF73.2090302@suse.de> <54E62E1C.4030105@suse.de> <54E6314E.5060509@suse.de> <54E64C09.5000505@collabora.co.uk> In-Reply-To: <54E64C09.5000505@collabora.co.uk> Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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: > 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 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); }