Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp757225pxf; Thu, 11 Mar 2021 14:14:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJxoXucPO7GkGfT8edUIycP91tsc9753JSxlTeVMDPdtKJ3Gqz5dUelonnURqJ5uWRAPuBRI X-Received: by 2002:a05:6402:1103:: with SMTP id u3mr10604390edv.205.1615500885276; Thu, 11 Mar 2021 14:14:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615500885; cv=none; d=google.com; s=arc-20160816; b=UHU86r0s4MK6DMUyviRaz8bhRvC8mHsCOrEUMUqkR2gbJybO1SUwl8YlP8P9QbcqcF YVnlNQeXmzfTrWVXcbFIUleHKLibs4HBy/v5OqxVGi4JTcXzjSeB6PzYBjaGe8IqJ5Z4 TNR4ZgnfeL/pim4TJow6RysRiiYzJs+6ieejI+dAq2RR3pxTbkJ35V3aCsvDU+rErxl1 hjTWOHpy8zgniO8cfI2gg+vTzEdMqnv8AaU9da4JVTGn9uqRmvDpz2EWRRPeSdj1yFRy 6zMhI2h5H4D8G0fEWJRlIjccQL2K1WltMzIimf1wcvBGmEm+c89Pn9Sms9ZQJv/+XzZf 22qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :dkim-signature; bh=WsPITZ64nIWI+4FRusiGTBCLY0TRr7/LpaTTzy5rpfE=; b=Srw3nVzpiMlcPB6vdKWnrsW9pip+WklM63/ewfU+QzRGyg2W1q5XWJzborP9M24etP NyYnM/mDXIoIQyCH2Xw/wNtklDx/MikXccGFICK6WgobJrTgzq75m3TKKZ3fe4Cga2mH bBrZAZ14SjGpjcb/MltTyBh0iTK2wgzN4kOxp8rNZMwRnFl2VHmi/v8n6EOLtfN+75he 9jElV3eHvyV1nUZzif6u8j+F+GP3xKrzsWPys+ljZZdDENmyhzmoy6vZVOtNfzRLF6me 5Ow7yWa1/VMLpP/pN9QIC6int3OPhi/7tX2SrJJAZFtSTIfv+82MdDTPY9zaYcgcjMHi 1lyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b="l/wtr47o"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g3si2630408ejz.605.2021.03.11.14.14.20; Thu, 11 Mar 2021 14:14:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b="l/wtr47o"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230300AbhCKWLS (ORCPT + 99 others); Thu, 11 Mar 2021 17:11:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229774AbhCKWLR (ORCPT ); Thu, 11 Mar 2021 17:11:17 -0500 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E2FFC061574; Thu, 11 Mar 2021 14:11:17 -0800 (PST) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 5B5A52224F; Thu, 11 Mar 2021 23:11:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1615500675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WsPITZ64nIWI+4FRusiGTBCLY0TRr7/LpaTTzy5rpfE=; b=l/wtr47oZIFZkvukRdDqx0Yj4naCigu5BD9AeZS5626ItX0mk4ZONt6BKlZ3+YmjEIxmWW Rjo/kOfBd78omPKmg0B+71lY71DJkeN8Va45ywiR/+rdXrvjMKjt06HRc4uPT/7+zavxCJ +JyyrtHbiqzXJD4XpFEUtijKHJU5G0Q= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 11 Mar 2021 23:11:15 +0100 From: Michael Walle To: Mark Brown Cc: Sameer Pujar , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, jonathanh@nvidia.com, kuninori.morimoto.gx@renesas.com, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, robh@kernel.org, sharadg@nvidia.com, thierry.reding@gmail.com Subject: Re: [PATCH 1/3] ASoC: simple-card-utils: Fix device module clock In-Reply-To: <20210311161558.GG4962@sirena.org.uk> References: <1612939421-19900-2-git-send-email-spujar@nvidia.com> <20210309144156.18887-1-michael@walle.cc> <611ed3362dee3b3b7c7a80edfe763fd0@walle.cc> <20210311161558.GG4962@sirena.org.uk> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: michael@walle.cc Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2021-03-11 17:15, schrieb Mark Brown: > On Wed, Mar 10, 2021 at 08:20:28PM +0530, Sameer Pujar wrote: > >> If I read this correctly below is the configuration you need, >> SoC -> MCLK(fixed rate) -> PLL(wm8904) -> PLL output (256 * fs) -> >> sysclk > > For this device for integration with something like simple-audio-card > since there's limited flexibility within the device the simplest thing > would be to not make the internal clocking of the device visible and > just have it figure out how to use the input clock, using the MCLK > directly if possible otherwise using the FLL to generate a suitable > clock. Before this patch, part of this was already happening. That is, simple-audio-card called set_sysclk(samplerate * mclk-fs), then the codec figured out that its mclk was different than the requested sample rate and enabled its FLL to generate the requested sample rate automatically. With this patch applied, simple-audio-card already tries to change mclk, which isn't working in my case (the MCLK isn't generated by a PLL and just supports fixed frequencies) and thus breaks audio. And this patch also propagate to the stable kernels and breaks my board there, too. > The trick is figuring out if it's best to vary the input clock > or to use the FLL to adapt a fixed input clock, For simple-audio-card you can set the "clock" property if you want that clock to be changed/enabled/disabled. But that doesn't seem to be the way to go, at least it was NAKed by Rob for the audio-graph-card. I don't see a way to figure out if MCLK should be controlled by simple-*-card without adding further properties to the device tree. > and of course adapting any existing users if things get changed. To be frank, I don't see that happening. -michael