diff for duplicates of <1501089183.2401.28.camel@baylibre.com> diff --git a/a/1.txt b/N1/1.txt index 506b0ca..33e9102 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,7 +5,7 @@ On Tue, 2017-07-11 at 19:00 -0700, Stephen Boyd wrote: > Add () to functions please. > > > 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 +> > if the request would not result in rate a change. This important when > > s/in rate a change/in a rate change/ > s/This important/This is important/ @@ -16,11 +16,11 @@ On Tue, 2017-07-11 at 19:00 -0700, Stephen Boyd wrote: > > > > > 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. +> > - 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. > > I think Peter reported a similar problem as to what you're > describing. Can you further explain a problem situation that this @@ -32,7 +32,7 @@ On Tue, 2017-07-11 at 19:00 -0700, Stephen Boyd wrote: I had not seen the thread you referring to. I assume Peter is Peter De Schrijver and the thread is: -http://lkml.kernel.org/r/1490103807-21821-1-git-send-email-pdeschrijver at nvidia.c +http://lkml.kernel.org/r/1490103807-21821-1-git-send-email-pdeschrijver@nvidia.c om Peter is right, There is indeed a problem when the current rate is out of the @@ -87,19 +87,19 @@ discuss this in another thread. > > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > > --- -> > ?drivers/clk/clk.c | 23 +++++++++++++++++++++-- -> > ?1 file changed, 21 insertions(+), 2 deletions(-) +> > 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 8cc4672414be..163cb9832f10 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); -> > ?} -> > ? +> > clk_change_rate(core->new_child); +> > } +> > > > +static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core, -> > + ?????unsigned long +> > + unsigned long > > req_rate) > > +{ > > + int ret; @@ -120,7 +120,7 @@ pointer. Even when it is not strictly necessary, I think we should be consistent In the unlikely event this function is used some place else, it would avoid bad surprise -So?if it is OK with you, I would prefer to keep this check and add the check of +So if it is OK with you, I would prefer to keep this check and add the check of the prepare lock. Maybe I could go over the other "_nolock" functions in clk.c to verify they are all doing it ? What do you think ? @@ -136,7 +136,7 @@ to verify they are all doing it ? What do you think ? Here we are trying to return a rate, so unsigned long. I think (and I remember discussing it with Mike sometimes ago) that a 0 clock -rate quite often represent an error.? +rate quite often represent an error. > We should bail the set rate diff --git a/a/content_digest b/N1/content_digest index 49646ac..dd530ea 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,10 +1,18 @@ "ref\020170612194438.12298-1-jbrunet@baylibre.com\0" "ref\020170612194438.12298-5-jbrunet@baylibre.com\0" "ref\020170712020041.GU22780@codeaurora.org\0" - "From\0jbrunet@baylibre.com (Jerome Brunet)\0" - "Subject\0[PATCH v3 04/10] clk: use round rate to bail out early in set_rate\0" + "From\0Jerome Brunet <jbrunet@baylibre.com>\0" + "Subject\0Re: [PATCH v3 04/10] clk: use round rate to bail out early in set_rate\0" "Date\0Wed, 26 Jul 2017 19:13:03 +0200\0" - "To\0linus-amlogic@lists.infradead.org\0" + "To\0Stephen Boyd <sboyd@codeaurora.org>" + " Peter De Schrijver <pdeschrijver@nvidia.com>\0" + "Cc\0Michael Turquette <mturquette@baylibre.com>" + linux-clk@vger.kernel.org + Kevin Hilman <khilman@baylibre.com> + linux-amlogic@lists.infradead.org + Russell King <linux@armlinux.org.uk> + Linus Walleij <linus.walleij@linaro.org> + " Boris Brezillon <boris.brezillon@free-electrons.com>\0" "\00:1\0" "b\0" "On Tue, 2017-07-11 at 19:00 -0700, Stephen Boyd wrote:\n" @@ -14,7 +22,7 @@ "> Add () to functions please.\n" "> \n" "> > the requested rate is exactly the same as the one set. It should bail out\n" - "> > if the request would not result in rate a change.??This important when\n" + "> > if the request would not result in rate a change.\302\240\302\240This important when\n" "> \n" "> s/in rate a change/in a rate change/\n" "> s/This important/This is important/\n" @@ -25,11 +33,11 @@ "> \n" "> > \n" "> > Ex: provider able to give any rate with steps of 100Hz\n" - "> > ?- 1st consumer request 48000Hz and gets it.\n" - "> > ?- 2nd consumer request 48010Hz as well. If we were to perform the usual\n" - "> > ???mechanism, we would get 48000Hz as well. The clock would not change so\n" - "> > ???there is no point performing any checks to make sure the clock can\n" - "> > ???change, we know it won't.\n" + "> > \302\240- 1st consumer request 48000Hz and gets it.\n" + "> > \302\240- 2nd consumer request 48010Hz as well. If we were to perform the usual\n" + "> > \302\240\302\240\302\240mechanism, we would get 48000Hz as well. The clock would not change so\n" + "> > \302\240\302\240\302\240there is no point performing any checks to make sure the clock can\n" + "> > \302\240\302\240\302\240change, we know it won't.\n" "> \n" "> I think Peter reported a similar problem as to what you're\n" "> describing. Can you further explain a problem situation that this\n" @@ -41,7 +49,7 @@ "I had not seen the thread you referring to.\n" "I assume Peter is Peter De Schrijver and the thread is:\n" "\n" - "http://lkml.kernel.org/r/1490103807-21821-1-git-send-email-pdeschrijver at nvidia.c\n" + "http://lkml.kernel.org/r/1490103807-21821-1-git-send-email-pdeschrijver@nvidia.c\n" "om\n" "\n" "Peter is right, There is indeed a problem when the current rate is out of the\n" @@ -96,19 +104,19 @@ "> > \n" "> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>\n" "> > ---\n" - "> > ?drivers/clk/clk.c | 23 +++++++++++++++++++++--\n" - "> > ?1 file changed, 21 insertions(+), 2 deletions(-)\n" + "> > \302\240drivers/clk/clk.c | 23 +++++++++++++++++++++--\n" + "> > \302\2401 file changed, 21 insertions(+), 2 deletions(-)\n" "> > \n" "> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c\n" "> > index 8cc4672414be..163cb9832f10 100644\n" "> > --- a/drivers/clk/clk.c\n" "> > +++ b/drivers/clk/clk.c\n" "> > @@ -1570,15 +1570,34 @@ static void clk_change_rate(struct clk_core *core)\n" - "> > ?\t\tclk_change_rate(core->new_child);\n" - "> > ?}\n" - "> > ?\n" + "> > \302\240\t\tclk_change_rate(core->new_child);\n" + "> > \302\240}\n" + "> > \302\240\n" "> > +static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core,\n" - "> > +\t\t\t\t\t\t?????unsigned long\n" + "> > +\t\t\t\t\t\t\302\240\302\240\302\240\302\240\302\240unsigned long\n" "> > req_rate)\n" "> > +{\n" "> > +\tint ret;\n" @@ -129,7 +137,7 @@ "In the unlikely event this function is used some place else, it would avoid bad\n" "surprise\n" "\n" - "So?if it is OK with you, I would prefer to keep this check and add the check of\n" + "So\302\240if it is OK with you, I would prefer to keep this check and add the check of\n" "the prepare lock. Maybe I could go over the other \"_nolock\" functions in clk.c\n" "to verify they are all doing it ? What do you think ?\n" "\n" @@ -145,7 +153,7 @@ "\n" "Here we are trying to return a rate, so unsigned long.\n" "I think (and I remember discussing it with Mike sometimes ago) that a 0 clock\n" - "rate quite often represent an error.?\n" + "rate quite often represent an error.\302\240\n" "\n" "\n" "> We should bail the set rate\n" @@ -161,4 +169,4 @@ "\n" > -851fd87cd452fe99e68503909c4716b5ba70b52d27a4faebceac53877b3670c5 +6cd13bdb19e80b16a4c751cf54753976328ecaaaa0db2341fc00e0866bfcc40e
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.