diff for duplicates of <20150811220609.31346.15943@quantum> diff --git a/a/1.txt b/N1/1.txt index f6b9040..48a3b55 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,73 +1,47 @@ Quoting Russell King - ARM Linux (2015-08-11 12:25:15) > On Tue, Aug 11, 2015 at 10:23:46PM +0300, Grygorii Strashko wrote: > > Hi All, -> > = - +> > > > On 08/04/2015 06:36 PM, Russell King - ARM Linux wrote: > > > On Tue, Aug 04, 2015 at 10:23:31AM -0500, Nishanth Menon wrote: -> > >> Consider clk_enable/disable/set_parent/setfreq operations. none of t= -hese -> > >> operations are "atomic" from hardware point of view. instead, they a= -re a -> > >> set of steps which culminates to moving from state A to state B of t= -he +> > >> Consider clk_enable/disable/set_parent/setfreq operations. none of these +> > >> operations are "atomic" from hardware point of view. instead, they are a +> > >> set of steps which culminates to moving from state A to state B of the > > >> clock tree configuration. -> > > = - +> > > > > > There's a world of difference between clk_enable()/clk_disable() and > > > the rest of the clk API. -> > > = - -> > > clk_enable()/clk_disable() _should_ be callable from any context, sin= -ce -> > > you may need to enable or disable a clock from any context. The rema= -inder -> > > of the clk API is callable only from contexts where sleeping is permi= -ssible. -> > > = - -> > > The reason we have this split is because clk_enable()/clk_disable() h= -ave +> > > +> > > clk_enable()/clk_disable() _should_ be callable from any context, since +> > > you may need to enable or disable a clock from any context. The remainder +> > > of the clk API is callable only from contexts where sleeping is permissible. +> > > +> > > The reason we have this split is because clk_enable()/clk_disable() have > > > historically been used in interrupt handlers, and they're specifically > > > not supposed to impose big delays. -> > > = - -> > > Things like waiting for a PLL to re-lock is time-consuming, so it's n= -ot +> > > +> > > Things like waiting for a PLL to re-lock is time-consuming, so it's not > > > something I'd expect to see behind a clk_enable() implementation (the > > > fact you can't sleep in there is a big hint.) Such waits should be in > > > the clk_prepare() stage instead. -> > > = - -> > > Now, as for clk_enable() being interrupted - if clk_enable() is inter= -rupted +> > > +> > > Now, as for clk_enable() being interrupted - if clk_enable() is interrupted > > > and another clk_enable() comes along for the same clock, that second -> > > clk_enable() should not return until the clock has actually been enab= -led, -> > > and it's up to the implementation to decode how to achieve that. If = -that +> > > clk_enable() should not return until the clock has actually been enabled, +> > > and it's up to the implementation to decode how to achieve that. If that > > > means a RT implementation using a raw spinlock, then that's one option -> > > (which basically would have the side effect of blocking until the pre= -empted +> > > (which basically would have the side effect of blocking until the preempted > > > clk_enable() finishes its business.) Alternatively, if we can preempt -> > > inside clk_enable(), then the clk_enable() implementation should be w= -ritten -> > > to cope with that (eg, by the second clk_enable() fiddling with the h= -ardware, +> > > inside clk_enable(), then the clk_enable() implementation should be written +> > > to cope with that (eg, by the second clk_enable() fiddling with the hardware, > > > and the first thread noticing that it has nothing to do.) -> > > = - -> > = - +> > > +> > > > Thanks a lot for your comments and explanations. -> > = - -> > Now lock object in CCF is not a raw spinlock, so, seems, I have to upda= -te = - +> > +> > Now lock object in CCF is not a raw spinlock, so, seems, I have to update > > code and try to move clk_enable()/clk_disable() out of atomic context. -> = - +> > clk_enable/clk_disable _should_ be usable from atomic contexts. Grygorii, @@ -85,10 +59,8 @@ relevant enough for me to add here. Regards, Mike -> = - -> -- = - +> +> -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. > -- diff --git a/a/content_digest b/N1/content_digest index 8b5f290..43ba058 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -20,73 +20,47 @@ "Quoting Russell King - ARM Linux (2015-08-11 12:25:15)\n" "> On Tue, Aug 11, 2015 at 10:23:46PM +0300, Grygorii Strashko wrote:\n" "> > Hi All,\n" - "> > =\n" - "\n" + "> > \n" "> > On 08/04/2015 06:36 PM, Russell King - ARM Linux wrote:\n" "> > > On Tue, Aug 04, 2015 at 10:23:31AM -0500, Nishanth Menon wrote:\n" - "> > >> Consider clk_enable/disable/set_parent/setfreq operations. none of t=\n" - "hese\n" - "> > >> operations are \"atomic\" from hardware point of view. instead, they a=\n" - "re a\n" - "> > >> set of steps which culminates to moving from state A to state B of t=\n" - "he\n" + "> > >> Consider clk_enable/disable/set_parent/setfreq operations. none of these\n" + "> > >> operations are \"atomic\" from hardware point of view. instead, they are a\n" + "> > >> set of steps which culminates to moving from state A to state B of the\n" "> > >> clock tree configuration.\n" - "> > > =\n" - "\n" + "> > > \n" "> > > There's a world of difference between clk_enable()/clk_disable() and\n" "> > > the rest of the clk API.\n" - "> > > =\n" - "\n" - "> > > clk_enable()/clk_disable() _should_ be callable from any context, sin=\n" - "ce\n" - "> > > you may need to enable or disable a clock from any context. The rema=\n" - "inder\n" - "> > > of the clk API is callable only from contexts where sleeping is permi=\n" - "ssible.\n" - "> > > =\n" - "\n" - "> > > The reason we have this split is because clk_enable()/clk_disable() h=\n" - "ave\n" + "> > > \n" + "> > > clk_enable()/clk_disable() _should_ be callable from any context, since\n" + "> > > you may need to enable or disable a clock from any context. The remainder\n" + "> > > of the clk API is callable only from contexts where sleeping is permissible.\n" + "> > > \n" + "> > > The reason we have this split is because clk_enable()/clk_disable() have\n" "> > > historically been used in interrupt handlers, and they're specifically\n" "> > > not supposed to impose big delays.\n" - "> > > =\n" - "\n" - "> > > Things like waiting for a PLL to re-lock is time-consuming, so it's n=\n" - "ot\n" + "> > > \n" + "> > > Things like waiting for a PLL to re-lock is time-consuming, so it's not\n" "> > > something I'd expect to see behind a clk_enable() implementation (the\n" "> > > fact you can't sleep in there is a big hint.) Such waits should be in\n" "> > > the clk_prepare() stage instead.\n" - "> > > =\n" - "\n" - "> > > Now, as for clk_enable() being interrupted - if clk_enable() is inter=\n" - "rupted\n" + "> > > \n" + "> > > Now, as for clk_enable() being interrupted - if clk_enable() is interrupted\n" "> > > and another clk_enable() comes along for the same clock, that second\n" - "> > > clk_enable() should not return until the clock has actually been enab=\n" - "led,\n" - "> > > and it's up to the implementation to decode how to achieve that. If =\n" - "that\n" + "> > > clk_enable() should not return until the clock has actually been enabled,\n" + "> > > and it's up to the implementation to decode how to achieve that. If that\n" "> > > means a RT implementation using a raw spinlock, then that's one option\n" - "> > > (which basically would have the side effect of blocking until the pre=\n" - "empted\n" + "> > > (which basically would have the side effect of blocking until the preempted\n" "> > > clk_enable() finishes its business.) Alternatively, if we can preempt\n" - "> > > inside clk_enable(), then the clk_enable() implementation should be w=\n" - "ritten\n" - "> > > to cope with that (eg, by the second clk_enable() fiddling with the h=\n" - "ardware,\n" + "> > > inside clk_enable(), then the clk_enable() implementation should be written\n" + "> > > to cope with that (eg, by the second clk_enable() fiddling with the hardware,\n" "> > > and the first thread noticing that it has nothing to do.)\n" - "> > > =\n" - "\n" - "> > =\n" - "\n" + "> > > \n" + "> > \n" "> > Thanks a lot for your comments and explanations.\n" - "> > =\n" - "\n" - "> > Now lock object in CCF is not a raw spinlock, so, seems, I have to upda=\n" - "te =\n" - "\n" + "> > \n" + "> > Now lock object in CCF is not a raw spinlock, so, seems, I have to update \n" "> > code and try to move clk_enable()/clk_disable() out of atomic context.\n" - "> =\n" - "\n" + "> \n" "> clk_enable/clk_disable _should_ be usable from atomic contexts.\n" "\n" "Grygorii,\n" @@ -104,10 +78,8 @@ "Regards,\n" "Mike\n" "\n" - "> =\n" - "\n" - "> -- =\n" - "\n" + "> \n" + "> -- \n" "> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up\n" "> according to speedtest.net.\n" "> --\n" @@ -115,4 +87,4 @@ "> the body of a message to majordomo@vger.kernel.org\n" > More majordomo info at http://vger.kernel.org/majordomo-info.html -09582cf328b12410802a407e98f0b944ade82c1ed9dc6e4de85ad977dab5dc42 +997b294560012b31f3a68050e66dcce94af21fb8630e6be06cb500c9a29ae39b
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.