From: Maxime Ripard <maxime@cerno.tech>
To: Mike Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>,
Phil Elwell <phil@raspberrypi.com>,
Tim Gover <tim.gover@raspberrypi.com>,
Dom Cobley <dom@raspberrypi.com>,
dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org,
Maxime Ripard <maxime@cerno.tech>
Subject: [PATCH v7 00/12] clk: Improve clock range handling
Date: Fri, 25 Feb 2022 15:35:22 +0100 [thread overview]
Message-ID: <20220225143534.405820-1-maxime@cerno.tech> (raw)
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 v6:
- Removed unused header
- Used more fitting KUNIT macros
- Enhanced some comments
- Reworded a commit message
Changes from v5:
- Changed clk_hw_create_clk for clk_hw_get_clk since the former isn't
exported to modules.
- Added fix for clk_hw_get_clk
Changes from v4:
- Rename the test file
- Move all the tests to the first patch, and fix them up as fixes are done
- Improved the test conditions
- Added more tests
- Improved commit messages
- Fixed a regression where two disjoints clock ranges would now be accepted
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 (12):
clk: Fix clk_hw_get_clk() when dev is NULL
clk: Introduce Kunit Tests for the framework
clk: Enforce that disjoints limits are invalid
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.c | 76 ++-
drivers/clk/clk_test.c | 795 ++++++++++++++++++++++++++++++
drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -
drivers/gpu/drm/vc4/vc4_kms.c | 11 +
include/linux/clk.h | 11 +
9 files changed, 985 insertions(+), 55 deletions(-)
create mode 100644 drivers/clk/clk_test.c
--
2.35.1
next reply other threads:[~2022-02-25 14:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 14:35 Maxime Ripard [this message]
2022-02-25 14:35 ` [PATCH v7 01/12] clk: Fix clk_hw_get_clk() when dev is NULL Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 02/12] clk: Introduce Kunit Tests for the framework Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 03/12] clk: Enforce that disjoints limits are invalid Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 04/12] clk: Always clamp the rounded rate Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 05/12] clk: Use clamp instead of open-coding our own Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 06/12] clk: Always set the rate on clk_set_range_rate Maxime Ripard
2022-03-22 19:05 ` Dmitry Osipenko
2022-03-23 8:51 ` Maxime Ripard
2022-03-24 19:09 ` Stephen Boyd
2022-03-24 19:25 ` Dmitry Osipenko
2022-02-25 14:35 ` [PATCH v7 07/12] clk: Add clk_drop_range Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 08/12] clk: bcm: rpi: Add variant structure Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 09/12] clk: bcm: rpi: Set a default minimum rate Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 10/12] clk: bcm: rpi: Run some clocks at the minimum rate allowed Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 11/12] drm/vc4: Add logging and comments Maxime Ripard
2022-04-06 8:50 ` Thomas Zimmermann
2022-02-25 14:35 ` [PATCH v7 12/12] drm/vc4: hdmi: Remove clock rate initialization Maxime Ripard
2022-04-06 8:53 ` Thomas Zimmermann
2022-03-12 3:08 ` [PATCH v7 00/12] clk: Improve clock range handling Stephen Boyd
2022-03-16 8:37 ` Maxime Ripard
2022-04-06 10:42 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220225143534.405820-1-maxime@cerno.tech \
--to=maxime@cerno.tech \
--cc=dave.stevenson@raspberrypi.com \
--cc=dom@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=phil@raspberrypi.com \
--cc=sboyd@kernel.org \
--cc=tim.gover@raspberrypi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox