diff for duplicates of <1494597899.2135.3.camel@baylibre.com> diff --git a/a/1.txt b/N1/1.txt index f0f9b3a..843a565 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -54,33 +54,33 @@ This case is easier, if they use min=max, yes for sure. > > Inside the clock framework, 2 new count values are introduced to keep track > > of the protection: > > * core "protect_count": this reference count value works in the same way as -> > ? prepare and enable count, and track whether the clock is protected or -> > ? not. This is the value that will checked to allow operation which may -> > ? cause glitches or change the rate of clock source. +> > prepare and enable count, and track whether the clock is protected or +> > not. This is the value that will checked to allow operation which may +> > cause glitches or change the rate of clock source. > > * clk consumer "protect_ucount": this allows to track if the consumer is -> > ? protecting the clock. +> > protecting the clock. > > > > Requiring the consumer to unprotect its clock before changing it would have > > been very annoying for the consumer. It would also be unsafe, as it would > > still be possible for another consumer to change the rate between the call -> > to set_rate and protect. This needs to happen in a critical section.??A +> > to set_rate and protect. This needs to happen in a critical section. A > > solution would be to add "set_rate_protect", but we would need to do the > > same for the set_parent and set_phase (and the possible future -> > functions). It does not scale well.??The solution proposed in this patch is +> > functions). It does not scale well. The solution proposed in this patch is > > to use the consumer protect count. > > > > In function altering the clock, if the consumer is protecting the clock, > > the protection is temporarily release under the prepare_lock. This ensure > > that: > > * the clock is still protect from another consumer because of the -> > ? prepare_lock +> > prepare_lock > > * the rate set on a protected clock cannot change between set_rate and -> > ? later enable +> > later enable > > * only a consumer protecting a clock can do this temporary protection -> > ? removal (less chance of people messing with the refcount) +> > removal (less chance of people messing with the refcount) > > * if more than one consumer protect the clock, it remains protected. -> > ? Because the protection is removed for the calling consumer, it gives -> > ? it a chance to jump to another provider, if available. +> > Because the protection is removed for the calling consumer, it gives +> > it a chance to jump to another provider, if available. > > > > This protection mechanism assume that "protecting" consumer knows what it > > is doing when it comes to setting the rate, and does not expect to be @@ -91,12 +91,12 @@ This case is easier, if they use min=max, yes for sure. > > One caveat is the following case: > > N+1 consumers protect their clocks. These clocks come from N possible > > providers. We should able to satisfy at least N consumers before exhausting -> > the resources.??In the particular case where all the consumers call +> > the resources. In the particular case where all the consumers call > > "protect" before having a chance to call "set_rate", the last 2 consumers > > will remains stuck on the last provider w/o being able to set the rate on > > it. This means that in situation where there is 2 consumers on 1 > > providers, they will compete for the clock, and may end up in situation -> > where both protect the clock and none can set the rate they need.??This can +> > where both protect the clock and none can set the rate they need. This can > > be solved if, when the rate fails to be set, the consumer release the > > protection. Then the second consumer will be able to satisfy its request. > @@ -106,14 +106,14 @@ This case is easier, if they use min=max, yes for sure. > initializing rates during .probe(). Automatically dropping the lock > might complicate things in other cases though... -set_rate_lock would solve the problem for? +set_rate_lock would solve the problem for > > "the last 2 consumers > > will remains stuck on the last provider w/o being able to set the rate" With set_rate_lock, only the last one won't be satisfied, which is fine I suppose. -> ?if setting the rate failes +> if setting the rate failes Setting aside this RFC, when can we consider a that setting the rate failed ? CCF always give the best it can, according to a set of constraints (possible @@ -152,26 +152,26 @@ Jerome > > With this patchset, we should probably change the use the flags > > "CLK_SET_RATE_GATE" and "CLK_SET_PARENT_GATE" We discussed removing > > them. Another solution would be to have them automatically gate the clock -> > before performing the related operation.??What is your view on this ? +> > before performing the related operation. What is your view on this ? > > -> > [0]: http://lkml.kernel.org/r/148942423440.82235.17188153691656009029 at resona +> > [0]: http://lkml.kernel.org/r/148942423440.82235.17188153691656009029@resona > > nce > > > > Jerome Brunet (7): -> > ? clk: take the prepare lock out of clk_core_set_parent -> > ? clk: add set_phase core function -> > ? clk: rework calls to round and determine rate callbacks -> > ? clk: add support for clock protection -> > ? clk: rollback set_rate_range changes on failure -> > ? clk: cosmetic changes to clk_summary debugfs entry -> > ? clk: fix incorrect usage of ENOSYS -> > -> > ?drivers/clk/clk.c????????????| 313 ++++++++++++++++++++++++++++++++++---- +> > clk: take the prepare lock out of clk_core_set_parent +> > clk: add set_phase core function +> > clk: rework calls to round and determine rate callbacks +> > clk: add support for clock protection +> > clk: rollback set_rate_range changes on failure +> > clk: cosmetic changes to clk_summary debugfs entry +> > clk: fix incorrect usage of ENOSYS +> > +> > drivers/clk/clk.c | 313 ++++++++++++++++++++++++++++++++++---- > > ----- -> > ?include/linux/clk-provider.h |???1 + -> > ?include/linux/clk.h??????????|??29 ++++ -> > ?3 files changed, 279 insertions(+), 64 deletions(-) +> > include/linux/clk-provider.h | 1 + +> > include/linux/clk.h | 29 ++++ +> > 3 files changed, 279 insertions(+), 64 deletions(-) > > -> > --? +> > -- > > 2.9.3 > > diff --git a/a/content_digest b/N1/content_digest index 935b911..f355d70 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,9 +1,13 @@ "ref\020170321183330.26722-1-jbrunet@baylibre.com\0" "ref\0149228583018.88277.3542713369128557565@resonance\0" - "From\0jbrunet@baylibre.com (Jerome Brunet)\0" - "Subject\0[RFC 0/7] clk: implement clock locking mechanism\0" + "From\0Jerome Brunet <jbrunet@baylibre.com>\0" + "Subject\0Re: [RFC 0/7] clk: implement clock locking mechanism\0" "Date\0Fri, 12 May 2017 16:04:59 +0200\0" - "To\0linus-amlogic@lists.infradead.org\0" + "To\0Michael Turquette <mturquette@baylibre.com>" + Stephen Boyd <sboyd@codeaurora.org> + " Kevin Hilman <khilman@baylibre.com>\0" + "Cc\0linux-clk@vger.kernel.org" + " linux-amlogic@lists.infradead.org\0" "\00:1\0" "b\0" "On Sat, 2017-04-15 at 21:50 +0200, Michael Turquette wrote:\n" @@ -62,33 +66,33 @@ "> > Inside the clock framework, 2 new count values are introduced to keep track\n" "> > of the protection:\n" "> > * core \"protect_count\": this reference count value works in the same way as\n" - "> > ? prepare and enable count, and track whether the clock is protected or\n" - "> > ? not. This is the value that will checked to allow operation which may\n" - "> > ? cause glitches or change the rate of clock source.\n" + "> > \302\240 prepare and enable count, and track whether the clock is protected or\n" + "> > \302\240 not. This is the value that will checked to allow operation which may\n" + "> > \302\240 cause glitches or change the rate of clock source.\n" "> > * clk consumer \"protect_ucount\": this allows to track if the consumer is\n" - "> > ? protecting the clock.\n" + "> > \302\240 protecting the clock.\n" "> > \n" "> > Requiring the consumer to unprotect its clock before changing it would have\n" "> > been very annoying for the consumer. It would also be unsafe, as it would\n" "> > still be possible for another consumer to change the rate between the call\n" - "> > to set_rate and protect. This needs to happen in a critical section.??A\n" + "> > to set_rate and protect. This needs to happen in a critical section.\302\240\302\240A\n" "> > solution would be to add \"set_rate_protect\", but we would need to do the\n" "> > same for the set_parent and set_phase (and the possible future\n" - "> > functions). It does not scale well.??The solution proposed in this patch is\n" + "> > functions). It does not scale well.\302\240\302\240The solution proposed in this patch is\n" "> > to use the consumer protect count.\n" "> > \n" "> > In function altering the clock, if the consumer is protecting the clock,\n" "> > the protection is temporarily release under the prepare_lock. This ensure\n" "> > that:\n" "> > * the clock is still protect from another consumer because of the\n" - "> > ? prepare_lock\n" + "> > \302\240 prepare_lock\n" "> > * the rate set on a protected clock cannot change between set_rate and\n" - "> > ? later enable\n" + "> > \302\240 later enable\n" "> > * only a consumer protecting a clock can do this temporary protection\n" - "> > ? removal (less chance of people messing with the refcount)\n" + "> > \302\240 removal (less chance of people messing with the refcount)\n" "> > * if more than one consumer protect the clock, it remains protected.\n" - "> > ? Because the protection is removed for the calling consumer, it gives\n" - "> > ? it a chance to jump to another provider, if available.\n" + "> > \302\240 Because the protection is removed for the calling consumer, it gives\n" + "> > \302\240 it a chance to jump to another provider, if available.\n" "> > \n" "> > This protection mechanism assume that \"protecting\" consumer knows what it\n" "> > is doing when it comes to setting the rate, and does not expect to be\n" @@ -99,12 +103,12 @@ "> > One caveat is the following case:\n" "> > N+1 consumers protect their clocks. These clocks come from N possible\n" "> > providers. We should able to satisfy at least N consumers before exhausting\n" - "> > the resources.??In the particular case where all the consumers call\n" + "> > the resources.\302\240\302\240In the particular case where all the consumers call\n" "> > \"protect\" before having a chance to call \"set_rate\", the last 2 consumers\n" "> > will remains stuck on the last provider w/o being able to set the rate on\n" "> > it. This means that in situation where there is 2 consumers on 1\n" "> > providers, they will compete for the clock, and may end up in situation\n" - "> > where both protect the clock and none can set the rate they need.??This can\n" + "> > where both protect the clock and none can set the rate they need.\302\240\302\240This can\n" "> > be solved if, when the rate fails to be set, the consumer release the\n" "> > protection. Then the second consumer will be able to satisfy its request.\n" "> \n" @@ -114,14 +118,14 @@ "> initializing rates during .probe(). Automatically dropping the lock\n" "> might complicate things in other cases though...\n" "\n" - "set_rate_lock would solve the problem for?\n" + "set_rate_lock would solve the problem for\302\240\n" "> > \"the last 2 consumers\n" "> > will remains stuck on the last provider w/o being able to set the rate\"\n" "\n" "With set_rate_lock, only the last one won't be satisfied, which is fine I\n" "suppose.\n" "\n" - "> ?if setting the rate failes\n" + "> \302\240if setting the rate failes\n" "\n" "Setting aside this RFC, when can we consider a that setting the rate failed ?\n" "CCF always give the best it can, according to a set of constraints (possible\n" @@ -160,28 +164,28 @@ "> > With this patchset, we should probably change the use the flags\n" "> > \"CLK_SET_RATE_GATE\" and \"CLK_SET_PARENT_GATE\" We discussed removing\n" "> > them. Another solution would be to have them automatically gate the clock\n" - "> > before performing the related operation.??What is your view on this ?\n" + "> > before performing the related operation.\302\240\302\240What is your view on this ?\n" "> > \n" - "> > [0]: http://lkml.kernel.org/r/148942423440.82235.17188153691656009029 at resona\n" + "> > [0]: http://lkml.kernel.org/r/148942423440.82235.17188153691656009029@resona\n" "> > nce\n" "> > \n" "> > Jerome Brunet (7):\n" - "> > ? clk: take the prepare lock out of clk_core_set_parent\n" - "> > ? clk: add set_phase core function\n" - "> > ? clk: rework calls to round and determine rate callbacks\n" - "> > ? clk: add support for clock protection\n" - "> > ? clk: rollback set_rate_range changes on failure\n" - "> > ? clk: cosmetic changes to clk_summary debugfs entry\n" - "> > ? clk: fix incorrect usage of ENOSYS\n" - "> > \n" - "> > ?drivers/clk/clk.c????????????| 313 ++++++++++++++++++++++++++++++++++----\n" + "> > \302\240 clk: take the prepare lock out of clk_core_set_parent\n" + "> > \302\240 clk: add set_phase core function\n" + "> > \302\240 clk: rework calls to round and determine rate callbacks\n" + "> > \302\240 clk: add support for clock protection\n" + "> > \302\240 clk: rollback set_rate_range changes on failure\n" + "> > \302\240 clk: cosmetic changes to clk_summary debugfs entry\n" + "> > \302\240 clk: fix incorrect usage of ENOSYS\n" + "> > \n" + "> > \302\240drivers/clk/clk.c\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240| 313 ++++++++++++++++++++++++++++++++++----\n" "> > -----\n" - "> > ?include/linux/clk-provider.h |???1 +\n" - "> > ?include/linux/clk.h??????????|??29 ++++\n" - "> > ?3 files changed, 279 insertions(+), 64 deletions(-)\n" + "> > \302\240include/linux/clk-provider.h |\302\240\302\240\302\2401 +\n" + "> > \302\240include/linux/clk.h\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24029 ++++\n" + "> > \302\2403 files changed, 279 insertions(+), 64 deletions(-)\n" "> > \n" - "> > --?\n" + "> > --\302\240\n" "> > 2.9.3\n" > > -11eca8f5e884db2f5e3bf61bf1727d7450d1aebcbeb1bebf6dba7a88725f4808 +c2ed70069530b7322657e12e0b1ffca2c1b2fb4aae8f7455b44aa58c7d01f233
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.