All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Turquette <mturquette@baylibre.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"Kevin Hilman" <khilman@baylibre.com>
Cc: "Jerome Brunet" <jbrunet@baylibre.com>,
	linux-clk@vger.kernel.org, linux-amlogic@lists.infradead.org,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Boris Brezillon" <boris.brezillon@free-electrons.com>
Subject: Re: [PATCH v2 04/11] clk: use round rate to bail out early in set_rate
Date: Thu, 25 May 2017 13:20:50 -0700	[thread overview]
Message-ID: <149574365034.52617.9521289317050513324@resonance> (raw)
In-Reply-To: <20170521215958.19743-5-jbrunet@baylibre.com>

Quoting Jerome Brunet (2017-05-21 14:59:51)
> The current implementation of clk_core_set_rate_nolock bails out early if
> the requested rate is exactly the same as the one set. It should bail out
> if the request would not result in rate a change.  This important when ra=
te
> is not exactly what is requested, which is fairly common with PLLs.
> =

> Ex: provider able to give any rate with steps of 100Hz
>  - 1st consumer request 48000Hz and gets it.
>  - 2nd consumer request 48010Hz as well. If we were to perform the usual
>    mechanism, we would get 48000Hz as well. The clock would not change so
>    there is no point performing any checks to make sure the clock can
>    change, we know it won't.
> =

> This is important to prepare the addition of the clock protection mechani=
sm

Why is this change necessary for the rate_protect feature? I don't see a
major problem with it, but not sure I want to change the expected
behavior unless it is required.

Thanks,
Mike

> =

> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
>  drivers/clk/clk.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> =

> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 100f72472e10..1a8c0d013238 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1570,15 +1570,34 @@ static void clk_change_rate(struct clk_core *core)
>                 clk_change_rate(core->new_child);
>  }
>  =

