All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Mike Turquette <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Phil Elwell <phil@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dom Cobley <dom@raspberrypi.com>
Subject: Re: [PATCH v4 02/10] clk: Always clamp the rounded rate
Date: Mon, 21 Feb 2022 17:18:21 +0100	[thread overview]
Message-ID: <20220221161821.jbktbgx2t6aaxds3@houat> (raw)
In-Reply-To: <20220218231508.7B5FCC340E9@smtp.kernel.org>

[-- Attachment #1: Type: text/plain, Size: 4164 bytes --]

Hi,

On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-01-25 06:15:41)
> > The current core while setting the min and max rate properly in the
> > clk_request structure will not make sure that the requested rate is
> > within these boundaries, leaving it to each and every driver to make
> > sure it is.
> 
> It would be good to describe why. Or decide that it was an oversight and
> write that down here.
> 
> > Add a clamp call to make sure it's always done, and add a few unit tests
> > to make sure we don't have any regression there.
> 
> I looked through the per-user constraint patch history on the list but I
> couldn't really figure out why it was done this way. I guess we didn't
> clamp the rate in the core because we wanted to give the clk providers
> all the information, i.e. the rate that was requested and the boundaries
> that the consumers have placed on the rate.

I'm not really sure we should really leave it to the users, something like:

clk_set_range_rate(clk, 1000, 2000);
clk_set_rate(clk, 500);
clk_get_rate(clk) # == 500

Is definitely weird, and would break the least surprise :)

We shouldn't leave that to drivers, especially since close to none of
them handle this properly.

> With the round_rate() clk_op the providers don't know the min/max
> because the rate request structure isn't passed. I think my concern a
> long time ago was that a consumer could call clk_round_rate() and get
> one frequency and then call clk_set_rate() and get another frequency.

I'm not sure I follow you there.

The function affected is clk_core_determine_round_nolock(), which is
called by clk_core_round_rate_nolock() and clk_calc_new_rates(). In
turn, they will be part of clk(_hw_)_round_clock for the former, and
clk_core_set_rate_nolock() (and thus clk_set_rate()) for the latter.

I don't see how you can get a discrepancy between clk_round_rate() and
clk_set_rate().

And yeah, it's true that the round_rate op won't have the min and max
passed to them, but i'd consider this an argument for doing this check
here, since you don't have that option at all for those clocks.

