From: "Turquette, Mike" <mturquette@ti.com> To: Saravana Kannan <skannan@codeaurora.org> Cc: Shawn Guo <shawn.guo@linaro.org>, Paul Walmsley <paul@pwsan.com>, Russell King <linux@arm.linux.org.uk>, Linus Walleij <linus.walleij@stericsson.com>, patches@linaro.org, Magnus Damm <magnus.damm@gmail.com>, Sascha Hauer <s.hauer@pengutronix.de>, Mark Brown <broonie@opensource.wolfsonmicro.com>, Stephen Boyd <sboyd@codeaurora.org>, linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org, Jeremy Kerr <jeremy.kerr@canonical.com>, linux-arm-kernel@lists.infradead.org, Arnd Bergman <arnd.bergmann@linaro.org> Subject: Re: [PATCH v7 2/3] clk: introduce the common clock framework Date: Wed, 28 Mar 2012 10:08:56 -0700 [thread overview] Message-ID: <CAJOA=zM0_czNzdqXfJDn8vzfpVLywBvYTg3SxKs6BHUOsRNd9w@mail.gmail.com> (raw) In-Reply-To: <4F728050.9030904@codeaurora.org> On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan <skannan@codeaurora.org> wrote: > On 03/23/2012 04:28 PM, Turquette, Mike wrote: >> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan<skannan@codeaurora.org> >> wrote: >>> On 03/23/2012 03:32 PM, Turquette, Mike wrote: >>> How does a child (or grand child) clock (not a driver using the clock) >>> reject a rate change if it know it can't handle that freq from the >>> parent? I >>> won't claim to know this part of the code thoroughly, but I can't find an >>> easy way to do this. >> >> >> Technically you could subscribe a notifier to your grand-child clock, >> even if there is no driver for it. The same code that implements your >> platform's clock operations could register the notifier handler. > >> >> >> You can see how this works in clk_propagate_rate_change. That usage >> is certainly targeted more at drivers but could be made to work for >> your case. Let me know what you think; this is an interesting issue. > > > I think notifications should be left to drivers. Notifications are too heavy > handed for enforcing requirements of the clock tree. Agreed. I'm working on a "clock dependency" design at the moment, which should hopefully answer your question. > Also, clk_hw to clk > might no longer be a 1-1 mapping in the future. It's quite possible that > each clk_get() would get a different struct clk based on the caller to keep > track of their constraints separately. So, clock drivers shouldn't ever use > them to identify a clock. I'm also working on this same thing! Lots to keep me busy these days. snip > I think there is still a problem with not being able to differentiate > between pre-change recalc and post-change recalc. This applies for any set > parent and set rate on a clock that has children. > > Consider this simple example: > * Divider clock B is fed from clock A. > * Clock B can never output > 120 MHz due to downstream > HW/clock limitations. > * Clock A is running at 200 MHz > * Clock B divider is set to 2. > > Now, say the rate of clock A is changing from 200 MHz to 300 MHz (due to set > rate or set parent). In this case, the clock B divider should be set to 3 > pre-rate change to guarantee that the output of clock B is never > 120 MHz. > So the rate of clock B will go from 100 MHz (200/2) to 66 MHz (200/3) to 100 > MHz (300/3) and everything is good. > > Assume we somehow managed to do the above. So, now clock A is at 300 MHz, > clock B divider is at 3 and the clock B output is 100 MHz. > > Now, say the rate of clock A changes from 300 MHz to 100 MHz. In this case > the clock B divider should only be changed post rate change. If we do it pre > rate change, then the output will go from 100 MHz (300/3) to 150 MHz (300/1) > to 100 MHz (100/1). We went past the 120 MHz limit of clock B's output rate. > > If we do this post rate change, we can do this without exceeding the max > output limit of clock B. It will go from 100 MHz (300/3) to 33 MHz (100/3) > to 100 MHz (100/1). We never went past the 120 MHz limit. > > So, at least for this reason above, I think we need to pass a pre/post > parameter to the recalc ops. > > While we are at it, we should probably just add a failure option for recalc > to make it easy to reject unacceptable rate changes. To keep the clock > framework code simpler, you could decide to allow errors only for the > pre-change recalc calls. That way, the error case roll back code won't be > crazy. recalc is too late to catch this. I think you mean round_rate. We want to determine which rate changes are out-of-spec during clk_calc_new_rates (for clk_set_rate) which involves round_rate being a bit smarter about what it can and cannot do. Anyways I'm looking at ways to do this in my clk-dependencies branch. Regards, Mike
WARNING: multiple messages have this Message-ID (diff)
From: mturquette@ti.com (Turquette, Mike) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v7 2/3] clk: introduce the common clock framework Date: Wed, 28 Mar 2012 10:08:56 -0700 [thread overview] Message-ID: <CAJOA=zM0_czNzdqXfJDn8vzfpVLywBvYTg3SxKs6BHUOsRNd9w@mail.gmail.com> (raw) In-Reply-To: <4F728050.9030904@codeaurora.org> On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan <skannan@codeaurora.org> wrote: > On 03/23/2012 04:28 PM, Turquette, Mike wrote: >> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan<skannan@codeaurora.org> >> ?wrote: >>> On 03/23/2012 03:32 PM, Turquette, Mike wrote: >>> How does a child (or grand child) clock (not a driver using the clock) >>> reject a rate change if it know it can't handle that freq from the >>> parent? I >>> won't claim to know this part of the code thoroughly, but I can't find an >>> easy way to do this. >> >> >> Technically you could subscribe a notifier to your grand-child clock, >> even if there is no driver for it. ?The same code that implements your >> platform's clock operations could register the notifier handler. > >> >> >> You can see how this works in clk_propagate_rate_change. ?That usage >> is certainly targeted more at drivers but could be made to work for >> your case. ?Let me know what you think; this is an interesting issue. > > > I think notifications should be left to drivers. Notifications are too heavy > handed for enforcing requirements of the clock tree. Agreed. I'm working on a "clock dependency" design at the moment, which should hopefully answer your question. > Also, clk_hw to clk > might no longer be a 1-1 mapping in the future. It's quite possible that > each clk_get() would get a different struct clk based on the caller to keep > track of their constraints separately. So, clock drivers shouldn't ever use > them to identify a clock. I'm also working on this same thing! Lots to keep me busy these days. snip > I think there is still a problem with not being able to differentiate > between pre-change recalc and post-change recalc. This applies for any set > parent and set rate on a clock that has children. > > Consider this simple example: > * Divider clock B is fed from clock A. > * Clock B can never output > 120 MHz due to downstream > ?HW/clock limitations. > * Clock A is running at 200 MHz > * Clock B divider is set to 2. > > Now, say the rate of clock A is changing from 200 MHz to 300 MHz (due to set > rate or set parent). In this case, the clock B divider should be set to 3 > pre-rate change to guarantee that the output of clock B is never > 120 MHz. > So the rate of clock B will go from 100 MHz (200/2) to 66 MHz (200/3) to 100 > MHz (300/3) and everything is good. > > Assume we somehow managed to do the above. So, now clock A is at 300 MHz, > clock B divider is at 3 and the clock B output is 100 MHz. > > Now, say the rate of clock A changes from 300 MHz to 100 MHz. In this case > the clock B divider should only be changed post rate change. If we do it pre > rate change, then the output will go from 100 MHz (300/3) to 150 MHz (300/1) > to 100 MHz (100/1). We went past the 120 MHz limit of clock B's output rate. > > If we do this post rate change, we can do this without exceeding the max > output limit of clock B. It will go from 100 MHz (300/3) to 33 MHz (100/3) > to 100 MHz (100/1). We never went past the 120 MHz limit. > > So, at least for this reason above, I think we need to pass a pre/post > parameter to the recalc ops. > > While we are at it, we should probably just add a failure option for recalc > to make it easy to reject unacceptable rate changes. To keep the clock > framework code simpler, you could decide to allow errors only for the > pre-change recalc calls. That way, the error case roll back code won't be > crazy. recalc is too late to catch this. I think you mean round_rate. We want to determine which rate changes are out-of-spec during clk_calc_new_rates (for clk_set_rate) which involves round_rate being a bit smarter about what it can and cannot do. Anyways I'm looking at ways to do this in my clk-dependencies branch. Regards, Mike
next prev parent reply other threads:[~2012-03-28 17:09 UTC|newest] Thread overview: 242+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-16 6:11 [PATCH v7 0/3] common clk framework Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-16 6:11 ` [PATCH v7 1/3] Documentation: common clk API Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-16 8:25 ` Linus Walleij 2012-03-16 8:25 ` Linus Walleij 2012-03-16 10:29 ` Thomas Gleixner 2012-03-16 10:29 ` Thomas Gleixner 2012-03-16 11:14 ` Amit Kucheria 2012-03-16 11:14 ` Amit Kucheria 2012-03-16 12:18 ` Arnd Bergmann 2012-03-16 12:18 ` Arnd Bergmann 2012-03-16 20:57 ` Arnd Bergmann 2012-03-16 20:57 ` Arnd Bergmann 2012-03-16 21:40 ` Turquette, Mike 2012-03-16 21:40 ` Turquette, Mike 2012-03-16 21:50 ` Nicolas Pitre 2012-03-16 21:50 ` Nicolas Pitre 2012-03-16 22:21 ` Paul Walmsley 2012-03-16 22:21 ` Paul Walmsley 2012-03-16 22:21 ` Paul Walmsley 2012-03-16 22:33 ` Turquette, Mike 2012-03-16 22:33 ` Turquette, Mike 2012-03-17 9:05 ` Arnd Bergmann 2012-03-17 9:05 ` Arnd Bergmann 2012-03-17 9:05 ` Arnd Bergmann 2012-03-17 18:02 ` Turquette, Mike 2012-03-17 18:02 ` Turquette, Mike 2012-03-17 18:02 ` Turquette, Mike 2012-03-17 18:33 ` Arnd Bergmann 2012-03-17 18:33 ` Arnd Bergmann 2012-03-17 18:33 ` Arnd Bergmann 2012-03-17 20:29 ` Sascha Hauer 2012-03-17 20:29 ` Sascha Hauer 2012-03-17 20:29 ` Sascha Hauer 2012-03-17 21:13 ` Arnd Bergmann 2012-03-17 21:13 ` Arnd Bergmann 2012-03-17 21:13 ` Arnd Bergmann 2012-03-20 23:40 ` Paul Walmsley 2012-03-20 23:40 ` Paul Walmsley 2012-03-21 8:59 ` Arnd Bergmann 2012-03-21 8:59 ` Arnd Bergmann 2012-03-16 23:47 ` Sascha Hauer 2012-03-16 23:47 ` Sascha Hauer 2012-03-16 23:47 ` Sascha Hauer 2012-03-17 0:54 ` Rob Herring 2012-03-17 0:54 ` Rob Herring 2012-03-17 0:54 ` Rob Herring 2012-03-17 3:38 ` Saravana Kannan 2012-03-17 3:38 ` Saravana Kannan 2012-03-17 3:38 ` Saravana Kannan 2012-03-20 23:31 ` Paul Walmsley 2012-03-20 23:31 ` Paul Walmsley 2012-03-20 23:31 ` Paul Walmsley 2012-03-21 3:15 ` Nicolas Pitre 2012-03-21 3:15 ` Nicolas Pitre 2012-03-21 3:15 ` Nicolas Pitre 2012-03-21 3:26 ` Saravana Kannan 2012-03-21 3:26 ` Saravana Kannan 2012-03-21 3:26 ` Saravana Kannan 2012-03-21 7:44 ` Paul Walmsley 2012-03-21 7:44 ` Paul Walmsley 2012-03-21 7:44 ` Paul Walmsley 2012-03-21 9:10 ` Sascha Hauer 2012-03-21 9:10 ` Sascha Hauer 2012-03-21 9:10 ` Sascha Hauer 2012-03-21 18:38 ` Saravana Kannan 2012-03-21 18:38 ` Saravana Kannan 2012-03-21 18:38 ` Saravana Kannan 2012-03-21 19:07 ` Mark Brown 2012-03-21 19:07 ` Mark Brown 2012-03-21 19:07 ` Mark Brown 2012-03-21 19:33 ` Tony Lindgren 2012-03-21 19:33 ` Tony Lindgren 2012-03-21 19:33 ` Tony Lindgren 2012-03-21 19:41 ` Saravana Kannan 2012-03-21 19:41 ` Saravana Kannan 2012-03-21 19:41 ` Saravana Kannan 2012-03-21 19:56 ` Mark Brown 2012-03-21 19:56 ` Mark Brown 2012-03-21 19:56 ` Mark Brown 2012-03-21 20:04 ` Saravana Kannan 2012-03-21 20:04 ` Saravana Kannan 2012-03-21 20:04 ` Saravana Kannan 2012-03-21 20:10 ` Mark Brown 2012-03-21 20:10 ` Mark Brown 2012-03-21 20:10 ` Mark Brown 2012-03-22 0:42 ` Russell King - ARM Linux 2012-03-22 0:42 ` Russell King - ARM Linux 2012-03-22 0:42 ` Russell King - ARM Linux 2012-03-21 7:30 ` Paul Walmsley 2012-03-21 7:30 ` Paul Walmsley 2012-03-21 7:30 ` Paul Walmsley 2012-03-21 13:23 ` Nicolas Pitre 2012-03-21 13:23 ` Nicolas Pitre 2012-03-21 13:23 ` Nicolas Pitre 2012-03-16 6:11 ` [PATCH v7 2/3] clk: introduce the common clock framework Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-17 3:28 ` Saravana Kannan 2012-03-17 3:28 ` Saravana Kannan 2012-03-19 18:56 ` Turquette, Mike 2012-03-19 18:56 ` Turquette, Mike 2012-03-19 19:13 ` Saravana Kannan 2012-03-19 19:13 ` Saravana Kannan 2012-03-19 19:33 ` Turquette, Mike 2012-03-19 19:33 ` Turquette, Mike 2012-03-19 19:49 ` Saravana Kannan 2012-03-19 19:49 ` Saravana Kannan 2012-03-20 3:38 ` [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn Saravana Kannan 2012-03-20 3:38 ` Saravana Kannan 2012-03-20 3:38 ` [PATCH 2/2] clk: Move init fields from clk to clk_hw Saravana Kannan 2012-03-20 3:38 ` Saravana Kannan 2012-03-20 7:20 ` Shawn Guo 2012-03-20 7:20 ` Shawn Guo 2012-03-20 7:54 ` Saravana Kannan 2012-03-20 7:54 ` Saravana Kannan 2012-03-20 7:54 ` Saravana Kannan 2012-03-20 8:13 ` Shawn Guo 2012-03-20 8:13 ` Shawn Guo 2012-03-20 9:40 ` Sascha Hauer 2012-03-20 9:40 ` Sascha Hauer 2012-03-20 10:17 ` Saravana Kannan 2012-03-20 10:17 ` Saravana Kannan 2012-03-20 10:17 ` Saravana Kannan 2012-03-20 18:14 ` Sascha Hauer 2012-03-20 18:14 ` Sascha Hauer 2012-03-20 20:14 ` Saravana Kannan 2012-03-20 20:14 ` Saravana Kannan 2012-03-20 22:40 ` Sascha Hauer 2012-03-20 22:40 ` Sascha Hauer 2012-03-22 3:23 ` Shawn Guo 2012-03-22 3:23 ` Shawn Guo 2012-03-20 14:18 ` Shawn Guo 2012-03-20 14:18 ` Shawn Guo 2012-03-20 18:10 ` Sascha Hauer 2012-03-20 18:10 ` Sascha Hauer 2012-03-20 20:06 ` Saravana Kannan 2012-03-20 20:06 ` Saravana Kannan 2012-03-20 23:12 ` Sascha Hauer 2012-03-20 23:12 ` Sascha Hauer 2012-03-21 1:47 ` Turquette, Mike 2012-03-21 1:47 ` Turquette, Mike 2012-03-21 3:01 ` Saravana Kannan 2012-03-21 3:01 ` Saravana Kannan 2012-03-27 4:35 ` Saravana Kannan 2012-03-27 4:35 ` Saravana Kannan 2012-03-27 18:49 ` Turquette, Mike 2012-03-27 18:49 ` Turquette, Mike 2012-03-27 22:27 ` Saravana Kannan 2012-03-27 22:27 ` Saravana Kannan 2012-04-06 1:30 ` Saravana Kannan 2012-04-06 1:30 ` Saravana Kannan 2012-04-11 17:59 ` Turquette, Mike 2012-04-11 17:59 ` Turquette, Mike 2012-04-11 19:57 ` Saravana Kannan 2012-04-11 19:57 ` Saravana Kannan 2012-04-11 19:57 ` Saravana Kannan 2012-04-11 20:17 ` Turquette, Mike 2012-04-11 20:17 ` Turquette, Mike 2012-04-11 20:21 ` Saravana Kannan 2012-04-11 20:21 ` Saravana Kannan 2012-04-11 20:21 ` Saravana Kannan 2012-03-20 23:47 ` Paul Walmsley 2012-03-20 23:47 ` Paul Walmsley 2012-03-21 9:16 ` Sascha Hauer 2012-03-21 9:16 ` Sascha Hauer 2012-03-20 7:19 ` [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn Sascha Hauer 2012-03-20 7:19 ` Sascha Hauer 2012-03-20 7:46 ` Saravana Kannan 2012-03-20 7:46 ` Saravana Kannan 2012-03-20 7:46 ` Saravana Kannan 2012-03-21 0:13 ` Turquette, Mike 2012-03-21 0:13 ` Turquette, Mike 2012-03-21 2:32 ` Saravana Kannan 2012-03-21 2:32 ` Saravana Kannan 2012-03-21 5:45 ` Turquette, Mike 2012-03-21 5:45 ` Turquette, Mike 2012-03-21 6:33 ` Saravana Kannan 2012-03-21 6:33 ` Saravana Kannan 2012-03-21 6:33 ` Saravana Kannan 2012-03-21 9:07 ` Russell King - ARM Linux 2012-03-21 9:07 ` Russell King - ARM Linux 2012-03-21 19:56 ` Turquette, Mike 2012-03-21 19:56 ` Turquette, Mike 2012-03-18 13:46 ` [PATCH v7 2/3] clk: introduce the common clock framework Shawn Guo 2012-03-18 13:46 ` Shawn Guo 2012-03-19 18:58 ` Turquette, Mike 2012-03-19 18:58 ` Turquette, Mike 2012-03-18 14:07 ` Shawn Guo 2012-03-18 14:07 ` Shawn Guo 2012-03-19 19:00 ` Turquette, Mike 2012-03-19 19:00 ` Turquette, Mike 2012-03-19 11:22 ` Rajendra Nayak 2012-03-19 11:22 ` Rajendra Nayak 2012-03-19 11:28 ` Sascha Hauer 2012-03-19 11:28 ` Sascha Hauer 2012-03-19 19:09 ` Turquette, Mike 2012-03-19 19:09 ` Turquette, Mike 2012-03-19 19:53 ` Turquette, Mike 2012-03-19 19:53 ` Turquette, Mike 2012-03-20 14:02 ` Shawn Guo 2012-03-20 14:02 ` Shawn Guo 2012-03-20 17:46 ` Saravana Kannan 2012-03-20 17:46 ` Saravana Kannan 2012-03-20 23:53 ` Turquette, Mike 2012-03-20 23:53 ` Turquette, Mike 2012-03-21 3:10 ` Saravana Kannan 2012-03-21 3:10 ` Saravana Kannan 2012-03-23 21:33 ` Saravana Kannan 2012-03-23 21:33 ` Saravana Kannan 2012-03-23 21:39 ` Turquette, Mike 2012-03-23 21:39 ` Turquette, Mike 2012-03-23 21:51 ` Saravana Kannan 2012-03-23 21:51 ` Saravana Kannan 2012-03-23 22:12 ` Saravana Kannan 2012-03-23 22:12 ` Saravana Kannan 2012-03-23 22:32 ` Turquette, Mike 2012-03-23 22:32 ` Turquette, Mike 2012-03-23 23:04 ` Saravana Kannan 2012-03-23 23:04 ` Saravana Kannan 2012-03-23 23:28 ` Turquette, Mike 2012-03-23 23:28 ` Turquette, Mike 2012-03-28 3:06 ` Saravana Kannan 2012-03-28 3:06 ` Saravana Kannan 2012-03-28 17:08 ` Turquette, Mike [this message] 2012-03-28 17:08 ` Turquette, Mike 2012-03-28 22:25 ` Saravana Kannan 2012-03-28 22:25 ` Saravana Kannan 2012-03-28 23:49 ` Turquette, Mike 2012-03-28 23:49 ` Turquette, Mike 2012-03-20 23:46 ` Turquette, Mike 2012-03-20 23:46 ` Turquette, Mike 2012-03-21 5:46 ` Shawn Guo 2012-03-21 5:46 ` Shawn Guo 2012-03-16 6:11 ` [PATCH v7 3/3] clk: basic clock hardware types Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-16 12:25 ` Richard Zhao 2012-03-16 12:25 ` Richard Zhao 2012-03-16 16:51 ` Turquette, Mike 2012-03-16 16:51 ` Turquette, Mike 2012-03-16 10:57 ` [PATCH v7 0/3] common clk framework Sascha Hauer 2012-03-16 10:57 ` Sascha Hauer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAJOA=zM0_czNzdqXfJDn8vzfpVLywBvYTg3SxKs6BHUOsRNd9w@mail.gmail.com' \ --to=mturquette@ti.com \ --cc=arnd.bergmann@linaro.org \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=jeremy.kerr@canonical.com \ --cc=linaro-dev@lists.linaro.org \ --cc=linus.walleij@stericsson.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=magnus.damm@gmail.com \ --cc=patches@linaro.org \ --cc=paul@pwsan.com \ --cc=s.hauer@pengutronix.de \ --cc=sboyd@codeaurora.org \ --cc=shawn.guo@linaro.org \ --cc=skannan@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.