> +static unsigned long clk_core_req_round_rate_nolock(struct clk_core *cor=
e,
> +                                                    unsigned long req_ra=
te)
> +{
> +       int ret;
> +       struct clk_rate_request req;
> +
> +       if (!core)
> +               return 0;
> +
> +       clk_core_get_boundaries(core, &req.min_rate, &req.max_rate);
> +       req.rate =3D req_rate;
> +
> +       ret =3D clk_core_round_rate_nolock(core, &req);
> +
> +       return ret ? 0 : req.rate;
> +}
> +
>  static int clk_core_set_rate_nolock(struct clk_core *core,
>                                     unsigned long req_rate)
>  {
>         struct clk_core *top, *fail_clk;
> -       unsigned long rate =3D req_rate;
> +       unsigned long rate;
>  =

>         if (!core)
>                 return 0;
>  =

> +       rate =3D clk_core_req_round_rate_nolock(core, req_rate);
> +
>         /* bail early if nothing to do */
>         if (rate =3D=3D clk_core_get_rate_nolock(core))
>                 return 0;
> @@ -1587,7 +1606,7 @@ static int clk_core_set_rate_nolock(struct clk_core=
 *core,
>                 return -EBUSY;
>  =

>         /* calculate new rates and get the topmost changed clock */
> -       top =3D clk_calc_new_rates(core, rate);
> +       top =3D clk_calc_new_rates(core, req_rate);
>         if (!top)
>                 return -EINVAL;
>  =

> -- =

> 2.9.4
>=20

WARNING: multiple messages have this Message-ID (diff)
From: mturquette@baylibre.com (Michael Turquette)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH v2 04/11] clk: use round rate to bail out early in set_rate
Date: Thu, 25 May 2017 13:20:50 -0700	[thread overview]
Message-ID: <149574365034.52617.9521289317050513324@resonance> (raw)
In-Reply-To: <20170521215958.19743-5-jbrunet@baylibre.com>

Quoting Jerome Brunet (2017-05-21 14:59:51)
> The current implementation of clk_core_set_rate_nolock bails out early if
> the requested rate is exactly the same as the one set. It should bail out
> if the request would not result in rate a change.  This important when rate
> is not exactly what is requested, which is fairly common with PLLs.
> 
> Ex: provider able to give any rate with steps of 100Hz
>  - 1st consumer request 48000Hz and gets it.
>  - 2nd consumer request 48010Hz as well. If we were to perform the usual
>    mechanism, we would get 48000Hz as well. The clock would not change so
>    there is no point performing any checks to make sure the clock can
>    change, we know it won't.
> 
> This is important to prepare the addition of the clock protection mechanism

Why is this change necessary for the rate_protect feature? I don't see a
major problem with it, but not sure I want to change the expected
behavior unless it is required.

Thanks,
Mike

> 
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
>  drivers/clk/clk.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 100f72472e10..1a8c0d013238 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1570,15 +1570,34 @@ static void clk_change_rate(struct clk_core *core)
>                 clk_change_rate(core->new_child);
>  }
>  
> +static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core,
> +                                                    unsigned long req_rate)
> +{
> +       int ret;
> +       struct clk_rate_request req;
> +
> +       if (!core)
> +               return 0;
> +
> +       clk_core_get_boundaries(core, &req.min_rate, &req.max_rate);
> +       req.rate = req_rate;
> +
> +       ret = clk_core_round_rate_nolock(core, &req);
> +
> +       return ret ? 0 : req.rate;
> +}
> +
>  static int clk_core_set_rate_nolock(struct clk_core *core,
>                                     unsigned long req_rate)
>  {
>         struct clk_core *top, *fail_clk;
> -       unsigned long rate = req_rate;
> +       unsigned long rate;
>  
>         if (!core)
>                 return 0;
>  
> +       rate = clk_core_req_round_rate_nolock(core, req_rate);
> +
>         /* bail early if nothing to do */
>         if (rate == clk_core_get_rate_nolock(core))
>                 return 0;
> @@ -1587,7 +1606,7 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
>                 return -EBUSY;
>  
>         /* calculate new rates and get the topmost changed clock */
> -       top = clk_calc_new_rates(core, rate);
> +       top = clk_calc_new_rates(core, req_rate);
>         if (!top)
>                 return -EINVAL;
>  
> -- 
> 2.9.4
> 

  reply	other threads:[~2017-05-25 20:20 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-21 21:59 [PATCH v2 00/11] clk: implement clock rate protection mechanism Jerome Brunet
2017-05-21 21:59 ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 01/11] clk: take the prepare lock out of clk_core_set_parent Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-25 18:54   ` Michael Turquette
2017-05-25 18:54     ` Michael Turquette
2017-05-29  9:35     ` Jerome Brunet
2017-05-29  9:35       ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 02/11] clk: add clk_core_set_phase_nolock function Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-23  9:35   ` Adriana Reus
2017-05-23  9:35     ` Adriana Reus
2017-05-23  9:48     ` Jerome Brunet
2017-05-23  9:48       ` Jerome Brunet
2017-05-25 18:58       ` Michael Turquette
2017-05-25 18:58         ` Michael Turquette
2017-05-21 21:59 ` [PATCH v2 03/11] clk: rework calls to round and determine rate callbacks Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-25 20:13   ` Michael Turquette
2017-05-25 20:13     ` Michael Turquette
2017-05-21 21:59 ` [PATCH v2 04/11] clk: use round rate to bail out early in set_rate Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-25 20:20   ` Michael Turquette [this message]
2017-05-25 20:20     ` Michael Turquette
2017-05-29  9:12     ` Jerome Brunet
2017-05-29  9:12       ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 05/11] clk: add support for clock protection Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-25 20:58   ` Michael Turquette
2017-05-25 20:58     ` Michael Turquette
2017-05-29  9:15     ` Jerome Brunet
2017-05-29  9:15       ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 06/11] clk: add clk_set_rate_protect Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 07/11] clk: rollback set_rate_range changes on failure Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 08/11] clk: cosmetic changes to clk_summary debugfs entry Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 09/11] clk: fix incorrect usage of ENOSYS Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 10/11] clk: fix CLK_SET_RATE_GATE with clock rate protection Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-23 13:42   ` Adriana Reus
2017-05-23 13:42     ` Adriana Reus
2017-05-23 15:09     ` Jerome Brunet
2017-05-23 15:09       ` Jerome Brunet
2017-05-21 21:59 ` [PATCH v2 11/11] clk: move CLK_SET_RATE_GATE protection from prepare to enable Jerome Brunet
2017-05-21 21:59   ` Jerome Brunet
2017-05-29  9:17   ` Jerome Brunet
2017-05-29  9:17     ` Jerome Brunet

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=149574365034.52617.9521289317050513324@resonance \
    --to=mturquette@baylibre.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=sboyd@codeaurora.org \
    /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.