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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 77890C6FA82 for ; Wed, 14 Sep 2022 16:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc: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=UjIR3ekrwB1c110/RNYR0nrJFbW0vHFWiAb7uINzaj8=; b=KC1G33vNZmgYjT9x41EOeWy5Wy IZGI7r/Tkyey7I8sx+t1YXK30TXgCrM0YZYtQlt1kWXREdadMoIPB+W2Ax5uPb7ENcgn9jnXifDcS usNeEQx/W4IF48i4cLYBzRBMKfLbZNXTAzQ1F4w+Q47zs14TLj5WQ/R3O2jzSt8rlbSOD2SzGyLxD nEi6Tkkil9zxbRsbhveKVll0990iEIvO5mVPp4DIhurG3ow+0J+t5Boh8M/fdUIN5QjNP83s2bCfs E7y2olPy/9wUmVEpV1Wm6Kk8D37KJ2xmiUsazvnO2IRSgknej8TThIVvVk78Zo3/VCIsoiLICKtj/ q6lIn/zQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYV2r-004pNu-9p; Wed, 14 Sep 2022 16:15:25 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYV2g-004p66-S3; Wed, 14 Sep 2022 16:15:16 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id ADD773200A47; Wed, 14 Sep 2022 12:15:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Sep 2022 12:15:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1663172104; x=1663258504; bh=P7L2M3/QwQ QV+BhHnSTWfJbZqDvMBCiXVeYbVx8YGkU=; b=2sbkhWFPhTMpwQYi30Crgjun7y 6SSollWw43tIrUy/gKS8DAEN6b11J2GBD6ZCt9CkYloWYnX9VZMKsUwQ1ErYDHdx wEIiP6IbbEugF6+nvtcJ1IpH6FO1C7wTyObQOd70b1xA+P+i7kA36QbBfYumUVYu RpD+8e2FGV910jr5inDIUeiehHKjyiHP2uhYrrXiSELODP2MzeHiDvYVB14mpwzn t6xKYyYZrwFkVpO5GBh2PciDJ6Hb2M0DxKIa3Ra6Cwi5X9OgnJpchvIcERx26TvN aP0h8DZGV3B4J1WkaGkE+9S8HfHi6gEjZgdEoR7DB+xPoChX43omeRJFYyBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1663172104; x=1663258504; bh=P7L2M3/QwQQV+BhHnSTWfJbZqDvM BCiXVeYbVx8YGkU=; b=X/vAU0WfPT777EzQTStl3FNv7jQAhd8QQqSx0AJkuDK7 zaPyJr4OJi3+w4LQGLsW/nnm8qjcTOvNNA2k2EALAx7qqZbcBw+SYS7t3OUSibqD c5rdwz4Gxgnp7w7IOqO/+I454Bjd3daulgIMs8RXmhj/qjV2fvEymK1GmYHX+J29 uD5M72gdHh0tk9OV4NhtgXNhxRa24rsyUHpC+sT55Ke+vluqnCO5cchvZDzI5SMl m/zuHYn96D99WjkMpoFEQS88vTFhkiBJTOU1zLq36NV7NHWSN8YUUIa3KU36EEHW Bjm59LV5bplh5PXKJvt04kHdTxVCBzD+aUdvISG6xg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduiedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgig ihhmvgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrf grthhtvghrnhepteefffefgfektdefgfeludfgtdejfeejvddttdekteeiffejvdfgheeh fffhvedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Sep 2022 12:15:03 -0400 (EDT) Date: Wed, 14 Sep 2022 17:15:02 +0100 From: Maxime Ripard To: Stephen Boyd Cc: Broadcom internal kernel review list , Daniel Vetter , David Airlie , Emma Anholt , Florian Fainelli , Michael Turquette , Ray Jui , Scott Branden , linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, Dom Cobley , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum Message-ID: <20220914161502.faiaccuxydyrdr6e@penduick> References: <20220815-rpi-fix-4k-60-v1-0-c52bd642f7c6@cerno.tech> <20220815-rpi-fix-4k-60-v1-2-c52bd642f7c6@cerno.tech> <20220914155035.88E45C433C1@smtp.kernel.org> MIME-Version: 1.0 In-Reply-To: <20220914155035.88E45C433C1@smtp.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220914_091515_301994_FB17FEAA X-CRM114-Status: GOOD ( 29.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0346342764108320458==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0346342764108320458== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lzv5z4zggisvled2" Content-Disposition: inline --lzv5z4zggisvled2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for reviewing that series On Wed, Sep 14, 2022 at 08:50:33AM -0700, Stephen Boyd wrote: > Quoting Maxime Ripard (2022-08-15 08:31:24) > > @@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(stru= ct clk_hw *hw, > > return 0; > > } > > =20 > > +unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk) > > +{ > > + const struct raspberrypi_clk_data *data; > > + struct raspberrypi_clk *rpi; > > + struct clk_hw *hw; > > + u32 max_rate; > > + int ret; > > + > > + if (!clk) > > + return 0; > > + > > + hw =3D __clk_get_hw(clk); >=20 > Ideally we don't add more users of this API. I should document that :/ What should be the proper way to implement this? > It begs the question though, why do we need this API to take a 'struct > clk'? Can it simply hardcode the data->id value for the clk you care > about and call rpi_firmware_property() directly (or some wrapper of it)? You mean push it down to the consumer? We will have two users of that function eventually. The KMS driver, and the codec driver that isn't upstream yet. AFAIK, both are using a different clock, so we can' really hardcode it, and duplicating it at the consumer level would be weird. > Furthermore, I wonder if even that part needs to be implemented. Why > not make a direct call to rpi_firmware_property() and get the max rate? > All of that can live in the drm driver. Making it a generic API that > takes a 'struct clk' means that it looks like any clk can be passed, > when that isn't true. It would be better to restrict it to the one use > case so that the scope of the problem doesn't grow. I understand that it > duplicates a few lines of code, but that looks like a fair tradeoff vs. > exposing an API that can be used for other clks in the future. So we'll want to have that function shared between the KMS and codec drivers eventually. The clock id used by both drivers is stored in the DT so we would create a function (outside of the clock drivers) that would parse the clocks property, get the ID, and then queries the firmware for it. Would that make sense? Maxime --lzv5z4zggisvled2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABMIAB0WIQTXEe0+DlZaRlgM8LOIQ8rmN6G3ywUCYyH+BgAKCRCIQ8rmN6G3 y8NdAQDNNVcy/hcyBCUGwW5D6Ba/bwnP5KpSp6uvbGHgAZ7/HQD/XIuX+7fGvFsy YBf5MZIJ0Vmh5SvM654kpU7dr8di1Hw= =F783 -----END PGP SIGNATURE----- --lzv5z4zggisvled2-- --===============0346342764108320458== 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 --===============0346342764108320458==--