From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10E1FC433DB for ; Fri, 15 Jan 2021 18:37:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BA5B123403 for ; Fri, 15 Jan 2021 18:37:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA5B123403 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JVGIjIsy+/8Gjqd2xQrd68WsKn8d3M5NfE7a6PnWfPE=; b=nexzXF6aYiNF42OTMBevAvDmS wCbO7dUdl7v5ojnENeK/d1ioS12Nr3wFlsLvOCN6NnMcK97TUbIthvJ7899smGcaPMAHY4ofGiJZE t3+Xj0k/k7GZ2QPLv4Nnh0Hr5iRxZ40WKiH5Ajqwg1W2m1Lwnovfu8t7stKhkBv8qummSh3aMRZt0 sjnWXICMCDlNNvge//dFdhIMkpCpoiWOQ8kj213/dXB+PIm2SYYIW9CwKgETXDpoUjCRT2mGqvvkd Y0lIu5IJOpRjQ1f4NT+DIi+PFNBs6cemMPnrPhGGL85aClKb9jOgux8kl1e4eTjTjsZKvULCGtP+z dCFUE3zUw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0Tx7-0004Bu-R2; Fri, 15 Jan 2021 18:36:05 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0Tx5-0004BB-1k; Fri, 15 Jan 2021 18:36:03 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CBF892371F; Fri, 15 Jan 2021 18:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610735762; bh=nrEh5qKyFfcqrhQvojtYrOk8oDWspF+B8YHetNxIp/I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iud4H4qhXR7cQadVrAZeKW3YsK9FY+a6ESBYwIDqPuHCrVo1FTirO4xZK11ZOcx4w lhdZ3iWiiuaAn4db+D3/pACYwfMX4PgMM+8a8xbdgSVUg7jiPuTF7k5ib0JRsxJSKN KVHM0ZKAqeNP8SirE7ocjw16rqeDu9UblTqtmNxE9ILFVn6VZm8ZouQno8BaYniDS9 w5JgP0NzqNUtXEwrQWs06NtyLpp7p+YZE71C0qfm6seHnuP4bmj6AzuO4Xr9H03IIh efYdqRW3fXg/wbTZooTu8cCrpK04KhjyeRoNQ4YCcqFFboCllOz7SB/nZ5LhcnH2wM T2NdtCgMzFaIQ== Date: Fri, 15 Jan 2021 18:35:27 +0000 From: Mark Brown To: Richard Fitzgerald Subject: Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties Message-ID: <20210115183527.GG4384@sirena.org.uk> References: <20210108160501.7638-1-rf@opensource.cirrus.com> <20210108160501.7638-3-rf@opensource.cirrus.com> <20210113152225.GA2334778@robh.at.kernel.org> <20210113160917.GF4641@sirena.org.uk> <20210115131142.GA4384@sirena.org.uk> <1ec5e5f4-f672-2c60-23a5-9d985b943379@opensource.cirrus.com> <20210115152004.GD4384@sirena.org.uk> MIME-Version: 1.0 In-Reply-To: X-Cookie: Debug is human, de-fix divine. User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210115_133603_236855_851991AC X-CRM114-Status: GOOD ( 22.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org, alsa-devel@alsa-project.org, f.fainelli@gmail.com, kuninori.morimoto.gx@renesas.com, devicetree@vger.kernel.org, patches@opensource.cirrus.com, linux-kernel@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, nsaenzjulienne@suse.de Content-Type: multipart/mixed; boundary="===============0117532358942558408==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0117532358942558408== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="reI/iBAAp9kzkmX4" Content-Disposition: inline --reI/iBAAp9kzkmX4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 15, 2021 at 04:15:21PM +0000, Richard Fitzgerald wrote: > If I do: > sound { > clocks =3D <&clock>; > }; >=20 > clock: clock { > compatible =3D "fixed-clock"; > clock-frequency =3D <98304000>; > }; >=20 > I can clk_bulk_get_all(). > But if I remove the 'compatible' from the clock node, clk_bulk_get_all() > will return -EPROBE_DEFER and log: OK, so if this is only supposed to represent a fixed clock on the board separate to the CODEC then yes, of course you do need to instantiate a driver for it like you do for every device on the board. However it shouldn't be a subdevice of the CODEC as you had it originally, it should be a distinct device as the above has it since that is what physically exists. This obviously won't configure the FLL at all though (which was what the binding you were proposing was for, the above is definitely not a direct substitute for the binding you originally proposed). > > When we say to use the clock binding what we are saying is to use the > > actual clock bindings to describe the clocks, not make a custom binding > > that looks kind of like them - making a custom binding doesn't address > > the problem. > But I don't know what you mean by "use the actual clock bindings to > describe the clocks". > What is not clear to me is how you want me to use a clock binding to > describe something that isn't a clk-framework clk. If you know what you > want, then please.. an example would help explain. The concept of a clock framework is an implementation detail of Linux which should not affect how the DT bindings for a device or system are written, DT bindings should be clear and idiomatic as DT bindings. The goal is to represent the system in a clear and standardized fashion which is useful to OSs in general, not just something convenient for Linux as it happens to be implemented right now. Current Linux internals are not a constraint for DT bindings. In this case if you can't figure out how to parse clock bindings without moving the clocks over to standard Linux clock APIs (which seems likely) then it follows that if you want to describe the clock configuration in DT then the driver support for these clocks should use the standard Linux clock framework. This seems like a good idea in general anyway. --reI/iBAAp9kzkmX4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmAB4G4ACgkQJNaLcl1U h9Ajugf/V/c7kkx7kjE3+tn6nJNrg21PFVDm4St0hGGrFYbLX5tp94E++n7e+0S4 1O72CIgQcws/PAoj49e1eR9ucRcZztKs5ahuZNxEtGti7ASiGaVfsP63/496zQZN VPW5tOl/xrSw4kNiMkoCSZXT4Izm05XeLtLvV2SQxeVevR2ifnp38Ms5KTEG9PXT q5Kecf+CmTuIXlFFvyY3eD5Pqdvqe7F7obdoOxUET3NEEfuPYtRCA7YLHmFu/EfH Co3vKlM5RmSi8s4RJ4jXplNFEGMDSjfdLbvrIUPFl/fC4aHMIRk0sAQnKftj9vkO rs0GP4a8Qfuiyb0YYpMLrw2ora7WTQ== =sFv+ -----END PGP SIGNATURE----- --reI/iBAAp9kzkmX4-- --===============0117532358942558408== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============0117532358942558408==--