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 7C0B8C433EF for ; Thu, 20 Jan 2022 14:34:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345760AbiATOeX (ORCPT ); Thu, 20 Jan 2022 09:34:23 -0500 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:53783 "EHLO wout4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242716AbiATOeW (ORCPT ); Thu, 20 Jan 2022 09:34:22 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2E9453200F72; Thu, 20 Jan 2022 09:34:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 20 Jan 2022 09:34:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; bh=obwHIxOpczJ8YsM5Ary7YpyYT6D7lDEJcwV9qL rQ5NM=; b=JeF8G4zjiflLS4wrYaUJIOudSNuahhfb7wKxV00lDufkZFA9Mq/ycd Q8/iMwbLhnzM/ohp5ZW0H2F7AP2NdTYV6dq3lRiXP9yd8pozzjdLRv2lR+ss/SYq fDz/v47Lmm0+S16rMSNjauXguCwGVaBHBQyQk76e7KfqmND6kNYIbecHyyhCA0aP NrFqYRin4Pz25hAhs7Lsg+K9YqFURYjA2RtzLxNJLzDZjX7VmILYXZCZiYnuQPao vamX6gxFu5x4fp3l7olJFl05Y0GsFvhA4rgh9JqlZ43ykx168nwo6kncn49Yv0Ts b+CHeFAxd5fQbCmqCkzXX9CbnuPCwbhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:message-id :mime-version: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=obwHIx OpczJ8YsM5Ary7YpyYT6D7lDEJcwV9qLrQ5NM=; b=QFRCSveXpG5VbiasnluYNy HeZIFbbLpUNrqNhufGrln54yVzS938P6HRPW0aua5IhA7y+fAcev7xkWi0qiNV6N VakDpm821ypW2IpYRJOti4vrbaDJb0sJOZ3+a6zDpsnI1LTq5nkf6R76wBYfs9t2 0xg6iJa2+xNADEED2KFPiWM+uCY97IK5tCZmpbYFhv1XxbXJB3CZmCZq1O6OJjXN XU626mIn8WlxuBe8QIpoEoVDKmIsEyrGh5J3bIU9G+0296mNsqqCIe5Uo1CHQpfV 8botUu3zFrJbwJZIpWdcq3TeR80C0QEzBOXEa7TQe71YiQDRaa8hSfNY1giKO77Q == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgtggfgsehtqhertdertdejnecuhfhrohhmpeforgigihhmvgcu tfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrthhtvg hrnhepteetledtudejhffftdeugfduffelleelheejgeegffduvddvgfdvhffhlefgteff necuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jan 2022 09:34:19 -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 00/10] clk: Improve clock range handling Date: Thu, 20 Jan 2022 15:34:07 +0100 Message-Id: <20220120143417.543744-1-maxime@cerno.tech> X-Mailer: git-send-email 2.34.1 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Hi,=0D =0D This is a follow-up of the discussion here:=0D https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/= =0D =0D and here:=0D https://lore.kernel.org/all/20210914093515.260031-1-maxime@cerno.tech/=0D =0D While the initial proposal implemented a new API to temporarily raise and l= ower=0D clock rates based on consumer workloads, Stephen suggested an=0D alternative approach implemented here.=0D =0D The main issue that needed to be addressed in our case was that in a=0D situation where we would have multiple calls to clk_set_rate_range, we=0D would end up with a clock at the maximum of the minimums being set. This=0D would be expected, but the issue was that if one of the users was to=0D relax or drop its requirements, the rate would be left unchanged, even=0D though the ideal rate would have changed.=0D =0D So something like=0D =0D clk_set_rate(user1_clk, 1000);=0D clk_set_min_rate(user1_clk, 2000);=0D clk_set_min_rate(user2_clk, 3000);=0D clk_set_min_rate(user2_clk, 1000);=0D =0D Would leave the clock running at 3000Hz, while the minimum would now be=0D 2000Hz.=0D =0D This was mostly due to the fact that the core only triggers a rate=0D change in clk_set_rate_range() if the current rate is outside of the=0D boundaries, but not if it's within the new boundaries.=0D =0D That series changes that and will trigger a rate change on every call,=0D with the former rate being tried again. This way, providers have a=0D chance to follow whatever policy they see fit for a given clock each=0D time the boundaries change.=0D =0D This series also implements some kunit tests, first to test a few rate=0D related functions in the CCF, and then extends it to make sure that=0D behaviour has some test coverage.=0D =0D Let me know what you think=0D Maxime=0D =0D Changes from v2:=0D - Rebased on current next=0D - Rewrote the whole thing according to Stephen reviews=0D - Implemented some kunit tests=0D =0D Changes from v1:=0D - Return NULL in clk_request_start if clk pointer is NULL=0D - Test for clk_req pointer in clk_request_done=0D - Add another user in vc4=0D - Rebased on top of v5.15-rc1=0D =0D Maxime Ripard (10):=0D clk: Add Kunit tests for rate=0D clk: Always clamp the rounded rate=0D clk: Use clamp instead of open-coding our own=0D clk: Always set the rate on clk_set_range_rate=0D clk: Add clk_drop_range=0D clk: bcm: rpi: Add variant structure=0D clk: bcm: rpi: Set a default minimum rate=0D clk: bcm: rpi: Run some clocks at the minimum rate allowed=0D drm/vc4: Add logging and comments=0D drm/vc4: hdmi: Remove clock rate initialization=0D =0D drivers/clk/Kconfig | 7 +=0D drivers/clk/Makefile | 1 +=0D drivers/clk/bcm/clk-raspberrypi.c | 125 ++++++-=0D drivers/clk/clk-rate-test.c | 603 ++++++++++++++++++++++++++++++=0D drivers/clk/clk.c | 51 ++-=0D drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -=0D drivers/gpu/drm/vc4/vc4_kms.c | 11 +=0D include/linux/clk.h | 11 +=0D 8 files changed, 767 insertions(+), 55 deletions(-)=0D create mode 100644 drivers/clk/clk-rate-test.c=0D =0D -- =0D 2.34.1=0D =0D 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 A9424C4332F for ; Thu, 20 Jan 2022 14:34:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8CE2189F49; Thu, 20 Jan 2022 14:34:25 +0000 (UTC) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2B06789F49 for ; Thu, 20 Jan 2022 14:34:23 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2E9453200F72; Thu, 20 Jan 2022 09:34:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 20 Jan 2022 09:34:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; bh=obwHIxOpczJ8YsM5Ary7YpyYT6D7lDEJcwV9qL rQ5NM=; b=JeF8G4zjiflLS4wrYaUJIOudSNuahhfb7wKxV00lDufkZFA9Mq/ycd Q8/iMwbLhnzM/ohp5ZW0H2F7AP2NdTYV6dq3lRiXP9yd8pozzjdLRv2lR+ss/SYq fDz/v47Lmm0+S16rMSNjauXguCwGVaBHBQyQk76e7KfqmND6kNYIbecHyyhCA0aP NrFqYRin4Pz25hAhs7Lsg+K9YqFURYjA2RtzLxNJLzDZjX7VmILYXZCZiYnuQPao vamX6gxFu5x4fp3l7olJFl05Y0GsFvhA4rgh9JqlZ43ykx168nwo6kncn49Yv0Ts b+CHeFAxd5fQbCmqCkzXX9CbnuPCwbhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:message-id :mime-version: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=obwHIx OpczJ8YsM5Ary7YpyYT6D7lDEJcwV9qLrQ5NM=; b=QFRCSveXpG5VbiasnluYNy HeZIFbbLpUNrqNhufGrln54yVzS938P6HRPW0aua5IhA7y+fAcev7xkWi0qiNV6N VakDpm821ypW2IpYRJOti4vrbaDJb0sJOZ3+a6zDpsnI1LTq5nkf6R76wBYfs9t2 0xg6iJa2+xNADEED2KFPiWM+uCY97IK5tCZmpbYFhv1XxbXJB3CZmCZq1O6OJjXN XU626mIn8WlxuBe8QIpoEoVDKmIsEyrGh5J3bIU9G+0296mNsqqCIe5Uo1CHQpfV 8botUu3zFrJbwJZIpWdcq3TeR80C0QEzBOXEa7TQe71YiQDRaa8hSfNY1giKO77Q == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgtggfgsehtqhertdertdejnecuhfhrohhmpeforgigihhmvgcu tfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrthhtvg hrnhepteetledtudejhffftdeugfduffelleelheejgeegffduvddvgfdvhffhlefgteff necuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jan 2022 09:34:19 -0500 (EST) From: Maxime Ripard To: Mike Turquette , Stephen Boyd Subject: [PATCH v3 00/10] clk: Improve clock range handling Date: Thu, 20 Jan 2022 15:34:07 +0100 Message-Id: <20220120143417.543744-1-maxime@cerno.tech> X-Mailer: git-send-email 2.34.1 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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" Hi,=0D =0D This is a follow-up of the discussion here:=0D https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/= =0D =0D and here:=0D https://lore.kernel.org/all/20210914093515.260031-1-maxime@cerno.tech/=0D =0D While the initial proposal implemented a new API to temporarily raise and l= ower=0D clock rates based on consumer workloads, Stephen suggested an=0D alternative approach implemented here.=0D =0D The main issue that needed to be addressed in our case was that in a=0D situation where we would have multiple calls to clk_set_rate_range, we=0D would end up with a clock at the maximum of the minimums being set. This=0D would be expected, but the issue was that if one of the users was to=0D relax or drop its requirements, the rate would be left unchanged, even=0D though the ideal rate would have changed.=0D =0D So something like=0D =0D clk_set_rate(user1_clk, 1000);=0D clk_set_min_rate(user1_clk, 2000);=0D clk_set_min_rate(user2_clk, 3000);=0D clk_set_min_rate(user2_clk, 1000);=0D =0D Would leave the clock running at 3000Hz, while the minimum would now be=0D 2000Hz.=0D =0D This was mostly due to the fact that the core only triggers a rate=0D change in clk_set_rate_range() if the current rate is outside of the=0D boundaries, but not if it's within the new boundaries.=0D =0D That series changes that and will trigger a rate change on every call,=0D with the former rate being tried again. This way, providers have a=0D chance to follow whatever policy they see fit for a given clock each=0D time the boundaries change.=0D =0D This series also implements some kunit tests, first to test a few rate=0D related functions in the CCF, and then extends it to make sure that=0D behaviour has some test coverage.=0D =0D Let me know what you think=0D Maxime=0D =0D Changes from v2:=0D - Rebased on current next=0D - Rewrote the whole thing according to Stephen reviews=0D - Implemented some kunit tests=0D =0D Changes from v1:=0D - Return NULL in clk_request_start if clk pointer is NULL=0D - Test for clk_req pointer in clk_request_done=0D - Add another user in vc4=0D - Rebased on top of v5.15-rc1=0D =0D Maxime Ripard (10):=0D clk: Add Kunit tests for rate=0D clk: Always clamp the rounded rate=0D clk: Use clamp instead of open-coding our own=0D clk: Always set the rate on clk_set_range_rate=0D clk: Add clk_drop_range=0D clk: bcm: rpi: Add variant structure=0D clk: bcm: rpi: Set a default minimum rate=0D clk: bcm: rpi: Run some clocks at the minimum rate allowed=0D drm/vc4: Add logging and comments=0D drm/vc4: hdmi: Remove clock rate initialization=0D =0D drivers/clk/Kconfig | 7 +=0D drivers/clk/Makefile | 1 +=0D drivers/clk/bcm/clk-raspberrypi.c | 125 ++++++-=0D drivers/clk/clk-rate-test.c | 603 ++++++++++++++++++++++++++++++=0D drivers/clk/clk.c | 51 ++-=0D drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -=0D drivers/gpu/drm/vc4/vc4_kms.c | 11 +=0D include/linux/clk.h | 11 +=0D 8 files changed, 767 insertions(+), 55 deletions(-)=0D create mode 100644 drivers/clk/clk-rate-test.c=0D =0D -- =0D 2.34.1=0D =0D