> We need to make sure that round_rate and set_rate agree with each
> other. If we don't do that then we don't uphold the contract that
> clk_round_rate() tells the consumer what rate they'll get if they call
> clk_set_rate() with the same frequency.
> 
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> >  drivers/clk/clk-test.c | 46 ++++++++++++++++++++++++++++++++++++++++++
> >  drivers/clk/clk.c      |  2 ++
> >  2 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/clk/clk-test.c b/drivers/clk/clk-test.c
> > index 47a600d590c1..28c718ab82e1 100644
> > --- a/drivers/clk/clk-test.c
> > +++ b/drivers/clk/clk-test.c
> > @@ -203,6 +203,50 @@ static void clk_range_test_set_range_invalid(struct kunit *test)
> >                         0);
> >  }
> >  
> > +/*
> > + * Test that if our clock has some boundaries and we try to round a rate
> > + * lower than the minimum, the returned rate will be within range.
> > + */
> > +static void clk_range_test_set_range_round_rate_lower(struct kunit *test)
> > +{
> > +       struct clk_dummy_context *ctx = test->priv;
> > +       struct clk_hw *hw = &ctx->hw;
> > +       struct clk *clk = hw->clk;
> > +       long rate;
> > +
> > +       KUNIT_ASSERT_EQ(test,
> > +                       clk_set_rate_range(clk,
> > +                                          DUMMY_CLOCK_RATE_1,
> > +                                          DUMMY_CLOCK_RATE_2),
> > +                       0);
> > +
> > +       rate = clk_round_rate(clk, DUMMY_CLOCK_RATE_1 - 1000);
> > +       KUNIT_ASSERT_GT(test, rate, 0);
> > +       KUNIT_EXPECT_EQ(test, rate, DUMMY_CLOCK_RATE_1);
> 
> The comment says within range but this test says exactly the minimum
> rate. Please change it to test that the rate is within rate 1 and rate
> 2. Also, we should call clk_get_rate() here to make sure the rate is
> within the boundaries and matches what clk_round_rate() returned.

Ok

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Dom Cobley <dom@raspberrypi.com>,
	Tim Gover <tim.gover@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Mike Turquette <mturquette@baylibre.com>,
	dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org,
	Phil Elwell <phil@raspberrypi.com>
Subject: Re: [PATCH v4 02/10] clk: Always clamp the rounded rate
Date: Mon, 21 Feb 2022 17:18:21 +0100	[thread overview]
Message-ID: <20220221161821.jbktbgx2t6aaxds3@houat> (raw)
In-Reply-To: <20220218231508.7B5FCC340E9@smtp.kernel.org>

[-- Attachment #1: Type: text/plain, Size: 4164 bytes --]

Hi,

On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-01-25 06:15:41)
> > The current core while setting the min and max rate properly in the
> > clk_request structure will not make sure that the requested rate is
> > within these boundaries, leaving it to each and every driver to make
> > sure it is.
> 
> It would be good to describe why. Or decide that it was an oversight and
> write that down here.
> 
> > Add a clamp call to make sure it's always done, and add a few unit tests
> > to make sure we don't have any regression there.
> 
> I looked through the per-user constraint patch history on the list but I
> couldn't really figure out why it was done this way. I guess we didn't
> clamp the rate in the core because we wanted to give the clk providers
> all the information, i.e. the rate that was requested and the boundaries
> that the consumers have placed on the rate.

I'm not really sure we should really leave it to the users, something like:

clk_set_range_rate(clk, 1000, 2000);
clk_set_rate(clk, 500);
clk_get_rate(clk) # == 500

Is definitely weird, and would break the least surprise :)

We shouldn't leave that to drivers, especially since close to none of
them handle this properly.

> With the round_rate() clk_op the providers don't know the min/max
> because the rate request structure isn't passed. I think my concern a
> long time ago was that a consumer could call clk_round_rate() and get
> one frequency and then call clk_set_rate() and get another frequency.

I'm not sure I follow you there.

The function affected is clk_core_determine_round_nolock(), which is
called by clk_core_round_rate_nolock() and clk_calc_new_rates(). In
turn, they will be part of clk(_hw_)_round_clock for the former, and
clk_core_set_rate_nolock() (and thus clk_set_rate()) for the latter.

I don't see how you can get a discrepancy between clk_round_rate() and
clk_set_rate().

And yeah, it's true that the round_rate op won't have the min and max
passed to them, but i'd consider this an argument for doing this check
here, since you don't have that option at all for those clocks.

