diff for duplicates of <1502286356.2759.43.camel@baylibre.com> diff --git a/a/1.txt b/N1/1.txt index b8e24af..3acdcc4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -8,7 +8,7 @@ On Wed, 2017-08-09 at 14:40 +0100, Russell King - ARM Linux wrote: > > > > speculation/rounding phase would be different if some other > > > > consumer goes and changes some rate high up in the tree. > > > -> > > That's probably because people tend to get this stuff wrong.??It is +> > > That's probably because people tend to get this stuff wrong. It is > > > _not_ supposed to be: > > > > > > rounded_rate = clk_round_rate(clk, requested_rate); @@ -24,7 +24,7 @@ On Wed, 2017-08-09 at 14:40 +0100, Russell King - ARM Linux wrote: > > > The former is wrong for two reasons: > > > > > > 1. it's completely wasteful of CPU resources to do all the calculations -> > > ???that need to be done within clk_set_rate(). +> > > that need to be done within clk_set_rate(). > > > > > > 2. it's racy - there is no guarantee that you'll end up with > > > "rounded_rate" @@ -36,13 +36,13 @@ On Wed, 2017-08-09 at 14:40 +0100, Russell King - ARM Linux wrote: > > > I'm not sure that the clock rate protection API is really the right > > > solution - if we're trying to stop others from changing the clock rate, > > > that implies we have multiple different threads potentially changing -> > > the rate at any time.??If a driver does this: +> > > the rate at any time. If a driver does this: > > > > > > clk_set_rate(clk, foo); > > > clk_rate_protect(clk); > > > > > > what prevents another thread from changing the clock rate between these -> > > two calls???The only way to do this safely would be something like: +> > > two calls? The only way to do this safely would be something like: > > > > > > r = clk_round_rate(clk, foo); > > > while (1) { @@ -63,19 +63,19 @@ On Wed, 2017-08-09 at 14:40 +0100, Russell King - ARM Linux wrote: > > Russell, > > I think you have missed one subtle thing, when trying any clock altering > > operation, if the consumer is protecting the clock, it will temporarily -> > release? +> > release > > the protection once, under the prepare_lock (to guarantee safe operation). > > This > > is explained in the cover letter: > > > > """ > > With this series there is 3 use-case: -> > ?- the provider is not protected: nothing changes -> > ?- the provider is protected by only 1 consumer (and only once), then only -> > ???this consumer will be able to alter the rate of the clock, as it is the -> > ???only one depending on it. -> > ?- If the provider is protected more than once, or by the provider itself, -> > ???the rate is basically locked and protected against reparenting. +> > - the provider is not protected: nothing changes +> > - the provider is protected by only 1 consumer (and only once), then only +> > this consumer will be able to alter the rate of the clock, as it is the +> > only one depending on it. +> > - If the provider is protected more than once, or by the provider itself, +> > the rate is basically locked and protected against reparenting. > > """ > > > > So what you should do if you have to protect the clock is: diff --git a/a/content_digest b/N1/content_digest index 4c2d9ab..0078fad 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,10 +8,17 @@ "ref\020170809114548.GD20805@n2100.armlinux.org.uk\0" "ref\01502285688.2759.41.camel@baylibre.com\0" "ref\020170809134036.GE20805@n2100.armlinux.org.uk\0" - "From\0jbrunet@baylibre.com (Jerome Brunet)\0" - "Subject\0[PATCH v3 05/10] clk: add support for clock protection\0" + "From\0Jerome Brunet <jbrunet@baylibre.com>\0" + "Subject\0Re: [PATCH v3 05/10] clk: add support for clock protection\0" "Date\0Wed, 09 Aug 2017 15:45:56 +0200\0" - "To\0linus-amlogic@lists.infradead.org\0" + "To\0Russell King - ARM Linux <linux@armlinux.org.uk>\0" + "Cc\0Stephen Boyd <sboyd@codeaurora.org>" + Michael Turquette <mturquette@baylibre.com> + linux-clk@vger.kernel.org + Kevin Hilman <khilman@baylibre.com> + linux-amlogic@lists.infradead.org + Linus Walleij <linus.walleij@linaro.org> + " Boris Brezillon <boris.brezillon@free-electrons.com>\0" "\00:1\0" "b\0" "On Wed, 2017-08-09 at 14:40 +0100, Russell King - ARM Linux wrote:\n" @@ -24,7 +31,7 @@ "> > > > speculation/rounding phase would be different if some other\n" "> > > > consumer goes and changes some rate high up in the tree.\n" "> > > \n" - "> > > That's probably because people tend to get this stuff wrong.??It is\n" + "> > > That's probably because people tend to get this stuff wrong.\302\240\302\240It is\n" "> > > _not_ supposed to be:\n" "> > > \n" "> > > \trounded_rate = clk_round_rate(clk, requested_rate);\n" @@ -40,7 +47,7 @@ "> > > The former is wrong for two reasons:\n" "> > > \n" "> > > 1. it's completely wasteful of CPU resources to do all the calculations\n" - "> > > ???that need to be done within clk_set_rate().\n" + "> > > \302\240\302\240\302\240that need to be done within clk_set_rate().\n" "> > > \n" "> > > 2. it's racy - there is no guarantee that you'll end up with\n" "> > > \"rounded_rate\"\n" @@ -52,13 +59,13 @@ "> > > I'm not sure that the clock rate protection API is really the right\n" "> > > solution - if we're trying to stop others from changing the clock rate,\n" "> > > that implies we have multiple different threads potentially changing\n" - "> > > the rate at any time.??If a driver does this:\n" + "> > > the rate at any time.\302\240\302\240If a driver does this:\n" "> > > \n" "> > > \tclk_set_rate(clk, foo);\n" "> > > \tclk_rate_protect(clk);\n" "> > > \n" "> > > what prevents another thread from changing the clock rate between these\n" - "> > > two calls???The only way to do this safely would be something like:\n" + "> > > two calls?\302\240\302\240The only way to do this safely would be something like:\n" "> > > \n" "> > > \tr = clk_round_rate(clk, foo);\n" "> > > \twhile (1) {\n" @@ -79,19 +86,19 @@ "> > Russell,\n" "> > I think you have missed one subtle thing, when trying any clock altering\n" "> > operation, if the consumer is protecting the clock, it will temporarily\n" - "> > release?\n" + "> > release\302\240\n" "> > the protection once, under the prepare_lock (to guarantee safe operation).\n" "> > This\n" "> > is explained in the cover letter:\n" "> > \n" "> > \"\"\"\n" "> > With this series there is 3 use-case:\n" - "> > ?- the provider is not protected: nothing changes\n" - "> > ?- the provider is protected by only 1 consumer (and only once), then only\n" - "> > ???this consumer will be able to alter the rate of the clock, as it is the\n" - "> > ???only one depending on it.\n" - "> > ?- If the provider is protected more than once, or by the provider itself,\n" - "> > ???the rate is basically locked and protected against reparenting.\n" + "> > \302\240- the provider is not protected: nothing changes\n" + "> > \302\240- the provider is protected by only 1 consumer (and only once), then only\n" + "> > \302\240\302\240\302\240this consumer will be able to alter the rate of the clock, as it is the\n" + "> > \302\240\302\240\302\240only one depending on it.\n" + "> > \302\240- If the provider is protected more than once, or by the provider itself,\n" + "> > \302\240\302\240\302\240the rate is basically locked and protected against reparenting.\n" "> > \"\"\"\n" "> > \n" "> > So what you should do if you have to protect the clock is:\n" @@ -116,4 +123,4 @@ "> do what it says it does.\n" > -c00c45c503c65fc21ecac10d310b7055195b0bf72d1eed2ad401f6a3a8fc2983 +405a0024c4183a3c12e212c4222998dd1fe7ad0c4f2268bc1988306f4e798473
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.