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 01B70C6FA82 for ; Wed, 14 Sep 2022 15:51:46 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:Date:To:Cc:From:Subject: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZnL4yWdG+6jkqQBvhZ8SRWXAH4tA+po1Ha1mfPlWTj0=; b=wil4TadqwFlI2I zBfkLdG6fD4hTvyJTN9yyVZtei+41fj9cNr5xhxrObUKe0pBWMLT5J3Ja6b6uECTVtW4K/zzA/GiB kVhh/RFT/YoW6p20PxqflZRIa+6MNsFzFdKmG95xMz/WSPmxb7Fw8eskr8FftZQMuq4xvrWoNhoFN LZUCPzDibQgwRZvF6WzoN603Tje9dfZ4e8b3inYJe5bxKO4rh2quHsiaq9dfJ42lMYfscHQKKPt7I +BBATR1bNdtjY2zaN6SDoPGmb+CLRavKt7bFQw0NrW5XgNwjdU22nggGodhhDsYjt+E6QdBeFSmh1 GymJ8yhAz7pyWnasuxRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYUev-004KN4-So; Wed, 14 Sep 2022 15:50:41 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYUet-004KLB-7E; Wed, 14 Sep 2022 15:50:40 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E27EFB811C1; Wed, 14 Sep 2022 15:50:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88E45C433C1; Wed, 14 Sep 2022 15:50:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663170635; bh=S28EkrNLwS69diRhkX+rhYqUGi8w409B1c6Xk4uXdA4=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=C1M6MQGrR9MJB1trIJC+waXGVZ4KZTTS+JTEOpiEsWCK7+PWOVMNeHPvSp5Zl4s8J hHMEIylwNYQu3JpzME1k3+hI7h8ay3mg8Fyq4l/C+ahofwmf0Rn3jdPCSzhKqsnDrx kysQUItpAD3rBHGQLray2SjAX1d2+eCxXKLh3tDQHNB9cyN3oCMEsDVHIY4mDkxNH6 anaFqGtVu5W6ZNvtaBld6rImlbyjnnJ9hJP5j/LOhvlg2dlMMqaT5gS/zFChRTCGrh 1ShOEbmH3O+HVdVPwSmLqlIKfrr+nNcBJclbNQrjDOz8WoD/FudG4ZvVFX0Tv2SM7J CrNyxNvTJ96EQ== MIME-Version: 1.0 In-Reply-To: <20220815-rpi-fix-4k-60-v1-2-c52bd642f7c6@cerno.tech> References: <20220815-rpi-fix-4k-60-v1-0-c52bd642f7c6@cerno.tech> <20220815-rpi-fix-4k-60-v1-2-c52bd642f7c6@cerno.tech> Subject: Re: [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum From: Stephen Boyd Cc: Maxime Ripard , 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 To: Broadcom internal kernel review list , Daniel Vetter , David Airlie , Emma Anholt , Florian Fainelli , Maxime Ripard , Maxime Ripard , Michael Turquette , Ray Jui , Scott Branden Date: Wed, 14 Sep 2022 08:50:33 -0700 User-Agent: alot/0.10 Message-Id: <20220914155035.88E45C433C1@smtp.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220914_085039_425053_ACD14969 X-CRM114-Status: GOOD ( 18.18 ) 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Maxime Ripard (2022-08-15 08:31:24) > @@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw, > return 0; > } > > +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 = __clk_get_hw(clk); Ideally we don't add more users of this API. I should document that :/ 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)? 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. > + if (!hw) > + return 0; > + > + data = clk_hw_to_data(hw); > + rpi = data->rpi; > + ret = raspberrypi_clock_property(rpi->firmware, data, > + RPI_FIRMWARE_GET_MAX_CLOCK_RATE, > + &max_rate); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel