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 >
next prev parent 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: linkBe 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.