All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Brunet <jbrunet@baylibre.com>
To: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Kevin Hilman <khilman@baylibre.com>
Cc: 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: Mon, 29 May 2017 11:12:53 +0200	[thread overview]
Message-ID: <1496049173.7514.2.camel@baylibre.com> (raw)
In-Reply-To: <149574365034.52617.9521289317050513324@resonance>

On Thu, 2017-05-25 at 13:20 -0700, Michael Turquette wrote:
> 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.

It isn't strictly required for the clock protection to work but it allows the
consumer to get a coherent feedback from set_rate.

Without this, we may end up in a situation where the set_rate return with -EBUSY
while the rate of the clock is actually the best possible we could have wished
for (like in the example: we ask for 48010 and the rate set in 48000)

With this patch, If a consumer gets EBUSY, it knows the rate set is not optimal.
It could have been closer to what is requested if it wasn't busy doing something
else.

If the rate is (already) optimally set, as requested by the consumer, I think we
should not return an error here.

I don't think this changes the behavior of the function, the rate set will be
same anyway, it just won't return an error in a particular case.

If you firmly oppose this idea, I suppose It can be dropped but I think it could
be a valuable addition.

> 
> 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
> > 

WARNING: multiple messages have this Message-ID (diff)
From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH v2 04/11] clk: use round rate to bail out early in set_rate
Date: Mon, 29 May 2017 11:12:53 +0200	[thread overview]
Message-ID: <1496049173.7514.2.camel@baylibre.com> (raw)
In-Reply-To: <149574365034.52617.9521289317050513324@resonance>

On Thu, 2017-05-25 at 13:20 -0700, Michael Turquette wrote:
> 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.

It isn't strictly required for the clock protection to work but it allows the
consumer to get a coherent feedback from set_rate.

Without this, we may end up in a situation where the set_rate return with -EBUSY
while the rate of the clock is actually the best possible we could have wished
for (like in the example: we ask for 48010 and the rate set in 48000)

With this patch, If a consumer gets EBUSY, it knows the rate set is not optimal.
It could have been closer to what is requested if it wasn't busy doing something
else.

If the rate is (already) optimally set, as requested by the consumer, I think we
should not return an error here.

I don't think this changes the behavior of the function, the rate set will be
same anyway, it just won't return an error in a particular case.

If you firmly oppose this idea, I suppose It can be dropped but I think it could
be a valuable addition.

> 
> 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-29  9:12 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
2017-05-25 20:20     ` Michael Turquette
2017-05-29  9:12     ` Jerome Brunet [this message]
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=1496049173.7514.2.camel@baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=khilman@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --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.