From patchwork Tue Jan 25 14:15:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Ripard X-Patchwork-Id: 12723856 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 955C0C433FE for ; Tue, 25 Jan 2022 14:19:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1578185AbiAYOSt (ORCPT ); Tue, 25 Jan 2022 09:18:49 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:56341 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1451519AbiAYOP6 (ORCPT ); Tue, 25 Jan 2022 09:15:58 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 02AA95C0151; Tue, 25 Jan 2022 09:15:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 25 Jan 2022 09:15:53 -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=GThzqVct1ecqk2q3drmmDLq6ji2AfvsEb9Eaew 0Hd70=; b=XET9TqPDlbHkrowxZFiWAt1ARfjUpEGmhqDNhA9Dclc7ARx/ToOF+7 OZg3jr5hPrq9CYruqewlZMREF3+iEiQOxkdA04zgFBJetJGCvgsfISdF4oHB+rh7 IamXmfnyBtsOPa22pvy2RoLrCm/5yFaE7+aK7RMMlmQLF80W08MykMqUA8V9y2I7 feWide97BmFihS5tUfhuKwFCsHS2UmJNbpjjxtXP9L5ZnADDJHgbNAtMqqNoXNu/ BPd5fixw6G5gF+JSObb6I4ehma3g7qXJxLqb+PTKxaMiRPfr6nzfao/BPmFKf+DN NrsOsRnW0dD2+MmxlOLg4QzrTnQB5ktw== 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=GThzqV ct1ecqk2q3drmmDLq6ji2AfvsEb9Eaew0Hd70=; b=HK3sN0RVIvcuJsN9etslcn tq6c0+13RqqUh8ppcj0FQW2GIe7CkNWyzhMLSxmfdJdG+3ToKUSTjeN0WLr78OlK L7vZFIYpqUDwfaGd+5ayf1fat5aI9qnsGXg/kMSrgr8+x6n5KbpVbB06+G5DV/Y5 338itNvpMzg3VQMi5AgLLGdzPzPU5DQgiTPjD1e5E9myD+S+Z4/PYZ1aHoZ2Z66Y qPDKH9OjpSP/Pi77gjCPHayqP+s1Pr1AhS2ajS3CQTHPELX7gnnX/wYKvu2At6zN buDoX6zlcsuU84elDOCA2xaayPpVmdV9LA9dDWaljZGy/y0ct3wDOdC+XWfFkldw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdelgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgtggfgsehtqhertdertdejnecuhfhrohhmpeforgigihhmvgcu tfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrthhtvg hrnhepteetledtudejhffftdeugfduffelleelheejgeegffduvddvgfdvhffhlefgteff necuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Jan 2022 09:15:51 -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 v4 00/10] clk: Improve clock range handling Date: Tue, 25 Jan 2022 15:15:39 +0100 Message-Id: <20220125141549.747889-1-maxime@cerno.tech> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ and here: https://lore.kernel.org/all/20210914093515.260031-1-maxime@cerno.tech/ While the initial proposal implemented a new API to temporarily raise and lower clock rates based on consumer workloads, Stephen suggested an alternative approach implemented here. The main issue that needed to be addressed in our case was that in a situation where we would have multiple calls to clk_set_rate_range, we would end up with a clock at the maximum of the minimums being set. This would be expected, but the issue was that if one of the users was to relax or drop its requirements, the rate would be left unchanged, even though the ideal rate would have changed. So something like clk_set_rate(user1_clk, 1000); clk_set_min_rate(user1_clk, 2000); clk_set_min_rate(user2_clk, 3000); clk_set_min_rate(user2_clk, 1000); Would leave the clock running at 3000Hz, while the minimum would now be 2000Hz. This was mostly due to the fact that the core only triggers a rate change in clk_set_rate_range() if the current rate is outside of the boundaries, but not if it's within the new boundaries. That series changes that and will trigger a rate change on every call, with the former rate being tried again. This way, providers have a chance to follow whatever policy they see fit for a given clock each time the boundaries change. This series also implements some kunit tests, first to test a few rate related functions in the CCF, and then extends it to make sure that behaviour has some test coverage. Let me know what you think Maxime Changes from v3: - Renamed the test file and Kconfig option - Add option to .kunitconfig - Switch to kunit_kzalloc - Use KUNIT_EXPECT_* instead of KUNIT_ASSERT_* where relevant - Test directly relevant calls instead of going through a temporary variable - Switch to more precise KUNIT_ASSERT_* macros where relevant Changes from v2: - Rebased on current next - Rewrote the whole thing according to Stephen reviews - Implemented some kunit tests Changes from v1: - Return NULL in clk_request_start if clk pointer is NULL - Test for clk_req pointer in clk_request_done - Add another user in vc4 - Rebased on top of v5.15-rc1 Maxime Ripard (10): clk: Introduce Kunit Tests for the framework clk: Always clamp the rounded rate clk: Use clamp instead of open-coding our own clk: Always set the rate on clk_set_range_rate clk: Add clk_drop_range clk: bcm: rpi: Add variant structure clk: bcm: rpi: Set a default minimum rate clk: bcm: rpi: Run some clocks at the minimum rate allowed drm/vc4: Add logging and comments drm/vc4: hdmi: Remove clock rate initialization drivers/clk/.kunitconfig | 1 + drivers/clk/Kconfig | 7 + drivers/clk/Makefile | 1 + drivers/clk/bcm/clk-raspberrypi.c | 125 +++++- drivers/clk/clk-test.c | 621 ++++++++++++++++++++++++++++++ drivers/clk/clk.c | 51 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 13 - drivers/gpu/drm/vc4/vc4_kms.c | 11 + include/linux/clk.h | 11 + 9 files changed, 786 insertions(+), 55 deletions(-) create mode 100644 drivers/clk/clk-test.c