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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C0B9C433EF for ; Thu, 20 Jan 2022 14:34:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351069AbiATOet (ORCPT ); Thu, 20 Jan 2022 09:34:49 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:45535 "EHLO wout4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350112AbiATOet (ORCPT ); Thu, 20 Jan 2022 09:34:49 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8BE4F320100E; Thu, 20 Jan 2022 09:34:48 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 20 Jan 2022 09:34:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; bh=wkyNpQaqe/5yqepEtzW1vHU0+7nQsE z2kObpQxckMxk=; b=TkX6qyBjcNL5NtQUJ1UnkYIqq+ICTI/lPJjXwyw1/vjOok igtQss6QnIWw6J3ncnR7A8zoJ+TVHXDtr6G/hGb2vLLGLNhOszGuMQTZf/JeT/6O drgO8/j6Nl07/Kjqj/WFKNi8UGNUtATlYx5jCCLECPk2AUcObQiQxA31I2PvuEhj r3F0UppitLr+o0TwHMd7mzGIhem/0jSqAv1NS/8C3+P+eS6tVwUkWfZc3p3YRmqL 81xt+WeDAh+Da0uC+El/QSINkZn7I0iJDuRMmRJG6lFg8guiGFFpT2CCGcitk4uJ EpzzTzCEC2+rM7q44vywYdYmHRnusgpYPRKlRvrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :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=fm1; bh=wkyNpQ aqe/5yqepEtzW1vHU0+7nQsEz2kObpQxckMxk=; b=mNs6fgKLJPYMlRy5uuhYng SGSol3UwlQyxkGC8xb/tRxI034yRVsKyCXFnHDZ/omwVL9uTH3/jAMWZrBc/o3it h//u+CEClRe5uL7HW4MxzLpV+JjQs/l3xvCHZFm7T6D83iYe0tydX1IXOLIoIUvP jLtpASS1/SBl7Hy8iT8ysvoJtmaE+sZVhjBDhk3jK35RbFReyiW4n7fGG+VZlikX 54T4Ag6eQDTfyF5RtNdUUwJSIfy5PJ87SaoMmsie/1beG9eRid+kmsTVbwFa91Bg mV5hwJvEsfJBJv4974dAJa+lZhe6DCJC9z6xBf0jSDfKPE1Qzi8oTsDap+7tK8rw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpedvkeelveefffekjefhffeuleetleefudeifeehuddugffghffhffehveevheeh vdenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg igihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jan 2022 09:34:47 -0500 (EST) From: Maxime Ripard To: Mike Turquette , Stephen Boyd Cc: linux-clk@vger.kernel.org, dri-devel@lists.freedesktop.org, Dave Stevenson , Phil Elwell , Tim Gover , Dom Cobley , Maxime Ripard Subject: [PATCH v3 08/10] clk: bcm: rpi: Run some clocks at the minimum rate allowed Date: Thu, 20 Jan 2022 15:34:15 +0100 Message-Id: <20220120143417.543744-9-maxime@cerno.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220120143417.543744-1-maxime@cerno.tech> References: <20220120143417.543744-1-maxime@cerno.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org The core clock and M2MC clocks are shared between some devices (Unicam controllers and the HVS, and the HDMI controllers, respectively) that will have various, varying, requirements depending on their current work load. Since those loads can require a fairly high clock rate in extreme conditions (up to ~600MHz), we can end up running those clocks at their maximum frequency even though we no longer require such a high rate. Fortunately, those devices don't require an exact rate but a minimum rate, and all the drivers are using clk_set_min_rate. Thus, we can just rely on the fact that the clk_request minimum (which is the aggregated minimum of all the clock users) is what we want at all times. Signed-off-by: Maxime Ripard --- drivers/clk/bcm/clk-raspberrypi.c | 37 +++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c index c879f2e9a4a7..9d09621549b9 100644 --- a/drivers/clk/bcm/clk-raspberrypi.c +++ b/drivers/clk/bcm/clk-raspberrypi.c @@ -77,6 +77,7 @@ struct raspberrypi_clk_variant { bool export; char *clkdev; unsigned long min_rate; + bool minimize; }; static struct raspberrypi_clk_variant @@ -87,6 +88,18 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = { }, [RPI_FIRMWARE_CORE_CLK_ID] = { .export = true, + + /* + * The clock is shared between the HVS and the CSI + * controllers, on the BCM2711 and will change depending + * on the pixels composited on the HVS and the capture + * resolution on Unicam. + * + * Since the rate can get quite large, and we need to + * coordinate between both driver instances, let's + * always use the minimum the drivers will let us. + */ + .minimize = true, }, [RPI_FIRMWARE_M2MC_CLK_ID] = { .export = true, @@ -102,6 +115,16 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = { * in this situation. */ .min_rate = 120000000, + + /* + * The clock is shared between the two HDMI controllers + * on the BCM2711 and will change depending on the + * resolution output on each. Since the rate can get + * quite large, and we need to coordinate between both + * driver instances, let's always use the minimum the + * drivers will let us. + */ + .minimize = true, }, [RPI_FIRMWARE_V3D_CLK_ID] = { .export = true, @@ -206,12 +229,26 @@ static int raspberrypi_fw_set_rate(struct clk_hw *hw, unsigned long rate, static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw, struct clk_rate_request *req) { + struct raspberrypi_clk_data *data = + container_of(hw, struct raspberrypi_clk_data, hw); + struct raspberrypi_clk_variant *variant = data->variant; + /* * The firmware will do the rounding but that isn't part of * the interface with the firmware, so we just do our best * here. */ + req->rate = clamp(req->rate, req->min_rate, req->max_rate); + + /* + * We want to aggressively reduce the clock rate here, so let's + * just ignore the requested rate and return the bare minimum + * rate we can get away with. + */ + if (variant->minimize && req->min_rate > 0) + req->rate = req->min_rate; + return 0; } -- 2.34.1 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 E3185C433EF for ; Thu, 20 Jan 2022 14:34:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2CB3E10E38B; Thu, 20 Jan 2022 14:34:53 +0000 (UTC) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id A154A10E537 for ; Thu, 20 Jan 2022 14:34:49 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8BE4F320100E; Thu, 20 Jan 2022 09:34:48 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 20 Jan 2022 09:34:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; bh=wkyNpQaqe/5yqepEtzW1vHU0+7nQsE z2kObpQxckMxk=; b=TkX6qyBjcNL5NtQUJ1UnkYIqq+ICTI/lPJjXwyw1/vjOok igtQss6QnIWw6J3ncnR7A8zoJ+TVHXDtr6G/hGb2vLLGLNhOszGuMQTZf/JeT/6O drgO8/j6Nl07/Kjqj/WFKNi8UGNUtATlYx5jCCLECPk2AUcObQiQxA31I2PvuEhj r3F0UppitLr+o0TwHMd7mzGIhem/0jSqAv1NS/8C3+P+eS6tVwUkWfZc3p3YRmqL 81xt+WeDAh+Da0uC+El/QSINkZn7I0iJDuRMmRJG6lFg8guiGFFpT2CCGcitk4uJ EpzzTzCEC2+rM7q44vywYdYmHRnusgpYPRKlRvrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :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=fm1; bh=wkyNpQ aqe/5yqepEtzW1vHU0+7nQsEz2kObpQxckMxk=; b=mNs6fgKLJPYMlRy5uuhYng SGSol3UwlQyxkGC8xb/tRxI034yRVsKyCXFnHDZ/omwVL9uTH3/jAMWZrBc/o3it h//u+CEClRe5uL7HW4MxzLpV+JjQs/l3xvCHZFm7T6D83iYe0tydX1IXOLIoIUvP jLtpASS1/SBl7Hy8iT8ysvoJtmaE+sZVhjBDhk3jK35RbFReyiW4n7fGG+VZlikX 54T4Ag6eQDTfyF5RtNdUUwJSIfy5PJ87SaoMmsie/1beG9eRid+kmsTVbwFa91Bg mV5hwJvEsfJBJv4974dAJa+lZhe6DCJC9z6xBf0jSDfKPE1Qzi8oTsDap+7tK8rw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpedvkeelveefffekjefhffeuleetleefudeifeehuddugffghffhffehveevheeh vdenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrg igihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jan 2022 09:34:47 -0500 (EST) From: Maxime Ripard To: Mike Turquette , Stephen Boyd Subject: [PATCH v3 08/10] clk: bcm: rpi: Run some clocks at the minimum rate allowed Date: Thu, 20 Jan 2022 15:34:15 +0100 Message-Id: <20220120143417.543744-9-maxime@cerno.tech> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220120143417.543744-1-maxime@cerno.tech> References: <20220120143417.543744-1-maxime@cerno.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dom Cobley , Tim Gover , Dave Stevenson , dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org, Maxime Ripard , Phil Elwell Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" The core clock and M2MC clocks are shared between some devices (Unicam controllers and the HVS, and the HDMI controllers, respectively) that will have various, varying, requirements depending on their current work load. Since those loads can require a fairly high clock rate in extreme conditions (up to ~600MHz), we can end up running those clocks at their maximum frequency even though we no longer require such a high rate. Fortunately, those devices don't require an exact rate but a minimum rate, and all the drivers are using clk_set_min_rate. Thus, we can just rely on the fact that the clk_request minimum (which is the aggregated minimum of all the clock users) is what we want at all times. Signed-off-by: Maxime Ripard --- drivers/clk/bcm/clk-raspberrypi.c | 37 +++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c index c879f2e9a4a7..9d09621549b9 100644 --- a/drivers/clk/bcm/clk-raspberrypi.c +++ b/drivers/clk/bcm/clk-raspberrypi.c @@ -77,6 +77,7 @@ struct raspberrypi_clk_variant { bool export; char *clkdev; unsigned long min_rate; + bool minimize; }; static struct raspberrypi_clk_variant @@ -87,6 +88,18 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = { }, [RPI_FIRMWARE_CORE_CLK_ID] = { .export = true, + + /* + * The clock is shared between the HVS and the CSI + * controllers, on the BCM2711 and will change depending + * on the pixels composited on the HVS and the capture + * resolution on Unicam. + * + * Since the rate can get quite large, and we need to + * coordinate between both driver instances, let's + * always use the minimum the drivers will let us. + */ + .minimize = true, }, [RPI_FIRMWARE_M2MC_CLK_ID] = { .export = true, @@ -102,6 +115,16 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = { * in this situation. */ .min_rate = 120000000, + + /* + * The clock is shared between the two HDMI controllers + * on the BCM2711 and will change depending on the + * resolution output on each. Since the rate can get + * quite large, and we need to coordinate between both + * driver instances, let's always use the minimum the + * drivers will let us. + */ + .minimize = true, }, [RPI_FIRMWARE_V3D_CLK_ID] = { .export = true, @@ -206,12 +229,26 @@ static int raspberrypi_fw_set_rate(struct clk_hw *hw, unsigned long rate, static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw, struct clk_rate_request *req) { + struct raspberrypi_clk_data *data = + container_of(hw, struct raspberrypi_clk_data, hw); + struct raspberrypi_clk_variant *variant = data->variant; + /* * The firmware will do the rounding but that isn't part of * the interface with the firmware, so we just do our best * here. */ + req->rate = clamp(req->rate, req->min_rate, req->max_rate); + + /* + * We want to aggressively reduce the clock rate here, so let's + * just ignore the requested rate and return the bare minimum + * rate we can get away with. + */ + if (variant->minimize && req->min_rate > 0) + req->rate = req->min_rate; + return 0; } -- 2.34.1