diff for duplicates of <20170804003249.GV2146@codeaurora.org> diff --git a/a/1.txt b/N1/1.txt index 803918f..131f7e5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,11 +4,11 @@ On 07/26, Jerome Brunet 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 @@ -20,7 +20,7 @@ On 07/26, Jerome Brunet 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 @@ -90,19 +90,19 @@ Ok. > > > > > > 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; @@ -123,7 +123,7 @@ Ok. > 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 ? @@ -143,7 +143,7 @@ the NULL check here. > > 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 83b852b..aa4471e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,10 +2,18 @@ "ref\020170612194438.12298-5-jbrunet@baylibre.com\0" "ref\020170712020041.GU22780@codeaurora.org\0" "ref\01501089183.2401.28.camel@baylibre.com\0" - "From\0sboyd@codeaurora.org (Stephen Boyd)\0" - "Subject\0[PATCH v3 04/10] clk: use round rate to bail out early in set_rate\0" + "From\0Stephen Boyd <sboyd@codeaurora.org>\0" + "Subject\0Re: [PATCH v3 04/10] clk: use round rate to bail out early in set_rate\0" "Date\0Thu, 3 Aug 2017 17:32:49 -0700\0" - "To\0linus-amlogic@lists.infradead.org\0" + "To\0Jerome Brunet <jbrunet@baylibre.com>\0" + "Cc\0Peter De Schrijver <pdeschrijver@nvidia.com>" + Michael 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 07/26, Jerome Brunet wrote:\n" @@ -14,11 +22,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" @@ -30,7 +38,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" @@ -100,19 +108,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" @@ -133,7 +141,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" @@ -153,7 +161,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" @@ -178,4 +186,4 @@ "Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\n" a Linux Foundation Collaborative Project -ec8ed9bc472543ec93e68b3b46aa22a7f6c3c26b4d45b837906ded627cbb4f63 +d01b6f9e151296fcadae99a336660988bd31f8eca4ab7febc01ade5bbc1c8531
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.