The common clock framework defines a common struct clk as well as an implementation of the clk api that unifies clock operations on various platforms and devices.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This series is the feature freeze for the common clock framework. Unless any major bugs are reported this should be the final version of this patchset. Now is the time to add any acked-by's, reviewed-by's or tested-by's. I've carried over the *-by's from v6; I hope everyone is OK with that.
Big thanks to Sascha Hauer for his changes to clk_set_rate in this version.
Major changes since v6: * clk_set_rate rewritten to set clock rates from top-to-bottom * should also reduce pre-rate change notifier noise (thanks Sascha) * fixed up clk_divider's .round_rate logic (thanks Sascha) * removed useless locking around basic clock types * fixed return types for __clk_get_(enable|prepare)_count * some NULL pointer fixes for handling .parent_names and .parents * removed unnecessary checks for recursive calls in a few helpers * made __clk_round_rate more sane and aligned with clk_round_rate * parent rates are returned if .round_rate is not implemented * fixed CONFIG_COMMON_CLK_DEBUGFS to select DEBUG_FS * rebased onto Linus' v3.3-rc7 tag
Major changes since v5: * removed redundant HAVE_CLK_PREPARE in Kconfig * new CONFIG_COMMON_CLK_DISABLE_UNUSED feature * results in a new clk_op callback, .is_enabled * standardized the hw-specific locking in the basic clock types * export the individual ops for each basic clock type * improve registration for single-parent basic clocks (thanks Sascha) * fixed bugs in gate clock's static initializers (thanks Andrew) * overall improvements to Documentation/clk.txt * rebased onto Linus' v3.3-rc6 tag
Major changes since v4: * rolled in TGLX's comments on overall design. We now have, * proper handling of root clocks and orphan clocks * multi-parent clocks are handled in the core * struct clk is shielded from struct clk_foo and vice versa * this is a return to the previous struct clk_hw design * split basic clock types out into separate files * split headers up by purpose * clk.h remains the driver-level interface * declarations for rate change notifiers are the only additions * clk-provider.h is primary header for implementing clock operations * clk-private.h allows for static initialization of clock data * validation and bug fixes * rebased onto Linus' v3.3-rc5 tag
Patches can be pulled from: git://git.linaro.org/people/mturquette/linux.git v3.3-rc7-clkv7
v6 can be found at, http://article.gmane.org/gmane.linux.kernel/1265022
v5 can be found at, http://article.gmane.org/gmane.linux.kernel/1261472
v4 can be found at, http://article.gmane.org/gmane.linux.linaro.devel/8896/
v3 can be found at, http://article.gmane.org/gmane.linux.kernel/1218622
Mike Turquette (3): Documentation: common clk API clk: introduce the common clock framework clk: basic clock hardware types
Documentation/clk.txt | 233 +++++++ drivers/clk/Kconfig | 40 ++ drivers/clk/Makefile | 2 + drivers/clk/clk-divider.c | 200 ++++++ drivers/clk/clk-fixed-rate.c | 82 +++ drivers/clk/clk-gate.c | 150 +++++ drivers/clk/clk-mux.c | 116 ++++ drivers/clk/clk.c | 1461 ++++++++++++++++++++++++++++++++++++++++++ include/linux/clk-private.h | 196 ++++++ include/linux/clk-provider.h | 300 +++++++++ include/linux/clk.h | 68 ++- 11 files changed, 2843 insertions(+), 5 deletions(-) create mode 100644 Documentation/clk.txt create mode 100644 drivers/clk/clk-divider.c create mode 100644 drivers/clk/clk-fixed-rate.c create mode 100644 drivers/clk/clk-gate.c create mode 100644 drivers/clk/clk-mux.c create mode 100644 drivers/clk/clk.c create mode 100644 include/linux/clk-private.h create mode 100644 include/linux/clk-provider.h
Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk*.h.
Signed-off-by: Mike Turquette mturquette@linaro.org Signed-off-by: Mike Turquette mturquette@ti.com Reviewed-by: Andrew Lunn andrew@lunn.ch Cc: Russell King linux@arm.linux.org.uk Cc: Jeremy Kerr jeremy.kerr@canonical.com Cc: Thomas Gleixner tglx@linutronix.de Cc: Arnd Bergman arnd.bergmann@linaro.org Cc: Paul Walmsley paul@pwsan.com Cc: Shawn Guo shawn.guo@freescale.com Cc: Sascha Hauer s.hauer@pengutronix.de Cc: Richard Zhao richard.zhao@linaro.org Cc: Saravana Kannan skannan@codeaurora.org Cc: Magnus Damm magnus.damm@gmail.com Cc: Rob Herring rob.herring@calxeda.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com Cc: Linus Walleij linus.walleij@stericsson.com Cc: Stephen Boyd sboyd@codeaurora.org Cc: Amit Kucheria amit.kucheria@linaro.org Cc: Deepak Saxena dsaxena@linaro.org Cc: Grant Likely grant.likely@secretlab.ca --- No changes since v6
Changes since v5: * __clk_init must be called for statically initialized clocks * added "clk_ops matrix" to better clarify which ops are mandatory
Documentation/clk.txt | 233 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 233 insertions(+), 0 deletions(-) create mode 100644 Documentation/clk.txt
diff --git a/Documentation/clk.txt b/Documentation/clk.txt new file mode 100644 index 0000000..1943fae --- /dev/null +++ b/Documentation/clk.txt @@ -0,0 +1,233 @@ + The Common Clk Framework + Mike Turquette mturquette@ti.com + +This document endeavours to explain the common clk framework details, +and how to port a platform over to this framework. It is not yet a +detailed explanation of the clock api in include/linux/clk.h, but +perhaps someday it will include that information. + + Part 1 - introduction and interface split + +The common clk framework is an interface to control the clock nodes +available on various devices today. This may come in the form of clock +gating, rate adjustment, muxing or other operations. This framework is +enabled with the CONFIG_COMMON_CLK option. + +The interface itself is divided into two halves, each shielded from the +details of its counterpart. First is the common definition of struct +clk which unifies the framework-level accounting and infrastructure that +has traditionally been duplicated across a variety of platforms. Second +is a common implementation of the clk.h api, defined in +drivers/clk/clk.c. Finally there is struct clk_ops, whose operations +are invoked by the clk api implementation. + +The second half of the interface is comprised of the hardware-specific +callbacks registered with struct clk_ops and the corresponding +hardware-specific structures needed to model a particular clock. For +the remainder of this document any reference to a callback in struct +clk_ops, such as .enable or .set_rate, implies the hardware-specific +implementation of that code. Likewise, references to struct clk_foo +serve as a convenient shorthand for the implementation of the +hardware-specific bits for the hypothetical "foo" hardware. + +Tying the two halves of this interface together is struct clk_hw, which +is defined in struct clk_foo and pointed to within struct clk. This +allows easy for navigation between the two discrete halves of the common +clock interface. + + Part 2 - common data structures and api + +Below is the common struct clk definition from +include/linux/clk-private.h, modified for brevity: + + struct clk { + const char *name; + const struct clk_ops *ops; + struct clk_hw *hw; + char **parent_names; + struct clk **parents; + struct clk *parent; + struct hlist_head children; + struct hlist_node child_node; + ... + }; + +The members above make up the core of the clk tree topology. The clk +api itself defines several driver-facing functions which operate on +struct clk. That api is documented in include/linux/clk.h. + +Platforms and devices utilizing the common struct clk use the struct +clk_ops pointer in struct clk to perform the hardware-specific parts of +the operations defined in clk.h: + + struct clk_ops { + int (*prepare)(struct clk_hw *hw); + void (*unprepare)(struct clk_hw *hw); + int (*enable)(struct clk_hw *hw); + void (*disable)(struct clk_hw *hw); + int (*is_enabled)(struct clk_hw *hw); + unsigned long (*recalc_rate)(struct clk_hw *hw, + unsigned long parent_rate); + long (*round_rate)(struct clk_hw *hw, unsigned long, + unsigned long *); + int (*set_parent)(struct clk_hw *hw, u8 index); + u8 (*get_parent)(struct clk_hw *hw); + int (*set_rate)(struct clk_hw *hw, unsigned long); + void (*init)(struct clk_hw *hw); + }; + + Part 3 - hardware clk implementations + +The strength of the common struct clk comes from its .ops and .hw pointers +which abstract the details of struct clk from the hardware-specific bits, and +vice versa. To illustrate consider the simple gateable clk implementation in +drivers/clk/clk-gate.c: + +struct clk_gate { + struct clk_hw hw; + void __iomem *reg; + u8 bit_idx; + ... +}; + +struct clk_gate contains struct clk_hw hw as well as hardware-specific +knowledge about which register and bit controls this clk's gating. +Nothing about clock topology or accounting, such as enable_count or +notifier_count, is needed here. That is all handled by the common +framework code and struct clk. + +Let's walk through enabling this clk from driver code: + + struct clk *clk; + clk = clk_get(NULL, "my_gateable_clk"); + + clk_prepare(clk); + clk_enable(clk); + +The call graph for clk_enable is very simple: + +clk_enable(clk); + clk->ops->enable(clk->hw); + [resolves to...] + clk_gate_enable(hw); + [resolves struct clk gate with to_clk_gate(hw)] + clk_gate_set_bit(gate); + +And the definition of clk_gate_set_bit: + +static void clk_gate_set_bit(struct clk_gate *gate) +{ + u32 reg; + + reg = __raw_readl(gate->reg); + reg |= BIT(gate->bit_idx); + writel(reg, gate->reg); +} + +Note that to_clk_gate is defined as: + +#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, clk) + +This pattern of abstraction is used for every clock hardware +representation. + + Part 4 - supporting your own clk hardware + +When implementing support for a new type of clock it only necessary to +include the following header: + +#include <linux/clk-provider.h> + +include/linux/clk.h is included within that header and clk-private.h +must never be included from the code which implements the operations for +a clock. More on that below in Part 5. + +To construct a clk hardware structure for your platform you must define +the following: + +struct clk_foo { + struct clk_hw hw; + ... hardware specific data goes here ... +}; + +To take advantage of your data you'll need to support valid operations +for your clk: + +struct clk_ops clk_foo_ops { + .enable = &clk_foo_enable; + .disable = &clk_foo_disable; +}; + +Implement the above functions using container_of: + +#define to_clk_foo(_hw) container_of(_hw, struct clk_foo, hw) + +int clk_foo_enable(struct clk_hw *hw) +{ + struct clk_foo *foo; + + foo = to_clk_foo(hw); + + ... perform magic on foo ... + + return 0; +}; + +Below is a matrix detailing which clk_ops are mandatory based upon the +hardware capbilities of that clock. A cell marked as "y" means +mandatory, a cell marked as "n" implies that either including that +callback is invalid or otherwise uneccesary. Empty cells are either +optional or must be evaluated on a case-by-case basis. + + clock hardware characteristics + ----------------------------------------------------------- + | gate | change rate | single parent | multiplexer | root | + |------|-------------|---------------|-------------|------| +.prepare | | | | | | +.unprepare | | | | | | + | | | | | | +.enable | y | | | | | +.disable | y | | | | | +.is_enabled | y | | | | | + | | | | | | +.recalc_rate | | y | | | | +.round_rate | | y | | | | +.set_rate | | y | | | | + | | | | | | +.set_parent | | | n | y | n | +.get_parent | | | n | y | n | + | | | | | | +.init | | | | | | + ----------------------------------------------------------- + +Finally, register your clock at run-time with a hardware-specific +registration function. This function simply populates struct clk_foo's +data and then passes the common struct clk parameters to the framework +with a call to: + +clk_register(...) + +See the basic clock types in drivers/clk/clk-*.c for examples. + + Part 5 - static initialization of clock data + +For platforms with many clocks (often numbering into the hundreds) it +may be desirable to statically initialize some clock data. This +presents a problem since the definition of struct clk should be hidden +from everyone except for the clock core in drivers/clk/clk.c. + +To get around this problem struct clk's definition is exposed in +include/linux/clk-private.h along with some macros for more easily +initializing instances of the basic clock types. These clocks must +still be initialized with the common clock framework via a call to +__clk_init. + +clk-private.h must NEVER be included by code which implements struct +clk_ops callbacks, nor must it be included by any logic which pokes +around inside of struct clk at run-time. To do so is a layering +violation. + +To better enforce this policy, always follow this simple rule: any +statically initialized clock data MUST be defined in a separate file +from the logic that implements its ops. Basically separate the logic +from the data and all is well.
On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturquette@linaro.org wrote:
Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk*.h.
Acked-by: Linus Wallej linus.walleij@linaro.org For this three-piece v7 patchset.
It already does magnitudes more advanced stuff than what I need so I'm pretty pleased, any remaining details can surely be ironed out in-tree.
Thanks, Linus Walleij
On Fri, 16 Mar 2012, Linus Walleij wrote:
On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturquette@linaro.org wrote:
Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk*.h.
Acked-by: Linus Wallej linus.walleij@linaro.org For this three-piece v7 patchset.
It already does magnitudes more advanced stuff than what I need so I'm pretty pleased, any remaining details can surely be ironed out in-tree.
Ack. We really need to get that in now and sort out the details in tree otherwise we will never finish that thing.
Thanks,
tglx
On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner tglx@linutronix.de wrote:
On Fri, 16 Mar 2012, Linus Walleij wrote:
On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturquette@linaro.org wrote:
Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk*.h.
Acked-by: Linus Wallej linus.walleij@linaro.org For this three-piece v7 patchset.
It already does magnitudes more advanced stuff than what I need so I'm pretty pleased, any remaining details can surely be ironed out in-tree.
Ack. We really need to get that in now and sort out the details in tree otherwise we will never finish that thing.
Thomas, Russell, Arnd,
Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so that platform ports can gather speed? Several people are waiting for a somewhat stable version before starting their ports.
And what is the path into mainline - will Russell carry it or Arnd (with Russell's blessing)?
Regards, Amit
On Friday 16 March 2012, Amit Kucheria wrote:
On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner tglx@linutronix.de wrote:
On Fri, 16 Mar 2012, Linus Walleij wrote:
On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturquette@linaro.org wrote:
Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk*.h.
Acked-by: Linus Wallej linus.walleij@linaro.org For this three-piece v7 patchset.
It already does magnitudes more advanced stuff than what I need so I'm pretty pleased, any remaining details can surely be ironed out in-tree.
Ack. We really need to get that in now and sort out the details in tree otherwise we will never finish that thing.
Thomas, Russell, Arnd,
Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so that platform ports can gather speed? Several people are waiting for a somewhat stable version before starting their ports.
And what is the path into mainline - will Russell carry it or Arnd (with Russell's blessing)?
I would suggest putting it into a late/* branch of arm-soc so it finally gets some linux-next exposure, and then sending it in the second week of the merge window.
Russell, please let me know if you want to carry it instead or if you have found any last-minute show stoppers in the code.
Arnd
On Friday 16 March 2012, Arnd Bergmann wrote:
Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so that platform ports can gather speed? Several people are waiting for a somewhat stable version before starting their ports.
And what is the path into mainline - will Russell carry it or Arnd (with Russell's blessing)?
I would suggest putting it into a late/* branch of arm-soc so it finally gets some linux-next exposure, and then sending it in the second week of the merge window.
Russell, please let me know if you want to carry it instead or if you have found any last-minute show stoppers in the code.
FWIW, it's in arm-soc now, and it's the last thing I put in there for v3.4. From now on until v3.4-rc1, feature patches can only get removed from arm-soc, not added.
Arnd
On Fri, Mar 16, 2012 at 1:57 PM, Arnd Bergmann arnd@arndb.de wrote:
On Friday 16 March 2012, Arnd Bergmann wrote:
Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so that platform ports can gather speed? Several people are waiting for a somewhat stable version before starting their ports.
And what is the path into mainline - will Russell carry it or Arnd (with Russell's blessing)?
I would suggest putting it into a late/* branch of arm-soc so it finally gets some linux-next exposure, and then sending it in the second week of the merge window.
Russell, please let me know if you want to carry it instead or if you have found any last-minute show stoppers in the code.
FWIW, it's in arm-soc now, and it's the last thing I put in there for v3.4. From now on until v3.4-rc1, feature patches can only get removed from arm-soc, not added.
Thanks Arnd.
Regards, Mike
Arnd
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
On Friday 16 March 2012, Arnd Bergmann wrote:
Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so that platform ports can gather speed? Several people are waiting for a somewhat stable version before starting their ports.
And what is the path into mainline - will Russell carry it or Arnd (with Russell's blessing)?
I would suggest putting it into a late/* branch of arm-soc so it finally gets some linux-next exposure, and then sending it in the second week of the merge window.
Russell, please let me know if you want to carry it instead or if you have found any last-minute show stoppers in the code.
FWIW, it's in arm-soc now [...]
If the common clock code is to go upstream now, it should be marked as experimental. This is because we know the API is not well-defined, and that both the API and the underlying mechanics will almost certainly need to change for non-trivial uses of the rate changing code (e.g., DVFS with external I/O devices).
While I understand and accept the motivation to get the common clk code upstream now, if platforms start to use it, they need to be aware that the behavior of the code can change significantly. These platforms may need to revalidate their implementations or change the way that many of their drivers use the clock functions.
It also seems important to recognize that significant changes are still coming into the common clk code (e.g., the clk_set_rate() changes that came in just a few days ago).
So, the following is a patch to mark it as experimental. It applies on the current head of arm-soc/next/clk (9d9f78ed9af0e465d2fd15550471956e7f559b9f). This should be a good compromise: it allows simple platforms or platforms with maintainers with lots of time to start converting over to the common clk code, while still clearly indicating that the API and underlying code is likely to change in significant ways.
Once at least two major SoC ports have DVFS with external I/O devices safely up and running on their mainline kernels with the common clk code, I'd suggest removing the experimental designation.
...
None of this is meant to reflect on Mike, by the way, who is doing a good job in a difficult situation.
- Paul
From: Paul Walmsley paul@pwsan.com Date: Fri, 16 Mar 2012 16:06:30 -0600 Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this EXPERIMENTAL designation would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com --- drivers/clk/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,6 +12,7 @@ config HAVE_MACH_CLKDEV menuconfig COMMON_CLK bool "Common Clock Framework" select HAVE_CLK_PREPARE + depends on EXPERIMENTAL ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley paul@pwsan.com wrote:
From: Paul Walmsley paul@pwsan.com Date: Fri, 16 Mar 2012 16:06:30 -0600 Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this EXPERIMENTAL designation would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com
ACK. This will set some reasonable expectations while things are in flux.
Arnd are you willing to take this in?
Thanks, Mike
drivers/clk/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,6 +12,7 @@ config HAVE_MACH_CLKDEV menuconfig COMMON_CLK bool "Common Clock Framework" select HAVE_CLK_PREPARE
- depends on EXPERIMENTAL
---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an -- 1.7.9.1
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley paul@pwsan.com wrote:
From: Paul Walmsley paul@pwsan.com Date: Fri, 16 Mar 2012 16:06:30 -0600 Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this EXPERIMENTAL designation would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com
ACK. This will set some reasonable expectations while things are in flux.
Arnd are you willing to take this in?
I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel.
However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation.
Arnd
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
menuconfig COMMON_CLK - bool "Common Clock Framework" + bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an
On Sat, Mar 17, 2012 at 2:05 AM, Arnd Bergmann arnd@arndb.de wrote:
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley paul@pwsan.com wrote:
From: Paul Walmsley paul@pwsan.com Date: Fri, 16 Mar 2012 16:06:30 -0600 Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this EXPERIMENTAL designation would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com
ACK. This will set some reasonable expectations while things are in flux.
Arnd are you willing to take this in?
I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel.
The consensus seems to be to not set experimental.
However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation.
Arnd
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
menuconfig COMMON_CLK
- bool "Common Clock Framework"
- bool
select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an
Much like experimental I'm not sure how needed this change is. The help section does say to leave it disabled by default, if unsure. If you merge it I won't object but this might be fixing an imaginary problem.
Regards, Mike
On Saturday 17 March 2012, Turquette, Mike wrote:
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
menuconfig COMMON_CLK
bool "Common Clock Framework"
bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as anMuch like experimental I'm not sure how needed this change is. The help section does say to leave it disabled by default, if unsure. If you merge it I won't object but this might be fixing an imaginary problem.
Well, it doesn't have any consequences for real users, but it I think it does for randconfig builds, which we are trying to repair currently.
Arnd
On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
On Sat, Mar 17, 2012 at 2:05 AM, Arnd Bergmann arnd@arndb.de wrote:
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley paul@pwsan.com wrote:
From: Paul Walmsley paul@pwsan.com Date: Fri, 16 Mar 2012 16:06:30 -0600 Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this EXPERIMENTAL designation would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com
ACK. This will set some reasonable expectations while things are in flux.
Arnd are you willing to take this in?
I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel.
The consensus seems to be to not set experimental.
However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation.
Arnd
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
menuconfig COMMON_CLK
- bool "Common Clock Framework"
- bool
select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an
Much like experimental I'm not sure how needed this change is. The help section does say to leave it disabled by default, if unsure. If you merge it I won't object but this might be fixing an imaginary problem.
Architectures without common clock support won't build with this option enabled (multiple definition of clk_enable etc), so I think this should not be user visible.
Sascha
On Saturday 17 March 2012, Sascha Hauer wrote:
On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
Much like experimental I'm not sure how needed this change is. The help section does say to leave it disabled by default, if unsure. If you merge it I won't object but this might be fixing an imaginary problem.
Architectures without common clock support won't build with this option enabled (multiple definition of clk_enable etc), so I think this should not be user visible.
I've applied this patch now.
Arnd
commit c173033d154e9792b1b5059783b802f82536d48f Author: Arnd Bergmann arnd@arndb.de Date: Sat Mar 17 21:10:51 2012 +0000
clk: make CONFIG_COMMON_CLK invisible
All platforms that use the common clk infrastructure should select COMMON_CLK from platform code, and on all other platforms, it must not be enabled, so there is no point making the option visible to users, and when it is visible, we break randconfig builds.
Signed-off-by: Arnd Bergmann arnd@arndb.de
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..82bcfbd 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -10,18 +10,14 @@ config HAVE_MACH_CLKDEV bool
menuconfig COMMON_CLK - bool "Common Clock Framework" + bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an implementation of the clock API in include/linux/clk.h. Architectures utilizing the common struct clk should select - this automatically, but it may be necessary to manually select - this option for loadable modules requiring the common clock - framework. - - If in doubt, say "N". + this option.
if COMMON_CLK
Hello Arnd,
On Sat, 17 Mar 2012, Arnd Bergmann wrote:
I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework.
This is where we have differing views, I think. Clearly, Sascha, Saravana, Rob, and I have at least slightly different opinions on the durability of the existing API and code. So it seems reasonable to assume that others who have not followed the development of the common clock code might mistake the implementation or API as being stable and well-defined.
It sounds like the primary objection is to the use of CONFIG_EXPERIMENTAL. So here is a patch to simply note the status of this code in its Kconfig text.
- Paul
From: Paul Walmsley paul@pwsan.com Date: Tue, 20 Mar 2012 17:19:06 -0600 Subject: [PATCH] clk: note that the common clk code is still subject to significant change
Indicate that the common clk code and API is still likely to require significant change. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this help text would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com --- drivers/clk/Kconfig | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..dd2d528 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -21,6 +21,11 @@ menuconfig COMMON_CLK this option for loadable modules requiring the common clock framework.
+ The API and implementation enabled by this option is still + incomplete. The API and implementation is expected to be + fluid and subject to change at any time, potentially + breaking existing users. + If in doubt, say "N".
if COMMON_CLK
On Tuesday 20 March 2012, Paul Walmsley wrote:
Hello Arnd,
On Sat, 17 Mar 2012, Arnd Bergmann wrote:
I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework.
This is where we have differing views, I think. Clearly, Sascha, Saravana, Rob, and I have at least slightly different opinions on the durability of the existing API and code. So it seems reasonable to assume that others who have not followed the development of the common clock code might mistake the implementation or API as being stable and well-defined.
It sounds like the primary objection is to the use of CONFIG_EXPERIMENTAL. So here is a patch to simply note the status of this code in its Kconfig text.
Yes, looks good to me. If there are no objections, I'll apply this one.
Thanks,
Arnd
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as experimental.
No, please don't do this. This effectively marks the architectures using the generic clock framework experimental. We can mark drivers as 'you have been warned', but marking an architecture as experimental is the wrong sign for both its users and people willing to adopt the framework. Also we get this:
warning: (ARCH_MX1 && MACH_MX21 && ARCH_MX25 && MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL)
(and no, I don't want to support to clock frameworks in parallel)
This is because we know the API is not well-defined, and that both the API and the underlying mechanics will almost certainly need to change for non-trivial uses of the rate changing code (e.g., DVFS with external I/O devices).
Please leave DVFS out of the game. DVFS will use the clock framework for the F part and the regulator framework for the V part, but the clock framework should not get extended with DVFS features. The notifiers we currently have in the clock framework should give enough information for DVFS implementations. Even if they don't and we have to change something here this will have no influence on the architectures implementing their clock tree with the common clock framework.
Sascha
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as experimental.
No, please don't do this. This effectively marks the architectures using the generic clock framework experimental. We can mark drivers as 'you have been warned', but marking an architecture as experimental is the wrong sign for both its users and people willing to adopt the framework. Also we get this:
warning: (ARCH_MX1 && MACH_MX21 && ARCH_MX25 && MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL)
(and no, I don't want to support to clock frameworks in parallel)
+1
For simple users at least, the api is perfectly adequate and it is not experimental (unless new means experimental).
Rob
This is because we know the API is not well-defined, and that both the API and the underlying mechanics will almost certainly need to change for non-trivial uses of the rate changing code (e.g., DVFS with external I/O devices).
Please leave DVFS out of the game. DVFS will use the clock framework for the F part and the regulator framework for the V part, but the clock framework should not get extended with DVFS features. The notifiers we currently have in the clock framework should give enough information for DVFS implementations. Even if they don't and we have to change something here this will have no influence on the architectures implementing their clock tree with the common clock framework.
Sascha
On 03/16/2012 05:54 PM, Rob Herring wrote:
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as experimental.
No, please don't do this. This effectively marks the architectures using the generic clock framework experimental. We can mark drivers as 'you have been warned', but marking an architecture as experimental is the wrong sign for both its users and people willing to adopt the framework. Also we get this:
warning: (ARCH_MX1&& MACH_MX21&& ARCH_MX25&& MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL)
(and no, I don't want to support to clock frameworks in parallel)
+1
For simple users at least, the api is perfectly adequate and it is not experimental (unless new means experimental).
+1 - not experimental please.
While I agree with Mike and Paul that there is room for a lot of improvements to the clock APIs, I think the existing APIs in this patch series can become macro wrappers around any new APIs improvements we add in the future.
We should have really done that for the clk_prepare_enable/unprepare_disable(), but it should certainly be doable for future API additions now that we have the atomic/non-atomic differentiation out of the way.
Thanks, Saravana
Hello Sascha,
On Sat, 17 Mar 2012, Sascha Hauer wrote:
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
If the common clock code is to go upstream now, it should be marked as experimental.
No, please don't do this. This effectively marks the architectures using the generic clock framework experimental. We can mark drivers as 'you have been warned', but marking an architecture as experimental is the wrong sign for both its users and people willing to adopt the framework. Also we get this:
warning: (ARCH_MX1 && MACH_MX21 && ARCH_MX25 && MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL)
(and no, I don't want to support to clock frameworks in parallel)
It sounds as if your objection is with CONFIG_EXPERIMENTAL. If that is indeed your objection, I personally have no objection to simply marking the code experimental in the Kconfig text. (Patch at the bottom of this message.)
We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters.
This is because we know the API is not well-defined, and that both the API and the underlying mechanics will almost certainly need to change for non-trivial uses of the rate changing code (e.g., DVFS with external I/O devices).
Please leave DVFS out of the game. DVFS will use the clock framework for the F part and the regulator framework for the V part, but the clock framework should not get extended with DVFS features. The notifiers we currently have in the clock framework should give enough information for DVFS implementations.
Sadly, that's not so.
Consider a CPUFreq driver as one common clock framework user. This driver will attempt to repeatedly change the rate of a clock. Changing that clock's rate may also involve changing the rate of several other clocks used by active devices. So drivers for these devices will need to register rate change notifiers. The notifier callbacks might involve heavyweight work, such as asserting flow control to an externally-connected device.
Suppose now that the last registered device in the notifier chain cannot handle the frequency transition and must abort it. This in turn will require notifier callbacks to all of the previously-notified devices to abort the change. And then shortly after that, CPUFreq is likely to request the same frequency change again: hammering a notifier chain that can never succeed.
Bad enough. We know at least one way to solve this problem. We can use something like the clk_{block,allow}_changes() functions that have been discussed for some time now. But these quickly reveal another problem in the existing API. By default, when there are multiple enabled users of a clock, another entity is allowed to change the clock's rate, or the rate of any parent of that clock (!).
This has several implications. One that is significant is that for any non-trivial clock tree, any driver that cares about its clock's rate will need to implement notifier callbacks. This is because the driver has no way of knowing if or when any other code on the system will attempt to change that clock's rate or source. Or any parent clock's rate or source might change. Should we really force all current drivers using the clock code to implement these callbacks? Or can we restrict the situations in which the clock's rate or parent can change by placing restrictions on the API? But then, driver code may need to be rewritten, and behavior assumptions may change.
Even if they don't and we have to change something here this will have no influence on the architectures implementing their clock tree with the common clock framework.
That sounds pretty confident. Are you sure that the semantics are so well understood?
For example, should we allow clk_set_rate() on disabled clocks? How about prepared, but disabled clocks? If so, what exactly should the clock framework do in these circumstances? Should notifier callbacks go out immediately to registered callbacks? Or should those callbacks be delayed until the clock is prepared or enabled? How should that work when clk_enable() cannot block? And are you confident that any other user of the clock framework will answer these undefined questions in the same way you would?
The above questions are simply "scratching the surface." (Just as examples, there are still significant questions about locking, reentrancy, and so on - [1] is just one example)
These questions have reasonable answers that I think can be mostly aligned on. Thinking through the use-cases, and implications, and answering them, should have been the first task in working on the common clock code. I am sorry to say -- and perhaps this is partially my fault -- that it seems as if most people are not even aware that these questions exist, despite discussions at several conferences and on the mailing lists.
Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly.
Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline. Once several platforms start using it, there will naturally be resistance and conservatism in changing its semantics and interface. Many drivers may have to be changed, across many different maintainers. And power management code may well need to be revalidated on the platforms that use it. PM code, in my opinion, is generally the most difficult code to debug in the kernel.
So, until the API is well-defined and does all that it needs to do for its major users, we should at least have something like the following patch applied.
- Paul
1. King, Russell. _Re: [PATCH v3 3/5] clk: introduce the common clock framework_. 2 Dec 2011 20:23:06 +0000. linux-omap mailing list. http://www.spinics.net/lists/linux-omap/msg61024.html
From: Paul Walmsley paul@pwsan.com Date: Tue, 20 Mar 2012 17:19:06 -0600 Subject: [PATCH] clk: note that the common clk code is still subject to significant change
Indicate that the common clk code and API is still likely to require significant change. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined.
A good time for removing this help text would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code.
Signed-off-by: Paul Walmsley paul@pwsan.com Cc: Mike Turquette mturquette@ti.com --- drivers/clk/Kconfig | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..dd2d528 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -21,6 +21,11 @@ menuconfig COMMON_CLK this option for loadable modules requiring the common clock framework.
+ The API and implementation enabled by this option is still + incomplete. The API and implementation is expected to be + fluid and subject to change at any time, potentially + breaking existing users. + If in doubt, say "N".
if COMMON_CLK
On Tue, 20 Mar 2012, Paul Walmsley wrote:
We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters.
[...]
Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly.
Paul,
While I understand your concern, please don't forget that the perfect is the enemy of the good.
This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke.
We finally have something that the majority of reviewers are happy with and which should cover the majority of existing cases out there. Let's give it a chance, shall we? Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly?
Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline.
The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes.
Let's see how things go with the current code and improve it incrementally. Otherwise no one will get involved with this API which is almost just as bad as not having the code merged at all.
So, until the API is well-defined and does all that it needs to do for its major users, [...]
No, the API simply can't ever be well defined if people don't actually start using it to eventually refine it further. Major users were converted to it, and in most cases The API does all that it needs to do already. Otherwise you'll be stuck in a catch22 situation forever.
And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily.
Nicolas
On 03/20/2012 08:15 PM, Nicolas Pitre wrote:
On Tue, 20 Mar 2012, Paul Walmsley wrote:
We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters.
[...]
Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly.
Paul,
While I understand your concern, please don't forget that the perfect is the enemy of the good.
This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke.
We finally have something that the majority of reviewers are happy with and which should cover the majority of existing cases out there. Let's give it a chance, shall we? Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly?
Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline.
The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes.
Let's see how things go with the current code and improve it incrementally. Otherwise no one will get involved with this API which is almost just as bad as not having the code merged at all.
So, until the API is well-defined and does all that it needs to do for its major users, [...]
No, the API simply can't ever be well defined if people don't actually start using it to eventually refine it further. Major users were converted to it, and in most cases The API does all that it needs to do already. Otherwise you'll be stuck in a catch22 situation forever.
And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily.
+1 to the general idea in Nicolas's email.
To add a few more thoughts, while I agree with Paul that there is room for improvement in the APIs, I think the difference in opinion comes when we ask the question:
"When we eventually refine the APIs in the future to be more expressive, do we think that the current APIs can or cannot be made as wrappers around the new more expressive APIs?"
Absolutes are almost never right, so I can't give an absolute answer. But I'm strongly leaning towards "we can" as the answer to the question. That combined with the reasons Nicholas mentioned is why I think the APIs should not be marked as experimental in anyway.
-Saravana
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
To add a few more thoughts, while I agree with Paul that there is room for improvement in the APIs, I think the difference in opinion comes when we ask the question:
"When we eventually refine the APIs in the future to be more expressive, do we think that the current APIs can or cannot be made as wrappers around the new more expressive APIs?"
Absolutes are almost never right, so I can't give an absolute answer. But I'm strongly leaning towards "we can" as the answer to the question. That combined with the reasons Nicholas mentioned is why I think the APIs should not be marked as experimental in anyway.
The resistance to documenting that the clock interface is not well-defined, and that therefore it is likely to change, and that users should not expect it to be stable, is perplexing to me.
Certainly a Kconfig help text change seems trivial enough. But even the resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given that every single defconfig in arch/arm/defconfig sets it:
$ find arch/arm/configs -type f | wc -l 122 $ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l 122 $
(that includes iMX, by the way...)
Certainly, neither Kconfig change is going to prevent us on OMAP from figuring out what else is needed to convert our platform to the common clock code. And given the level of enthusiasm on the lists, I don't think it's going to prevent many of the other ARM platforms from experimenting with the conversion, either.
So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful.
- Paul
On Wed, Mar 21, 2012 at 01:44:01AM -0600, Paul Walmsley wrote:
Hello Saravana,
Certainly a Kconfig help text change seems trivial enough. But even the resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given that every single defconfig in arch/arm/defconfig sets it:
$ find arch/arm/configs -type f | wc -l 122 $ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l 122 $
(that includes iMX, by the way...)
Certainly, neither Kconfig change is going to prevent us on OMAP from figuring out what else is needed to convert our platform to the common clock code. And given the level of enthusiasm on the lists, I don't think it's going to prevent many of the other ARM platforms from experimenting with the conversion, either.
So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful.
Mainly because COMMON_CLK is an invisible option which has to be selected by architectures. So with the Kconfig change we either have to:
config ARCH_MXC depends on EXPERIMENTAL
or:
config ARCH_MXC select EXPERIMENTAL select COMMON_CLK
Neither of both seems very appealing to me.
You can add a warning to the Kconfig help text if you like, I have no problem with that. As you said it will prevent noone from using it anyway.
Sascha
On 03/21/2012 12:44 AM, Paul Walmsley wrote:
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
To add a few more thoughts, while I agree with Paul that there is room for improvement in the APIs, I think the difference in opinion comes when we ask the question:
"When we eventually refine the APIs in the future to be more expressive, do we think that the current APIs can or cannot be made as wrappers around the new more expressive APIs?"
Absolutes are almost never right, so I can't give an absolute answer. But I'm strongly leaning towards "we can" as the answer to the question. That combined with the reasons Nicholas mentioned is why I think the APIs should not be marked as experimental in anyway.
The resistance to documenting that the clock interface is not well-defined, and that therefore it is likely to change, and that users should not expect it to be stable, is perplexing to me.
Certainly a Kconfig help text change seems trivial enough. But even the resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given that every single defconfig in arch/arm/defconfig sets it:
$ find arch/arm/configs -type f | wc -l 122 $ fgrep -r CONFIG_EXPERIMENTAL=y arch/arm/configs | wc -l 122 $
(that includes iMX, by the way...)
Certainly, neither Kconfig change is going to prevent us on OMAP from figuring out what else is needed to convert our platform to the common clock code. And given the level of enthusiasm on the lists,
I think the enthusiasm we are seeing are from the clock driver developers. And for good reasons. Everyone is tired of having to write or rewrite their own implementation.
I don't think it's going to prevent many of the other ARM platforms from experimenting with the conversion, either.
So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful.
But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework either. If a lot of platform don't convert to the common clock framework, the effort to get it merged in now is not also very meaningful.
Also, at the rate at which we come to an agreement on new APIs, I think these new APIs should be considered quite stable :-) It's certainly better than what we have today. We should encourage driver devs to move to these new APIs and get the benefits while we go on another 2 yr cycle to agree on the next set of APIs improvements.
And as I said before, I think it's much less likely that we will break backward source compatibility when we do the next improvement. We could have mostly avoid this large scale change by calling the APIs prepare/unprepare/gate/ungate (or whatever) and make clk_enable/disable similar to clk_prepare_enable/clk_disable_unprepare(). That would have avoid a lot of drivers from having to mess with their clock calls. But we didn't think about that in the excitement for improved APIs. I think this will still be seared in our minds enough to make sure we don't repeat that in the future.
That covers all I have to say on this topic.
-Saravana
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful.
But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework
These aren't new APIs, the clock API has been around since forever. For driver authors working on anything that isn't platform specific the issue has been that it's not implemented at all on the overwhelming majority of architectures and those that do all have their own random implementations with their own random quirks and with no ability for anything except the platform to even try to do incredibly basic stuff like register a new clock.
Simply having something, anything, in place even if it's going to churn is a massive step forward here for people working with clocks.
* Mark Brown broonie@opensource.wolfsonmicro.com [120321 12:11]:
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful.
But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework
These aren't new APIs, the clock API has been around since forever. For driver authors working on anything that isn't platform specific the issue has been that it's not implemented at all on the overwhelming majority of architectures and those that do all have their own random implementations with their own random quirks and with no ability for anything except the platform to even try to do incredibly basic stuff like register a new clock.
Simply having something, anything, in place even if it's going to churn is a massive step forward here for people working with clocks.
Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :)
Regards,
Tony
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
- Mark Brownbroonie@opensource.wolfsonmicro.com [120321 12:11]:
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else) perceive that the Kconfig changes would be harmful.
But the enthusiasm of the clock driver developers doesn't necessarily translate to users of the clock APIs (other driver devs). My worry with marking it as experimental in Kconfig and to a certain extent in the documentation is that it will discourage the driver devs from switching to the new APIs. If no one is using the new APIs, then platforms can't switch to the common clock framework
These aren't new APIs, the clock API has been around since forever.
I disagree. When I say clock API, I mean the actual functions and their semantics. Not the existence of a header file.
The meaning of clk_enable/disable has been changed and they won't work without calling clk_prepare/unprepare. So, these are definitely new APIs. If it weren't new APIs, then none of the general drivers would need to change.
For driver authors working on anything that isn't platform specific the issue has been that it's not implemented at all on the overwhelming majority of architectures and those that do all have their own random implementations with their own random quirks and with no ability for anything except the platform to even try to do incredibly basic stuff like register a new clock.
Simply having something, anything, in place even if it's going to churn is a massive step forward here for people working with clocks.
Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :)
:-) Shhh... not so loud!
-Saravana
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
- Mark Brownbroonie@opensource.wolfsonmicro.com [120321 12:11]:
These aren't new APIs, the clock API has been around since forever.
I disagree. When I say clock API, I mean the actual functions and their semantics. Not the existence of a header file.
The meaning of clk_enable/disable has been changed and they won't work without calling clk_prepare/unprepare. So, these are definitely new APIs. If it weren't new APIs, then none of the general drivers would need to change.
clk_prepare() and clk_unprepare() are already there for any clk.h user and are stubbed in no matter what, they're really not a meaningful barrier here.
On 03/21/2012 12:56 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
- Mark Brownbroonie@opensource.wolfsonmicro.com [120321 12:11]:
These aren't new APIs, the clock API has been around since forever.
I disagree. When I say clock API, I mean the actual functions and their semantics. Not the existence of a header file.
The meaning of clk_enable/disable has been changed and they won't work without calling clk_prepare/unprepare. So, these are definitely new APIs. If it weren't new APIs, then none of the general drivers would need to change.
clk_prepare() and clk_unprepare() are already there for any clk.h user and are stubbed in no matter what, they're really not a meaningful barrier here.
Isn't this whole experimental vs non-experimental discussion about the actual external facing clock APIs and not the platform driver facing APIs?
Sure, prepare/unprepare are already there in the .h file. But they are stubs and have no impact till we move to the common clock framework or platforms move to them with their own implementation (certainly not happening in upstream, so let's leave that part out of this discussion).
So. IMO, for all practical purposes, common clk fwk forces the move to these new APIs and hence IMO forces the new APIs.
-Saravana
On Wed, Mar 21, 2012 at 01:04:22PM -0700, Saravana Kannan wrote:
Sure, prepare/unprepare are already there in the .h file. But they are stubs and have no impact till we move to the common clock framework or platforms move to them with their own implementation (certainly not happening in upstream, so let's leave that part out of this discussion).
So. IMO, for all practical purposes, common clk fwk forces the move to these new APIs and hence IMO forces the new APIs.
Sure, if you want to look at it from that point of view - anything wanting to run on a platform which uses the generic API needs to use them, but there's no blocker on the user from this (it can convert with or without the platform it runs on) - but it's hardly a tough sell.
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
The meaning of clk_enable/disable has been changed and they won't work without calling clk_prepare/unprepare. So, these are definitely new APIs. If it weren't new APIs, then none of the general drivers would need to change.
Yes and no. I disagree that the meaning of clk_enable/disable() has changed. It hasn't. What has changed is the preconditions for calling those functions, and necessarily so in the interest of being able to unify the different implementations.
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke.
There is a misunderstanding. I am not calling for a redesign. I am simply stating that the current maturity level of the API and code should be documented in the Kconfig dependencies or description text before the code goes upstream. The objectives are to make future changes easier, set expectations, and clearly disclose the extent to which the API and code will need to change.
The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes.
I hope you are right. To me, these conclusions seem unlikely. It seems equally likely that these rationales will make it much more difficult to change the code once it's upstream and platforms are depending on it. Particularly given the ongoing sensitivity to reducing "churn" of mainline code, so publicly discussed. So it seems like a good idea to attempt to address these potential roadblocks and criticisms to major clock framework changes early.
And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily.
Yes, simple extensions should be straightforward. Of greater concern are changes to the existing interface that will probably be required. These could involve significant changes to driver or platform code. It seems likely that there will be strong inertia to making these changes after platforms and drivers are converted.
However, if we clearly state that these API changes are likely until the API is well-defined, we will hopefully reduce some angst by disclosing what some of us know.
...
One last comment to address which is orthogonal to the technical content of this discussion.
Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly?
One might ask this. If one were to ask this, another might briefly outline the participation in public and private clock discussions at Linaro Connect in Budapest and Redwood Shores, at LPC in Santa Rosa, at ELCE/KS in Prague, at ELC in Redwood Shores, in conference calls, IRC sessions, and private E-mails with many of the people included in the header of this message, not to mention the list posts.
None of the concerns that have been described are new. There has been an endeavour to discuss them with anyone who seemed even remotely interested.
Of course it is a personal source of regret that the participation could not have been greater, but this regret is hardly limited to the common clock project.
regards,
- Paul
On Wed, 21 Mar 2012, Paul Walmsley wrote:
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke.
There is a misunderstanding. I am not calling for a redesign. I am simply stating that the current maturity level of the API and code should be documented in the Kconfig dependencies or description text before the code goes upstream. The objectives are to make future changes easier, set expectations, and clearly disclose the extent to which the API and code will need to change.
Maybe there is no actual consensus on that extent.
The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes.
I hope you are right. To me, these conclusions seem unlikely. It seems equally likely that these rationales will make it much more difficult to change the code once it's upstream and platforms are depending on it.
No code should go upstream if no one depends on it. Therefore we change code that many platforms depend on all the time. What is killing us is the need to synchronize with multiple external code bases scattered around.
Particularly given the ongoing sensitivity to reducing "churn" of mainline code, so publicly discussed.
Please stop buying into that crap. We congratulate ourselves every merge cycles with the current process being able to deal with around half a million of lines changed every 3 months or so. It's pointless churn that is frowned upon, not useful and incremental API changes. I don't think that "pointless" would apply here.
So it seems like a good idea to attempt to address these potential roadblocks and criticisms to major clock framework changes early.
I understand your concern, however I don't think it is as serious as you are making it.
One last comment to address which is orthogonal to the technical content of this discussion.
Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly?
One might ask this. If one were to ask this, another might briefly outline the participation in public and private clock discussions at Linaro Connect in Budapest and Redwood Shores, at LPC in Santa Rosa, at ELCE/KS in Prague, at ELC in Redwood Shores, in conference calls, IRC sessions, and private E-mails with many of the people included in the header of this message, not to mention the list posts.
Sure. I was there too and came across you many times. I just don't understand why some apparent consensus was built around the current submission, that people involved appeared to be highly satisfied at last, given the emphasis you are giving to your present concern which doesn't seem to be widely shared. This is a bit surprising.
None of the concerns that have been described are new. There has been an endeavour to discuss them with anyone who seemed even remotely interested.
Let's change tactics then. We've been discussing this code for over two years and no one could really benefit from it during that time. Maybe future discussion could become more productive and concrete when some code is merged _and_ used at last.
Nicolas
The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw.
See Documentation/clk.txt for more details.
This patch is based on the work of Jeremy Kerr, which in turn was based on the work of Ben Herrenschmidt.
Signed-off-by: Mike Turquette mturquette@linaro.org Signed-off-by: Mike Turquette mturquette@ti.com Reviewed-by: Thomas Gleixner tglx@linutronix.de Tested-by: Andrew Lunn andrew@lunn.ch Reviewed-by: Rob Herring <rob.herring <at> calxeda.com> Cc: Russell King linux@arm.linux.org.uk Cc: Jeremy Kerr jeremy.kerr@canonical.com Cc: Arnd Bergman arnd.bergmann@linaro.org Cc: Paul Walmsley paul@pwsan.com Cc: Shawn Guo shawn.guo@freescale.com Cc: Sascha Hauer s.hauer@pengutronix.de Cc: Richard Zhao richard.zhao@linaro.org Cc: Saravana Kannan skannan@codeaurora.org Cc: Magnus Damm magnus.damm@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com Cc: Linus Walleij linus.walleij@stericsson.com Cc: Stephen Boyd sboyd@codeaurora.org Cc: Amit Kucheria amit.kucheria@linaro.org Cc: Deepak Saxena dsaxena@linaro.org Cc: Grant Likely grant.likely@secretlab.ca --- Changes since v6: * clk_set_rate rewritten to set clock rates from top-to-bottom * should also reduce pre-rate change notifier noise (thanks Sascha) * fixed return types for __clk_get_(enable|prepare)_count * some NULL pointer fixes for handling .parent_names and .parents * removed unnecessary checks for recursive calls in a few helpers * made __clk_round_rate more sane and aligned with clk_round_rate * parent rates are returned if .round_rate is not implemented * fixed CONFIG_COMMON_CLK_DEBUGFS to select DEBUG_FS
Changes since v5: * new CONFIG_COMMON_CLK_DISABLE_UNUSED feature * results in a new clk_op callback, .is_enabled * new helpers * __clk_get_prepare_count * __clk_get_enable_count * __clk_is_enabled * fix bug in __clk_get_rate for orphan clocks
drivers/clk/Kconfig | 40 ++ drivers/clk/Makefile | 1 + drivers/clk/clk.c | 1461 ++++++++++++++++++++++++++++++++++++++++++ include/linux/clk-private.h | 72 ++ include/linux/clk-provider.h | 173 +++++ include/linux/clk.h | 68 ++- 6 files changed, 1810 insertions(+), 5 deletions(-) create mode 100644 drivers/clk/clk.c create mode 100644 include/linux/clk-private.h create mode 100644 include/linux/clk-provider.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 9b3cd08..2eaf17e 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -8,3 +8,43 @@ config HAVE_CLK_PREPARE
config HAVE_MACH_CLKDEV bool + +menuconfig COMMON_CLK + bool "Common Clock Framework" + select HAVE_CLK_PREPARE + ---help--- + The common clock framework is a single definition of struct + clk, useful across many platforms, as well as an + implementation of the clock API in include/linux/clk.h. + Architectures utilizing the common struct clk should select + this automatically, but it may be necessary to manually select + this option for loadable modules requiring the common clock + framework. + + If in doubt, say "N". + +if COMMON_CLK + +config COMMON_CLK_DISABLE_UNUSED + bool "Disabled unused clocks at boot" + depends on COMMON_CLK + ---help--- + Traverses the entire clock tree and disables any clocks that are + enabled in hardware but have not been enabled by any device drivers. + This saves power and keeps the software model of the clock in line + with reality. + + If in doubt, say "N". + +config COMMON_CLK_DEBUG + bool "DebugFS representation of clock tree" + depends on COMMON_CLK + select DEBUG_FS + ---help--- + Creates a directory hierchy in debugfs for visualizing the clk + tree structure. Each directory contains read-only members + that export information specific to that clk node: clk_rate, + clk_flags, clk_prepare_count, clk_enable_count & + clk_notifier_count. + +endif diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 07613fa..ff362c4 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -1,2 +1,3 @@
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o +obj-$(CONFIG_COMMON_CLK) += clk.o diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c new file mode 100644 index 0000000..9cf6f59 --- /dev/null +++ b/drivers/clk/clk.c @@ -0,0 +1,1461 @@ +/* + * Copyright (C) 2010-2011 Canonical Ltd jeremy.kerr@canonical.com + * Copyright (C) 2011-2012 Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Standard functionality for the common clock API. See Documentation/clk.txt + */ + +#include <linux/clk-private.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/err.h> +#include <linux/list.h> +#include <linux/slab.h> + +static DEFINE_SPINLOCK(enable_lock); +static DEFINE_MUTEX(prepare_lock); + +static HLIST_HEAD(clk_root_list); +static HLIST_HEAD(clk_orphan_list); +static LIST_HEAD(clk_notifier_list); + +/*** debugfs support ***/ + +#ifdef CONFIG_COMMON_CLK_DEBUG +#include <linux/debugfs.h> + +static struct dentry *rootdir; +static struct dentry *orphandir; +static int inited = 0; + +/* caller must hold prepare_lock */ +static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry) +{ + struct dentry *d; + int ret = -ENOMEM; + + if (!clk || !pdentry) { + ret = -EINVAL; + goto out; + } + + d = debugfs_create_dir(clk->name, pdentry); + if (!d) + goto out; + + clk->dentry = d; + + d = debugfs_create_u32("clk_rate", S_IRUGO, clk->dentry, + (u32 *)&clk->rate); + if (!d) + goto err_out; + + d = debugfs_create_x32("clk_flags", S_IRUGO, clk->dentry, + (u32 *)&clk->flags); + if (!d) + goto err_out; + + d = debugfs_create_u32("clk_prepare_count", S_IRUGO, clk->dentry, + (u32 *)&clk->prepare_count); + if (!d) + goto err_out; + + d = debugfs_create_u32("clk_enable_count", S_IRUGO, clk->dentry, + (u32 *)&clk->enable_count); + if (!d) + goto err_out; + + d = debugfs_create_u32("clk_notifier_count", S_IRUGO, clk->dentry, + (u32 *)&clk->notifier_count); + if (!d) + goto err_out; + + ret = 0; + goto out; + +err_out: + debugfs_remove(clk->dentry); +out: + return ret; +} + +/* caller must hold prepare_lock */ +static int clk_debug_create_subtree(struct clk *clk, struct dentry *pdentry) +{ + struct clk *child; + struct hlist_node *tmp; + int ret = -EINVAL;; + + if (!clk || !pdentry) + goto out; + + ret = clk_debug_create_one(clk, pdentry); + + if (ret) + goto out; + + hlist_for_each_entry(child, tmp, &clk->children, child_node) + clk_debug_create_subtree(child, clk->dentry); + + ret = 0; +out: + return ret; +} + +/** + * clk_debug_register - add a clk node to the debugfs clk tree + * @clk: the clk being added to the debugfs clk tree + * + * Dynamically adds a clk to the debugfs clk tree if debugfs has been + * initialized. Otherwise it bails out early since the debugfs clk tree + * will be created lazily by clk_debug_init as part of a late_initcall. + * + * Caller must hold prepare_lock. Only clk_init calls this function (so + * far) so this is taken care. + */ +static int clk_debug_register(struct clk *clk) +{ + struct clk *parent; + struct dentry *pdentry; + int ret = 0; + + if (!inited) + goto out; + + parent = clk->parent; + + /* + * Check to see if a clk is a root clk. Also check that it is + * safe to add this clk to debugfs + */ + if (!parent) + if (clk->flags & CLK_IS_ROOT) + pdentry = rootdir; + else + pdentry = orphandir; + else + if (parent->dentry) + pdentry = parent->dentry; + else + goto out; + + ret = clk_debug_create_subtree(clk, pdentry); + +out: + return ret; +} + +/** + * clk_debug_init - lazily create the debugfs clk tree visualization + * + * clks are often initialized very early during boot before memory can + * be dynamically allocated and well before debugfs is setup. + * clk_debug_init walks the clk tree hierarchy while holding + * prepare_lock and creates the topology as part of a late_initcall, + * thus insuring that clks initialized very early will still be + * represented in the debugfs clk tree. This function should only be + * called once at boot-time, and all other clks added dynamically will + * be done so with clk_debug_register. + */ +static int __init clk_debug_init(void) +{ + struct clk *clk; + struct hlist_node *tmp; + + rootdir = debugfs_create_dir("clk", NULL); + + if (!rootdir) + return -ENOMEM; + + orphandir = debugfs_create_dir("orphans", rootdir); + + if (!orphandir) + return -ENOMEM; + + mutex_lock(&prepare_lock); + + hlist_for_each_entry(clk, tmp, &clk_root_list, child_node) + clk_debug_create_subtree(clk, rootdir); + + hlist_for_each_entry(clk, tmp, &clk_orphan_list, child_node) + clk_debug_create_subtree(clk, orphandir); + + inited = 1; + + mutex_unlock(&prepare_lock); + + return 0; +} +late_initcall(clk_debug_init); +#else +static inline int clk_debug_register(struct clk *clk) { return 0; } +#endif /* CONFIG_COMMON_CLK_DEBUG */ + +#ifdef CONFIG_COMMON_CLK_DISABLE_UNUSED +/* caller must hold prepare_lock */ +static void clk_disable_unused_subtree(struct clk *clk) +{ + struct clk *child; + struct hlist_node *tmp; + unsigned long flags; + + if (!clk) + goto out; + + hlist_for_each_entry(child, tmp, &clk->children, child_node) + clk_disable_unused_subtree(child); + + spin_lock_irqsave(&enable_lock, flags); + + if (clk->enable_count) + goto unlock_out; + + if (clk->flags & CLK_IGNORE_UNUSED) + goto unlock_out; + + if (__clk_is_enabled(clk) && clk->ops->disable) + clk->ops->disable(clk->hw); + +unlock_out: + spin_unlock_irqrestore(&enable_lock, flags); + +out: + return; +} + +static int clk_disable_unused(void) +{ + struct clk *clk; + struct hlist_node *tmp; + + mutex_lock(&prepare_lock); + + hlist_for_each_entry(clk, tmp, &clk_root_list, child_node) + clk_disable_unused_subtree(clk); + + hlist_for_each_entry(clk, tmp, &clk_orphan_list, child_node) + clk_disable_unused_subtree(clk); + + mutex_unlock(&prepare_lock); + + return 0; +} +late_initcall(clk_disable_unused); +#else +static inline int clk_disable_unused(struct clk *clk) { return 0; } +#endif /* CONFIG_COMMON_CLK_DISABLE_UNUSED */ + +/*** helper functions ***/ + +inline const char *__clk_get_name(struct clk *clk) +{ + return !clk ? NULL : clk->name; +} + +inline struct clk_hw *__clk_get_hw(struct clk *clk) +{ + return !clk ? NULL : clk->hw; +} + +inline u8 __clk_get_num_parents(struct clk *clk) +{ + return !clk ? -EINVAL : clk->num_parents; +} + +inline struct clk *__clk_get_parent(struct clk *clk) +{ + return !clk ? NULL : clk->parent; +} + +inline int __clk_get_enable_count(struct clk *clk) +{ + return !clk ? -EINVAL : clk->enable_count; +} + +inline int __clk_get_prepare_count(struct clk *clk) +{ + return !clk ? -EINVAL : clk->prepare_count; +} + +unsigned long __clk_get_rate(struct clk *clk) +{ + unsigned long ret; + + if (!clk) { + ret = -EINVAL; + goto out; + } + + ret = clk->rate; + + if (clk->flags & CLK_IS_ROOT) + goto out; + + if (!clk->parent) + ret = -ENODEV; + +out: + return ret; +} + +inline unsigned long __clk_get_flags(struct clk *clk) +{ + return !clk ? -EINVAL : clk->flags; +} + +int __clk_is_enabled(struct clk *clk) +{ + int ret; + + if (!clk) + return -EINVAL; + + /* + * .is_enabled is only mandatory for clocks that gate + * fall back to software usage counter if .is_enabled is missing + */ + if (!clk->ops->is_enabled) { + ret = clk->enable_count ? 1 : 0; + goto out; + } + + ret = clk->ops->is_enabled(clk->hw); +out: + return ret; +} + +static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk) +{ + struct clk *child; + struct clk *ret; + struct hlist_node *tmp; + + if (!strcmp(clk->name, name)) + return clk; + + hlist_for_each_entry(child, tmp, &clk->children, child_node) { + ret = __clk_lookup_subtree(name, child); + if (ret) + return ret; + } + + return NULL; +} + +struct clk *__clk_lookup(const char *name) +{ + struct clk *root_clk; + struct clk *ret; + struct hlist_node *tmp; + + if (!name) + return NULL; + + /* search the 'proper' clk tree first */ + hlist_for_each_entry(root_clk, tmp, &clk_root_list, child_node) { + ret = __clk_lookup_subtree(name, root_clk); + if (ret) + return ret; + } + + /* if not found, then search the orphan tree */ + hlist_for_each_entry(root_clk, tmp, &clk_orphan_list, child_node) { + ret = __clk_lookup_subtree(name, root_clk); + if (ret) + return ret; + } + + return NULL; +} + +/*** clk api ***/ + +void __clk_unprepare(struct clk *clk) +{ + if (!clk) + return; + + if (WARN_ON(clk->prepare_count == 0)) + return; + + if (--clk->prepare_count > 0) + return; + + WARN_ON(clk->enable_count > 0); + + if (clk->ops->unprepare) + clk->ops->unprepare(clk->hw); + + __clk_unprepare(clk->parent); +} + +/** + * clk_unprepare - undo preparation of a clock source + * @clk: the clk being unprepare + * + * clk_unprepare may sleep, which differentiates it from clk_disable. In a + * simple case, clk_unprepare can be used instead of clk_disable to gate a clk + * if the operation may sleep. One example is a clk which is accessed over + * I2c. In the complex case a clk gate operation may require a fast and a slow + * part. It is this reason that clk_unprepare and clk_disable are not mutually + * exclusive. In fact clk_disable must be called before clk_unprepare. + */ +void clk_unprepare(struct clk *clk) +{ + mutex_lock(&prepare_lock); + __clk_unprepare(clk); + mutex_unlock(&prepare_lock); +} +EXPORT_SYMBOL_GPL(clk_unprepare); + +int __clk_prepare(struct clk *clk) +{ + int ret = 0; + + if (!clk) + return 0; + + if (clk->prepare_count == 0) { + ret = __clk_prepare(clk->parent); + if (ret) + return ret; + + if (clk->ops->prepare) { + ret = clk->ops->prepare(clk->hw); + if (ret) { + __clk_unprepare(clk->parent); + return ret; + } + } + } + + clk->prepare_count++; + + return 0; +} + +/** + * clk_prepare - prepare a clock source + * @clk: the clk being prepared + * + * clk_prepare may sleep, which differentiates it from clk_enable. In a simple + * case, clk_prepare can be used instead of clk_enable to ungate a clk if the + * operation may sleep. One example is a clk which is accessed over I2c. In + * the complex case a clk ungate operation may require a fast and a slow part. + * It is this reason that clk_prepare and clk_enable are not mutually + * exclusive. In fact clk_prepare must be called before clk_enable. + * Returns 0 on success, -EERROR otherwise. + */ +int clk_prepare(struct clk *clk) +{ + int ret; + + mutex_lock(&prepare_lock); + ret = __clk_prepare(clk); + mutex_unlock(&prepare_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_prepare); + +static void __clk_disable(struct clk *clk) +{ + if (!clk) + return; + + if (WARN_ON(clk->enable_count == 0)) + return; + + if (--clk->enable_count > 0) + return; + + if (clk->ops->disable) + clk->ops->disable(clk->hw); + + __clk_disable(clk->parent); +} + +/** + * clk_disable - gate a clock + * @clk: the clk being gated + * + * clk_disable must not sleep, which differentiates it from clk_unprepare. In + * a simple case, clk_disable can be used instead of clk_unprepare to gate a + * clk if the operation is fast and will never sleep. One example is a + * SoC-internal clk which is controlled via simple register writes. In the + * complex case a clk gate operation may require a fast and a slow part. It is + * this reason that clk_unprepare and clk_disable are not mutually exclusive. + * In fact clk_disable must be called before clk_unprepare. + */ +void clk_disable(struct clk *clk) +{ + unsigned long flags; + + spin_lock_irqsave(&enable_lock, flags); + __clk_disable(clk); + spin_unlock_irqrestore(&enable_lock, flags); +} +EXPORT_SYMBOL_GPL(clk_disable); + +static int __clk_enable(struct clk *clk) +{ + int ret = 0; + + if (!clk) + return 0; + + if (WARN_ON(clk->prepare_count == 0)) + return -ESHUTDOWN; + + if (clk->enable_count == 0) { + ret = __clk_enable(clk->parent); + + if (ret) + return ret; + + if (clk->ops->enable) { + ret = clk->ops->enable(clk->hw); + if (ret) { + __clk_disable(clk->parent); + return ret; + } + } + } + + clk->enable_count++; + return 0; +} + +/** + * clk_enable - ungate a clock + * @clk: the clk being ungated + * + * clk_enable must not sleep, which differentiates it from clk_prepare. In a + * simple case, clk_enable can be used instead of clk_prepare to ungate a clk + * if the operation will never sleep. One example is a SoC-internal clk which + * is controlled via simple register writes. In the complex case a clk ungate + * operation may require a fast and a slow part. It is this reason that + * clk_enable and clk_prepare are not mutually exclusive. In fact clk_prepare + * must be called before clk_enable. Returns 0 on success, -EERROR + * otherwise. + */ +int clk_enable(struct clk *clk) +{ + unsigned long flags; + int ret; + + spin_lock_irqsave(&enable_lock, flags); + ret = __clk_enable(clk); + spin_unlock_irqrestore(&enable_lock, flags); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_enable); + +/** + * clk_get_rate - return the rate of clk + * @clk: the clk whose rate is being returned + * + * Simply returns the cached rate of the clk. Does not query the hardware. If + * clk is NULL then returns -EINVAL. + */ +unsigned long clk_get_rate(struct clk *clk) +{ + unsigned long rate; + + mutex_lock(&prepare_lock); + rate = __clk_get_rate(clk); + mutex_unlock(&prepare_lock); + + return rate; +} +EXPORT_SYMBOL_GPL(clk_get_rate); + +/** + * __clk_round_rate - round the given rate for a clk + * @clk: round the rate of this clock + * + * Caller must hold prepare_lock. Useful for clk_ops such as .set_rate + */ +unsigned long __clk_round_rate(struct clk *clk, unsigned long rate) +{ + unsigned long unused; + + if (!clk) + return -EINVAL; + + if (!clk->ops->round_rate) + return clk->rate; + + if (clk->flags & CLK_SET_RATE_PARENT) + return clk->ops->round_rate(clk->hw, rate, &unused); + else + return clk->ops->round_rate(clk->hw, rate, NULL); +} + +/** + * clk_round_rate - round the given rate for a clk + * @clk: the clk for which we are rounding a rate + * @rate: the rate which is to be rounded + * + * Takes in a rate as input and rounds it to a rate that the clk can actually + * use which is then returned. If clk doesn't support round_rate operation + * then the parent rate is returned. + */ +long clk_round_rate(struct clk *clk, unsigned long rate) +{ + unsigned long ret; + + mutex_lock(&prepare_lock); + ret = __clk_round_rate(clk, rate); + mutex_unlock(&prepare_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_round_rate); + +/** + * __clk_notify - call clk notifier chain + * @clk: struct clk * that is changing rate + * @msg: clk notifier type (see include/linux/clk.h) + * @old_rate: old clk rate + * @new_rate: new clk rate + * + * Triggers a notifier call chain on the clk rate-change notification + * for 'clk'. Passes a pointer to the struct clk and the previous + * and current rates to the notifier callback. Intended to be called by + * internal clock code only. Returns NOTIFY_DONE from the last driver + * called if all went well, or NOTIFY_STOP or NOTIFY_BAD immediately if + * a driver returns that. + */ +static int __clk_notify(struct clk *clk, unsigned long msg, + unsigned long old_rate, unsigned long new_rate) +{ + struct clk_notifier *cn; + struct clk_notifier_data cnd; + int ret = NOTIFY_DONE; + + cnd.clk = clk; + cnd.old_rate = old_rate; + cnd.new_rate = new_rate; + + list_for_each_entry(cn, &clk_notifier_list, node) { + if (cn->clk == clk) { + ret = srcu_notifier_call_chain(&cn->notifier_head, msg, + &cnd); + break; + } + } + + return ret; +} + +/** + * __clk_recalc_rates + * @clk: first clk in the subtree + * @msg: notification type (see include/linux/clk.h) + * + * Walks the subtree of clks starting with clk and recalculates rates as it + * goes. Note that if a clk does not implement the .recalc_rate callback then + * it is assumed that the clock will take on the rate of it's parent. + * + * clk_recalc_rates also propagates the POST_RATE_CHANGE notification, + * if necessary. + * + * Caller must hold prepare_lock. + */ +static void __clk_recalc_rates(struct clk *clk, unsigned long msg) +{ + unsigned long old_rate; + unsigned long parent_rate = 0; + struct hlist_node *tmp; + struct clk *child; + + old_rate = clk->rate; + + if (clk->parent) + parent_rate = clk->parent->rate; + + if (clk->ops->recalc_rate) + clk->rate = clk->ops->recalc_rate(clk->hw, parent_rate); + else + clk->rate = parent_rate; + + /* + * ignore NOTIFY_STOP and NOTIFY_BAD return values for POST_RATE_CHANGE + * & ABORT_RATE_CHANGE notifiers + */ + if (clk->notifier_count && msg) + __clk_notify(clk, msg, old_rate, clk->rate); + + hlist_for_each_entry(child, tmp, &clk->children, child_node) + __clk_recalc_rates(child, msg); +} + +/** + * __clk_speculate_rates + * @clk: first clk in the subtree + * @parent_rate: the "future" rate of clk's parent + * + * Walks the subtree of clks starting with clk, speculating rates as it + * goes and firing off PRE_RATE_CHANGE notifications as necessary. + * + * Unlike clk_recalc_rates, clk_speculate_rates exists only for sending + * pre-rate change notifications and returns early if no clks in the + * subtree have subscribed to the notifications. Note that if a clk does not + * implement the .recalc_rate callback then it is assumed that the clock will + * take on the rate of it's parent. + * + * Caller must hold prepare_lock. + */ +static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate) +{ + struct hlist_node *tmp; + struct clk *child; + unsigned long new_rate; + int ret = NOTIFY_DONE; + + if (clk->ops->recalc_rate) + new_rate = clk->ops->recalc_rate(clk->hw, parent_rate); + else + new_rate = parent_rate; + + /* abort the rate change if a driver returns NOTIFY_BAD */ + if (clk->notifier_count) + ret = __clk_notify(clk, PRE_RATE_CHANGE, clk->rate, new_rate); + + if (ret == NOTIFY_BAD) + goto out; + + hlist_for_each_entry(child, tmp, &clk->children, child_node) { + ret = __clk_speculate_rates(child, new_rate); + if (ret == NOTIFY_BAD) + break; + } + +out: + return ret; +} + +static void clk_calc_subtree(struct clk *clk, unsigned long new_rate) +{ + struct clk *child; + struct hlist_node *tmp; + + clk->new_rate = new_rate; + + hlist_for_each_entry(child, tmp, &clk->children, child_node) { + if (child->ops->recalc_rate) + child->new_rate = child->ops->recalc_rate(child->hw, new_rate); + else + child->new_rate = new_rate; + clk_calc_subtree(child, child->new_rate); + } +} + +/* + * calculate the new rates returning the topmost clock that has to be + * changed. + */ +static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) +{ + struct clk *top = clk; + unsigned long best_parent_rate = clk->parent->rate; + unsigned long new_rate; + + if (!clk->ops->round_rate && !(clk->flags & CLK_SET_RATE_PARENT)) { + clk->new_rate = clk->rate; + return NULL; + } + + if (!clk->ops->round_rate && (clk->flags & CLK_SET_RATE_PARENT)) { + top = clk_calc_new_rates(clk->parent, rate); + new_rate = clk->new_rate = clk->parent->new_rate; + + goto out; + } + + if (clk->flags & CLK_SET_RATE_PARENT) + new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate); + else + new_rate = clk->ops->round_rate(clk->hw, rate, NULL); + + if (best_parent_rate != clk->parent->rate) { + top = clk_calc_new_rates(clk->parent, best_parent_rate); + + goto out; + } + +out: + clk_calc_subtree(clk, new_rate); + + return top; +} + +/* + * Notify about rate changes in a subtree. Always walk down the whole tree + * so that in case of an error we can walk down the whole tree again and + * abort the change. + */ +static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long event) +{ + struct hlist_node *tmp; + struct clk *child, *fail_clk = NULL; + int ret = NOTIFY_DONE; + + if (clk->rate == clk->new_rate) + return 0; + + if (clk->notifier_count) { + ret = __clk_notify(clk, event, clk->rate, clk->new_rate); + if (ret == NOTIFY_BAD) + fail_clk = clk; + } + + hlist_for_each_entry(child, tmp, &clk->children, child_node) { + clk = clk_propagate_rate_change(child, event); + if (clk) + fail_clk = clk; + } + + return fail_clk; +} + +/* + * walk down a subtree and set the new rates notifying the rate + * change on the way + */ +static void clk_change_rate(struct clk *clk) +{ + struct clk *child; + unsigned long old_rate; + struct hlist_node *tmp; + + old_rate = clk->rate; + + if (clk->ops->set_rate) + clk->ops->set_rate(clk->hw, clk->new_rate); + + if (clk->ops->recalc_rate) + clk->rate = clk->ops->recalc_rate(clk->hw, + clk->parent->rate); + else + clk->rate = clk->parent->rate; + + if (clk->notifier_count && old_rate != clk->rate) + __clk_notify(clk, POST_RATE_CHANGE, old_rate, clk->rate); + + hlist_for_each_entry(child, tmp, &clk->children, child_node) + clk_change_rate(child); +} + +/** + * clk_set_rate - specify a new rate for clk + * @clk: the clk whose rate is being changed + * @rate: the new rate for clk + * + * In the simplest case clk_set_rate will only change the rate of clk. + * + * If clk has the CLK_SET_RATE_GATE flag set and it is enabled this call + * will fail; only when the clk is disabled will it be able to change + * its rate. + * + * Setting the CLK_SET_RATE_PARENT flag allows clk_set_rate to + * recursively propagate up to clk's parent; whether or not this happens + * depends on the outcome of clk's .round_rate implementation. If + * *parent_rate is 0 after calling .round_rate then upstream parent + * propagation is ignored. If *parent_rate comes back with a new rate + * for clk's parent then we propagate up to clk's parent and set it's + * rate. Upward propagation will continue until either a clk does not + * support the CLK_SET_RATE_PARENT flag or .round_rate stops requesting + * changes to clk's parent_rate. If there is a failure during upstream + * propagation then clk_set_rate will unwind and restore each clk's rate + * that had been successfully changed. Afterwards a rate change abort + * notification will be propagated downstream, starting from the clk + * that failed. + * + * At the end of all of the rate setting, clk_set_rate internally calls + * __clk_recalc_rates and propagates the rate changes downstream, + * starting from the highest clk whose rate was changed. This has the + * added benefit of propagating post-rate change notifiers. + * + * Note that while post-rate change and rate change abort notifications + * are guaranteed to be sent to a clk only once per call to + * clk_set_rate, pre-change notifications will be sent for every clk + * whose rate is changed. Stacking pre-change notifications is noisy + * for the drivers subscribed to them, but this allows drivers to react + * to intermediate clk rate changes up until the point where the final + * rate is achieved at the end of upstream propagation. + * + * Returns 0 on success, -EERROR otherwise. + */ +int clk_set_rate(struct clk *clk, unsigned long rate) +{ + struct clk *top, *fail_clk; + int ret = 0; + + /* prevent racing with updates to the clock topology */ + mutex_lock(&prepare_lock); + + /* bail early if nothing to do */ + if (rate == clk->rate) + goto out; + + /* calculate new rates and get the topmost changed clock */ + top = clk_calc_new_rates(clk, rate); + if (!top) { + ret = -EINVAL; + goto out; + } + + /* notify that we are about to change rates */ + fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE); + if (fail_clk) { + pr_warn("%s: failed to set %s rate\n", __func__, + fail_clk->name); + clk_propagate_rate_change(top, ABORT_RATE_CHANGE); + ret = -EBUSY; + goto out; + } + + /* change the rates */ + clk_change_rate(top); + + mutex_unlock(&prepare_lock); + + return 0; +out: + mutex_unlock(&prepare_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_set_rate); + +/** + * clk_get_parent - return the parent of a clk + * @clk: the clk whose parent gets returned + * + * Simply returns clk->parent. Returns NULL if clk is NULL. + */ +struct clk *clk_get_parent(struct clk *clk) +{ + struct clk *parent; + + mutex_lock(&prepare_lock); + parent = __clk_get_parent(clk); + mutex_unlock(&prepare_lock); + + return parent; +} +EXPORT_SYMBOL_GPL(clk_get_parent); + +/* + * .get_parent is mandatory for clocks with multiple possible parents. It is + * optional for single-parent clocks. Always call .get_parent if it is + * available and WARN if it is missing for multi-parent clocks. + * + * For single-parent clocks without .get_parent, first check to see if the + * .parents array exists, and if so use it to avoid an expensive tree + * traversal. If .parents does not exist then walk the tree with __clk_lookup. + */ +static struct clk *__clk_init_parent(struct clk *clk) +{ + struct clk *ret = NULL; + u8 index; + + /* handle the trivial cases */ + + if (!clk->num_parents) + goto out; + + if (clk->num_parents == 1) { + if (IS_ERR_OR_NULL(clk->parent)) + ret = clk->parent = __clk_lookup(clk->parent_names[0]); + ret = clk->parent; + goto out; + } + + if (!clk->ops->get_parent) { + WARN(!clk->ops->get_parent, + "%s: multi-parent clocks must implement .get_parent\n", + __func__); + goto out; + }; + + /* + * Do our best to cache parent clocks in clk->parents. This prevents + * unnecessary and expensive calls to __clk_lookup. We don't set + * clk->parent here; that is done by the calling function + */ + + index = clk->ops->get_parent(clk->hw); + + if (!clk->parents) + clk->parents = + kmalloc((sizeof(struct clk*) * clk->num_parents), + GFP_KERNEL); + + if (!clk->parents) + ret = __clk_lookup(clk->parent_names[index]); + else if (!clk->parents[index]) + ret = clk->parents[index] = + __clk_lookup(clk->parent_names[index]); + else + ret = clk->parents[index]; + +out: + return ret; +} + +void __clk_reparent(struct clk *clk, struct clk *new_parent) +{ +#ifdef CONFIG_COMMON_CLK_DEBUG + struct dentry *d; + struct dentry *new_parent_d; +#endif + + if (!clk || !new_parent) + return; + + hlist_del(&clk->child_node); + + if (new_parent) + hlist_add_head(&clk->child_node, &new_parent->children); + else + hlist_add_head(&clk->child_node, &clk_orphan_list); + +#ifdef CONFIG_COMMON_CLK_DEBUG + if (!inited) + goto out; + + if (new_parent) + new_parent_d = new_parent->dentry; + else + new_parent_d = orphandir; + + d = debugfs_rename(clk->dentry->d_parent, clk->dentry, + new_parent_d, clk->name); + if (d) + clk->dentry = d; + else + pr_debug("%s: failed to rename debugfs entry for %s\n", + __func__, clk->name); +out: +#endif + + clk->parent = new_parent; + + __clk_recalc_rates(clk, POST_RATE_CHANGE); +} + +static int __clk_set_parent(struct clk *clk, struct clk *parent) +{ + struct clk *old_parent; + unsigned long flags; + int ret = -EINVAL; + u8 i; + + old_parent = clk->parent; + + /* find index of new parent clock using cached parent ptrs */ + for (i = 0; i < clk->num_parents; i++) + if (clk->parents[i] == parent) + break; + + /* + * find index of new parent clock using string name comparison + * also try to cache the parent to avoid future calls to __clk_lookup + */ + if (i == clk->num_parents) + for (i = 0; i < clk->num_parents; i++) + if (!strcmp(clk->parent_names[i], parent->name)) { + clk->parents[i] = __clk_lookup(parent->name); + break; + } + + if (i == clk->num_parents) { + pr_debug("%s: clock %s is not a possible parent of clock %s\n", + __func__, parent->name, clk->name); + goto out; + } + + /* migrate prepare and enable */ + if (clk->prepare_count) + __clk_prepare(parent); + + /* FIXME replace with clk_is_enabled(clk) someday */ + spin_lock_irqsave(&enable_lock, flags); + if (clk->enable_count) + __clk_enable(parent); + spin_unlock_irqrestore(&enable_lock, flags); + + /* change clock input source */ + ret = clk->ops->set_parent(clk->hw, i); + + /* clean up old prepare and enable */ + spin_lock_irqsave(&enable_lock, flags); + if (clk->enable_count) + __clk_disable(old_parent); + spin_unlock_irqrestore(&enable_lock, flags); + + if (clk->prepare_count) + __clk_unprepare(old_parent); + +out: + return ret; +} + +/** + * clk_set_parent - switch the parent of a mux clk + * @clk: the mux clk whose input we are switching + * @parent: the new input to clk + * + * Re-parent clk to use parent as it's new input source. If clk has the + * CLK_SET_PARENT_GATE flag set then clk must be gated for this + * operation to succeed. After successfully changing clk's parent + * clk_set_parent will update the clk topology, sysfs topology and + * propagate rate recalculation via __clk_recalc_rates. Returns 0 on + * success, -EERROR otherwise. + */ +int clk_set_parent(struct clk *clk, struct clk *parent) +{ + int ret = 0; + + if (!clk || !clk->ops) + return -EINVAL; + + if (!clk->ops->set_parent) + return -ENOSYS; + + /* prevent racing with updates to the clock topology */ + mutex_lock(&prepare_lock); + + if (clk->parent == parent) + goto out; + + /* propagate PRE_RATE_CHANGE notifications */ + if (clk->notifier_count) + ret = __clk_speculate_rates(clk, parent->rate); + + /* abort if a driver objects */ + if (ret == NOTIFY_STOP) + goto out; + + /* only re-parent if the clock is not in use */ + if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count) + ret = -EBUSY; + else + ret = __clk_set_parent(clk, parent); + + /* propagate ABORT_RATE_CHANGE if .set_parent failed */ + if (ret) { + __clk_recalc_rates(clk, ABORT_RATE_CHANGE); + goto out; + } + + /* propagate rate recalculation downstream */ + __clk_reparent(clk, parent); + +out: + mutex_unlock(&prepare_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_set_parent); + +/** + * __clk_init - initialize the data structures in a struct clk + * @dev: device initializing this clk, placeholder for now + * @clk: clk being initialized + * + * Initializes the lists in struct clk, queries the hardware for the + * parent and rate and sets them both. + * + * Any struct clk passed into __clk_init must have the following members + * populated: + * .name + * .ops + * .hw + * .parent_names + * .num_parents + * .flags + * + * Essentially, everything that would normally be passed into clk_register is + * assumed to be initialized already in __clk_init. The other members may be + * populated, but are optional. + * + * __clk_init is only exposed via clk-private.h and is intended for use with + * very large numbers of clocks that need to be statically initialized. It is + * a layering violation to include clk-private.h from any code which implements + * a clock's .ops; as such any statically initialized clock data MUST be in a + * separate C file from the logic that implements it's operations. + */ +void __clk_init(struct device *dev, struct clk *clk) +{ + int i; + struct clk *orphan; + struct hlist_node *tmp, *tmp2; + + if (!clk) + return; + + mutex_lock(&prepare_lock); + + /* check to see if a clock with this name is already registered */ + if (__clk_lookup(clk->name)) + goto out; + + /* throw a WARN if any entries in parent_names are NULL */ + for (i = 0; i < clk->num_parents; i++) + WARN(!clk->parent_names[i], + "%s: invalid NULL in %s's .parent_names\n", + __func__, clk->name); + + /* + * Allocate an array of struct clk *'s to avoid unnecessary string + * look-ups of clk's possible parents. This can fail for clocks passed + * in to clk_init during early boot; thus any access to clk->parents[] + * must always check for a NULL pointer and try to populate it if + * necessary. + * + * If clk->parents is not NULL we skip this entire block. This allows + * for clock drivers to statically initialize clk->parents. + */ + if (clk->num_parents && !clk->parents) { + clk->parents = kmalloc((sizeof(struct clk*) * clk->num_parents), + GFP_KERNEL); + /* + * __clk_lookup returns NULL for parents that have not been + * clk_init'd; thus any access to clk->parents[] must check + * for a NULL pointer. We can always perform lazy lookups for + * missing parents later on. + */ + if (clk->parents) + for (i = 0; i < clk->num_parents; i++) + clk->parents[i] = + __clk_lookup(clk->parent_names[i]); + } + + clk->parent = __clk_init_parent(clk); + + /* + * Populate clk->parent if parent has already been __clk_init'd. If + * parent has not yet been __clk_init'd then place clk in the orphan + * list. If clk has set the CLK_IS_ROOT flag then place it in the root + * clk list. + * + * Every time a new clk is clk_init'd then we walk the list of orphan + * clocks and re-parent any that are children of the clock currently + * being clk_init'd. + */ + if (clk->parent) + hlist_add_head(&clk->child_node, + &clk->parent->children); + else if (clk->flags & CLK_IS_ROOT) + hlist_add_head(&clk->child_node, &clk_root_list); + else + hlist_add_head(&clk->child_node, &clk_orphan_list); + + /* + * Set clk's rate. The preferred method is to use .recalc_rate. For + * simple clocks and lazy developers the default fallback is to use the + * parent's rate. If a clock doesn't have a parent (or is orphaned) + * then rate is set to zero. + */ + if (clk->ops->recalc_rate) + clk->rate = clk->ops->recalc_rate(clk->hw, + __clk_get_rate(clk->parent)); + else if (clk->parent) + clk->rate = clk->parent->rate; + else + clk->rate = 0; + + /* + * walk the list of orphan clocks and reparent any that are children of + * this clock + */ + hlist_for_each_entry_safe(orphan, tmp, tmp2, &clk_orphan_list, child_node) + for (i = 0; i < orphan->num_parents; i++) + if (!strcmp(clk->name, orphan->parent_names[i])) { + __clk_reparent(orphan, clk); + break; + } + + /* + * optional platform-specific magic + * + * The .init callback is not used by any of the basic clock types, but + * exists for weird hardware that must perform initialization magic. + * Please consider other ways of solving initialization problems before + * using this callback, as it's use is discouraged. + */ + if (clk->ops->init) + clk->ops->init(clk->hw); + + clk_debug_register(clk); + +out: + mutex_unlock(&prepare_lock); + + return; +} + +/** + * clk_register - allocate a new clock, register it and return an opaque cookie + * @dev: device that is registering this clock + * @name: clock name + * @ops: operations this clock supports + * @hw: link to hardware-specific clock data + * @parent_names: array of string names for all possible parents + * @num_parents: number of possible parents + * @flags: framework-level hints and quirks + * + * clk_register is the primary interface for populating the clock tree with new + * clock nodes. It returns a pointer to the newly allocated struct clk which + * cannot be dereferenced by driver code but may be used in conjuction with the + * rest of the clock API. + */ +struct clk *clk_register(struct device *dev, const char *name, + const struct clk_ops *ops, struct clk_hw *hw, + char **parent_names, u8 num_parents, unsigned long flags) +{ + struct clk *clk; + + clk = kzalloc(sizeof(*clk), GFP_KERNEL); + if (!clk) + return NULL; + + clk->name = name; + clk->ops = ops; + clk->hw = hw; + clk->flags = flags; + clk->parent_names = parent_names; + clk->num_parents = num_parents; + hw->clk = clk; + + __clk_init(dev, clk); + + return clk; +} +EXPORT_SYMBOL_GPL(clk_register); + +/*** clk rate change notifiers ***/ + +/** + * clk_notifier_register - add a clk rate change notifier + * @clk: struct clk * to watch + * @nb: struct notifier_block * with callback info + * + * Request notification when clk's rate changes. This uses an SRCU + * notifier because we want it to block and notifier unregistrations are + * uncommon. The callbacks associated with the notifier must not + * re-enter into the clk framework by calling any top-level clk APIs; + * this will cause a nested prepare_lock mutex. + * + * Pre-change notifier callbacks will be passed the current, pre-change + * rate of the clk via struct clk_notifier_data.old_rate. The new, + * post-change rate of the clk is passed via struct + * clk_notifier_data.new_rate. + * + * Post-change notifiers will pass the now-current, post-change rate of + * the clk in both struct clk_notifier_data.old_rate and struct + * clk_notifier_data.new_rate. + * + * Abort-change notifiers are effectively the opposite of pre-change + * notifiers: the original pre-change clk rate is passed in via struct + * clk_notifier_data.new_rate and the failed post-change rate is passed + * in via struct clk_notifier_data.old_rate. + * + * clk_notifier_register() must be called from non-atomic context. + * Returns -EINVAL if called with null arguments, -ENOMEM upon + * allocation failure; otherwise, passes along the return value of + * srcu_notifier_chain_register(). + */ +int clk_notifier_register(struct clk *clk, struct notifier_block *nb) +{ + struct clk_notifier *cn; + int ret = -ENOMEM; + + if (!clk || !nb) + return -EINVAL; + + mutex_lock(&prepare_lock); + + /* search the list of notifiers for this clk */ + list_for_each_entry(cn, &clk_notifier_list, node) + if (cn->clk == clk) + break; + + /* if clk wasn't in the notifier list, allocate new clk_notifier */ + if (cn->clk != clk) { + cn = kzalloc(sizeof(struct clk_notifier), GFP_KERNEL); + if (!cn) + goto out; + + cn->clk = clk; + srcu_init_notifier_head(&cn->notifier_head); + + list_add(&cn->node, &clk_notifier_list); + } + + ret = srcu_notifier_chain_register(&cn->notifier_head, nb); + + clk->notifier_count++; + +out: + mutex_unlock(&prepare_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_notifier_register); + +/** + * clk_notifier_unregister - remove a clk rate change notifier + * @clk: struct clk * + * @nb: struct notifier_block * with callback info + * + * Request no further notification for changes to 'clk' and frees memory + * allocated in clk_notifier_register. + * + * Returns -EINVAL if called with null arguments; otherwise, passes + * along the return value of srcu_notifier_chain_unregister(). + */ +int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb) +{ + struct clk_notifier *cn = NULL; + int ret = -EINVAL; + + if (!clk || !nb) + return -EINVAL; + + mutex_lock(&prepare_lock); + + list_for_each_entry(cn, &clk_notifier_list, node) + if (cn->clk == clk) + break; + + if (cn->clk == clk) { + ret = srcu_notifier_chain_unregister(&cn->notifier_head, nb); + + clk->notifier_count--; + + /* XXX the notifier code should handle this better */ + if (!cn->notifier_head.head) { + srcu_cleanup_notifier_head(&cn->notifier_head); + kfree(cn); + } + + } else { + ret = -ENOENT; + } + + mutex_unlock(&prepare_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(clk_notifier_unregister); diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h new file mode 100644 index 0000000..e2cce6f --- /dev/null +++ b/include/linux/clk-private.h @@ -0,0 +1,72 @@ +/* + * linux/include/linux/clk-private.h + * + * Copyright (c) 2010-2011 Jeremy Kerr jeremy.kerr@canonical.com + * Copyright (C) 2011-2012 Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __LINUX_CLK_PRIVATE_H +#define __LINUX_CLK_PRIVATE_H + +#include <linux/clk-provider.h> +#include <linux/list.h> + +/* + * WARNING: Do not include clk-private.h from any file that implements struct + * clk_ops. Doing so is a layering violation! + * + * This header exists only to allow for statically initialized clock data. Any + * static clock data must be defined in a separate file from the logic that + * implements the clock operations for that same data. + */ + +#ifdef CONFIG_COMMON_CLK + +struct clk { + const char *name; + const struct clk_ops *ops; + struct clk_hw *hw; + struct clk *parent; + char **parent_names; + struct clk **parents; + u8 num_parents; + unsigned long rate; + unsigned long new_rate; + unsigned long flags; + unsigned int enable_count; + unsigned int prepare_count; + struct hlist_head children; + struct hlist_node child_node; + unsigned int notifier_count; +#ifdef CONFIG_COMMON_CLK_DEBUG + struct dentry *dentry; +#endif +}; + +/** + * __clk_init - initialize the data structures in a struct clk + * @dev: device initializing this clk, placeholder for now + * @clk: clk being initialized + * + * Initializes the lists in struct clk, queries the hardware for the + * parent and rate and sets them both. + * + * Any struct clk passed into __clk_init must have the following members + * populated: + * .name + * .ops + * .hw + * .parent_names + * .num_parents + * .flags + * + * It is not necessary to call clk_register if __clk_init is used directly with + * statically initialized clock data. + */ +void __clk_init(struct device *dev, struct clk *clk); + +#endif /* CONFIG_COMMON_CLK */ +#endif /* CLK_PRIVATE_H */ diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h new file mode 100644 index 0000000..b18b0e7 --- /dev/null +++ b/include/linux/clk-provider.h @@ -0,0 +1,173 @@ +/* + * linux/include/linux/clk-provider.h + * + * Copyright (c) 2010-2011 Jeremy Kerr jeremy.kerr@canonical.com + * Copyright (C) 2011-2012 Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __LINUX_CLK_PROVIDER_H +#define __LINUX_CLK_PROVIDER_H + +#include <linux/clk.h> + +#ifdef CONFIG_COMMON_CLK + +/** + * struct clk_hw - handle for traversing from a struct clk to its corresponding + * hardware-specific structure. struct clk_hw should be declared within struct + * clk_foo and then referenced by the struct clk instance that uses struct + * clk_foo's clk_ops + * + * clk: pointer to the struct clk instance that points back to this struct + * clk_hw instance + */ +struct clk_hw { + struct clk *clk; +}; + +/* + * flags used across common struct clk. these flags should only affect the + * top-level framework. custom flags for dealing with hardware specifics + * belong in struct clk_foo + */ +#define CLK_SET_RATE_GATE BIT(0) /* must be gated across rate change */ +#define CLK_SET_PARENT_GATE BIT(1) /* must be gated across re-parent */ +#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one level */ +#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */ +#define CLK_IS_ROOT BIT(4) /* root clk, has no parent */ + +/** + * struct clk_ops - Callback operations for hardware clocks; these are to + * be provided by the clock implementation, and will be called by drivers + * through the clk_* api. + * + * @prepare: Prepare the clock for enabling. This must not return until + * the clock is fully prepared, and it's safe to call clk_enable. + * This callback is intended to allow clock implementations to + * do any initialisation that may sleep. Called with + * prepare_lock held. + * + * @unprepare: Release the clock from its prepared state. This will typically + * undo any work done in the @prepare callback. Called with + * prepare_lock held. + * + * @enable: Enable the clock atomically. This must not return until the + * clock is generating a valid clock signal, usable by consumer + * devices. Called with enable_lock held. This function must not + * sleep. + * + * @disable: Disable the clock atomically. Called with enable_lock held. + * This function must not sleep. + * + * @recalc_rate Recalculate the rate of this clock, by quering hardware. The + * parent rate is an input parameter. It is up to the caller to + * insure that the prepare_mutex is held across this call. + * Returns the calculated rate. Optional, but recommended - if + * this op is not set then clock rate will be initialized to 0. + * + * @round_rate: Given a target rate as input, returns the closest rate actually + * supported by the clock. + * + * @get_parent: Queries the hardware to determine the parent of a clock. The + * return value is a u8 which specifies the index corresponding to + * the parent clock. This index can be applied to either the + * .parent_names or .parents arrays. In short, this function + * translates the parent value read from hardware into an array + * index. Currently only called when the clock is initialized by + * __clk_init. This callback is mandatory for clocks with + * multiple parents. It is optional (and unnecessary) for clocks + * with 0 or 1 parents. + * + * @set_parent: Change the input source of this clock; for clocks with multiple + * possible parents specify a new parent by passing in the index + * as a u8 corresponding to the parent in either the .parent_names + * or .parents arrays. This function in affect translates an + * array index into the value programmed into the hardware. + * Returns 0 on success, -EERROR otherwise. + * + * @set_rate: Change the rate of this clock. If this callback returns + * CLK_SET_RATE_PARENT, the rate change will be propagated to the + * parent clock (which may propagate again if the parent clock + * also sets this flag). The requested rate of the parent is + * passed back from the callback in the second 'unsigned long *' + * argument. Note that it is up to the hardware clock's set_rate + * implementation to insure that clocks do not run out of spec + * when propgating the call to set_rate up to the parent. One way + * to do this is to gate the clock (via clk_disable and/or + * clk_unprepare) before calling clk_set_rate, then ungating it + * afterward. If your clock also has the CLK_GATE_SET_RATE flag + * set then this will insure safety. Returns 0 on success, + * -EERROR otherwise. + * + * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow + * implementations to split any work between atomic (enable) and sleepable + * (prepare) contexts. If enabling a clock requires code that might sleep, + * this must be done in clk_prepare. Clock enable code that will never be + * called in a sleepable context may be implement in clk_enable. + * + * Typically, drivers will call clk_prepare when a clock may be needed later + * (eg. when a device is opened), and clk_enable when the clock is actually + * required (eg. from an interrupt). Note that clk_prepare MUST have been + * called before clk_enable. + */ +struct clk_ops { + int (*prepare)(struct clk_hw *hw); + void (*unprepare)(struct clk_hw *hw); + int (*enable)(struct clk_hw *hw); + void (*disable)(struct clk_hw *hw); + int (*is_enabled)(struct clk_hw *hw); + unsigned long (*recalc_rate)(struct clk_hw *hw, + unsigned long parent_rate); + long (*round_rate)(struct clk_hw *hw, unsigned long, + unsigned long *); + int (*set_parent)(struct clk_hw *hw, u8 index); + u8 (*get_parent)(struct clk_hw *hw); + int (*set_rate)(struct clk_hw *hw, unsigned long); + void (*init)(struct clk_hw *hw); +}; + + +/** + * clk_register - allocate a new clock, register it and return an opaque cookie + * @dev: device that is registering this clock + * @name: clock name + * @ops: operations this clock supports + * @hw: link to hardware-specific clock data + * @parent_names: array of string names for all possible parents + * @num_parents: number of possible parents + * @flags: framework-level hints and quirks + * + * clk_register is the primary interface for populating the clock tree with new + * clock nodes. It returns a pointer to the newly allocated struct clk which + * cannot be dereferenced by driver code but may be used in conjuction with the + * rest of the clock API. + */ +struct clk *clk_register(struct device *dev, const char *name, + const struct clk_ops *ops, struct clk_hw *hw, + char **parent_names, u8 num_parents, unsigned long flags); + +/* helper functions */ +const char *__clk_get_name(struct clk *clk); +struct clk_hw *__clk_get_hw(struct clk *clk); +u8 __clk_get_num_parents(struct clk *clk); +struct clk *__clk_get_parent(struct clk *clk); +inline int __clk_get_enable_count(struct clk *clk); +inline int __clk_get_prepare_count(struct clk *clk); +unsigned long __clk_get_rate(struct clk *clk); +unsigned long __clk_get_flags(struct clk *clk); +int __clk_is_enabled(struct clk *clk); +struct clk *__clk_lookup(const char *name); + +/* + * FIXME clock api without lock protection + */ +int __clk_prepare(struct clk *clk); +void __clk_unprepare(struct clk *clk); +void __clk_reparent(struct clk *clk, struct clk *new_parent); +unsigned long __clk_round_rate(struct clk *clk, unsigned long rate); + +#endif /* CONFIG_COMMON_CLK */ +#endif /* CLK_PROVIDER_H */ diff --git a/include/linux/clk.h b/include/linux/clk.h index b9d46fa..b025272 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -3,6 +3,7 @@ * * Copyright (C) 2004 ARM Limited. * Written by Deep Blue Solutions Limited. + * Copyright (C) 2011-2012 Linaro Ltd mturquette@linaro.org * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -12,18 +13,75 @@ #define __LINUX_CLK_H
#include <linux/kernel.h> +#include <linux/notifier.h>
struct device;
-/* - * The base API. +struct clk; + +#ifdef CONFIG_COMMON_CLK + +/** + * DOC: clk notifier callback types + * + * PRE_RATE_CHANGE - called immediately before the clk rate is changed, + * to indicate that the rate change will proceed. Drivers must + * immediately terminate any operations that will be affected by the + * rate change. Callbacks may either return NOTIFY_DONE or + * NOTIFY_STOP. + * + * ABORT_RATE_CHANGE: called if the rate change failed for some reason + * after PRE_RATE_CHANGE. In this case, all registered notifiers on + * the clk will be called with ABORT_RATE_CHANGE. Callbacks must + * always return NOTIFY_DONE. + * + * POST_RATE_CHANGE - called after the clk rate change has successfully + * completed. Callbacks must always return NOTIFY_DONE. + * */ +#define PRE_RATE_CHANGE BIT(0) +#define POST_RATE_CHANGE BIT(1) +#define ABORT_RATE_CHANGE BIT(2)
+/** + * struct clk_notifier - associate a clk with a notifier + * @clk: struct clk * to associate the notifier with + * @notifier_head: a blocking_notifier_head for this clk + * @node: linked list pointers + * + * A list of struct clk_notifier is maintained by the notifier code. + * An entry is created whenever code registers the first notifier on a + * particular @clk. Future notifiers on that @clk are added to the + * @notifier_head. + */ +struct clk_notifier { + struct clk *clk; + struct srcu_notifier_head notifier_head; + struct list_head node; +};
-/* - * struct clk - an machine class defined object / cookie. +/** + * struct clk_notifier_data - rate data to pass to the notifier callback + * @clk: struct clk * being changed + * @old_rate: previous rate of this clk + * @new_rate: new rate of this clk + * + * For a pre-notifier, old_rate is the clk's rate before this rate + * change, and new_rate is what the rate will be in the future. For a + * post-notifier, old_rate and new_rate are both set to the clk's + * current rate (this was done to optimize the implementation). */ -struct clk; +struct clk_notifier_data { + struct clk *clk; + unsigned long old_rate; + unsigned long new_rate; +}; + +int clk_notifier_register(struct clk *clk, struct notifier_block *nb); + +int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb); + +#endif /* !CONFIG_COMMON_CLK */
/** * clk_get - lookup and obtain a reference to a clock producer.
On 03/15/2012 11:11 PM, Mike Turquette wrote:
The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw.
See Documentation/clk.txt for more details.
This patch is based on the work of Jeremy Kerr, which in turn was based on the work of Ben Herrenschmidt.
Signed-off-by: Mike Turquettemturquette@linaro.org Signed-off-by: Mike Turquettemturquette@ti.com Reviewed-by: Thomas Gleixnertglx@linutronix.de Tested-by: Andrew Lunnandrew@lunn.ch Reviewed-by: Rob Herring<rob.herring<at> calxeda.com> Cc: Russell Kinglinux@arm.linux.org.uk Cc: Jeremy Kerrjeremy.kerr@canonical.com Cc: Arnd Bergmanarnd.bergmann@linaro.org Cc: Paul Walmsleypaul@pwsan.com Cc: Shawn Guoshawn.guo@freescale.com Cc: Sascha Hauers.hauer@pengutronix.de Cc: Richard Zhaorichard.zhao@linaro.org Cc: Saravana Kannanskannan@codeaurora.org Cc: Magnus Dammmagnus.damm@gmail.com Cc: Mark Brownbroonie@opensource.wolfsonmicro.com Cc: Linus Walleijlinus.walleij@stericsson.com Cc: Stephen Boydsboyd@codeaurora.org Cc: Amit Kucheriaamit.kucheria@linaro.org Cc: Deepak Saxenadsaxena@linaro.org Cc: Grant Likelygrant.likely@secretlab.ca
Mike,
Thanks for the patches! Glad to see that it's finally getting in! I sent a request for a minor change as a reply to the v5 series (since it had more context). Can you please take a look at that and let me know if you can send out a v8 or a patch on top of this to do that?
Thanks, Saravana
On Fri, Mar 16, 2012 at 8:28 PM, Saravana Kannan skannan@codeaurora.org wrote:
On 03/15/2012 11:11 PM, Mike Turquette wrote:
The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw.
See Documentation/clk.txt for more details.
This patch is based on the work of Jeremy Kerr, which in turn was based on the work of Ben Herrenschmidt.
Signed-off-by: Mike Turquettemturquette@linaro.org Signed-off-by: Mike Turquettemturquette@ti.com Reviewed-by: Thomas Gleixnertglx@linutronix.de Tested-by: Andrew Lunnandrew@lunn.ch Reviewed-by: Rob Herring<rob.herring<at> calxeda.com> Cc: Russell Kinglinux@arm.linux.org.uk Cc: Jeremy Kerrjeremy.kerr@canonical.com Cc: Arnd Bergmanarnd.bergmann@linaro.org Cc: Paul Walmsleypaul@pwsan.com Cc: Shawn Guoshawn.guo@freescale.com Cc: Sascha Hauers.hauer@pengutronix.de Cc: Richard Zhaorichard.zhao@linaro.org Cc: Saravana Kannanskannan@codeaurora.org Cc: Magnus Dammmagnus.damm@gmail.com Cc: Mark Brownbroonie@opensource.wolfsonmicro.com Cc: Linus Walleijlinus.walleij@stericsson.com Cc: Stephen Boydsboyd@codeaurora.org Cc: Amit Kucheriaamit.kucheria@linaro.org Cc: Deepak Saxenadsaxena@linaro.org Cc: Grant Likelygrant.likely@secretlab.ca
Mike,
Thanks for the patches! Glad to see that it's finally getting in! I sent a request for a minor change as a reply to the v5 series (since it had more context). Can you please take a look at that and let me know if you can send out a v8 or a patch on top of this to do that?
Hi Saravana,
I'm not sending a v8 series since Arnd has taken in v7 for the 3.4 merge window.
I'm formulating a reply to your v5 queries, but I'm not done looking at the implications of the initializer stuff. Lets keep the technical discussion in that thread for now.
Regards, Mike
Thanks, Saravana
-- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On 03/19/2012 11:56 AM, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 8:28 PM, Saravana Kannanskannan@codeaurora.org wrote:
On 03/15/2012 11:11 PM, Mike Turquette wrote:
The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw.
See Documentation/clk.txt for more details.
This patch is based on the work of Jeremy Kerr, which in turn was based on the work of Ben Herrenschmidt.
Signed-off-by: Mike Turquettemturquette@linaro.org Signed-off-by: Mike Turquettemturquette@ti.com Reviewed-by: Thomas Gleixnertglx@linutronix.de Tested-by: Andrew Lunnandrew@lunn.ch Reviewed-by: Rob Herring<rob.herring<at> calxeda.com> Cc: Russell Kinglinux@arm.linux.org.uk Cc: Jeremy Kerrjeremy.kerr@canonical.com Cc: Arnd Bergmanarnd.bergmann@linaro.org Cc: Paul Walmsleypaul@pwsan.com Cc: Shawn Guoshawn.guo@freescale.com Cc: Sascha Hauers.hauer@pengutronix.de Cc: Richard Zhaorichard.zhao@linaro.org Cc: Saravana Kannanskannan@codeaurora.org Cc: Magnus Dammmagnus.damm@gmail.com Cc: Mark Brownbroonie@opensource.wolfsonmicro.com Cc: Linus Walleijlinus.walleij@stericsson.com Cc: Stephen Boydsboyd@codeaurora.org Cc: Amit Kucheriaamit.kucheria@linaro.org Cc: Deepak Saxenadsaxena@linaro.org Cc: Grant Likelygrant.likely@secretlab.ca
Mike,
Thanks for the patches! Glad to see that it's finally getting in! I sent a request for a minor change as a reply to the v5 series (since it had more context). Can you please take a look at that and let me know if you can send out a v8 or a patch on top of this to do that?
Hi Saravana,
Hi Mike,
I'm not sending a v8 series since Arnd has taken in v7 for the 3.4 merge window.
Yeah, I later realized it might be better to send patches on top of v7.
I'm formulating a reply to your v5 queries, but I'm not done looking at the implications of the initializer stuff. Lets keep the technical discussion in that thread for now.
I saw some responses from you over the weekend but not to mine. So, I assumed you were busy with other stuff and I started working on a patch on top of v7. I will send that out if I get around to finishing it before you do. Hope that's alright with you.
Based on what I have done so far, to me it just looked like a search and replace of clk->name with clk->hw.name and similar changes for the rest of the fields. It looks like we might be able to remove clk_register_mux, clk_register_divider, etc if we go with this. No stong opinion about removing those, but they seemed redundant after the suggester refactor.
I think it would be okay to just move those init fields into clk_hw and not bother with renaming it to clk_initializer (I would prefer, clk_info or clk_common) if it makes the match much less invasive.
Thanks, Saravana
On Mon, Mar 19, 2012 at 12:13 PM, Saravana Kannan skannan@codeaurora.org wrote:
I saw some responses from you over the weekend but not to mine. So, I assumed you were busy with other stuff and I started working on a patch on top of v7.
I only answer trivial emails on the weekend ;-)
I will send that out if I get around to finishing it before you do. Hope that's alright with you.
I'm happy to for you to take a crack at it. I don't know what your implementation looks like, but here are a couple concerns I have:
1) if you're copying the data from the initializer over to the struct clk then make sure you handle the __init data aspects of it properly
2) are the members of struct clk_hw visible to the rest of the world? Are they modifiable (i.e., not const)? This is undesirable.
Thanks, Mike
On 03/19/2012 12:33 PM, Turquette, Mike wrote:
On Mon, Mar 19, 2012 at 12:13 PM, Saravana Kannan skannan@codeaurora.org wrote:
I saw some responses from you over the weekend but not to mine. So, I assumed you were busy with other stuff and I started working on a patch on top of v7.
I only answer trivial emails on the weekend ;-)
I will send that out if I get around to finishing it before you do. Hope that's alright with you.
I'm happy to for you to take a crack at it. I don't know what your implementation looks like, but here are a couple concerns I have:
- if you're copying the data from the initializer over to the struct
clk then make sure you handle the __init data aspects of it properly
Not copying them into clk again. Just leaving them in clk_hw and using them as is. The only fields moved into clk_hw are: + const char *name; + const struct clk_ops *ops; + char **parent_names; + u8 num_parents; + unsigned long flags;
- are the members of struct clk_hw visible to the rest of the world?
Are they modifiable (i.e., not const)? This is undesirable.
I'm leaving the const as is. Some of them you can't mark as const if you want to dynamically create them.
Yes, they are visible to all the platform drivers (not the rest of the world). But these values are provided by the platform drivers anyway, so I don't see a problem with it.
I also don't see any useful hacks a platform driver can do by messing with this fields without crashing the kernel since they don't have access to the locks.
flags might be the one that provides some possibilities since I think you look at them often in the core code. We could just copy it into clk if people really feel strongly about it. At the worst case, we can have a full copy of all these fields inside clk and copy all of them over, but I think that would be overkill for things like names, ops and parent info.
Thanks, Saravana
Reading the documentation of function clk_set_rate(), I'm not sure it exactly matches what the code does.
If there is mismatch, it might be worth sending an incremental patch to update the documentation and avoid the confusion?
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote:
+/**
- clk_set_rate - specify a new rate for clk
- @clk: the clk whose rate is being changed
- @rate: the new rate for clk
- In the simplest case clk_set_rate will only change the rate of clk.
- If clk has the CLK_SET_RATE_GATE flag set and it is enabled this call
- will fail; only when the clk is disabled will it be able to change
- its rate.
- Setting the CLK_SET_RATE_PARENT flag allows clk_set_rate to
- recursively propagate up to clk's parent; whether or not this happens
- depends on the outcome of clk's .round_rate implementation. If
- *parent_rate is 0 after calling .round_rate then upstream parent
Might "*parent_rate is not changed" be more accurate?
- propagation is ignored. If *parent_rate comes back with a new rate
- for clk's parent then we propagate up to clk's parent and set it's
- rate. Upward propagation will continue until either a clk does not
- support the CLK_SET_RATE_PARENT flag or .round_rate stops requesting
- changes to clk's parent_rate.
- If there is a failure during upstream
- propagation then clk_set_rate will unwind and restore each clk's rate
- that had been successfully changed. Afterwards a rate change abort
- notification will be propagated downstream, starting from the clk
- that failed.
I'm not sure this part still matches the code.
- At the end of all of the rate setting, clk_set_rate internally calls
- __clk_recalc_rates and propagates the rate changes downstream,
I do not see __clk_recalc_rates is called by clk_set_rate in any way.
Regards, Shawn
- starting from the highest clk whose rate was changed. This has the
- added benefit of propagating post-rate change notifiers.
- Note that while post-rate change and rate change abort notifications
- are guaranteed to be sent to a clk only once per call to
- clk_set_rate, pre-change notifications will be sent for every clk
- whose rate is changed. Stacking pre-change notifications is noisy
- for the drivers subscribed to them, but this allows drivers to react
- to intermediate clk rate changes up until the point where the final
- rate is achieved at the end of upstream propagation.
- Returns 0 on success, -EERROR otherwise.
- */
On Sun, Mar 18, 2012 at 6:46 AM, Shawn Guo shawn.guo@linaro.org wrote:
Reading the documentation of function clk_set_rate(), I'm not sure it exactly matches what the code does.
If there is mismatch, it might be worth sending an incremental patch to update the documentation and avoid the confusion?
The clk_set_rate code did change rapidly leading up to the merge request, and updating the documentation slipped through the cracks. I'll cook up a patch and it can probably go in one of the -rc's for 3.4. I'll take in all of your comments below.
Thanks, Mike
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote:
+/**
- clk_set_rate - specify a new rate for clk
- @clk: the clk whose rate is being changed
- @rate: the new rate for clk
- In the simplest case clk_set_rate will only change the rate of clk.
- If clk has the CLK_SET_RATE_GATE flag set and it is enabled this call
- will fail; only when the clk is disabled will it be able to change
- its rate.
- Setting the CLK_SET_RATE_PARENT flag allows clk_set_rate to
- recursively propagate up to clk's parent; whether or not this happens
- depends on the outcome of clk's .round_rate implementation. If
- *parent_rate is 0 after calling .round_rate then upstream parent
Might "*parent_rate is not changed" be more accurate?
- propagation is ignored. If *parent_rate comes back with a new rate
- for clk's parent then we propagate up to clk's parent and set it's
- rate. Upward propagation will continue until either a clk does not
- support the CLK_SET_RATE_PARENT flag or .round_rate stops requesting
- changes to clk's parent_rate.
- If there is a failure during upstream
- propagation then clk_set_rate will unwind and restore each clk's rate
- that had been successfully changed. Afterwards a rate change abort
- notification will be propagated downstream, starting from the clk
- that failed.
I'm not sure this part still matches the code.
- At the end of all of the rate setting, clk_set_rate internally calls
- __clk_recalc_rates and propagates the rate changes downstream,
I do not see __clk_recalc_rates is called by clk_set_rate in any way.
Regards, Shawn
- starting from the highest clk whose rate was changed. This has the
- added benefit of propagating post-rate change notifiers.
- Note that while post-rate change and rate change abort notifications
- are guaranteed to be sent to a clk only once per call to
- clk_set_rate, pre-change notifications will be sent for every clk
- whose rate is changed. Stacking pre-change notifications is noisy
- for the drivers subscribed to them, but this allows drivers to react
- to intermediate clk rate changes up until the point where the final
- rate is achieved at the end of upstream propagation.
- Returns 0 on success, -EERROR otherwise.
- */
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Another trivial comment. But if there is an incremental patch, maybe consider to include it.
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+#ifdef CONFIG_COMMON_CLK_DISABLE_UNUSED +static int clk_disable_unused(void) +{
- struct clk *clk;
- struct hlist_node *tmp;
- mutex_lock(&prepare_lock);
- hlist_for_each_entry(clk, tmp, &clk_root_list, child_node)
clk_disable_unused_subtree(clk);- hlist_for_each_entry(clk, tmp, &clk_orphan_list, child_node)
clk_disable_unused_subtree(clk);- mutex_unlock(&prepare_lock);
- return 0;
+} +late_initcall(clk_disable_unused); +#else +static inline int clk_disable_unused(struct clk *clk) { return 0; }
This #else block seems completely unnecessary to me.
+#endif /* CONFIG_COMMON_CLK_DISABLE_UNUSED */
On Sun, Mar 18, 2012 at 7:07 AM, Shawn Guo shawn.guo@linaro.org wrote:
Another trivial comment. But if there is an incremental patch, maybe consider to include it.
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+#ifdef CONFIG_COMMON_CLK_DISABLE_UNUSED +static int clk_disable_unused(void) +{
- struct clk *clk;
- struct hlist_node *tmp;
- mutex_lock(&prepare_lock);
- hlist_for_each_entry(clk, tmp, &clk_root_list, child_node)
- clk_disable_unused_subtree(clk);
- hlist_for_each_entry(clk, tmp, &clk_orphan_list, child_node)
- clk_disable_unused_subtree(clk);
- mutex_unlock(&prepare_lock);
- return 0;
+} +late_initcall(clk_disable_unused); +#else +static inline int clk_disable_unused(struct clk *clk) { return 0; }
This #else block seems completely unnecessary to me.
+#endif /* CONFIG_COMMON_CLK_DISABLE_UNUSED */
Oops. This is a leftover from when there was a separate drivers/clk/clk-debug.c which implemented this stuff. I'll make a cleanup series and roll all these little things into it.
Thanks, Mike
Hi Mike,
On Friday 16 March 2012 11:41 AM, Mike Turquette wrote:
The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw.
See Documentation/clk.txt for more details.
+/*
- calculate the new rates returning the topmost clock that has to be
- changed.
- */
+static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) +{
- struct clk *top = clk;
- unsigned long best_parent_rate = clk->parent->rate;
Shouldn't you check for a valid parent before dereferencing it? A clk_set_rate() on a root clock might throw up some issues otherwise.
- unsigned long new_rate;
- if (!clk->ops->round_rate&& !(clk->flags& CLK_SET_RATE_PARENT)) {
clk->new_rate = clk->rate;return NULL;
So does this mean a clk_set_rate() fails for a clk which does not have a valid .round_rate and does not have a CLK_SET_RATE_PARENT flag set? I was thinking this could do a.. clk->new_rate = rate; top = clk; goto out; ..instead.
regards, Rajendra
- }
- if (!clk->ops->round_rate&& (clk->flags& CLK_SET_RATE_PARENT)) {
top = clk_calc_new_rates(clk->parent, rate);new_rate = clk->new_rate = clk->parent->new_rate;goto out;- }
- if (clk->flags& CLK_SET_RATE_PARENT)
new_rate = clk->ops->round_rate(clk->hw, rate,&best_parent_rate);- else
new_rate = clk->ops->round_rate(clk->hw, rate, NULL);- if (best_parent_rate != clk->parent->rate) {
top = clk_calc_new_rates(clk->parent, best_parent_rate);goto out;- }
+out:
- clk_calc_subtree(clk, new_rate);
- return top;
+}
+/*
- Notify about rate changes in a subtree. Always walk down the whole tree
- so that in case of an error we can walk down the whole tree again and
- abort the change.
- */
+static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long event) +{
- struct hlist_node *tmp;
- struct clk *child, *fail_clk = NULL;
- int ret = NOTIFY_DONE;
- if (clk->rate == clk->new_rate)
return 0;- if (clk->notifier_count) {
ret = __clk_notify(clk, event, clk->rate, clk->new_rate);if (ret == NOTIFY_BAD)fail_clk = clk;- }
- hlist_for_each_entry(child, tmp,&clk->children, child_node) {
clk = clk_propagate_rate_change(child, event);if (clk)fail_clk = clk;- }
- return fail_clk;
+}
+/*
- walk down a subtree and set the new rates notifying the rate
- change on the way
- */
+static void clk_change_rate(struct clk *clk) +{
- struct clk *child;
- unsigned long old_rate;
- struct hlist_node *tmp;
- old_rate = clk->rate;
- if (clk->ops->set_rate)
clk->ops->set_rate(clk->hw, clk->new_rate);- if (clk->ops->recalc_rate)
clk->rate = clk->ops->recalc_rate(clk->hw,clk->parent->rate);- else
clk->rate = clk->parent->rate;- if (clk->notifier_count&& old_rate != clk->rate)
__clk_notify(clk, POST_RATE_CHANGE, old_rate, clk->rate);- hlist_for_each_entry(child, tmp,&clk->children, child_node)
clk_change_rate(child);+}
+/**
- clk_set_rate - specify a new rate for clk
- @clk: the clk whose rate is being changed
- @rate: the new rate for clk
- In the simplest case clk_set_rate will only change the rate of clk.
- If clk has the CLK_SET_RATE_GATE flag set and it is enabled this call
- will fail; only when the clk is disabled will it be able to change
- its rate.
- Setting the CLK_SET_RATE_PARENT flag allows clk_set_rate to
- recursively propagate up to clk's parent; whether or not this happens
- depends on the outcome of clk's .round_rate implementation. If
- *parent_rate is 0 after calling .round_rate then upstream parent
- propagation is ignored. If *parent_rate comes back with a new rate
- for clk's parent then we propagate up to clk's parent and set it's
- rate. Upward propagation will continue until either a clk does not
- support the CLK_SET_RATE_PARENT flag or .round_rate stops requesting
- changes to clk's parent_rate. If there is a failure during upstream
- propagation then clk_set_rate will unwind and restore each clk's rate
- that had been successfully changed. Afterwards a rate change abort
- notification will be propagated downstream, starting from the clk
- that failed.
- At the end of all of the rate setting, clk_set_rate internally calls
- __clk_recalc_rates and propagates the rate changes downstream,
- starting from the highest clk whose rate was changed. This has the
- added benefit of propagating post-rate change notifiers.
- Note that while post-rate change and rate change abort notifications
- are guaranteed to be sent to a clk only once per call to
- clk_set_rate, pre-change notifications will be sent for every clk
- whose rate is changed. Stacking pre-change notifications is noisy
- for the drivers subscribed to them, but this allows drivers to react
- to intermediate clk rate changes up until the point where the final
- rate is achieved at the end of upstream propagation.
- Returns 0 on success, -EERROR otherwise.
- */
+int clk_set_rate(struct clk *clk, unsigned long rate) +{
- struct clk *top, *fail_clk;
- int ret = 0;
- /* prevent racing with updates to the clock topology */
- mutex_lock(&prepare_lock);
- /* bail early if nothing to do */
- if (rate == clk->rate)
goto out;- /* calculate new rates and get the topmost changed clock */
- top = clk_calc_new_rates(clk, rate);
- if (!top) {
ret = -EINVAL;goto out;- }
- /* notify that we are about to change rates */
- fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
- if (fail_clk) {
pr_warn("%s: failed to set %s rate\n", __func__,fail_clk->name);clk_propagate_rate_change(top, ABORT_RATE_CHANGE);ret = -EBUSY;goto out;- }
- /* change the rates */
- clk_change_rate(top);
- mutex_unlock(&prepare_lock);
- return 0;
+out:
- mutex_unlock(&prepare_lock);
- return ret;
+} +EXPORT_SYMBOL_GPL(clk_set_rate);
+/**
- clk_get_parent - return the parent of a clk
- @clk: the clk whose parent gets returned
- Simply returns clk->parent. Returns NULL if clk is NULL.
- */
+struct clk *clk_get_parent(struct clk *clk) +{
- struct clk *parent;
- mutex_lock(&prepare_lock);
- parent = __clk_get_parent(clk);
- mutex_unlock(&prepare_lock);
- return parent;
+} +EXPORT_SYMBOL_GPL(clk_get_parent);
+/*
- .get_parent is mandatory for clocks with multiple possible parents. It is
- optional for single-parent clocks. Always call .get_parent if it is
- available and WARN if it is missing for multi-parent clocks.
- For single-parent clocks without .get_parent, first check to see if the
- .parents array exists, and if so use it to avoid an expensive tree
- traversal. If .parents does not exist then walk the tree with __clk_lookup.
- */
+static struct clk *__clk_init_parent(struct clk *clk) +{
- struct clk *ret = NULL;
- u8 index;
- /* handle the trivial cases */
- if (!clk->num_parents)
goto out;- if (clk->num_parents == 1) {
if (IS_ERR_OR_NULL(clk->parent))ret = clk->parent = __clk_lookup(clk->parent_names[0]);ret = clk->parent;goto out;- }
- if (!clk->ops->get_parent) {
WARN(!clk->ops->get_parent,"%s: multi-parent clocks must implement .get_parent\n",__func__);goto out;- };
- /*
* Do our best to cache parent clocks in clk->parents. This prevents* unnecessary and expensive calls to __clk_lookup. We don't set* clk->parent here; that is done by the calling function*/- index = clk->ops->get_parent(clk->hw);
- if (!clk->parents)
clk->parents =kmalloc((sizeof(struct clk*) * clk->num_parents),GFP_KERNEL);- if (!clk->parents)
ret = __clk_lookup(clk->parent_names[index]);- else if (!clk->parents[index])
ret = clk->parents[index] =__clk_lookup(clk->parent_names[index]);- else
ret = clk->parents[index];+out:
- return ret;
+}
+void __clk_reparent(struct clk *clk, struct clk *new_parent) +{ +#ifdef CONFIG_COMMON_CLK_DEBUG
- struct dentry *d;
- struct dentry *new_parent_d;
+#endif
- if (!clk || !new_parent)
return;- hlist_del(&clk->child_node);
- if (new_parent)
hlist_add_head(&clk->child_node,&new_parent->children);- else
hlist_add_head(&clk->child_node,&clk_orphan_list);+#ifdef CONFIG_COMMON_CLK_DEBUG
- if (!inited)
goto out;- if (new_parent)
new_parent_d = new_parent->dentry;- else
new_parent_d = orphandir;- d = debugfs_rename(clk->dentry->d_parent, clk->dentry,
new_parent_d, clk->name);- if (d)
clk->dentry = d;- else
pr_debug("%s: failed to rename debugfs entry for %s\n",__func__, clk->name);+out: +#endif
- clk->parent = new_parent;
- __clk_recalc_rates(clk, POST_RATE_CHANGE);
+}
+static int __clk_set_parent(struct clk *clk, struct clk *parent) +{
- struct clk *old_parent;
- unsigned long flags;
- int ret = -EINVAL;
- u8 i;
- old_parent = clk->parent;
- /* find index of new parent clock using cached parent ptrs */
- for (i = 0; i< clk->num_parents; i++)
if (clk->parents[i] == parent)break;- /*
* find index of new parent clock using string name comparison* also try to cache the parent to avoid future calls to __clk_lookup*/- if (i == clk->num_parents)
for (i = 0; i< clk->num_parents; i++)if (!strcmp(clk->parent_names[i], parent->name)) {clk->parents[i] = __clk_lookup(parent->name);break;}- if (i == clk->num_parents) {
pr_debug("%s: clock %s is not a possible parent of clock %s\n",__func__, parent->name, clk->name);goto out;- }
- /* migrate prepare and enable */
- if (clk->prepare_count)
__clk_prepare(parent);- /* FIXME replace with clk_is_enabled(clk) someday */
- spin_lock_irqsave(&enable_lock, flags);
- if (clk->enable_count)
__clk_enable(parent);- spin_unlock_irqrestore(&enable_lock, flags);
- /* change clock input source */
- ret = clk->ops->set_parent(clk->hw, i);
- /* clean up old prepare and enable */
- spin_lock_irqsave(&enable_lock, flags);
- if (clk->enable_count)
__clk_disable(old_parent);- spin_unlock_irqrestore(&enable_lock, flags);
- if (clk->prepare_count)
__clk_unprepare(old_parent);+out:
- return ret;
+}
+/**
- clk_set_parent - switch the parent of a mux clk
- @clk: the mux clk whose input we are switching
- @parent: the new input to clk
- Re-parent clk to use parent as it's new input source. If clk has the
- CLK_SET_PARENT_GATE flag set then clk must be gated for this
- operation to succeed. After successfully changing clk's parent
- clk_set_parent will update the clk topology, sysfs topology and
- propagate rate recalculation via __clk_recalc_rates. Returns 0 on
- success, -EERROR otherwise.
- */
+int clk_set_parent(struct clk *clk, struct clk *parent) +{
- int ret = 0;
- if (!clk || !clk->ops)
return -EINVAL;- if (!clk->ops->set_parent)
return -ENOSYS;- /* prevent racing with updates to the clock topology */
- mutex_lock(&prepare_lock);
- if (clk->parent == parent)
goto out;- /* propagate PRE_RATE_CHANGE notifications */
- if (clk->notifier_count)
ret = __clk_speculate_rates(clk, parent->rate);- /* abort if a driver objects */
- if (ret == NOTIFY_STOP)
goto out;- /* only re-parent if the clock is not in use */
- if ((clk->flags& CLK_SET_PARENT_GATE)&& clk->prepare_count)
ret = -EBUSY;- else
ret = __clk_set_parent(clk, parent);- /* propagate ABORT_RATE_CHANGE if .set_parent failed */
- if (ret) {
__clk_recalc_rates(clk, ABORT_RATE_CHANGE);goto out;- }
- /* propagate rate recalculation downstream */
- __clk_reparent(clk, parent);
+out:
- mutex_unlock(&prepare_lock);
- return ret;
+} +EXPORT_SYMBOL_GPL(clk_set_parent);
+/**
- __clk_init - initialize the data structures in a struct clk
- @dev: device initializing this clk, placeholder for now
- @clk: clk being initialized
- Initializes the lists in struct clk, queries the hardware for the
- parent and rate and sets them both.
- Any struct clk passed into __clk_init must have the following members
- populated:
- .name
- .ops
- .hw
- .parent_names
- .num_parents
- .flags
- Essentially, everything that would normally be passed into clk_register is
- assumed to be initialized already in __clk_init. The other members may be
- populated, but are optional.
- __clk_init is only exposed via clk-private.h and is intended for use with
- very large numbers of clocks that need to be statically initialized. It is
- a layering violation to include clk-private.h from any code which implements
- a clock's .ops; as such any statically initialized clock data MUST be in a
- separate C file from the logic that implements it's operations.
- */
+void __clk_init(struct device *dev, struct clk *clk) +{
- int i;
- struct clk *orphan;
- struct hlist_node *tmp, *tmp2;
- if (!clk)
return;- mutex_lock(&prepare_lock);
- /* check to see if a clock with this name is already registered */
- if (__clk_lookup(clk->name))
goto out;- /* throw a WARN if any entries in parent_names are NULL */
- for (i = 0; i< clk->num_parents; i++)
WARN(!clk->parent_names[i],"%s: invalid NULL in %s's .parent_names\n",__func__, clk->name);- /*
* Allocate an array of struct clk *'s to avoid unnecessary string* look-ups of clk's possible parents. This can fail for clocks passed* in to clk_init during early boot; thus any access to clk->parents[]* must always check for a NULL pointer and try to populate it if* necessary.** If clk->parents is not NULL we skip this entire block. This allows* for clock drivers to statically initialize clk->parents.*/- if (clk->num_parents&& !clk->parents) {
clk->parents = kmalloc((sizeof(struct clk*) * clk->num_parents),GFP_KERNEL);/** __clk_lookup returns NULL for parents that have not been* clk_init'd; thus any access to clk->parents[] must check* for a NULL pointer. We can always perform lazy lookups for* missing parents later on.*/if (clk->parents)for (i = 0; i< clk->num_parents; i++)clk->parents[i] =__clk_lookup(clk->parent_names[i]);- }
- clk->parent = __clk_init_parent(clk);
- /*
* Populate clk->parent if parent has already been __clk_init'd. If* parent has not yet been __clk_init'd then place clk in the orphan* list. If clk has set the CLK_IS_ROOT flag then place it in the root* clk list.** Every time a new clk is clk_init'd then we walk the list of orphan* clocks and re-parent any that are children of the clock currently* being clk_init'd.*/- if (clk->parent)
hlist_add_head(&clk->child_node,&clk->parent->children);- else if (clk->flags& CLK_IS_ROOT)
hlist_add_head(&clk->child_node,&clk_root_list);- else
hlist_add_head(&clk->child_node,&clk_orphan_list);- /*
* Set clk's rate. The preferred method is to use .recalc_rate. For* simple clocks and lazy developers the default fallback is to use the* parent's rate. If a clock doesn't have a parent (or is orphaned)* then rate is set to zero.*/- if (clk->ops->recalc_rate)
clk->rate = clk->ops->recalc_rate(clk->hw,__clk_get_rate(clk->parent));- else if (clk->parent)
clk->rate = clk->parent->rate;- else
clk->rate = 0;- /*
* walk the list of orphan clocks and reparent any that are children of* this clock*/- hlist_for_each_entry_safe(orphan, tmp, tmp2,&clk_orphan_list, child_node)
for (i = 0; i< orphan->num_parents; i++)if (!strcmp(clk->name, orphan->parent_names[i])) {__clk_reparent(orphan, clk);break;}- /*
* optional platform-specific magic** The .init callback is not used by any of the basic clock types, but* exists for weird hardware that must perform initialization magic.* Please consider other ways of solving initialization problems before* using this callback, as it's use is discouraged.*/- if (clk->ops->init)
clk->ops->init(clk->hw);- clk_debug_register(clk);
+out:
- mutex_unlock(&prepare_lock);
- return;
+}
+/**
- clk_register - allocate a new clock, register it and return an opaque cookie
- @dev: device that is registering this clock
- @name: clock name
- @ops: operations this clock supports
- @hw: link to hardware-specific clock data
- @parent_names: array of string names for all possible parents
- @num_parents: number of possible parents
- @flags: framework-level hints and quirks
- clk_register is the primary interface for populating the clock tree with new
- clock nodes. It returns a pointer to the newly allocated struct clk which
- cannot be dereferenced by driver code but may be used in conjuction with the
- rest of the clock API.
- */
+struct clk *clk_register(struct device *dev, const char *name,
const struct clk_ops *ops, struct clk_hw *hw,char **parent_names, u8 num_parents, unsigned long flags)+{
- struct clk *clk;
- clk = kzalloc(sizeof(*clk), GFP_KERNEL);
- if (!clk)
return NULL;- clk->name = name;
- clk->ops = ops;
- clk->hw = hw;
- clk->flags = flags;
- clk->parent_names = parent_names;
- clk->num_parents = num_parents;
- hw->clk = clk;
- __clk_init(dev, clk);
- return clk;
+} +EXPORT_SYMBOL_GPL(clk_register);
+/*** clk rate change notifiers ***/
+/**
- clk_notifier_register - add a clk rate change notifier
- @clk: struct clk * to watch
- @nb: struct notifier_block * with callback info
- Request notification when clk's rate changes. This uses an SRCU
- notifier because we want it to block and notifier unregistrations are
- uncommon. The callbacks associated with the notifier must not
- re-enter into the clk framework by calling any top-level clk APIs;
- this will cause a nested prepare_lock mutex.
- Pre-change notifier callbacks will be passed the current, pre-change
- rate of the clk via struct clk_notifier_data.old_rate. The new,
- post-change rate of the clk is passed via struct
- clk_notifier_data.new_rate.
- Post-change notifiers will pass the now-current, post-change rate of
- the clk in both struct clk_notifier_data.old_rate and struct
- clk_notifier_data.new_rate.
- Abort-change notifiers are effectively the opposite of pre-change
- notifiers: the original pre-change clk rate is passed in via struct
- clk_notifier_data.new_rate and the failed post-change rate is passed
- in via struct clk_notifier_data.old_rate.
- clk_notifier_register() must be called from non-atomic context.
- Returns -EINVAL if called with null arguments, -ENOMEM upon
- allocation failure; otherwise, passes along the return value of
- srcu_notifier_chain_register().
- */
+int clk_notifier_register(struct clk *clk, struct notifier_block *nb) +{
- struct clk_notifier *cn;
- int ret = -ENOMEM;
- if (!clk || !nb)
return -EINVAL;- mutex_lock(&prepare_lock);
- /* search the list of notifiers for this clk */
- list_for_each_entry(cn,&clk_notifier_list, node)
if (cn->clk == clk)break;- /* if clk wasn't in the notifier list, allocate new clk_notifier */
- if (cn->clk != clk) {
cn = kzalloc(sizeof(struct clk_notifier), GFP_KERNEL);if (!cn)goto out;cn->clk = clk;srcu_init_notifier_head(&cn->notifier_head);list_add(&cn->node,&clk_notifier_list);- }
- ret = srcu_notifier_chain_register(&cn->notifier_head, nb);
- clk->notifier_count++;
+out:
- mutex_unlock(&prepare_lock);
- return ret;
+} +EXPORT_SYMBOL_GPL(clk_notifier_register);
+/**
- clk_notifier_unregister - remove a clk rate change notifier
- @clk: struct clk *
- @nb: struct notifier_block * with callback info
- Request no further notification for changes to 'clk' and frees memory
- allocated in clk_notifier_register.
- Returns -EINVAL if called with null arguments; otherwise, passes
- along the return value of srcu_notifier_chain_unregister().
- */
+int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb) +{
- struct clk_notifier *cn = NULL;
- int ret = -EINVAL;
- if (!clk || !nb)
return -EINVAL;- mutex_lock(&prepare_lock);
- list_for_each_entry(cn,&clk_notifier_list, node)
if (cn->clk == clk)break;- if (cn->clk == clk) {
ret = srcu_notifier_chain_unregister(&cn->notifier_head, nb);clk->notifier_count--;/* XXX the notifier code should handle this better */if (!cn->notifier_head.head) {srcu_cleanup_notifier_head(&cn->notifier_head);kfree(cn);}- } else {
ret = -ENOENT;- }
- mutex_unlock(&prepare_lock);
- return ret;
+} +EXPORT_SYMBOL_GPL(clk_notifier_unregister); diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h new file mode 100644 index 0000000..e2cce6f --- /dev/null +++ b/include/linux/clk-private.h @@ -0,0 +1,72 @@ +/*
- linux/include/linux/clk-private.h
- Copyright (c) 2010-2011 Jeremy Kerrjeremy.kerr@canonical.com
- Copyright (C) 2011-2012 Linaro Ltdmturquette@linaro.org
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License version 2 as
- published by the Free Software Foundation.
- */
+#ifndef __LINUX_CLK_PRIVATE_H +#define __LINUX_CLK_PRIVATE_H
+#include<linux/clk-provider.h> +#include<linux/list.h>
+/*
- WARNING: Do not include clk-private.h from any file that implements struct
- clk_ops. Doing so is a layering violation!
- This header exists only to allow for statically initialized clock data. Any
- static clock data must be defined in a separate file from the logic that
- implements the clock operations for that same data.
- */
+#ifdef CONFIG_COMMON_CLK
+struct clk {
- const char *name;
- const struct clk_ops *ops;
- struct clk_hw *hw;
- struct clk *parent;
- char **parent_names;
- struct clk **parents;
- u8 num_parents;
- unsigned long rate;
- unsigned long new_rate;
- unsigned long flags;
- unsigned int enable_count;
- unsigned int prepare_count;
- struct hlist_head children;
- struct hlist_node child_node;
- unsigned int notifier_count;
+#ifdef CONFIG_COMMON_CLK_DEBUG
- struct dentry *dentry;
+#endif +};
+/**
- __clk_init - initialize the data structures in a struct clk
- @dev: device initializing this clk, placeholder for now
- @clk: clk being initialized
- Initializes the lists in struct clk, queries the hardware for the
- parent and rate and sets them both.
- Any struct clk passed into __clk_init must have the following members
- populated:
- .name
- .ops
- .hw
- .parent_names
- .num_parents
- .flags
- It is not necessary to call clk_register if __clk_init is used directly with
- statically initialized clock data.
- */
+void __clk_init(struct device *dev, struct clk *clk);
+#endif /* CONFIG_COMMON_CLK */ +#endif /* CLK_PRIVATE_H */ diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h new file mode 100644 index 0000000..b18b0e7 --- /dev/null +++ b/include/linux/clk-provider.h @@ -0,0 +1,173 @@ +/*
- linux/include/linux/clk-provider.h
- Copyright (c) 2010-2011 Jeremy Kerrjeremy.kerr@canonical.com
- Copyright (C) 2011-2012 Linaro Ltdmturquette@linaro.org
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License version 2 as
- published by the Free Software Foundation.
- */
+#ifndef __LINUX_CLK_PROVIDER_H +#define __LINUX_CLK_PROVIDER_H
+#include<linux/clk.h>
+#ifdef CONFIG_COMMON_CLK
+/**
- struct clk_hw - handle for traversing from a struct clk to its corresponding
- hardware-specific structure. struct clk_hw should be declared within struct
- clk_foo and then referenced by the struct clk instance that uses struct
- clk_foo's clk_ops
- clk: pointer to the struct clk instance that points back to this struct
- clk_hw instance
- */
+struct clk_hw {
- struct clk *clk;
+};
+/*
- flags used across common struct clk. these flags should only affect the
- top-level framework. custom flags for dealing with hardware specifics
- belong in struct clk_foo
- */
+#define CLK_SET_RATE_GATE BIT(0) /* must be gated across rate change */ +#define CLK_SET_PARENT_GATE BIT(1) /* must be gated across re-parent */ +#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one level */ +#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */ +#define CLK_IS_ROOT BIT(4) /* root clk, has no parent */
+/**
- struct clk_ops - Callback operations for hardware clocks; these are to
- be provided by the clock implementation, and will be called by drivers
- through the clk_* api.
- @prepare: Prepare the clock for enabling. This must not return until
the clock is fully prepared, and it's safe to call clk_enable.
This callback is intended to allow clock implementations to
do any initialisation that may sleep. Called with
prepare_lock held.
- @unprepare: Release the clock from its prepared state. This will typically
undo any work done in the @prepare callback. Called with
prepare_lock held.
- @enable: Enable the clock atomically. This must not return until the
clock is generating a valid clock signal, usable by consumer
devices. Called with enable_lock held. This function must not
sleep.
- @disable: Disable the clock atomically. Called with enable_lock held.
This function must not sleep.
- @recalc_rate Recalculate the rate of this clock, by quering hardware. The
parent rate is an input parameter. It is up to the caller to
insure that the prepare_mutex is held across this call.
Returns the calculated rate. Optional, but recommended - if
this op is not set then clock rate will be initialized to 0.
- @round_rate: Given a target rate as input, returns the closest rate actually
supported by the clock.
- @get_parent: Queries the hardware to determine the parent of a clock. The
return value is a u8 which specifies the index corresponding to
the parent clock. This index can be applied to either the
.parent_names or .parents arrays. In short, this function
translates the parent value read from hardware into an array
index. Currently only called when the clock is initialized by
__clk_init. This callback is mandatory for clocks with
multiple parents. It is optional (and unnecessary) for clocks
with 0 or 1 parents.
- @set_parent: Change the input source of this clock; for clocks with multiple
possible parents specify a new parent by passing in the index
as a u8 corresponding to the parent in either the .parent_names
or .parents arrays. This function in affect translates an
array index into the value programmed into the hardware.
Returns 0 on success, -EERROR otherwise.
- @set_rate: Change the rate of this clock. If this callback returns
CLK_SET_RATE_PARENT, the rate change will be propagated to the
parent clock (which may propagate again if the parent clock
also sets this flag). The requested rate of the parent is
passed back from the callback in the second 'unsigned long *'
argument. Note that it is up to the hardware clock's set_rate
implementation to insure that clocks do not run out of spec
when propgating the call to set_rate up to the parent. One way
to do this is to gate the clock (via clk_disable and/or
clk_unprepare) before calling clk_set_rate, then ungating it
afterward. If your clock also has the CLK_GATE_SET_RATE flag
set then this will insure safety. Returns 0 on success,
-EERROR otherwise.
- The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
- implementations to split any work between atomic (enable) and sleepable
- (prepare) contexts. If enabling a clock requires code that might sleep,
- this must be done in clk_prepare. Clock enable code that will never be
- called in a sleepable context may be implement in clk_enable.
- Typically, drivers will call clk_prepare when a clock may be needed later
- (eg. when a device is opened), and clk_enable when the clock is actually
- required (eg. from an interrupt). Note that clk_prepare MUST have been
- called before clk_enable.
- */
+struct clk_ops {
- int (*prepare)(struct clk_hw *hw);
- void (*unprepare)(struct clk_hw *hw);
- int (*enable)(struct clk_hw *hw);
- void (*disable)(struct clk_hw *hw);
- int (*is_enabled)(struct clk_hw *hw);
- unsigned long (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);- long (*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);- int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
- int (*set_rate)(struct clk_hw *hw, unsigned long);
- void (*init)(struct clk_hw *hw);
+};
+/**
- clk_register - allocate a new clock, register it and return an opaque cookie
- @dev: device that is registering this clock
- @name: clock name
- @ops: operations this clock supports
- @hw: link to hardware-specific clock data
- @parent_names: array of string names for all possible parents
- @num_parents: number of possible parents
- @flags: framework-level hints and quirks
- clk_register is the primary interface for populating the clock tree with new
- clock nodes. It returns a pointer to the newly allocated struct clk which
- cannot be dereferenced by driver code but may be used in conjuction with the
- rest of the clock API.
- */
+struct clk *clk_register(struct device *dev, const char *name,
const struct clk_ops *ops, struct clk_hw *hw,char **parent_names, u8 num_parents, unsigned long flags);+/* helper functions */ +const char *__clk_get_name(struct clk *clk); +struct clk_hw *__clk_get_hw(struct clk *clk); +u8 __clk_get_num_parents(struct clk *clk); +struct clk *__clk_get_parent(struct clk *clk); +inline int __clk_get_enable_count(struct clk *clk); +inline int __clk_get_prepare_count(struct clk *clk); +unsigned long __clk_get_rate(struct clk *clk); +unsigned long __clk_get_flags(struct clk *clk); +int __clk_is_enabled(struct clk *clk); +struct clk *__clk_lookup(const char *name);
+/*
- FIXME clock api without lock protection
- */
+int __clk_prepare(struct clk *clk); +void __clk_unprepare(struct clk *clk); +void __clk_reparent(struct clk *clk, struct clk *new_parent); +unsigned long __clk_round_rate(struct clk *clk, unsigned long rate);
+#endif /* CONFIG_COMMON_CLK */ +#endif /* CLK_PROVIDER_H */ diff --git a/include/linux/clk.h b/include/linux/clk.h index b9d46fa..b025272 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -3,6 +3,7 @@
- Copyright (C) 2004 ARM Limited.
- Written by Deep Blue Solutions Limited.
- Copyright (C) 2011-2012 Linaro Ltdmturquette@linaro.org
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License version 2 as
@@ -12,18 +13,75 @@ #define __LINUX_CLK_H
#include<linux/kernel.h> +#include<linux/notifier.h>
struct device;
-/*
- The base API.
+struct clk;
+#ifdef CONFIG_COMMON_CLK
+/**
- DOC: clk notifier callback types
- PRE_RATE_CHANGE - called immediately before the clk rate is changed,
to indicate that the rate change will proceed. Drivers must
immediately terminate any operations that will be affected by the
rate change. Callbacks may either return NOTIFY_DONE or
NOTIFY_STOP.
- ABORT_RATE_CHANGE: called if the rate change failed for some reason
after PRE_RATE_CHANGE. In this case, all registered notifiers on
the clk will be called with ABORT_RATE_CHANGE. Callbacks must
always return NOTIFY_DONE.
- POST_RATE_CHANGE - called after the clk rate change has successfully
completed. Callbacks must always return NOTIFY_DONE.*/
+#define PRE_RATE_CHANGE BIT(0) +#define POST_RATE_CHANGE BIT(1) +#define ABORT_RATE_CHANGE BIT(2)
+/**
- struct clk_notifier - associate a clk with a notifier
- @clk: struct clk * to associate the notifier with
- @notifier_head: a blocking_notifier_head for this clk
- @node: linked list pointers
- A list of struct clk_notifier is maintained by the notifier code.
- An entry is created whenever code registers the first notifier on a
- particular @clk. Future notifiers on that @clk are added to the
- @notifier_head.
- */
+struct clk_notifier {
- struct clk *clk;
- struct srcu_notifier_head notifier_head;
- struct list_head node;
+};
-/*
- struct clk - an machine class defined object / cookie.
+/**
- struct clk_notifier_data - rate data to pass to the notifier callback
- @clk: struct clk * being changed
- @old_rate: previous rate of this clk
- @new_rate: new rate of this clk
- For a pre-notifier, old_rate is the clk's rate before this rate
- change, and new_rate is what the rate will be in the future. For a
- post-notifier, old_rate and new_rate are both set to the clk's
*/
- current rate (this was done to optimize the implementation).
-struct clk; +struct clk_notifier_data {
- struct clk *clk;
- unsigned long old_rate;
- unsigned long new_rate;
+};
+int clk_notifier_register(struct clk *clk, struct notifier_block *nb);
+int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb);
+#endif /* !CONFIG_COMMON_CLK */
/**
- clk_get - lookup and obtain a reference to a clock producer.
On Mon, Mar 19, 2012 at 04:52:05PM +0530, Rajendra Nayak wrote:
Hi Mike,
+/*
- calculate the new rates returning the topmost clock that has to be
- changed.
- */
+static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) +{
- struct clk *top = clk;
- unsigned long best_parent_rate = clk->parent->rate;
Shouldn't you check for a valid parent before dereferencing it? A clk_set_rate() on a root clock might throw up some issues otherwise.
Yes, should be checked.
- unsigned long new_rate;
- if (!clk->ops->round_rate&& !(clk->flags& CLK_SET_RATE_PARENT)) {
clk->new_rate = clk->rate;return NULL;So does this mean a clk_set_rate() fails for a clk which does not have a valid .round_rate and does not have a CLK_SET_RATE_PARENT flag set? I was thinking this could do a.. clk->new_rate = rate; top = clk; goto out; ..instead.
The core should make sure that either both set_rate and round_rate are present or none of them.
Sascha
On Mon, Mar 19, 2012 at 4:28 AM, Sascha Hauer s.hauer@pengutronix.de wrote:
On Mon, Mar 19, 2012 at 04:52:05PM +0530, Rajendra Nayak wrote:
Hi Mike,
+/*
- calculate the new rates returning the topmost clock that has to be
- changed.
- */
+static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) +{
- struct clk *top = clk;
- unsigned long best_parent_rate = clk->parent->rate;
Shouldn't you check for a valid parent before dereferencing it? A clk_set_rate() on a root clock might throw up some issues otherwise.
Yes, should be checked.
The clk_calc_new_rates code assumes a valid parent pointer in several locations. Thanks for the catch Rajendra. Will roll into my fixes series.
- unsigned long new_rate;
- if (!clk->ops->round_rate&& !(clk->flags& CLK_SET_RATE_PARENT)) {
- clk->new_rate = clk->rate;
- return NULL;
So does this mean a clk_set_rate() fails for a clk which does not have a valid .round_rate and does not have a CLK_SET_RATE_PARENT flag set? I was thinking this could do a.. clk->new_rate = rate; top = clk; goto out; ..instead.
The core should make sure that either both set_rate and round_rate are present or none of them.
Agreed. The documentation covers which clk_ops are hard dependencies (based on supported operations), but the code doesn't strictly check this. I'll add a small state machine to __clk_init which validates that .round_rate, .recalc_rate and .set_rate are *all* present if any one of them are present, and present a WARN if otherwise.
Thanks, Mike
On Mon, Mar 19, 2012 at 4:22 AM, Rajendra Nayak rnayak@ti.com wrote:
On Friday 16 March 2012 11:41 AM, Mike Turquette wrote:
+/*
- calculate the new rates returning the topmost clock that has to be
- changed.
- */
+static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) +{
- struct clk *top = clk;
- unsigned long best_parent_rate = clk->parent->rate;
Shouldn't you check for a valid parent before dereferencing it? A clk_set_rate() on a root clock might throw up some issues otherwise.
Yes, the clk_calc_new_rates code assumes a valid parent pointer in several locations. Thanks for the catch. Will roll into my fixes series.
Regards, Mike
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+struct clk_ops {
- int (*prepare)(struct clk_hw *hw);
- void (*unprepare)(struct clk_hw *hw);
- int (*enable)(struct clk_hw *hw);
- void (*disable)(struct clk_hw *hw);
- int (*is_enabled)(struct clk_hw *hw);
- unsigned long (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);
I believe I have heard people love the interface with parent_rate passed in. I love that too. But I would like to ask the same thing on .round_rate and .set_rate as well for the same reason why we have it for .recalc_rate.
- long (*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
Yes, we already have parent_rate passed in .round_rate with an pointer. But I think it'd be better to have it passed in no matter flag CLK_SET_RATE_PARENT is set or not. Something like:
8<--- @@ -584,7 +584,7 @@ EXPORT_SYMBOL_GPL(clk_get_rate); */ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate) { - unsigned long unused; + unsigned long parent_rate = 0;
if (!clk) return -EINVAL; @@ -592,10 +592,10 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate) if (!clk->ops->round_rate) return clk->rate;
- if (clk->flags & CLK_SET_RATE_PARENT) - return clk->ops->round_rate(clk->hw, rate, &unused); - else - return clk->ops->round_rate(clk->hw, rate, NULL); + if (clk->parent) + parent_rate = clk->parent->rate; + + return clk->ops->round_rate(clk->hw, rate, &parent_rate); }
/** @@ -765,9 +765,12 @@ static void clk_calc_subtree(struct clk *clk, unsigned long new_rate) static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) { struct clk *top = clk; - unsigned long best_parent_rate = clk->parent->rate; + unsigned long best_parent_rate = 0; unsigned long new_rate;
+ if (clk->parent) + best_parent_rate = clk->parent->rate; + if (!clk->ops->round_rate && !(clk->flags & CLK_SET_RATE_PARENT)) { clk->new_rate = clk->rate; return NULL; @@ -780,10 +783,7 @@ static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) goto out; }
- if (clk->flags & CLK_SET_RATE_PARENT) - new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate); - else - new_rate = clk->ops->round_rate(clk->hw, rate, NULL); + new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
if (best_parent_rate != clk->parent->rate) { top = clk_calc_new_rates(clk->parent, best_parent_rate);
--->8
The reason behind the change is that any clk implements .round_rate will mostly need to get the parent rate, no matter flag CLK_SET_RATE_PARENT is set or not. Instead of expecting every .round_rate implementation to get the parent rate in the way beloe
parent_rate = __clk_get_rate(__clk_get_parent(hw->clk));
we can just pass the parent rate into .round_rate.
- int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
- int (*set_rate)(struct clk_hw *hw, unsigned long);
For the same reason, I would change .set_rate interface like below.
8<---
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c index d5ac6a7..6bd8037 100644 --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -119,7 +119,8 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, } EXPORT_SYMBOL_GPL(clk_divider_round_rate);
-static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate) +static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate, + unsigned long parent_rate) { struct clk_divider *divider = to_clk_divider(hw); unsigned int div; diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index dbc310a..d74ac4b 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -833,17 +833,18 @@ static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long even static void clk_change_rate(struct clk *clk) { struct clk *child; - unsigned long old_rate; + unsigned long old_rate, parent_rate = 0; struct hlist_node *tmp;
old_rate = clk->rate; + if (clk->parent) + parent_rate = clk->parent->rate;
if (clk->ops->set_rate) - clk->ops->set_rate(clk->hw, clk->new_rate); + clk->ops->set_rate(clk->hw, clk->new_rate, parent_rate);
if (clk->ops->recalc_rate) - clk->rate = clk->ops->recalc_rate(clk->hw, - clk->parent->rate); + clk->rate = clk->ops->recalc_rate(clk->hw, parent_rate); else clk->rate = clk->parent->rate;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index 5508897..1031f1f 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -125,7 +125,8 @@ struct clk_ops { unsigned long *); int (*set_parent)(struct clk_hw *hw, u8 index); u8 (*get_parent)(struct clk_hw *hw); - int (*set_rate)(struct clk_hw *hw, unsigned long); + int (*set_rate)(struct clk_hw *hw, unsigned long, + unsigned long); void (*init)(struct clk_hw *hw); };
--->8
Then with parent rate passed into .round_rate and .set_rate like what we do with .recalc_rate right now, we can save particular clk implementation from calling __clk_get_parent() and __clk_get_rate to get parent rate.
For example, the following will the be diff we gain on clk-divider.
8<---
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c index 6bd8037..8a28ffb 100644 --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -68,8 +68,8 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate, if (divider->flags & CLK_DIVIDER_ONE_BASED) maxdiv--;
- if (!best_parent_rate) { - parent_rate = __clk_get_rate(__clk_get_parent(hw->clk)); + if (!(divider->flags & CLK_SET_RATE_PARENT)) { + parent_rate = *best_parent_rate; bestdiv = DIV_ROUND_UP(parent_rate, rate); bestdiv = bestdiv == 0 ? 1 : bestdiv; bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv; @@ -109,13 +109,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, int div; div = clk_divider_bestdiv(hw, rate, prate);
- if (prate) - return *prate / div; - else { - unsigned long r; - r = __clk_get_rate(__clk_get_parent(hw->clk)); - return r / div; - } + return *prate / div; } EXPORT_SYMBOL_GPL(clk_divider_round_rate);
@@ -127,7 +121,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long flags = 0; u32 val;
- div = __clk_get_rate(__clk_get_parent(hw->clk)) / rate; + div = parent_rate / rate;
if (!(divider->flags & CLK_DIVIDER_ONE_BASED)) div--;
--->8
I always get a sense of worry in using functions named in __xxx which sounds like something somehow internal. With the requested interface change above, I can get all __xxx functions out of my clk_ops implementation.
- void (*init)(struct clk_hw *hw);
+};
On Tue, March 20, 2012 7:02 am, Shawn Guo wrote:
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+struct clk_ops {
- int (*prepare)(struct clk_hw *hw);
- void (*unprepare)(struct clk_hw *hw);
- int (*enable)(struct clk_hw *hw);
- void (*disable)(struct clk_hw *hw);
- int (*is_enabled)(struct clk_hw *hw);
- unsigned long (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);I believe I have heard people love the interface with parent_rate passed in. I love that too. But I would like to ask the same thing on .round_rate and .set_rate as well for the same reason why we have it for .recalc_rate.
In my case, for most clocks, set rate involves reparenting. So, what does passing parent_rate for these even mean? Passing parent_rate seems more apt for recalc_rate since it's called when the parent rate changes -- so, the actual parent itself is not expected to change.
I could ignore the parameter, but just wondering how many of the others see value in this. And if we do add this parameter, it shouldn't be made mandatory for the platform driver to use it (due to other assumptions the clock framework might make).
-Saravana
On Tue, Mar 20, 2012 at 10:46 AM, Saravana Kannan skannan@codeaurora.org wrote:
On Tue, March 20, 2012 7:02 am, Shawn Guo wrote:
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+struct clk_ops {
- int (*prepare)(struct clk_hw *hw);
- void (*unprepare)(struct clk_hw *hw);
- int (*enable)(struct clk_hw *hw);
- void (*disable)(struct clk_hw *hw);
- int (*is_enabled)(struct clk_hw *hw);
- unsigned long (*recalc_rate)(struct clk_hw *hw,
- unsigned long parent_rate);
I believe I have heard people love the interface with parent_rate passed in. I love that too. But I would like to ask the same thing on .round_rate and .set_rate as well for the same reason why we have it for .recalc_rate.
In my case, for most clocks, set rate involves reparenting. So, what does passing parent_rate for these even mean? Passing parent_rate seems more apt for recalc_rate since it's called when the parent rate changes -- so, the actual parent itself is not expected to change.
From my conversations with folks across many platforms, I think that
the way your clock tree expects to change rates is the exception, not the rule. As such you should just ignore the parent_rate parameter as it useless to you.
I could ignore the parameter, but just wondering how many of the others see value in this. And if we do add this parameter, it shouldn't be made mandatory for the platform driver to use it (due to other assumptions the clock framework might make).
From my rough census of folks that actually need .set_rate support, I
think that everyone except MSM could benefit from this. Your concept of clk_set_rate is everyone else's clk_set_parent.
Ignoring the new parameter should cause you no harm. It does make me wonder if it would be a good idea to pass in the parent rate for .set_parent, which is analogous to .set_rate in many ways.
Regards, Mike
-Saravana
On 03/20/2012 04:53 PM, Turquette, Mike wrote:
On Tue, Mar 20, 2012 at 10:46 AM, Saravana Kannan skannan@codeaurora.org wrote:
On Tue, March 20, 2012 7:02 am, Shawn Guo wrote:
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+struct clk_ops {
- int (*prepare)(struct clk_hw *hw);
- void (*unprepare)(struct clk_hw *hw);
- int (*enable)(struct clk_hw *hw);
- void (*disable)(struct clk_hw *hw);
- int (*is_enabled)(struct clk_hw *hw);
- unsigned long (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);I believe I have heard people love the interface with parent_rate passed in. I love that too. But I would like to ask the same thing on .round_rate and .set_rate as well for the same reason why we have it for .recalc_rate.
In my case, for most clocks, set rate involves reparenting. So, what does passing parent_rate for these even mean? Passing parent_rate seems more apt for recalc_rate since it's called when the parent rate changes -- so, the actual parent itself is not expected to change.
From my conversations with folks across many platforms, I think that the way your clock tree expects to change rates is the exception, not the rule. As such you should just ignore the parent_rate parameter as it useless to you.
I could ignore the parameter, but just wondering how many of the others see value in this. And if we do add this parameter, it shouldn't be made mandatory for the platform driver to use it (due to other assumptions the clock framework might make).
From my rough census of folks that actually need .set_rate support, I think that everyone except MSM could benefit from this. Your concept of clk_set_rate is everyone else's clk_set_parent.
To clarify, MSM's set parent is a subset of steps needed to be done to finish set parent. So, it's not that we just randomly decided to swap the meanings of these two functions.
Also, I think don't think the difference in view of set_rate is due to the difference in the clock trees between platforms with complicated trees. I think it's more because of who actually decides the rates for the clock tree. It looks like some platforms pick a top-down approach to deciding the rates of the clock tre while others pick a bottom-up approach.
Ignoring the new parameter should cause you no harm.
As long as this is guaranteed, I have no problems with Shawn's suggestion.
It does make me wonder if it would be a good idea to pass in the parent rate for .set_parent, which is analogous to .set_rate in many ways.
I need to think a bit more about this.
-Saravana
On 03/20/2012 08:10 PM, Saravana Kannan wrote:
On 03/20/2012 04:53 PM, Turquette, Mike wrote:
It does make me wonder if it would be a good idea to pass in the parent rate for .set_parent, which is analogous to .set_rate in many ways.
I need to think a bit more about this.
I was thinking about this. I think the common clock fwk should let the set_parent ops "return" the rate of the clock in addition to passing the rate of the parent in.
Say this is a divider clock and some one changes the parent. The cached "rate" of the clock in the clock fwk is no longer correct. So, the clock fwk should also add a "*new_rate" param to set parent ops.
Thanks, Saravana
On Fri, Mar 23, 2012 at 2:33 PM, Saravana Kannan skannan@codeaurora.org wrote:
On 03/20/2012 08:10 PM, Saravana Kannan wrote:
On 03/20/2012 04:53 PM, Turquette, Mike wrote:
It does make me wonder if it would be a good idea to pass in the parent rate for .set_parent, which is analogous to .set_rate in many ways.
I need to think a bit more about this.
I was thinking about this. I think the common clock fwk should let the set_parent ops "return" the rate of the clock in addition to passing the rate of the parent in.
Say this is a divider clock and some one changes the parent. The cached "rate" of the clock in the clock fwk is no longer correct. So, the clock fwk should also add a "*new_rate" param to set parent ops.
__clk_recalc_rates is called by __clk_reparent which is called by clk_set_parent. __clk_recalc_rates is also called by clk_set_rate.
Does this not handle the old cached clk->rate for you?
Thanks, Mike
Thanks,
Saravana
-- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
On Fri, Mar 23, 2012 at 2:33 PM, Saravana Kannanskannan@codeaurora.org wrote:
On 03/20/2012 08:10 PM, Saravana Kannan wrote:
On 03/20/2012 04:53 PM, Turquette, Mike wrote:
It does make me wonder if it would be a good idea to pass in the parent rate for .set_parent, which is analogous to .set_rate in many ways.
I need to think a bit more about this.
I was thinking about this. I think the common clock fwk should let the set_parent ops "return" the rate of the clock in addition to passing the rate of the parent in.
Say this is a divider clock and some one changes the parent. The cached "rate" of the clock in the clock fwk is no longer correct. So, the clock fwk should also add a "*new_rate" param to set parent ops.
__clk_recalc_rates is called by __clk_reparent which is called by clk_set_parent. __clk_recalc_rates is also called by clk_set_rate.
Does this not handle the old cached clk->rate for you?
Yeah, I realized this just after I sent the email. I'm looking at the code to see if that's sufficient or not. Will get back soon.
-Saravana
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
On Fri, Mar 23, 2012 at 2:33 PM, Saravana Kannanskannan@codeaurora.org wrote:
On 03/20/2012 08:10 PM, Saravana Kannan wrote:
On 03/20/2012 04:53 PM, Turquette, Mike wrote:
It does make me wonder if it would be a good idea to pass in the parent rate for .set_parent, which is analogous to .set_rate in many ways.
I need to think a bit more about this.
I was thinking about this. I think the common clock fwk should let the set_parent ops "return" the rate of the clock in addition to passing the rate of the parent in.
Say this is a divider clock and some one changes the parent. The cached "rate" of the clock in the clock fwk is no longer correct. So, the clock fwk should also add a "*new_rate" param to set parent ops.
__clk_recalc_rates is called by __clk_reparent which is called by clk_set_parent. __clk_recalc_rates is also called by clk_set_rate.
Does this not handle the old cached clk->rate for you?
For the set_parent case, ops->recalc_rate() is called twice. Once for PRE_CHANGE and once for POST_CHANGE. For this clock, I can only really recalc the rate during the POST_CHANGE call. So, how should I differentiate the two cases?
On a separate note: Sorry if I missed any earlier discussion on this, but what's the reason for calling recalc_rate() pre-change and post-change but without giving it the ability to differentiate between the two?
I think it's quite useful for recalc_rate to be called pre/post change (some steps have to be done pre/post change depending on whether the parent rate is increasing or decreasing). But I don't see the "msg" being passed along.
Also, I noticed that clk_set_parent() is treating a NULL as an invalid clock. Should that be fixed? set_parent(NULL) could be treated as a grounding the clock. Should we let the ops->set_parent determine if NULL is valid option?
Thanks, Saravana
On Fri, Mar 23, 2012 at 3:12 PM, Saravana Kannan skannan@codeaurora.org wrote:
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
__clk_recalc_rates is called by __clk_reparent which is called by clk_set_parent. __clk_recalc_rates is also called by clk_set_rate.
Does this not handle the old cached clk->rate for you?
For the set_parent case, ops->recalc_rate() is called twice. Once for PRE_CHANGE and once for POST_CHANGE. For this clock, I can only really recalc the rate during the POST_CHANGE call. So, how should I differentiate the two cases?
.recalc_rate serves two purposes: first it recalculates the rate after the rate has changed and you pass in a new parent_rate argument. The second purpose is to "speculate" a rate change. You can pass in any rate for the parent_rate parameter when you call .recalc_rates. This is what __speculate_rates does before the rate changes. For clk_set_parent we call,
__clk_speculate_rates(clk, parent->rate);
Where parent above is the *new* parent. So this will let us propagate pre-rate change notifiers with the new rate.
Your .recalc_rate callback doesn't need to differentiate between the two calls to .recalc_rate. It should just take in the parent_rate value and do the calculation required of it.
Take a look at __clk_speculate_rates and __clk_recalc_rates and you'll see how to use it.
On a separate note: Sorry if I missed any earlier discussion on this, but what's the reason for calling recalc_rate() pre-change and post-change but without giving it the ability to differentiate between the two?
I think my answer above covers this. The .recalc_rate callback only exists to perform a hardware-specific calculation. The context of pre- or post-change is irrelevant since the parent_rate passed in could be the actual rate of the parent or a future rate of the parent.
I think it's quite useful for recalc_rate to be called pre/post change (some steps have to be done pre/post change depending on whether the parent rate is increasing or decreasing). But I don't see the "msg" being passed along.
What kind of steps? Does your .recalc_rate perform these steps? I need more details to understand your requirements.
Also, I noticed that clk_set_parent() is treating a NULL as an invalid clock. Should that be fixed? set_parent(NULL) could be treated as a grounding the clock. Should we let the ops->set_parent determine if NULL is valid option?
We must be looking at different code. clk_set_parent doesn't return any error if parent == NULL. Bringing this to my attention does show that we do deref the parent pointer without a check though...
Do you have a real use case for this? Due to the way that we match the parent pointer with the cached clk->parents member it would be painful to support NULL parents as valid.
It is also worth considering whether clk_set_parent is really the correct operation for grounding a clock. clk_unprepare might be a better candidate.
Regards, Mike
On 03/23/2012 03:32 PM, Turquette, Mike wrote:
On Fri, Mar 23, 2012 at 3:12 PM, Saravana Kannanskannan@codeaurora.org wrote:
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
__clk_recalc_rates is called by __clk_reparent which is called by clk_set_parent. __clk_recalc_rates is also called by clk_set_rate.
Does this not handle the old cached clk->rate for you?
For the set_parent case, ops->recalc_rate() is called twice. Once for PRE_CHANGE and once for POST_CHANGE. For this clock, I can only really recalc the rate during the POST_CHANGE call. So, how should I differentiate the two cases?
.recalc_rate serves two purposes: first it recalculates the rate after the rate has changed and you pass in a new parent_rate argument. The second purpose is to "speculate" a rate change. You can pass in any rate for the parent_rate parameter when you call .recalc_rates. This is what __speculate_rates does before the rate changes. For clk_set_parent we call,
__clk_speculate_rates(clk, parent->rate);
Where parent above is the *new* parent. So this will let us propagate pre-rate change notifiers with the new rate.
Your .recalc_rate callback doesn't need to differentiate between the two calls to .recalc_rate. It should just take in the parent_rate value and do the calculation required of it.
Yeah, this is generally true. But, in this specific case, the clock is a mux that can literally measure the real rate. I would like the rate of this mux clock to be the real measured rate and not just the parent rate.
I could actually measure the current rate and return that for recalc_rate(), but then the reported rate change during the pre-change notification would be wrong. Having the "msg" will let us at least fake the rate correctly for pre change notifiers.
I think it's quite useful for recalc_rate to be called pre/post change (some steps have to be done pre/post change depending on whether the parent rate is increasing or decreasing). But I don't see the "msg" being passed along.
What kind of steps? Does your .recalc_rate perform these steps? I need more details to understand your requirements.
Nevermind, my brain isn't working today. I can just do that different ordering in ops->set_parent(). But the measure clocks case is still true though.
But this did bring up another point in my head. Hopefully this one isn't my brain playing tricks again today.
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.
Reason for rejection could be things like the counter (for division, etc) has an upper limit on how fast it can run.
Also, I noticed that clk_set_parent() is treating a NULL as an invalid clock. Should that be fixed? set_parent(NULL) could be treated as a grounding the clock. Should we let the ops->set_parent determine if NULL is valid option?
We must be looking at different code. clk_set_parent doesn't return any error if parent == NULL. Bringing this to my attention does show that we do deref the parent pointer without a check though...
Do you have a real use case for this? Due to the way that we match the parent pointer with the cached clk->parents member it would be painful to support NULL parents as valid.
I don't have a real use case for MSM. We just have a ground_clock.
It is also worth considering whether clk_set_parent is really the correct operation for grounding a clock. clk_unprepare might be a better candidate.
Yeah, not a real use case for MSM.
Thanks, Saravana
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:
.recalc_rate serves two purposes: first it recalculates the rate after the rate has changed and you pass in a new parent_rate argument. The second purpose is to "speculate" a rate change. You can pass in any rate for the parent_rate parameter when you call .recalc_rates. This is what __speculate_rates does before the rate changes. For clk_set_parent we call,
__clk_speculate_rates(clk, parent->rate);
Where parent above is the *new* parent. So this will let us propagate pre-rate change notifiers with the new rate.
Your .recalc_rate callback doesn't need to differentiate between the two calls to .recalc_rate. It should just take in the parent_rate value and do the calculation required of it.
Yeah, this is generally true. But, in this specific case, the clock is a mux that can literally measure the real rate. I would like the rate of this mux clock to be the real measured rate and not just the parent rate.
That's pretty cool hardware. Do you find that software-only tracking doesn't match up with sampling the frequency in hardware? If software tracking of the rate changes is correct then you could just skip using this hardware feature.
I could actually measure the current rate and return that for recalc_rate(), but then the reported rate change during the pre-change notification would be wrong. Having the "msg" will let us at least fake the rate correctly for pre change notifiers.
In previous series I had separate .recalc_rate and .speculate_rate callbacks. I merged them since they were almost identical. I'd prefer not to reintroduce them since it creates a burden on others to support seperate callbacks, and passing in the message is one way to solve that... I'll think on this a bit more.
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.
Reason for rejection could be things like the counter (for division, etc) has an upper limit on how fast it can run.
Are you hitting this in practice today? The clock framework shouldn't be a perfect piece of code that can validate every possible combination imaginable. Some burden falls on the code calling the clk api (especially if that code is platform code) to make sure that it doesn't do stupid things.
Also, I noticed that clk_set_parent() is treating a NULL as an invalid clock. Should that be fixed? set_parent(NULL) could be treated as a grounding the clock. Should we let the ops->set_parent determine if NULL is valid option?
We must be looking at different code. clk_set_parent doesn't return any error if parent == NULL. Bringing this to my attention does show that we do deref the parent pointer without a check though...
Do you have a real use case for this? Due to the way that we match the parent pointer with the cached clk->parents member it would be painful to support NULL parents as valid.
I don't have a real use case for MSM. We just have a ground_clock.
I'm electing to ignore the issue until we have a real use-case for it.
Regards, Mike
On 03/23/2012 04:28 PM, Turquette, Mike wrote:
On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannanskannan@codeaurora.org wrote:
On 03/23/2012 03:32 PM, Turquette, Mike wrote:
.recalc_rate serves two purposes: first it recalculates the rate after the rate has changed and you pass in a new parent_rate argument. The second purpose is to "speculate" a rate change. You can pass in any rate for the parent_rate parameter when you call .recalc_rates. This is what __speculate_rates does before the rate changes. For clk_set_parent we call,
__clk_speculate_rates(clk, parent->rate);
Where parent above is the *new* parent. So this will let us propagate pre-rate change notifiers with the new rate.
Your .recalc_rate callback doesn't need to differentiate between the two calls to .recalc_rate. It should just take in the parent_rate value and do the calculation required of it.
Yeah, this is generally true. But, in this specific case, the clock is a mux that can literally measure the real rate. I would like the rate of this mux clock to be the real measured rate and not just the parent rate.
That's pretty cool hardware. Do you find that software-only tracking doesn't match up with sampling the frequency in hardware? If software tracking of the rate changes is correct then you could just skip using this hardware feature.
We use this HW for automated testing of the SW. It's very handy. So, I definitely need to support it.
I could actually measure the current rate and return that for recalc_rate(), but then the reported rate change during the pre-change notification would be wrong. Having the "msg" will let us at least fake the rate correctly for pre change notifiers.
In previous series I had separate .recalc_rate and .speculate_rate callbacks. I merged them since they were almost identical. I'd prefer not to reintroduce them since it creates a burden on others to support seperate callbacks, and passing in the message is one way to solve that... I'll think on this a bit more.
For this specific clock, I don't think anyone is really going to care if the pre rate change notification is correct. So, I will just go with reporting the wrong rate during pre-change for now.
But it does increase the total testing time quite a bit as I have to measure the real rate during pre and post change and measurement is relatively slow. It actually does add up into minutes when the whole test suite is run. So, would be nice to have this fixed eventually but it's not urgent for this measure clock.
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. 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.
Reason for rejection could be things like the counter (for division, etc) has an upper limit on how fast it can run.
Are you hitting this in practice today?
Such HW limitations are real. But we don't use clk_set_parent() in our drivers often.
The clock framework shouldn't be a perfect piece of code that can validate every possible combination imaginable. Some burden falls on the code calling the clk api (especially if that code is platform code) to make sure that it doesn't do stupid things.
We can't expect a normal driver to know that the clk_set_parent() shouldn't be called when the parent is at a particular rate since there are clock HW limitations. The clock framework doesn't need to validate everything, but it should give the clock driver the option of rejecting invalid requests.
Btw, I think this earlier comment from me is wrong.
Nevermind, my brain isn't working today. I can just do that different ordering in ops->set_parent().
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.
Do you have a real use case for this? Due to the way that we match the parent pointer with the cached clk->parents member it would be painful to support NULL parents as valid.
I don't have a real use case for MSM. We just have a ground_clock.
I'm electing to ignore the issue until we have a real use-case for it.
Sounds reasonable.
Thanks, Saravana
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 Kannanskannan@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
On 03/28/2012 10:08 AM, Turquette, Mike wrote:
On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannanskannan@codeaurora.org wrote:
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.
Sorry if I wasn't clear. But the case above is a separate issue from what I mention below. What are your thoughts on handling this? Pass "msg" to recalc_rates?
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.
The case I'm referring to is set_parent(). set_rate() and set_parent() have a lot of common implications and it doesn't look like the clock framework is handling the common cases the same way for both set_parent() and set_rate().
It almost feels like set_parent() and set_rate() should just be wrappers around some common function that handles most of the work. After all, set_parent() is just a slimmed down version of set_rate(). Set rate is just a combination of set parent and set divider.
Anyways I'm looking at ways to do this in my clk-dependencies branch.
Are you also looking into the pre/post rate change divider handling case I mentioned above?
Thanks, Saravana
On Wed, Mar 28, 2012 at 3:25 PM, Saravana Kannan skannan@codeaurora.org wrote:
On 03/28/2012 10:08 AM, Turquette, Mike wrote:
On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannanskannan@codeaurora.org wrote:
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.
Sorry if I wasn't clear. But the case above is a separate issue from what I mention below. What are your thoughts on handling this? Pass "msg" to recalc_rates?
I'm OK passing the msg to in .recalc_rates for your hardware which samples frequency.
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.
We do need a rate validation mechanism, which neither .round_rate or .recalc_rates provide. But I don't want to bolt one on right now because the proper solution to that problem is not a quick fix. Coupled to this issue are lingering topics that we've discussed tentatively in the past:
1) rate ranges (min/max)
2) clock dependencies; these should enforce functional dependencies between clocks
3) intended rates; this strays into the scary arena of policy, which has traditionally fallen outside the purview of the clock framework. But if we want a better clock framework we probably need a way for downstream clocks to make intelligent decisions about their rates when parent rates change. We could overload .round_rate to do this for clk_set_rate, but that doesn't help out clk_set_parent. And I'm against overloading the functionality of these callbacks any more than I already have.
I'm not sure that just overloading .recalc_rates is the best approach. I like that .recalc_rates only recalculates the rate! For clocks that need to make an intelligent decision about their rates when parent rates change we might need to introduce a new callback and/or refactor the clk_set_rate and clk_set_parent paths to use some common code.
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.
The case I'm referring to is set_parent(). set_rate() and set_parent() have a lot of common implications and it doesn't look like the clock framework is handling the common cases the same way for both set_parent() and set_rate().
Agreed that there needs to be some unification here. Certainly a common rate validation mechanism is missing and the downstream notification diverged in the last set of patches.
It almost feels like set_parent() and set_rate() should just be wrappers around some common function that handles most of the work. After all, set_parent() is just a slimmed down version of set_rate(). Set rate is just a combination of set parent and set divider.
I mostly agree. A big caveat is that clk_set_parent will never propagate a request up the tree, but that doesn't mean the implementation details of the two functions are mutually exclusive.
Anyways I'm looking at ways to do this in my clk-dependencies branch.
Are you also looking into the pre/post rate change divider handling case I mentioned above?
I'll admit that my initial focus on clk-deps was more along the lines of:
"Clock A wants to go faster, and has a functional dependency to scale Clock B to a faster rate first"
That sort of situation is often necessary to keep certain timing requirements valid. But your example reinforces that clocks need to have some clue about rate ranges, and it resets my opinion on writing a clk-dep mechanism which is just focused on raising rates. The real solution should be generic and able to handle lowering and NACKing rates also.
In short: for now I'll just pass the msg into .recalc_rates. The other stuff is a design activity which is out-of-scope for the upcoming -rc bugfix windows.
Regards, Mike
On Tue, Mar 20, 2012 at 7:02 AM, Shawn Guo shawn.guo@linaro.org wrote:
On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: ...
+struct clk_ops {
- int (*prepare)(struct clk_hw *hw);
- void (*unprepare)(struct clk_hw *hw);
- int (*enable)(struct clk_hw *hw);
- void (*disable)(struct clk_hw *hw);
- int (*is_enabled)(struct clk_hw *hw);
- unsigned long (*recalc_rate)(struct clk_hw *hw,
- unsigned long parent_rate);
I believe I have heard people love the interface with parent_rate passed in. I love that too. But I would like to ask the same thing on .round_rate and .set_rate as well for the same reason why we have it for .recalc_rate.
This is something that was discussed on the list but not taken in due to rapid flux in code. I always liked the idea however.
- long (*round_rate)(struct clk_hw *hw, unsigned long,
- unsigned long *);
Yes, we already have parent_rate passed in .round_rate with an pointer. But I think it'd be better to have it passed in no matter flag CLK_SET_RATE_PARENT is set or not. Something like:
This places the burden of checking the flags onto the .round_rate implementation with __clk_get_flags, but that's not a problem really.
8<--- @@ -584,7 +584,7 @@ EXPORT_SYMBOL_GPL(clk_get_rate); */ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate) {
- unsigned long unused;
- unsigned long parent_rate = 0;
if (!clk) return -EINVAL; @@ -592,10 +592,10 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate) if (!clk->ops->round_rate) return clk->rate;
- if (clk->flags & CLK_SET_RATE_PARENT)
- return clk->ops->round_rate(clk->hw, rate, &unused);
- else
- return clk->ops->round_rate(clk->hw, rate, NULL);
- if (clk->parent)
- parent_rate = clk->parent->rate;
- return clk->ops->round_rate(clk->hw, rate, &parent_rate);
}
/** @@ -765,9 +765,12 @@ static void clk_calc_subtree(struct clk *clk, unsigned long new_rate) static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) { struct clk *top = clk;
- unsigned long best_parent_rate = clk->parent->rate;
- unsigned long best_parent_rate = 0;
unsigned long new_rate;
- if (clk->parent)
- best_parent_rate = clk->parent->rate;
if (!clk->ops->round_rate && !(clk->flags & CLK_SET_RATE_PARENT)) { clk->new_rate = clk->rate; return NULL; @@ -780,10 +783,7 @@ static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate) goto out; }
- if (clk->flags & CLK_SET_RATE_PARENT)
- new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
- else
- new_rate = clk->ops->round_rate(clk->hw, rate, NULL);
- new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
if (best_parent_rate != clk->parent->rate) { top = clk_calc_new_rates(clk->parent, best_parent_rate);
--->8
ACK
The reason behind the change is that any clk implements .round_rate will mostly need to get the parent rate, no matter flag CLK_SET_RATE_PARENT is set or not. Instead of expecting every .round_rate implementation to get the parent rate in the way beloe
parent_rate = __clk_get_rate(__clk_get_parent(hw->clk));
we can just pass the parent rate into .round_rate.
- int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
- int (*set_rate)(struct clk_hw *hw, unsigned long);
For the same reason, I would change .set_rate interface like below.
8<---
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c index d5ac6a7..6bd8037 100644 --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -119,7 +119,8 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, } EXPORT_SYMBOL_GPL(clk_divider_round_rate);
-static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate) +static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long parent_rate)
{ struct clk_divider *divider = to_clk_divider(hw); unsigned int div; diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index dbc310a..d74ac4b 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -833,17 +833,18 @@ static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long even static void clk_change_rate(struct clk *clk) { struct clk *child;
- unsigned long old_rate;
- unsigned long old_rate, parent_rate = 0;
struct hlist_node *tmp;
old_rate = clk->rate;
- if (clk->parent)
- parent_rate = clk->parent->rate;
if (clk->ops->set_rate)
- clk->ops->set_rate(clk->hw, clk->new_rate);
- clk->ops->set_rate(clk->hw, clk->new_rate, parent_rate);
if (clk->ops->recalc_rate)
- clk->rate = clk->ops->recalc_rate(clk->hw,
- clk->parent->rate);
- clk->rate = clk->ops->recalc_rate(clk->hw, parent_rate);
else clk->rate = clk->parent->rate;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index 5508897..1031f1f 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -125,7 +125,8 @@ struct clk_ops { unsigned long *); int (*set_parent)(struct clk_hw *hw, u8 index); u8 (*get_parent)(struct clk_hw *hw);
- int (*set_rate)(struct clk_hw *hw, unsigned long);
- int (*set_rate)(struct clk_hw *hw, unsigned long,
- unsigned long);
void (*init)(struct clk_hw *hw); };
--->8
ACK
Then with parent rate passed into .round_rate and .set_rate like what we do with .recalc_rate right now, we can save particular clk implementation from calling __clk_get_parent() and __clk_get_rate to get parent rate.
For example, the following will the be diff we gain on clk-divider.
8<---
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c index 6bd8037..8a28ffb 100644 --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -68,8 +68,8 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate, if (divider->flags & CLK_DIVIDER_ONE_BASED) maxdiv--;
- if (!best_parent_rate) {
- parent_rate = __clk_get_rate(__clk_get_parent(hw->clk));
- if (!(divider->flags & CLK_SET_RATE_PARENT)) {
This is wrong. CLK_SET_RATE_PARENT is a common clock flag applied to struct clk's .flags member, not the divider. This function must still use __clk_get_flags(hw->clk) here, but that's OK.
- parent_rate = *best_parent_rate;
bestdiv = DIV_ROUND_UP(parent_rate, rate); bestdiv = bestdiv == 0 ? 1 : bestdiv; bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv; @@ -109,13 +109,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, int div; div = clk_divider_bestdiv(hw, rate, prate);
- if (prate)
- return *prate / div;
- else {
- unsigned long r;
- r = __clk_get_rate(__clk_get_parent(hw->clk));
- return r / div;
- }
- return *prate / div;
} EXPORT_SYMBOL_GPL(clk_divider_round_rate);
@@ -127,7 +121,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long flags = 0; u32 val;
- div = __clk_get_rate(__clk_get_parent(hw->clk)) / rate;
- div = parent_rate / rate;
if (!(divider->flags & CLK_DIVIDER_ONE_BASED)) div--;
--->8
ACK, besides my comment above.
I always get a sense of worry in using functions named in __xxx which sounds like something somehow internal. With the requested interface change above, I can get all __xxx functions out of my clk_ops implementation.
As mentioned above, you'll still need to check for CLK_SET_RATE_PARENT in your .round_rate implementation with __clk_get_flags(hw->clk).
Did you want to send a formal patch or just have me absorb this into the fixes I'm brewing already? I've already fixed the potential null ptr dereferences in clk_calc_new_rates, but that's no big deal.
Regards, Mike
On 21 March 2012 07:46, Turquette, Mike mturquette@ti.com wrote: ...
As mentioned above, you'll still need to check for CLK_SET_RATE_PARENT in your .round_rate implementation with __clk_get_flags(hw->clk).
For my particular case, the clk is PLL with fixed rate clk (oscillator) as parent. It's known that flag CLK_SET_RATE_PARENT will never be set for this type of clks.
Did you want to send a formal patch or just have me absorb this into the fixes I'm brewing already? I've already fixed the potential null ptr dereferences in clk_calc_new_rates, but that's no big deal.
The code was attached for better discussion, and I would leave the formal patch to you.
Regards, Shawn
Many platforms support simple gateable clocks, fixed-rate clocks, adjustable divider clocks and multi-parent multiplexer clocks.
This patch introduces basic clock types for the above-mentioned hardware which share some common characteristics.
Based on original work by Jeremy Kerr and contribution by Jamie Iles. Dividers and multiplexor clocks originally contributed by Richard Zhao & Sascha Hauer.
Signed-off-by: Mike Turquette mturquette@linaro.org Signed-off-by: Mike Turquette mturquette@ti.com Reviewed-by: Andrew Lunn andrew@lunn.ch Tested-by: Andrew Lunn andrew@lunn.ch Reviewed-by: Rob Herring rob.herring@calxeda.com Cc: Russell King linux@arm.linux.org.uk Cc: Jeremy Kerr jeremy.kerr@canonical.com Cc: Thomas Gleixner tglx@linutronix.de Cc: Arnd Bergman arnd.bergmann@linaro.org Cc: Paul Walmsley paul@pwsan.com Cc: Shawn Guo shawn.guo@freescale.com Cc: Sascha Hauer s.hauer@pengutronix.de Cc: Jamie Iles jamie@jamieiles.com Cc: Richard Zhao richard.zhao@linaro.org Cc: Saravana Kannan skannan@codeaurora.org Cc: Magnus Damm magnus.damm@gmail.com Cc: Mark Brown broonie@opensource.wolfsonmicro.com Cc: Linus Walleij linus.walleij@stericsson.com Cc: Stephen Boyd sboyd@codeaurora.org Cc: Amit Kucheria amit.kucheria@linaro.org Cc: Deepak Saxena dsaxena@linaro.org Cc: Grant Likely grant.likely@secretlab.ca --- Changes since v6: * fixed up clk_divider's .round_rate logic (thanks Sascha) * removed useless locking around basic clock types
Changes since v5: * standardized the hw-specific locking in the basic clock types * export the individual ops for each basic clock type * improve registration for single-parent basic clocks (thanks Sascha) * fixed bugs in gate clock's static initializers (thanks Andrew)
drivers/clk/Makefile | 3 +- drivers/clk/clk-divider.c | 200 ++++++++++++++++++++++++++++++++++++++++++ drivers/clk/clk-fixed-rate.c | 82 +++++++++++++++++ drivers/clk/clk-gate.c | 150 +++++++++++++++++++++++++++++++ drivers/clk/clk-mux.c | 116 ++++++++++++++++++++++++ include/linux/clk-private.h | 124 ++++++++++++++++++++++++++ include/linux/clk-provider.h | 127 ++++++++++++++++++++++++++ 7 files changed, 801 insertions(+), 1 deletions(-) create mode 100644 drivers/clk/clk-divider.c create mode 100644 drivers/clk/clk-fixed-rate.c create mode 100644 drivers/clk/clk-gate.c create mode 100644 drivers/clk/clk-mux.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index ff362c4..1f736bc 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -1,3 +1,4 @@
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o -obj-$(CONFIG_COMMON_CLK) += clk.o +obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \ + clk-mux.o clk-divider.o diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c new file mode 100644 index 0000000..d5ac6a7 --- /dev/null +++ b/drivers/clk/clk-divider.c @@ -0,0 +1,200 @@ +/* + * Copyright (C) 2011 Sascha Hauer, Pengutronix s.hauer@pengutronix.de + * Copyright (C) 2011 Richard Zhao, Linaro richard.zhao@linaro.org + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Adjustable divider clock implementation + */ + +#include <linux/clk-provider.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> +#include <linux/string.h> + +/* + * DOC: basic adjustable divider clock that cannot gate + * + * Traits of this clock: + * prepare - clk_prepare only ensures that parents are prepared + * enable - clk_enable only ensures that parents are enabled + * rate - rate is adjustable. clk->rate = parent->rate / divisor + * parent - fixed parent. No clk_set_parent support + */ + +#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw) + +#define div_mask(d) ((1 << (d->width)) - 1) + +static unsigned long clk_divider_recalc_rate(struct clk_hw *hw, + unsigned long parent_rate) +{ + struct clk_divider *divider = to_clk_divider(hw); + unsigned int div; + + div = readl(divider->reg) >> divider->shift; + div &= div_mask(divider); + + if (!(divider->flags & CLK_DIVIDER_ONE_BASED)) + div++; + + return parent_rate / div; +} +EXPORT_SYMBOL_GPL(clk_divider_recalc_rate); + +/* + * The reverse of DIV_ROUND_UP: The maximum number which + * divided by m is r + */ +#define MULT_ROUND_UP(r, m) ((r) * (m) + (m) - 1) + +static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate, + unsigned long *best_parent_rate) +{ + struct clk_divider *divider = to_clk_divider(hw); + int i, bestdiv = 0; + unsigned long parent_rate, best = 0, now, maxdiv; + + if (!rate) + rate = 1; + + maxdiv = (1 << divider->width); + + if (divider->flags & CLK_DIVIDER_ONE_BASED) + maxdiv--; + + if (!best_parent_rate) { + parent_rate = __clk_get_rate(__clk_get_parent(hw->clk)); + bestdiv = DIV_ROUND_UP(parent_rate, rate); + bestdiv = bestdiv == 0 ? 1 : bestdiv; + bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv; + return bestdiv; + } + + /* + * The maximum divider we can use without overflowing + * unsigned long in rate * i below + */ + maxdiv = min(ULONG_MAX / rate, maxdiv); + + for (i = 1; i <= maxdiv; i++) { + parent_rate = __clk_round_rate(__clk_get_parent(hw->clk), + MULT_ROUND_UP(rate, i)); + now = parent_rate / i; + if (now <= rate && now > best) { + bestdiv = i; + best = now; + *best_parent_rate = parent_rate; + } + } + + if (!bestdiv) { + bestdiv = (1 << divider->width); + if (divider->flags & CLK_DIVIDER_ONE_BASED) + bestdiv--; + *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk), 1); + } + + return bestdiv; +} + +static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate, + unsigned long *prate) +{ + int div; + div = clk_divider_bestdiv(hw, rate, prate); + + if (prate) + return *prate / div; + else { + unsigned long r; + r = __clk_get_rate(__clk_get_parent(hw->clk)); + return r / div; + } +} +EXPORT_SYMBOL_GPL(clk_divider_round_rate); + +static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate) +{ + struct clk_divider *divider = to_clk_divider(hw); + unsigned int div; + unsigned long flags = 0; + u32 val; + + div = __clk_get_rate(__clk_get_parent(hw->clk)) / rate; + + if (!(divider->flags & CLK_DIVIDER_ONE_BASED)) + div--; + + if (div > div_mask(divider)) + div = div_mask(divider); + + if (divider->lock) + spin_lock_irqsave(divider->lock, flags); + + val = readl(divider->reg); + val &= ~(div_mask(divider) << divider->shift); + val |= div << divider->shift; + writel(val, divider->reg); + + if (divider->lock) + spin_unlock_irqrestore(divider->lock, flags); + + return 0; +} +EXPORT_SYMBOL_GPL(clk_divider_set_rate); + +struct clk_ops clk_divider_ops = { + .recalc_rate = clk_divider_recalc_rate, + .round_rate = clk_divider_round_rate, + .set_rate = clk_divider_set_rate, +}; +EXPORT_SYMBOL_GPL(clk_divider_ops); + +struct clk *clk_register_divider(struct device *dev, const char *name, + const char *parent_name, unsigned long flags, + void __iomem *reg, u8 shift, u8 width, + u8 clk_divider_flags, spinlock_t *lock) +{ + struct clk_divider *div; + struct clk *clk; + + div = kzalloc(sizeof(struct clk_divider), GFP_KERNEL); + + if (!div) { + pr_err("%s: could not allocate divider clk\n", __func__); + return NULL; + } + + /* struct clk_divider assignments */ + div->reg = reg; + div->shift = shift; + div->width = width; + div->flags = clk_divider_flags; + div->lock = lock; + + if (parent_name) { + div->parent[0] = kstrdup(parent_name, GFP_KERNEL); + if (!div->parent[0]) + goto out; + } + + clk = clk_register(dev, name, + &clk_divider_ops, &div->hw, + div->parent, + (parent_name ? 1 : 0), + flags); + if (clk) + return clk; + +out: + kfree(div->parent[0]); + kfree(div); + + return NULL; +} diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c new file mode 100644 index 0000000..90c79fb --- /dev/null +++ b/drivers/clk/clk-fixed-rate.c @@ -0,0 +1,82 @@ +/* + * Copyright (C) 2010-2011 Canonical Ltd jeremy.kerr@canonical.com + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Fixed rate clock implementation + */ + +#include <linux/clk-provider.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> + +/* + * DOC: basic fixed-rate clock that cannot gate + * + * Traits of this clock: + * prepare - clk_(un)prepare only ensures parents are prepared + * enable - clk_enable only ensures parents are enabled + * rate - rate is always a fixed value. No clk_set_rate support + * parent - fixed parent. No clk_set_parent support + */ + +#define to_clk_fixed_rate(_hw) container_of(_hw, struct clk_fixed_rate, hw) + +static unsigned long clk_fixed_rate_recalc_rate(struct clk_hw *hw, + unsigned long parent_rate) +{ + return to_clk_fixed_rate(hw)->fixed_rate; +} +EXPORT_SYMBOL_GPL(clk_fixed_rate_recalc_rate); + +struct clk_ops clk_fixed_rate_ops = { + .recalc_rate = clk_fixed_rate_recalc_rate, +}; +EXPORT_SYMBOL_GPL(clk_fixed_rate_ops); + +struct clk *clk_register_fixed_rate(struct device *dev, const char *name, + const char *parent_name, unsigned long flags, + unsigned long fixed_rate) +{ + struct clk_fixed_rate *fixed; + char **parent_names = NULL; + u8 len; + + fixed = kzalloc(sizeof(struct clk_fixed_rate), GFP_KERNEL); + + if (!fixed) { + pr_err("%s: could not allocate fixed clk\n", __func__); + return ERR_PTR(-ENOMEM); + } + + /* struct clk_fixed_rate assignments */ + fixed->fixed_rate = fixed_rate; + + if (parent_name) { + parent_names = kmalloc(sizeof(char *), GFP_KERNEL); + + if (! parent_names) + goto out; + + len = sizeof(char) * strlen(parent_name); + + parent_names[0] = kmalloc(len, GFP_KERNEL); + + if (!parent_names[0]) + goto out; + + strncpy(parent_names[0], parent_name, len); + } + +out: + return clk_register(dev, name, + &clk_fixed_rate_ops, &fixed->hw, + parent_names, + (parent_name ? 1 : 0), + flags); +} diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c new file mode 100644 index 0000000..b5902e2 --- /dev/null +++ b/drivers/clk/clk-gate.c @@ -0,0 +1,150 @@ +/* + * Copyright (C) 2010-2011 Canonical Ltd jeremy.kerr@canonical.com + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Gated clock implementation + */ + +#include <linux/clk-provider.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> +#include <linux/string.h> + +/** + * DOC: basic gatable clock which can gate and ungate it's ouput + * + * Traits of this clock: + * prepare - clk_(un)prepare only ensures parent is (un)prepared + * enable - clk_enable and clk_disable are functional & control gating + * rate - inherits rate from parent. No clk_set_rate support + * parent - fixed parent. No clk_set_parent support + */ + +#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw) + +static void clk_gate_set_bit(struct clk_gate *gate) +{ + u32 reg; + unsigned long flags = 0; + + if (gate->lock) + spin_lock_irqsave(gate->lock, flags); + + reg = readl(gate->reg); + reg |= BIT(gate->bit_idx); + writel(reg, gate->reg); + + if (gate->lock) + spin_unlock_irqrestore(gate->lock, flags); +} + +static void clk_gate_clear_bit(struct clk_gate *gate) +{ + u32 reg; + unsigned long flags = 0; + + if (gate->lock) + spin_lock_irqsave(gate->lock, flags); + + reg = readl(gate->reg); + reg &= ~BIT(gate->bit_idx); + writel(reg, gate->reg); + + if (gate->lock) + spin_unlock_irqrestore(gate->lock, flags); +} + +static int clk_gate_enable(struct clk_hw *hw) +{ + struct clk_gate *gate = to_clk_gate(hw); + + if (gate->flags & CLK_GATE_SET_TO_DISABLE) + clk_gate_clear_bit(gate); + else + clk_gate_set_bit(gate); + + return 0; +} +EXPORT_SYMBOL_GPL(clk_gate_enable); + +static void clk_gate_disable(struct clk_hw *hw) +{ + struct clk_gate *gate = to_clk_gate(hw); + + if (gate->flags & CLK_GATE_SET_TO_DISABLE) + clk_gate_set_bit(gate); + else + clk_gate_clear_bit(gate); +} +EXPORT_SYMBOL_GPL(clk_gate_disable); + +static int clk_gate_is_enabled(struct clk_hw *hw) +{ + u32 reg; + struct clk_gate *gate = to_clk_gate(hw); + + reg = readl(gate->reg); + + /* if a set bit disables this clk, flip it before masking */ + if (gate->flags & CLK_GATE_SET_TO_DISABLE) + reg ^= BIT(gate->bit_idx); + + reg &= BIT(gate->bit_idx); + + return reg ? 1 : 0; +} +EXPORT_SYMBOL_GPL(clk_gate_is_enabled); + +struct clk_ops clk_gate_ops = { + .enable = clk_gate_enable, + .disable = clk_gate_disable, + .is_enabled = clk_gate_is_enabled, +}; +EXPORT_SYMBOL_GPL(clk_gate_ops); + +struct clk *clk_register_gate(struct device *dev, const char *name, + const char *parent_name, unsigned long flags, + void __iomem *reg, u8 bit_idx, + u8 clk_gate_flags, spinlock_t *lock) +{ + struct clk_gate *gate; + struct clk *clk; + + gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL); + + if (!gate) { + pr_err("%s: could not allocate gated clk\n", __func__); + return NULL; + } + + /* struct clk_gate assignments */ + gate->reg = reg; + gate->bit_idx = bit_idx; + gate->flags = clk_gate_flags; + gate->lock = lock; + + if (parent_name) { + gate->parent[0] = kstrdup(parent_name, GFP_KERNEL); + if (!gate->parent[0]) + goto out; + } + + clk = clk_register(dev, name, + &clk_gate_ops, &gate->hw, + gate->parent, + (parent_name ? 1 : 0), + flags); + if (clk) + return clk; +out: + kfree(gate->parent[0]); + kfree(gate); + + return NULL; +} diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c new file mode 100644 index 0000000..c71ad1f --- /dev/null +++ b/drivers/clk/clk-mux.c @@ -0,0 +1,116 @@ +/* + * Copyright (C) 2011 Sascha Hauer, Pengutronix s.hauer@pengutronix.de + * Copyright (C) 2011 Richard Zhao, Linaro richard.zhao@linaro.org + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturquette@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Simple multiplexer clock implementation + */ + +#include <linux/clk.h> +#include <linux/clk-provider.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/io.h> +#include <linux/err.h> + +/* + * DOC: basic adjustable multiplexer clock that cannot gate + * + * Traits of this clock: + * prepare - clk_prepare only ensures that parents are prepared + * enable - clk_enable only ensures that parents are enabled + * rate - rate is only affected by parent switching. No clk_set_rate support + * parent - parent is adjustable through clk_set_parent + */ + +#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw) + +static u8 clk_mux_get_parent(struct clk_hw *hw) +{ + struct clk_mux *mux = to_clk_mux(hw); + u32 val; + + /* + * FIXME need a mux-specific flag to determine if val is bitwise or numeric + * e.g. sys_clkin_ck's clksel field is 3 bits wide, but ranges from 0x1 + * to 0x7 (index starts at one) + * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so + * val = 0x4 really means "bit 2, index starts at bit 0" + */ + val = readl(mux->reg) >> mux->shift; + val &= (1 << mux->width) - 1; + + if (val && (mux->flags & CLK_MUX_INDEX_BIT)) + val = ffs(val) - 1; + + if (val && (mux->flags & CLK_MUX_INDEX_ONE)) + val--; + + if (val >= __clk_get_num_parents(hw->clk)) + return -EINVAL; + + return val; +} +EXPORT_SYMBOL_GPL(clk_mux_get_parent); + +static int clk_mux_set_parent(struct clk_hw *hw, u8 index) +{ + struct clk_mux *mux = to_clk_mux(hw); + u32 val; + unsigned long flags = 0; + + if (mux->flags & CLK_MUX_INDEX_BIT) + index = (1 << ffs(index)); + + if (mux->flags & CLK_MUX_INDEX_ONE) + index++; + + if (mux->lock) + spin_lock_irqsave(mux->lock, flags); + + val = readl(mux->reg); + val &= ~(((1 << mux->width) - 1) << mux->shift); + val |= index << mux->shift; + writel(val, mux->reg); + + if (mux->lock) + spin_unlock_irqrestore(mux->lock, flags); + + return 0; +} +EXPORT_SYMBOL_GPL(clk_mux_set_parent); + +struct clk_ops clk_mux_ops = { + .get_parent = clk_mux_get_parent, + .set_parent = clk_mux_set_parent, +}; +EXPORT_SYMBOL_GPL(clk_mux_ops); + +struct clk *clk_register_mux(struct device *dev, const char *name, + char **parent_names, u8 num_parents, unsigned long flags, + void __iomem *reg, u8 shift, u8 width, + u8 clk_mux_flags, spinlock_t *lock) +{ + struct clk_mux *mux; + + mux = kmalloc(sizeof(struct clk_mux), GFP_KERNEL); + + if (!mux) { + pr_err("%s: could not allocate mux clk\n", __func__); + return ERR_PTR(-ENOMEM); + } + + /* struct clk_mux assignments */ + mux->reg = reg; + mux->shift = shift; + mux->width = width; + mux->flags = clk_mux_flags; + mux->lock = lock; + + return clk_register(dev, name, &clk_mux_ops, &mux->hw, + parent_names, num_parents, flags); +} diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h index e2cce6f..5e4312b 100644 --- a/include/linux/clk-private.h +++ b/include/linux/clk-private.h @@ -46,6 +46,130 @@ struct clk { #endif };
+/* + * DOC: Basic clock implementations common to many platforms + * + * Each basic clock hardware type is comprised of a structure describing the + * clock hardware, implementations of the relevant callbacks in struct clk_ops, + * unique flags for that hardware type, a registration function and an + * alternative macro for static initialization + */ + +extern struct clk_ops clk_fixed_rate_ops; + +#define DEFINE_CLK_FIXED_RATE(_name, _flags, _rate, \ + _fixed_rate_flags) \ + static struct clk _name; \ + static char *_name##_parent_names[] = {}; \ + static struct clk_fixed_rate _name##_hw = { \ + .hw = { \ + .clk = &_name, \ + }, \ + .fixed_rate = _rate, \ + .flags = _fixed_rate_flags, \ + }; \ + static struct clk _name = { \ + .name = #_name, \ + .ops = &clk_fixed_rate_ops, \ + .hw = &_name##_hw.hw, \ + .parent_names = _name##_parent_names, \ + .num_parents = \ + ARRAY_SIZE(_name##_parent_names), \ + .flags = _flags, \ + }; + +extern struct clk_ops clk_gate_ops; + +#define DEFINE_CLK_GATE(_name, _parent_name, _parent_ptr, \ + _flags, _reg, _bit_idx, \ + _gate_flags, _lock) \ + static struct clk _name; \ + static char *_name##_parent_names[] = { \ + _parent_name, \ + }; \ + static struct clk *_name##_parents[] = { \ + _parent_ptr, \ + }; \ + static struct clk_gate _name##_hw = { \ + .hw = { \ + .clk = &_name, \ + }, \ + .reg = _reg, \ + .bit_idx = _bit_idx, \ + .flags = _gate_flags, \ + .lock = _lock, \ + }; \ + static struct clk _name = { \ + .name = #_name, \ + .ops = &clk_gate_ops, \ + .hw = &_name##_hw.hw, \ + .parent_names = _name##_parent_names, \ + .num_parents = \ + ARRAY_SIZE(_name##_parent_names), \ + .parents = _name##_parents, \ + .flags = _flags, \ + }; + +extern struct clk_ops clk_divider_ops; + +#define DEFINE_CLK_DIVIDER(_name, _parent_name, _parent_ptr, \ + _flags, _reg, _shift, _width, \ + _divider_flags, _lock) \ + static struct clk _name; \ + static char *_name##_parent_names[] = { \ + _parent_name, \ + }; \ + static struct clk *_name##_parents[] = { \ + _parent_ptr, \ + }; \ + static struct clk_divider _name##_hw = { \ + .hw = { \ + .clk = &_name, \ + }, \ + .reg = _reg, \ + .shift = _shift, \ + .width = _width, \ + .flags = _divider_flags, \ + .lock = _lock, \ + }; \ + static struct clk _name = { \ + .name = #_name, \ + .ops = &clk_divider_ops, \ + .hw = &_name##_hw.hw, \ + .parent_names = _name##_parent_names, \ + .num_parents = \ + ARRAY_SIZE(_name##_parent_names), \ + .parents = _name##_parents, \ + .flags = _flags, \ + }; + +extern struct clk_ops clk_mux_ops; + +#define DEFINE_CLK_MUX(_name, _parent_names, _parents, _flags, \ + _reg, _shift, _width, \ + _mux_flags, _lock) \ + static struct clk _name; \ + static struct clk_mux _name##_hw = { \ + .hw = { \ + .clk = &_name, \ + }, \ + .reg = _reg, \ + .shift = _shift, \ + .width = _width, \ + .flags = _mux_flags, \ + .lock = _lock, \ + }; \ + static struct clk _name = { \ + .name = #_name, \ + .ops = &clk_mux_ops, \ + .hw = &_name##_hw.hw, \ + .parent_names = _parent_names, \ + .num_parents = \ + ARRAY_SIZE(_parent_names), \ + .parents = _parents, \ + .flags = _flags, \ + }; + /** * __clk_init - initialize the data structures in a struct clk * @dev: device initializing this clk, placeholder for now diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index b18b0e7..5508897 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -129,6 +129,133 @@ struct clk_ops { void (*init)(struct clk_hw *hw); };
+/* + * DOC: Basic clock implementations common to many platforms + * + * Each basic clock hardware type is comprised of a structure describing the + * clock hardware, implementations of the relevant callbacks in struct clk_ops, + * unique flags for that hardware type, a registration function and an + * alternative macro for static initialization + */ + +/** + * struct clk_fixed_rate - fixed-rate clock + * @hw: handle between common and hardware-specific interfaces + * @fixed_rate: constant frequency of clock + */ +struct clk_fixed_rate { + struct clk_hw hw; + unsigned long fixed_rate; + u8 flags; +}; + +struct clk *clk_register_fixed_rate(struct device *dev, const char *name, + const char *parent_name, unsigned long flags, + unsigned long fixed_rate); + +/** + * struct clk_gate - gating clock + * + * @hw: handle between common and hardware-specific interfaces + * @reg: register controlling gate + * @bit_idx: single bit controlling gate + * @flags: hardware-specific flags + * @lock: register lock + * + * Clock which can gate its output. Implements .enable & .disable + * + * Flags: + * CLK_GATE_SET_DISABLE - by default this clock sets the bit at bit_idx to + * enable the clock. Setting this flag does the opposite: setting the bit + * disable the clock and clearing it enables the clock + */ +struct clk_gate { + struct clk_hw hw; + void __iomem *reg; + u8 bit_idx; + u8 flags; + spinlock_t *lock; + char *parent[1]; +}; + +#define CLK_GATE_SET_TO_DISABLE BIT(0) + +struct clk *clk_register_gate(struct device *dev, const char *name, + const char *parent_name, unsigned long flags, + void __iomem *reg, u8 bit_idx, + u8 clk_gate_flags, spinlock_t *lock); + +/** + * struct clk_divider - adjustable divider clock + * + * @hw: handle between common and hardware-specific interfaces + * @reg: register containing the divider + * @shift: shift to the divider bit field + * @width: width of the divider bit field + * @lock: register lock + * + * Clock with an adjustable divider affecting its output frequency. Implements + * .recalc_rate, .set_rate and .round_rate + * + * Flags: + * CLK_DIVIDER_ONE_BASED - by default the divisor is the value read from the + * register plus one. If CLK_DIVIDER_ONE_BASED is set then the divider is + * the raw value read from the register, with the value of zero considered + * invalid + * CLK_DIVIDER_POWER_OF_TWO - clock divisor is 2 raised to the value read from + * the hardware register + */ +struct clk_divider { + struct clk_hw hw; + void __iomem *reg; + u8 shift; + u8 width; + u8 flags; + spinlock_t *lock; + char *parent[1]; +}; + +#define CLK_DIVIDER_ONE_BASED BIT(0) +#define CLK_DIVIDER_POWER_OF_TWO BIT(1) + +struct clk *clk_register_divider(struct device *dev, const char *name, + const char *parent_name, unsigned long flags, + void __iomem *reg, u8 shift, u8 width, + u8 clk_divider_flags, spinlock_t *lock); + +/** + * struct clk_mux - multiplexer clock + * + * @hw: handle between common and hardware-specific interfaces + * @reg: register controlling multiplexer + * @shift: shift to multiplexer bit field + * @width: width of mutliplexer bit field + * @num_clks: number of parent clocks + * @lock: register lock + * + * Clock with multiple selectable parents. Implements .get_parent, .set_parent + * and .recalc_rate + * + * Flags: + * CLK_MUX_INDEX_ONE - register index starts at 1, not 0 + * CLK_MUX_INDEX_BITWISE - register index is a single bit (power of two) + */ +struct clk_mux { + struct clk_hw hw; + void __iomem *reg; + u8 shift; + u8 width; + u8 flags; + spinlock_t *lock; +}; + +#define CLK_MUX_INDEX_ONE BIT(0) +#define CLK_MUX_INDEX_BIT BIT(1) + +struct clk *clk_register_mux(struct device *dev, const char *name, + char **parent_names, u8 num_parents, unsigned long flags, + void __iomem *reg, u8 shift, u8 width, + u8 clk_mux_flags, spinlock_t *lock);
/** * clk_register - allocate a new clock, register it and return an opaque cookie
[...]
+static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)+{
- struct clk_divider *divider = to_clk_divider(hw);
- int i, bestdiv = 0;
- unsigned long parent_rate, best = 0, now, maxdiv;
- if (!rate)
rate = 1;- maxdiv = (1 << divider->width);
- if (divider->flags & CLK_DIVIDER_ONE_BASED)
maxdiv--;- if (!best_parent_rate) {
parent_rate = __clk_get_rate(__clk_get_parent(hw->clk));bestdiv = DIV_ROUND_UP(parent_rate, rate);bestdiv = bestdiv == 0 ? 1 : bestdiv;bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;return bestdiv;- }
- /*
* The maximum divider we can use without overflowing* unsigned long in rate * i below*/- maxdiv = min(ULONG_MAX / rate, maxdiv);
- for (i = 1; i <= maxdiv; i++) {
parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),MULT_ROUND_UP(rate, i));now = parent_rate / i;if (now <= rate && now > best) {bestdiv = i;best = now;*best_parent_rate = parent_rate;
Better add if (now == rate) break; There may be more than one hit for (now == rate). We'd better select smallest div, thus smallest parent_rate.
It's the same comment for v6, but not show stopper.
Thanks Richard
}- }
- if (!bestdiv) {
bestdiv = (1 << divider->width);if (divider->flags & CLK_DIVIDER_ONE_BASED)bestdiv--;*best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk), 1);- }
- return bestdiv;
+}
On Fri, Mar 16, 2012 at 5:25 AM, Richard Zhao richard.zhao@linaro.org wrote:
[...]
+static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
- unsigned long *best_parent_rate)
+{
- struct clk_divider *divider = to_clk_divider(hw);
- int i, bestdiv = 0;
- unsigned long parent_rate, best = 0, now, maxdiv;
- if (!rate)
- rate = 1;
- maxdiv = (1 << divider->width);
- if (divider->flags & CLK_DIVIDER_ONE_BASED)
- maxdiv--;
- if (!best_parent_rate) {
- parent_rate = __clk_get_rate(__clk_get_parent(hw->clk));
- bestdiv = DIV_ROUND_UP(parent_rate, rate);
- bestdiv = bestdiv == 0 ? 1 : bestdiv;
- bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
- return bestdiv;
- }
- /*
- * The maximum divider we can use without overflowing
- * unsigned long in rate * i below
- */
- maxdiv = min(ULONG_MAX / rate, maxdiv);
- for (i = 1; i <= maxdiv; i++) {
- parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
- MULT_ROUND_UP(rate, i));
- now = parent_rate / i;
- if (now <= rate && now > best) {
- bestdiv = i;
- best = now;
- *best_parent_rate = parent_rate;
Better add if (now == rate) break; There may be more than one hit for (now == rate). We'd better select smallest div, thus smallest parent_rate.
Hmm I forgot to take this in. Notice that the conditional above has changed:
if (now <= rate && now > best) {
So the smallest divider _will_ be selected, but adding in your check for now == rate is nice since it will prevent unnecessary looping if we've managed to hit the exact rate that we want. I'll ninja this one into the merge request.
Thanks, Mike
It's the same comment for v6, but not show stopper.
Thanks Richard
- }
- }
- if (!bestdiv) {
- bestdiv = (1 << divider->width);
- if (divider->flags & CLK_DIVIDER_ONE_BASED)
- bestdiv--;
- *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk), 1);
- }
- return bestdiv;
+}
On Thu, Mar 15, 2012 at 11:11:17PM -0700, Mike Turquette wrote:
The common clock framework defines a common struct clk as well as an implementation of the clk api that unifies clock operations on various platforms and devices.
The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations.
This series is the feature freeze for the common clock framework. Unless any major bugs are reported this should be the final version of this patchset. Now is the time to add any acked-by's, reviewed-by's or tested-by's. I've carried over the *-by's from v6; I hope everyone is OK with that.
Nice work, thanks again Mike. I gave it a test on various i.MX SoCs and I can give you my:
Tested-by: Sascha Hauer s.hauer@pengutronix.de Acked-by: Sascha Hauer s.hauer@pengutronix.de
Sascha
-
Amit Kucheria -
Arnd Bergmann -
Arnd Bergmann -
Linus Walleij -
Mark Brown -
Mike Turquette -
Nicolas Pitre -
Paul Walmsley -
Rajendra Nayak -
Richard Zhao -
Rob Herring -
Russell King - ARM Linux -
Saravana Kannan -
Sascha Hauer -
Shawn Guo -
Thomas Gleixner -
Tony Lindgren -
Turquette, Mike