All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Mike Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>
Cc: Dom Cobley <dom@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	dri-devel@lists.freedesktop.org,
	Phil Elwell <phil@raspberrypi.com>,
	Maxime Ripard <maxime@cerno.tech>,
	linux-clk@vger.kernel.org
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


             reply	other threads:[~2022-02-25 14:35 UTC|newest]

Thread overview: 44+ 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 00/12] clk: Improve clock range handling Maxime Ripard
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   ` 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   ` 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   ` Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 04/12] clk: Always clamp the rounded rate Maxime Ripard
2022-02-25 14:35   ` 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   ` Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 06/12] clk: Always set the rate on clk_set_range_rate Maxime Ripard
2022-02-25 14:35   ` Maxime Ripard
2022-03-22 19:05   ` Dmitry Osipenko
2022-03-22 19:05     ` Dmitry Osipenko
2022-03-23  8:51     ` Maxime Ripard
2022-03-23  8:51       ` Maxime Ripard
2022-03-24 19:09       ` Stephen Boyd
2022-03-24 19:09         ` Stephen Boyd
2022-03-24 19:25       ` Dmitry Osipenko
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   ` Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 08/12] clk: bcm: rpi: Add variant structure Maxime Ripard
2022-02-25 14:35   ` 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   ` 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   ` Maxime Ripard
2022-02-25 14:35 ` [PATCH v7 11/12] drm/vc4: Add logging and comments Maxime Ripard
2022-02-25 14:35   ` Maxime Ripard
2022-04-06  8:50   ` Thomas Zimmermann
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-02-25 14:35   ` Maxime Ripard
2022-04-06  8:53   ` Thomas Zimmermann
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-12  3:08   ` Stephen Boyd
2022-03-16  8:37   ` Maxime Ripard
2022-03-16  8:37     ` Maxime Ripard
2022-04-06 10:42 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.