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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 C09E6C433DB for ; Wed, 17 Mar 2021 13:05:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C1F764F50 for ; Wed, 17 Mar 2021 13:05:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229986AbhCQNEn (ORCPT ); Wed, 17 Mar 2021 09:04:43 -0400 Received: from new2-smtp.messagingengine.com ([66.111.4.224]:33387 "EHLO new2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229460AbhCQNEK (ORCPT ); Wed, 17 Mar 2021 09:04:10 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 7564D580E7F; Wed, 17 Mar 2021 09:04:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 17 Mar 2021 09:04:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=X+JMiDx99qnQ/mxxmcAoaRsPbxj JwehnTGBW3syNHdo=; b=gZ/NzPQ9Sn9gKoebwaDWUgubC9eFxS28y1o0vtvWT1c VKEI3qtEUci+2fErGACQpXX5Gn239zrAS4O2LEoqpC+kiZlbnID9upJsNCSLg/g7 DJotrib56+DjwEh6/eFPteTDvwNoKjXvAiMnKhyxTuDMuvk/EaFndKf23aInyrKI WhCQbh9lCe1mM9ZepAg5biR2vu5U+/QJU4JemLT9VmZpMUdv1RjqQcNVCBkiClaA lyPe3UBWqFpnM0p6bQ+EylSWC3OkUoiz9QntWIiaDuTLBrPssIfUBWffyMSc9ZSJ PS9pqGsOSHGOiysGFLX4C8AHFBS5JPd4TvQHzs/Geog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=X+JMiD x99qnQ/mxxmcAoaRsPbxjJwehnTGBW3syNHdo=; b=c/y3e1kDlsRT4cw9YPuwQ9 lTY+t+ma6H39aFSOW8cVxUYULFDEHVjDVckyEW5NOvw8n9tJg6j79w1I3Pib1V7U PW8rt+rUFHJkybmGBl0woetlAUbPJpjy4o5ig4k/cjzoj4+Qn4+dhHScAcUBeG7H Ntm37jG03VoVbb59J/R9GUV+BSrKDPq43PQAwGZOg/TE9rjFJquaFdpDY4HUurmC L6a3csTquiJR11ZzPyblQB4tzY2bnE4ENlhwyNzqrJhWB496v/GZaJQUSspB9Zen icTOuq6inmfS9iyc0BgPwBJfEpXRtjaD/kwgWRIsDyXE97AkBQxT3oov3IZFuUEg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefgedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 16E5A24005B; Wed, 17 Mar 2021 09:04:07 -0400 (EDT) Date: Wed, 17 Mar 2021 14:04:04 +0100 From: Maxime Ripard To: Stephen Boyd Cc: Maarten Lankhorst , Mike Turquette , Thomas Zimmermann , dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org, Phil Elwell , Nicolas Saenz Julienne , Tim Gover , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Dave Stevenson , Daniel Vetter , David Airlie Subject: Re: [PATCH 1/8] clk: Add range accessors Message-ID: <20210317130404.djerabewynzhvfol@gilmour> References: <20210225155909.1853812-1-maxime@cerno.tech> <20210225155909.1853812-2-maxime@cerno.tech> <161472713858.1478170.9594904338107431350@swboyd.mtv.corp.google.com> <20210303084527.rziaoiqsr7r4bhcv@gilmour> <161594320095.1478170.16988206902476583714@swboyd.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="23ldu23v25ksbcb5" Content-Disposition: inline In-Reply-To: <161594320095.1478170.16988206902476583714@swboyd.mtv.corp.google.com> Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org --23ldu23v25ksbcb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 16, 2021 at 06:06:40PM -0700, Stephen Boyd wrote: > Quoting Maxime Ripard (2021-03-03 00:45:27) > > Hi Stephen, > >=20 > > On Tue, Mar 02, 2021 at 03:18:58PM -0800, Stephen Boyd wrote: > > > Quoting Maxime Ripard (2021-02-25 07:59:02) > > > > Some devices might need to access the current available range of a = clock > > > > to discover their capabilities. Let's add those accessors. > > >=20 > > > This needs more than two sentences to describe what's required. > > >=20 > > > >=20 > > > > Signed-off-by: Maxime Ripard > > > > --- > > > > drivers/clk/clk.c | 30 ++++++++++++++++++++++++++++++ > > > > include/linux/clk.h | 16 ++++++++++++++++ > > > > 2 files changed, 46 insertions(+) > > > >=20 > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > > > > index 8c1d04db990d..b7307d4f090d 100644 > > > > --- a/drivers/clk/clk.c > > > > +++ b/drivers/clk/clk.c > > > > @@ -2407,6 +2407,36 @@ int clk_set_max_rate(struct clk *clk, unsign= ed long rate) > > > > } > > > > EXPORT_SYMBOL_GPL(clk_set_max_rate); > > > > =20 > > > > +long clk_get_min_rate(struct clk *clk) > > >=20 > > > I need to read the rest of the patches but I don't see the justificat= ion > > > for this sort of API vs. having the consumer constrain the clk freque= ncy > > > that it wants. Is the code that's setting the min/max constraints not > > > the same as the code that's calling this API? Would an OPP table bett= er > > > serve this so the device knows what frequencies are valid?s Please > > > provide the use case/justification in the commit text. > >=20 > > The patch that uses it is the patch 4 > >=20 > > The issue I'm trying to solve is that all the RaspberryPi have a > > configuration file for the firmware, and the firmware is in charge of > > the clocks communicating through a mailbox interface. > >=20 > > By default, one of the main clocks in the system can only reach 500MHz, > > and that's the range reported by the firmware when queried. However, in > > order to support display modes with a fairly high bandwidth such as 4k > > at 60Hz, that clock needs to be raised to at least 550MHz, and the > > firmware configuration has a special parameter for that one. Setting > > that parameter will increase the range of the clock to have proper > > boundaries for that display mode. > >=20 > > If a user doesn't enable it and tries to use those display modes, the > > display will be completely blank. > >=20 > > There's no way to query the firmware configuration directly, so we can > > instead query the range of the clock and see if the firmware enables us > > to use those modes, warn the user and ignore the modes that wouldn't > > work. That's what those accessors are here for >=20 > How does the clk driver query the firmware but it can't be done > directly by the drm driver?=20 The configuration is done through a text file accessed by the firmware. What I meant was that the kernel cannot access the content of that file to make sure the right options have been enabled. However, it can indeed communicate with the firmware through the extent of the API it provides, but it's fairly limited. In our case, the only way to tell is to look for side effects of the configuration option, ie the maximum rate of the clock that has been increased. > > > Why two functions instead of one function to get both min and max? > >=20 > > Since we have clk_set_min_rate and clk_set_max_rate, it made sense to me > > to mirror that, but I'd be happy to change if you think otherwise >=20 > Does using clk_round_rate() work just as well? I guess it could work too, I'll try it out Maxime --23ldu23v25ksbcb5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYFH+RAAKCRDj7w1vZxhR xTn+AP0eeKcFH5a9IEZWMRDaQf9BoLcamyE1qvq3VAwkdZ9S+QD+JLlEVK7b9TwI f7ZZ1kf7GGk38kE+DF6nSH3ae7+BxwE= =IVWD -----END PGP SIGNATURE----- --23ldu23v25ksbcb5--