> We need to make sure that round_rate and set_rate agree with each
> other. If we don't do that then we don't uphold the contract that
> clk_round_rate() tells the consumer what rate they'll get if they call
> clk_set_rate() with the same frequency.
> 
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> >  drivers/clk/clk-test.c | 46 ++++++++++++++++++++++++++++++++++++++++++
> >  drivers/clk/clk.c      |  2 ++
> >  2 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/clk/clk-test.c b/drivers/clk/clk-test.c
> > index 47a600d590c1..28c718ab82e1 100644
> > --- a/drivers/clk/clk-test.c
> > +++ b/drivers/clk/clk-test.c
> > @@ -203,6 +203,50 @@ static void clk_range_test_set_range_invalid(struct kunit *test)
> >                         0);
> >  }
> >  
> > +/*
> > + * Test that if our clock has some boundaries and we try to round a rate
> > + * lower than the minimum, the returned rate will be within range.
> > + */
> > +static void clk_range_test_set_range_round_rate_lower(struct kunit *test)
> > +{
> > +       struct clk_dummy_context *ctx = test->priv;
> > +       struct clk_hw *hw = &ctx->hw;
> > +       struct clk *clk = hw->clk;
> > +       long rate;
> > +
> > +       KUNIT_ASSERT_EQ(test,
> > +                       clk_set_rate_range(clk,
> > +                                          DUMMY_CLOCK_RATE_1,
> > +                                          DUMMY_CLOCK_RATE_2),
> > +                       0);
> > +
> > +       rate = clk_round_rate(clk, DUMMY_CLOCK_RATE_1 - 1000);
> > +       KUNIT_ASSERT_GT(test, rate, 0);
> > +       KUNIT_EXPECT_EQ(test, rate, DUMMY_CLOCK_RATE_1);
> 
> The comment says within range but this test says exactly the minimum
> rate. Please change it to test that the rate is within rate 1 and rate
> 2. Also, we should call clk_get_rate() here to make sure the rate is
> within the boundaries and matches what clk_round_rate() returned.

Ok

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2022-02-21 16:18 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 14:15 [PATCH v4 00/10] clk: Improve clock range handling Maxime Ripard
2022-01-25 14:15 ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 01/10] clk: Introduce Kunit Tests for the framework Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-02-19  2:20   ` Stephen Boyd
2022-02-19  2:20     ` Stephen Boyd
2022-02-21 15:12     ` Maxime Ripard
2022-02-21 15:12       ` Maxime Ripard
2022-02-24 22:30       ` Stephen Boyd
2022-02-24 22:30         ` Stephen Boyd
2022-01-25 14:15 ` [PATCH v4 02/10] clk: Always clamp the rounded rate Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-02-18 23:15   ` Stephen Boyd
2022-02-18 23:15     ` Stephen Boyd
2022-02-21 16:18     ` Maxime Ripard [this message]
2022-02-21 16:18       ` Maxime Ripard
2022-02-21 16:43       ` Maxime Ripard
2022-02-21 16:43         ` Maxime Ripard
2022-02-24 22:39         ` Stephen Boyd
2022-02-24 22:39           ` Stephen Boyd
2022-02-25  9:35           ` Maxime Ripard
2022-02-25  9:35             ` Maxime Ripard
2022-02-24 22:32       ` Stephen Boyd
2022-02-24 22:32         ` Stephen Boyd
2022-02-25  9:45         ` Maxime Ripard
2022-02-25  9:45           ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 03/10] clk: Use clamp instead of open-coding our own Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-02-18 22:34   ` Stephen Boyd
2022-02-18 22:34     ` Stephen Boyd
2022-02-21 16:30     ` Maxime Ripard
2022-02-21 16:30       ` Maxime Ripard
2022-02-24 22:44       ` Stephen Boyd
2022-02-24 22:44         ` Stephen Boyd
2022-02-25  9:39         ` Maxime Ripard
2022-02-25  9:39           ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 04/10] clk: Always set the rate on clk_set_range_rate Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 05/10] clk: Add clk_drop_range Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-02-19  2:22   ` Stephen Boyd
2022-02-19  2:22     ` Stephen Boyd
2022-01-25 14:15 ` [PATCH v4 06/10] clk: bcm: rpi: Add variant structure Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 07/10] clk: bcm: rpi: Set a default minimum rate Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 08/10] clk: bcm: rpi: Run some clocks at the minimum rate allowed Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 09/10] drm/vc4: Add logging and comments Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-01-25 14:15 ` [PATCH v4 10/10] drm/vc4: hdmi: Remove clock rate initialization Maxime Ripard
2022-01-25 14:15   ` Maxime Ripard
2022-02-10 10:19 ` [PATCH v4 00/10] clk: Improve clock range handling Maxime Ripard
2022-02-10 10:19   ` Maxime Ripard
2022-02-19  2:25   ` Stephen Boyd
2022-02-19  2:25     ` Stephen Boyd
2022-02-14  9:45 ` [PATCH v4 0/10] " Laurent Pinchart
2022-02-14  9:45   ` Laurent Pinchart
2022-02-19  2:24   ` Stephen Boyd
2022-02-19  2:24     ` Stephen Boyd
2022-02-21  9:56     ` Laurent Pinchart
2022-02-21  9:56       ` Laurent Pinchart

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=20220221161821.jbktbgx2t6aaxds3@houat \
    --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.