* [PATCH v7 0/3] common clk framework
@ 2012-03-16 6:11 ` Mike Turquette
0 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: Russell King
Cc: linux-kernel, linux-arm-kernel, linaro-dev, patches, Mike Turquette
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
--
1.7.5.4
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 0/3] common clk framework
@ 2012-03-16 6:11 ` Mike Turquette
0 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: linux-arm-kernel
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
--
1.7.5.4
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-16 6:11 ` Mike Turquette
-1 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: Russell King
Cc: linux-kernel, linux-arm-kernel, linaro-dev, patches,
Mike Turquette, Mike Turquette, Jeremy Kerr, Thomas Gleixner,
Arnd Bergman, Paul Walmsley, Shawn Guo, Sascha Hauer,
Richard Zhao, Saravana Kannan, Magnus Damm, Rob Herring,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Grant Likely
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.
--
1.7.5.4
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 6:11 ` Mike Turquette
0 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
1.7.5.4
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-16 6:11 ` Mike Turquette
-1 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: Russell King
Cc: linux-kernel, linux-arm-kernel, linaro-dev, patches,
Mike Turquette, Mike Turquette, Jeremy Kerr, Arnd Bergman,
Paul Walmsley, Shawn Guo, Sascha Hauer, Richard Zhao,
Saravana Kannan, Magnus Damm, Mark Brown, Linus Walleij,
Stephen Boyd, Amit Kucheria, Deepak Saxena, Grant Likely
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.
--
1.7.5.4
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-16 6:11 ` Mike Turquette
0 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
1.7.5.4
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 3/3] clk: basic clock hardware types
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-16 6:11 ` Mike Turquette
-1 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: Russell King
Cc: linux-kernel, linux-arm-kernel, linaro-dev, patches,
Mike Turquette, Mike Turquette, Jeremy Kerr, Thomas Gleixner,
Arnd Bergman, Paul Walmsley, Shawn Guo, Sascha Hauer, Jamie Iles,
Richard Zhao, Saravana Kannan, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
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
--
1.7.5.4
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 3/3] clk: basic clock hardware types
@ 2012-03-16 6:11 ` Mike Turquette
0 siblings, 0 replies; 242+ messages in thread
From: Mike Turquette @ 2012-03-16 6:11 UTC (permalink / raw)
To: linux-arm-kernel
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
--
1.7.5.4
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-16 8:25 ` Linus Walleij
-1 siblings, 0 replies; 242+ messages in thread
From: Linus Walleij @ 2012-03-16 8:25 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, linux-kernel, linux-arm-kernel, linaro-dev,
patches, Mike Turquette, Jeremy Kerr, Thomas Gleixner,
Arnd Bergman, Paul Walmsley, Shawn Guo, Sascha Hauer,
Richard Zhao, Saravana Kannan, Magnus Damm, Rob Herring,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Grant Likely
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 8:25 ` Linus Walleij
0 siblings, 0 replies; 242+ messages in thread
From: Linus Walleij @ 2012-03-16 8:25 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 8:25 ` Linus Walleij
@ 2012-03-16 10:29 ` Thomas Gleixner
-1 siblings, 0 replies; 242+ messages in thread
From: Thomas Gleixner @ 2012-03-16 10:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Mike Turquette, Russell King, linux-kernel, linux-arm-kernel,
linaro-dev, patches, Mike Turquette, Jeremy Kerr, Arnd Bergman,
Paul Walmsley, Shawn Guo, Sascha Hauer, Richard Zhao,
Saravana Kannan, Magnus Damm, Rob Herring, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
[-- Attachment #1: Type: TEXT/PLAIN, Size: 637 bytes --]
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 10:29 ` Thomas Gleixner
0 siblings, 0 replies; 242+ messages in thread
From: Thomas Gleixner @ 2012-03-16 10:29 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 0/3] common clk framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-16 10:57 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-16 10:57 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, linaro-dev, linux-kernel, linux-arm-kernel, patches
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 0/3] common clk framework
@ 2012-03-16 10:57 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-16 10:57 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 10:29 ` Thomas Gleixner
@ 2012-03-16 11:14 ` Amit Kucheria
-1 siblings, 0 replies; 242+ messages in thread
From: Amit Kucheria @ 2012-03-16 11:14 UTC (permalink / raw)
To: Thomas Gleixner, Russell King, Arnd Bergman, Mike Turquette
Cc: Linus Walleij, linux-kernel, linux-arm-kernel, linaro-dev,
patches, Mike Turquette, Jeremy Kerr, Paul Walmsley, Shawn Guo,
Sascha Hauer, Richard Zhao, Saravana Kannan, Magnus Damm,
Rob Herring, Mark Brown, Linus Walleij, Stephen Boyd,
Deepak Saxena, Grant Likely, Nicolas Pitre
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 11:14 ` Amit Kucheria
0 siblings, 0 replies; 242+ messages in thread
From: Amit Kucheria @ 2012-03-16 11:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 11:14 ` Amit Kucheria
@ 2012-03-16 12:18 ` Arnd Bergmann
-1 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-16 12:18 UTC (permalink / raw)
To: Amit Kucheria
Cc: Thomas Gleixner, Russell King, Mike Turquette, Linus Walleij,
linux-kernel, linux-arm-kernel, linaro-dev, patches,
Mike Turquette, Jeremy Kerr, Paul Walmsley, Shawn Guo,
Sascha Hauer, Richard Zhao, Saravana Kannan, Magnus Damm,
Rob Herring, Mark Brown, Linus Walleij, Stephen Boyd,
Deepak Saxena, Grant Likely, Nicolas Pitre
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 12:18 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-16 12:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 3/3] clk: basic clock hardware types
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-16 12:25 ` Richard Zhao
-1 siblings, 0 replies; 242+ messages in thread
From: Richard Zhao @ 2012-03-16 12:25 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, linux-kernel, linux-arm-kernel, linaro-dev,
patches, Mike Turquette, Jeremy Kerr, Thomas Gleixner,
Arnd Bergman, Paul Walmsley, Shawn Guo, Sascha Hauer, Jamie Iles,
Saravana Kannan, Magnus Damm, Mark Brown, Linus Walleij,
Stephen Boyd, Amit Kucheria, Deepak Saxena, Grant Likely
[...]
> +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;
> +}
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 3/3] clk: basic clock hardware types
@ 2012-03-16 12:25 ` Richard Zhao
0 siblings, 0 replies; 242+ messages in thread
From: Richard Zhao @ 2012-03-16 12:25 UTC (permalink / raw)
To: linux-arm-kernel
[...]
> +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;
> +}
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 3/3] clk: basic clock hardware types
2012-03-16 12:25 ` Richard Zhao
@ 2012-03-16 16:51 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-16 16:51 UTC (permalink / raw)
To: Richard Zhao
Cc: Russell King, linux-kernel, linux-arm-kernel, linaro-dev,
patches, Jeremy Kerr, Thomas Gleixner, Arnd Bergman,
Paul Walmsley, Shawn Guo, Sascha Hauer, Jamie Iles,
Saravana Kannan, Magnus Damm, Mark Brown, Linus Walleij,
Stephen Boyd, Amit Kucheria, Deepak Saxena, Grant Likely
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;
>> +}
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 3/3] clk: basic clock hardware types
@ 2012-03-16 16:51 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-16 16:51 UTC (permalink / raw)
To: linux-arm-kernel
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;
>> +}
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 12:18 ` Arnd Bergmann
@ 2012-03-16 20:57 ` Arnd Bergmann
-1 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-16 20:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Amit Kucheria, Nicolas Pitre, linaro-dev, Linus Walleij,
Grant Likely, Saravana Kannan, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches,
Sascha Hauer, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 20:57 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-16 20:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 20:57 ` Arnd Bergmann
@ 2012-03-16 21:40 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-16 21:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Amit Kucheria, Nicolas Pitre, linaro-dev,
Linus Walleij, Grant Likely, Saravana Kannan, Jeremy Kerr,
Magnus Damm, Deepak Saxena, patches, Sascha Hauer, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 21:40 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-16 21:40 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 20:57 ` Arnd Bergmann
@ 2012-03-16 21:50 ` Nicolas Pitre
-1 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-16 21:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Amit Kucheria, linaro-dev, Linus Walleij,
Grant Likely, Saravana Kannan, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches,
Sascha Hauer, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
> FWIW, it's in arm-soc now, and it's the last thing I put in there
> for v3.4.
Amen!
Nicolas
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 21:50 ` Nicolas Pitre
0 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-16 21:50 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
> FWIW, it's in arm-soc now, and it's the last thing I put in there
> for v3.4.
Amen!
Nicolas
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 20:57 ` Arnd Bergmann
(?)
@ 2012-03-16 22:21 ` Paul Walmsley
-1 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-16 22:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Amit Kucheria, Nicolas Pitre, linaro-dev,
Linus Walleij, Grant Likely, Saravana Kannan, Jeremy Kerr,
Mike Turquette, Mike Turquette, Magnus Damm, Deepak Saxena,
patches, Sascha Hauer, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 22:21 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-16 22:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Amit Kucheria, Nicolas Pitre, linaro-dev,
Linus Walleij, Grant Likely, Saravana Kannan, Jeremy Kerr,
Mike Turquette, Mike Turquette, Magnus Damm, Deepak Saxena,
patches, Sascha Hauer, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 22:21 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-16 22:21 UTC (permalink / raw)
To: linux-arm-kernel
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 22:21 ` Paul Walmsley
@ 2012-03-16 22:33 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-16 22:33 UTC (permalink / raw)
To: Paul Walmsley
Cc: Arnd Bergmann, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 22:33 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-16 22:33 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 23:47 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-16 23:47 UTC (permalink / raw)
To: Paul Walmsley
Cc: Arnd Bergmann, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 23:47 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-16 23:47 UTC (permalink / raw)
To: Paul Walmsley
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Thomas Gleixner,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Mark Brown,
Stephen Boyd, linux-kernel-u79uwXL29TY76Z2rM5mHXA
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-16 23:47 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-16 23:47 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 0:54 ` Rob Herring
0 siblings, 0 replies; 242+ messages in thread
From: Rob Herring @ 2012-03-17 0:54 UTC (permalink / raw)
To: Sascha Hauer
Cc: Paul Walmsley, Nicolas Pitre, linaro-dev, Saravana Kannan,
Jeremy Kerr, Russell King, Magnus Damm, linux-arm-kernel,
Arnd Bergmann, patches, Rob Herring, Thomas Gleixner, linux-omap,
Linus Walleij, Mark Brown, Stephen Boyd, linux-kernel
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
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 0:54 ` Rob Herring
0 siblings, 0 replies; 242+ messages in thread
From: Rob Herring @ 2012-03-17 0:54 UTC (permalink / raw)
To: Sascha Hauer
Cc: Nicolas Pitre, Paul Walmsley, Russell King, Linus Walleij,
Arnd Bergmann, patches-QSEj5FYQhm4dnm+yROfE0A, Stephen Boyd,
Mark Brown, Magnus Damm, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Saravana Kannan, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Jeremy Kerr, linux-omap-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 0:54 ` Rob Herring
0 siblings, 0 replies; 242+ messages in thread
From: Rob Herring @ 2012-03-17 0:54 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-17 3:28 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-17 3:28 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Shawn Guo, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel, Mike Turquette
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 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>
> ---
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-17 3:28 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-17 3:28 UTC (permalink / raw)
To: linux-arm-kernel
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 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>
> ---
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-17 0:54 ` Rob Herring
(?)
@ 2012-03-17 3:38 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-17 3:38 UTC (permalink / raw)
To: Rob Herring
Cc: Sascha Hauer, Nicolas Pitre, Paul Walmsley, Russell King,
Linus Walleij, Arnd Bergmann, patches, Stephen Boyd, Mark Brown,
Magnus Damm, linux-kernel, Rob Herring, linaro-dev, Jeremy Kerr,
linux-omap, Thomas Gleixner, linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 3:38 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-17 3:38 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Pitre, Paul Walmsley, Russell King, Linus Walleij,
Arnd Bergmann, patches, Magnus Damm, Sascha Hauer, Mark Brown,
Stephen Boyd, linux-kernel, Rob Herring, linaro-dev, Jeremy Kerr,
linux-omap, Thomas Gleixner, linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 3:38 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-17 3:38 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 9:05 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 9:05 UTC (permalink / raw)
To: Turquette, Mike
Cc: Paul Walmsley, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 9:05 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 9:05 UTC (permalink / raw)
To: Turquette, Mike
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Friday 16 March 2012, Turquette, Mike wrote:
> On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote:
> > From: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> > 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-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> > Cc: Mike Turquette <mturquette-l0cyMroinI0@public.gmane.org>
>
> 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
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 9:05 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 9:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-17 9:05 ` Arnd Bergmann
(?)
@ 2012-03-17 18:02 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-17 18:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Walmsley, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 18:02 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-17 18:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Walmsley, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 18:02 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-17 18:02 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 18:33 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 18:33 UTC (permalink / raw)
To: Turquette, Mike
Cc: Paul Walmsley, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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 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.
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 18:33 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 18:33 UTC (permalink / raw)
To: Turquette, Mike
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
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 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.
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 18:33 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 18:33 UTC (permalink / raw)
To: linux-arm-kernel
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 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.
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 20:29 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-17 20:29 UTC (permalink / raw)
To: Turquette, Mike
Cc: Arnd Bergmann, Paul Walmsley, linux-arm-kernel, Amit Kucheria,
Nicolas Pitre, linaro-dev, Linus Walleij, Grant Likely,
Saravana Kannan, Jeremy Kerr, Magnus Damm, Deepak Saxena,
patches, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd,
linux-omap, linux-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 20:29 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-17 20:29 UTC (permalink / raw)
To: Turquette, Mike
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Thomas Gleixner,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel-u79uwXL29TY76Z2rM5mHXA
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-r2nGTMty4D4@public.gmane.org> wrote:
> > On Friday 16 March 2012, Turquette, Mike wrote:
> >> On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > From: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> >> > 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-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> >> > Cc: Mike Turquette <mturquette-l0cyMroinI0@public.gmane.org>
> >>
> >> 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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 20:29 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-17 20:29 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 21:13 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 21:13 UTC (permalink / raw)
To: Sascha Hauer
Cc: Turquette, Mike, Paul Walmsley, linux-arm-kernel, Amit Kucheria,
Nicolas Pitre, linaro-dev, Linus Walleij, Grant Likely,
Saravana Kannan, Jeremy Kerr, Magnus Damm, Deepak Saxena,
patches, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd,
linux-omap, linux-kernel
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
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 21:13 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 21:13 UTC (permalink / raw)
To: Sascha Hauer
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Thomas Gleixner,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel-u79uwXL29TY76Z2rM5mHXA
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-r2nGTMty4D4@public.gmane.org>
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-r2nGTMty4D4@public.gmane.org>
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
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-17 21:13 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-17 21:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-18 13:46 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-18 13:46 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Saravana Kannan, linaro-dev, Jeremy Kerr,
Arnd Bergman, linux-arm-kernel
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.
> + */
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-18 13:46 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-18 13:46 UTC (permalink / raw)
To: linux-arm-kernel
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.
> + */
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-18 14:07 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-18 14:07 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Saravana Kannan, linaro-dev, Jeremy Kerr,
Arnd Bergman, 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 */
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-18 14:07 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-18 14:07 UTC (permalink / raw)
To: 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 */
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-19 11:22 ` Rajendra Nayak
-1 siblings, 0 replies; 242+ messages in thread
From: Rajendra Nayak @ 2012-03-19 11:22 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Saravana Kannan, Shawn Guo, linaro-dev,
Jeremy Kerr, Arnd Bergman, linux-arm-kernel, Mike Turquette
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 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 11:22 ` Rajendra Nayak
0 siblings, 0 replies; 242+ messages in thread
From: Rajendra Nayak @ 2012-03-19 11:22 UTC (permalink / raw)
To: linux-arm-kernel
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 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-19 11:22 ` Rajendra Nayak
@ 2012-03-19 11:28 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-19 11:28 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Mike Turquette, Russell King, Paul Walmsley, Linus Walleij,
patches, Stephen Boyd, Mark Brown, Magnus Damm, linux-kernel,
Amit Kucheria, Richard Zhao, Grant Likely, Deepak Saxena,
Saravana Kannan, Shawn Guo, linaro-dev, Jeremy Kerr,
Arnd Bergman, linux-arm-kernel, Mike Turquette
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 11:28 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-19 11:28 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-17 3:28 ` Saravana Kannan
@ 2012-03-19 18:56 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 18:56 UTC (permalink / raw)
To: Saravana Kannan
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Shawn Guo, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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 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>
>> ---
>
>
> 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 18:56 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 18:56 UTC (permalink / raw)
To: linux-arm-kernel
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 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>
>> ---
>
>
> 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-18 13:46 ` Shawn Guo
@ 2012-03-19 18:58 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 18:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Paul Walmsley, Russell King, Linus Walleij, patches, Magnus Damm,
Sascha Hauer, Mark Brown, Stephen Boyd, linux-kernel,
Saravana Kannan, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 18:58 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 18:58 UTC (permalink / raw)
To: linux-arm-kernel
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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-18 14:07 ` Shawn Guo
@ 2012-03-19 19:00 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:00 UTC (permalink / raw)
To: Shawn Guo
Cc: Paul Walmsley, Russell King, Linus Walleij, patches, Magnus Damm,
Sascha Hauer, Mark Brown, Stephen Boyd, linux-kernel,
Saravana Kannan, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 19:00 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-19 11:28 ` Sascha Hauer
@ 2012-03-19 19:09 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:09 UTC (permalink / raw)
To: Sascha Hauer
Cc: Rajendra Nayak, Russell King, Paul Walmsley, Linus Walleij,
patches, Stephen Boyd, Mark Brown, Magnus Damm, linux-kernel,
Amit Kucheria, Richard Zhao, Grant Likely, Deepak Saxena,
Saravana Kannan, Shawn Guo, linaro-dev, Jeremy Kerr,
Arnd Bergman, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 19:09 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-19 18:56 ` Turquette, Mike
@ 2012-03-19 19:13 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-19 19:13 UTC (permalink / raw)
To: Turquette, Mike
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Shawn Guo, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
On 03/19/2012 11:56 AM, Turquette, Mike wrote:
> 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 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>
>>> ---
>>
>>
>> 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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 19:13 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-19 19:13 UTC (permalink / raw)
To: linux-arm-kernel
On 03/19/2012 11:56 AM, Turquette, Mike wrote:
> 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 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>
>>> ---
>>
>>
>> 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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-19 19:13 ` Saravana Kannan
@ 2012-03-19 19:33 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:33 UTC (permalink / raw)
To: Saravana Kannan
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Shawn Guo, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 19:33 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:33 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-19 19:33 ` Turquette, Mike
@ 2012-03-19 19:49 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-19 19:49 UTC (permalink / raw)
To: Turquette, Mike
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Shawn Guo, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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:
>
> 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
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;
>
> 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 19:49 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-19 19:49 UTC (permalink / raw)
To: linux-arm-kernel
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:
>
> 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
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;
>
> 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-19 11:22 ` Rajendra Nayak
@ 2012-03-19 19:53 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:53 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Amit Kucheria, Richard Zhao, Grant Likely,
Deepak Saxena, Saravana Kannan, Shawn Guo, linaro-dev,
Jeremy Kerr, Arnd Bergman, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-19 19:53 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-19 19:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-19 19:33 ` Turquette, Mike
@ 2012-03-20 3:38 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 3:38 UTC (permalink / raw)
To: Mike Turquette, Arnd Bergman, linux-arm-kernel
Cc: linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Sascha Hauer, Jamie Iles, Richard Zhao, Magnus Damm,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Grant Likely
If memory allocation for the parents array or the parent string fails, then
fail the registration immediately instead of calling clk_register and
hoping it fails there.
Return -ENOMEM on failure.
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: 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>
---
There are still some memory free issues when clk_register() fails, but I will
fix it when I fixed the other register() fns to return ENOMEM of alloc
failure instead of a NULL.
drivers/clk/clk-fixed-rate.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 90c79fb..6423ae9 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
if (! parent_names)
- goto out;
+ goto fail_ptr;
len = sizeof(char) * strlen(parent_name);
parent_names[0] = kmalloc(len, GFP_KERNEL);
if (!parent_names[0])
- goto out;
+ goto fail_str;
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);
+fail_str:
+ kfree(parent_names);
+fail_ptr:
+ kfree(fixed);
+ return ERR_PTR(-ENOMEM);
}
--
1.7.8.3
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-20 3:38 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 3:38 UTC (permalink / raw)
To: linux-arm-kernel
If memory allocation for the parents array or the parent string fails, then
fail the registration immediately instead of calling clk_register and
hoping it fails there.
Return -ENOMEM on failure.
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: 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>
---
There are still some memory free issues when clk_register() fails, but I will
fix it when I fixed the other register() fns to return ENOMEM of alloc
failure instead of a NULL.
drivers/clk/clk-fixed-rate.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 90c79fb..6423ae9 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
if (! parent_names)
- goto out;
+ goto fail_ptr;
len = sizeof(char) * strlen(parent_name);
parent_names[0] = kmalloc(len, GFP_KERNEL);
if (!parent_names[0])
- goto out;
+ goto fail_str;
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);
+fail_str:
+ kfree(parent_names);
+fail_ptr:
+ kfree(fixed);
+ return ERR_PTR(-ENOMEM);
}
--
1.7.8.3
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 3:38 ` Saravana Kannan
@ 2012-03-20 3:38 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 3:38 UTC (permalink / raw)
To: Mike Turquette, Arnd Bergman, linux-arm-kernel
Cc: linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Sascha Hauer, Jamie Iles, Richard Zhao, Magnus Damm,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Grant Likely
This has a couple of advantages:
* Completely hides struct clk from many clock platform drivers and static
clock initialization code.
* Simplifies the generic clk_register() function and allows adding optional
fields in the future without modifying the function signature.
* Allows for simpler static initialization of clocks on all platforms by
removing the need for forward delcarations.
* Halves the number of symbols added for each static clock initialization.
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: 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>
---
drivers/clk/clk-divider.c | 12 ++-
drivers/clk/clk-fixed-rate.c | 12 ++-
drivers/clk/clk-gate.c | 12 ++-
drivers/clk/clk-mux.c | 9 ++-
drivers/clk/clk.c | 170 +++++++++++++++++++++---------------------
include/linux/clk-private.h | 5 -
include/linux/clk-provider.h | 9 ++-
7 files changed, 118 insertions(+), 111 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index d5ac6a7..68b69ed 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -184,11 +184,13 @@ struct clk *clk_register_divider(struct device *dev, const char *name,
goto out;
}
- clk = clk_register(dev, name,
- &clk_divider_ops, &div->hw,
- div->parent,
- (parent_name ? 1 : 0),
- flags);
+ div->hw.name = name;
+ div->hw.ops = &clk_divider_ops;
+ div->hw.flags = flags;
+ div->hw.parent_names = div->parent;
+ div->hw.num_parents = (parent_name ? 1 : 0);
+
+ clk = clk_register(dev, &div->hw);
if (clk)
return clk;
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 6423ae9..42a0156 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -73,11 +73,13 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
strncpy(parent_names[0], parent_name, len);
}
- return clk_register(dev, name,
- &clk_fixed_rate_ops, &fixed->hw,
- parent_names,
- (parent_name ? 1 : 0),
- flags);
+ fixed->hw.name = name;
+ fixed->hw.ops = &clk_fixed_rate_ops;
+ fixed->hw.flags = flags;
+ fixed->hw.parent_names = parent_names;
+ fixed->hw.num_parents = (parent_name ? 1 : 0);
+
+ return clk_register(dev, &fixed->hw);
fail_str:
kfree(parent_names);
fail_ptr:
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index b5902e2..cb515c7 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -135,11 +135,13 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
goto out;
}
- clk = clk_register(dev, name,
- &clk_gate_ops, &gate->hw,
- gate->parent,
- (parent_name ? 1 : 0),
- flags);
+ gate->hw.name = name;
+ gate->hw.ops = &clk_gate_ops;
+ gate->hw.flags = flags;
+ gate->hw.parent_names = gate->parent;
+ gate->hw.num_parents = (parent_name ? 1 : 0);
+
+ clk = clk_register(dev, &gate->hw);
if (clk)
return clk;
out:
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c71ad1f..1c88230 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -111,6 +111,11 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
mux->flags = clk_mux_flags;
mux->lock = lock;
- return clk_register(dev, name, &clk_mux_ops, &mux->hw,
- parent_names, num_parents, flags);
+ mux->hw.name = name;
+ mux->hw.ops = &clk_mux_ops;
+ mux->hw.flags = flags;
+ mux->hw.parent_names = parent_names;
+ mux->hw.num_parents = num_parents;
+
+ return clk_register(dev, &mux->hw);
}
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 9cf6f59..c448809 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -10,6 +10,7 @@
*/
#include <linux/clk-private.h>
+#include <linux/clk-provider.h>
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
@@ -44,7 +45,7 @@ static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
goto out;
}
- d = debugfs_create_dir(clk->name, pdentry);
+ d = debugfs_create_dir(clk->hw->name, pdentry);
if (!d)
goto out;
@@ -56,7 +57,7 @@ static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
goto err_out;
d = debugfs_create_x32("clk_flags", S_IRUGO, clk->dentry,
- (u32 *)&clk->flags);
+ (u32 *)&clk->hw->flags);
if (!d)
goto err_out;
@@ -134,7 +135,7 @@ static int clk_debug_register(struct clk *clk)
* safe to add this clk to debugfs
*/
if (!parent)
- if (clk->flags & CLK_IS_ROOT)
+ if (clk->hw->flags & CLK_IS_ROOT)
pdentry = rootdir;
else
pdentry = orphandir;
@@ -215,11 +216,11 @@ static void clk_disable_unused_subtree(struct clk *clk)
if (clk->enable_count)
goto unlock_out;
- if (clk->flags & CLK_IGNORE_UNUSED)
+ if (clk->hw->flags & CLK_IGNORE_UNUSED)
goto unlock_out;
- if (__clk_is_enabled(clk) && clk->ops->disable)
- clk->ops->disable(clk->hw);
+ if (__clk_is_enabled(clk) && clk->hw->ops->disable)
+ clk->hw->ops->disable(clk->hw);
unlock_out:
spin_unlock_irqrestore(&enable_lock, flags);
@@ -254,7 +255,7 @@ static inline int clk_disable_unused(struct clk *clk) { return 0; }
inline const char *__clk_get_name(struct clk *clk)
{
- return !clk ? NULL : clk->name;
+ return !clk ? NULL : clk->hw->name;
}
inline struct clk_hw *__clk_get_hw(struct clk *clk)
@@ -264,7 +265,7 @@ inline struct clk_hw *__clk_get_hw(struct clk *clk)
inline u8 __clk_get_num_parents(struct clk *clk)
{
- return !clk ? -EINVAL : clk->num_parents;
+ return !clk ? -EINVAL : clk->hw->num_parents;
}
inline struct clk *__clk_get_parent(struct clk *clk)
@@ -293,7 +294,7 @@ unsigned long __clk_get_rate(struct clk *clk)
ret = clk->rate;
- if (clk->flags & CLK_IS_ROOT)
+ if (clk->hw->flags & CLK_IS_ROOT)
goto out;
if (!clk->parent)
@@ -305,7 +306,7 @@ out:
inline unsigned long __clk_get_flags(struct clk *clk)
{
- return !clk ? -EINVAL : clk->flags;
+ return !clk ? -EINVAL : clk->hw->flags;
}
int __clk_is_enabled(struct clk *clk)
@@ -319,12 +320,12 @@ int __clk_is_enabled(struct clk *clk)
* .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) {
+ if (!clk->hw->ops->is_enabled) {
ret = clk->enable_count ? 1 : 0;
goto out;
}
- ret = clk->ops->is_enabled(clk->hw);
+ ret = clk->hw->ops->is_enabled(clk->hw);
out:
return ret;
}
@@ -335,7 +336,7 @@ static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
struct clk *ret;
struct hlist_node *tmp;
- if (!strcmp(clk->name, name))
+ if (!strcmp(clk->hw->name, name))
return clk;
hlist_for_each_entry(child, tmp, &clk->children, child_node) {
@@ -388,8 +389,8 @@ void __clk_unprepare(struct clk *clk)
WARN_ON(clk->enable_count > 0);
- if (clk->ops->unprepare)
- clk->ops->unprepare(clk->hw);
+ if (clk->hw->ops->unprepare)
+ clk->hw->ops->unprepare(clk->hw);
__clk_unprepare(clk->parent);
}
@@ -425,8 +426,8 @@ int __clk_prepare(struct clk *clk)
if (ret)
return ret;
- if (clk->ops->prepare) {
- ret = clk->ops->prepare(clk->hw);
+ if (clk->hw->ops->prepare) {
+ ret = clk->hw->ops->prepare(clk->hw);
if (ret) {
__clk_unprepare(clk->parent);
return ret;
@@ -474,8 +475,8 @@ static void __clk_disable(struct clk *clk)
if (--clk->enable_count > 0)
return;
- if (clk->ops->disable)
- clk->ops->disable(clk->hw);
+ if (clk->hw->ops->disable)
+ clk->hw->ops->disable(clk->hw);
__clk_disable(clk->parent);
}
@@ -518,8 +519,8 @@ static int __clk_enable(struct clk *clk)
if (ret)
return ret;
- if (clk->ops->enable) {
- ret = clk->ops->enable(clk->hw);
+ if (clk->hw->ops->enable) {
+ ret = clk->hw->ops->enable(clk->hw);
if (ret) {
__clk_disable(clk->parent);
return ret;
@@ -589,13 +590,13 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
if (!clk)
return -EINVAL;
- if (!clk->ops->round_rate)
+ if (!clk->hw->ops->round_rate)
return clk->rate;
- if (clk->flags & CLK_SET_RATE_PARENT)
- return clk->ops->round_rate(clk->hw, rate, &unused);
+ if (clk->hw->flags & CLK_SET_RATE_PARENT)
+ return clk->hw->ops->round_rate(clk->hw, rate, &unused);
else
- return clk->ops->round_rate(clk->hw, rate, NULL);
+ return clk->hw->ops->round_rate(clk->hw, rate, NULL);
}
/**
@@ -681,8 +682,8 @@ static void __clk_recalc_rates(struct clk *clk, unsigned long msg)
if (clk->parent)
parent_rate = clk->parent->rate;
- if (clk->ops->recalc_rate)
- clk->rate = clk->ops->recalc_rate(clk->hw, parent_rate);
+ if (clk->hw->ops->recalc_rate)
+ clk->rate = clk->hw->ops->recalc_rate(clk->hw, parent_rate);
else
clk->rate = parent_rate;
@@ -720,8 +721,8 @@ static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate)
unsigned long new_rate;
int ret = NOTIFY_DONE;
- if (clk->ops->recalc_rate)
- new_rate = clk->ops->recalc_rate(clk->hw, parent_rate);
+ if (clk->hw->ops->recalc_rate)
+ new_rate = clk->hw->ops->recalc_rate(clk->hw, parent_rate);
else
new_rate = parent_rate;
@@ -750,8 +751,8 @@ static void clk_calc_subtree(struct clk *clk, unsigned long new_rate)
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);
+ if (child->hw->ops->recalc_rate)
+ child->new_rate = child->hw->ops->recalc_rate(child->hw, new_rate);
else
child->new_rate = new_rate;
clk_calc_subtree(child, child->new_rate);
@@ -767,23 +768,24 @@ 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;
+ unsigned long flags = clk->hw->flags;
- if (!clk->ops->round_rate && !(clk->flags & CLK_SET_RATE_PARENT)) {
+ if (!clk->hw->ops->round_rate && !(flags & CLK_SET_RATE_PARENT)) {
clk->new_rate = clk->rate;
return NULL;
}
- if (!clk->ops->round_rate && (clk->flags & CLK_SET_RATE_PARENT)) {
+ if (!clk->hw->ops->round_rate && (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);
+ if (flags & CLK_SET_RATE_PARENT)
+ new_rate = clk->hw->ops->round_rate(clk->hw, rate, &best_parent_rate);
else
- new_rate = clk->ops->round_rate(clk->hw, rate, NULL);
+ new_rate = clk->hw->ops->round_rate(clk->hw, rate, NULL);
if (best_parent_rate != clk->parent->rate) {
top = clk_calc_new_rates(clk->parent, best_parent_rate);
@@ -838,11 +840,11 @@ static void clk_change_rate(struct clk *clk)
old_rate = clk->rate;
- if (clk->ops->set_rate)
- clk->ops->set_rate(clk->hw, clk->new_rate);
+ if (clk->hw->ops->set_rate)
+ clk->hw->ops->set_rate(clk->hw, clk->new_rate);
- if (clk->ops->recalc_rate)
- clk->rate = clk->ops->recalc_rate(clk->hw,
+ if (clk->hw->ops->recalc_rate)
+ clk->rate = clk->hw->ops->recalc_rate(clk->hw,
clk->parent->rate);
else
clk->rate = clk->parent->rate;
@@ -917,7 +919,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
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);
+ fail_clk->hw->name);
clk_propagate_rate_change(top, ABORT_RATE_CHANGE);
ret = -EBUSY;
goto out;
@@ -970,18 +972,19 @@ static struct clk *__clk_init_parent(struct clk *clk)
/* handle the trivial cases */
- if (!clk->num_parents)
+ if (!clk->hw->num_parents)
goto out;
- if (clk->num_parents == 1) {
+ if (clk->hw->num_parents == 1) {
if (IS_ERR_OR_NULL(clk->parent))
- ret = clk->parent = __clk_lookup(clk->parent_names[0]);
+ ret = clk->parent =
+ __clk_lookup(clk->hw->parent_names[0]);
ret = clk->parent;
goto out;
}
- if (!clk->ops->get_parent) {
- WARN(!clk->ops->get_parent,
+ if (!clk->hw->ops->get_parent) {
+ WARN(!clk->hw->ops->get_parent,
"%s: multi-parent clocks must implement .get_parent\n",
__func__);
goto out;
@@ -993,18 +996,18 @@ static struct clk *__clk_init_parent(struct clk *clk)
* clk->parent here; that is done by the calling function
*/
- index = clk->ops->get_parent(clk->hw);
+ index = clk->hw->ops->get_parent(clk->hw);
if (!clk->parents)
clk->parents =
- kmalloc((sizeof(struct clk*) * clk->num_parents),
+ kmalloc((sizeof(struct clk*) * clk->hw->num_parents),
GFP_KERNEL);
if (!clk->parents)
- ret = __clk_lookup(clk->parent_names[index]);
+ ret = __clk_lookup(clk->hw->parent_names[index]);
else if (!clk->parents[index])
ret = clk->parents[index] =
- __clk_lookup(clk->parent_names[index]);
+ __clk_lookup(clk->hw->parent_names[index]);
else
ret = clk->parents[index];
@@ -1039,12 +1042,12 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
new_parent_d = orphandir;
d = debugfs_rename(clk->dentry->d_parent, clk->dentry,
- new_parent_d, clk->name);
+ new_parent_d, clk->hw->name);
if (d)
clk->dentry = d;
else
pr_debug("%s: failed to rename debugfs entry for %s\n",
- __func__, clk->name);
+ __func__, clk->hw->name);
out:
#endif
@@ -1063,7 +1066,7 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
old_parent = clk->parent;
/* find index of new parent clock using cached parent ptrs */
- for (i = 0; i < clk->num_parents; i++)
+ for (i = 0; i < clk->hw->num_parents; i++)
if (clk->parents[i] == parent)
break;
@@ -1071,16 +1074,17 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
* 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);
+ if (i == clk->hw->num_parents)
+ for (i = 0; i < clk->hw->num_parents; i++)
+ if (!strcmp(clk->hw->parent_names[i],
+ parent->hw->name)) {
+ clk->parents[i] = __clk_lookup(parent->hw->name);
break;
}
- if (i == clk->num_parents) {
+ if (i == clk->hw->num_parents) {
pr_debug("%s: clock %s is not a possible parent of clock %s\n",
- __func__, parent->name, clk->name);
+ __func__, parent->hw->name, clk->hw->name);
goto out;
}
@@ -1095,7 +1099,7 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
spin_unlock_irqrestore(&enable_lock, flags);
/* change clock input source */
- ret = clk->ops->set_parent(clk->hw, i);
+ ret = clk->hw->ops->set_parent(clk->hw, i);
/* clean up old prepare and enable */
spin_lock_irqsave(&enable_lock, flags);
@@ -1126,10 +1130,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
{
int ret = 0;
- if (!clk || !clk->ops)
+ if (!clk || !clk->hw->ops)
return -EINVAL;
- if (!clk->ops->set_parent)
+ if (!clk->hw->ops->set_parent)
return -ENOSYS;
/* prevent racing with updates to the clock topology */
@@ -1147,7 +1151,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
goto out;
/* only re-parent if the clock is not in use */
- if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count)
+ if ((clk->hw->flags & CLK_SET_PARENT_GATE) && clk->prepare_count)
ret = -EBUSY;
else
ret = __clk_set_parent(clk, parent);
@@ -1207,14 +1211,14 @@ void __clk_init(struct device *dev, struct clk *clk)
mutex_lock(&prepare_lock);
/* check to see if a clock with this name is already registered */
- if (__clk_lookup(clk->name))
+ if (__clk_lookup(clk->hw->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],
+ for (i = 0; i < clk->hw->num_parents; i++)
+ WARN(!clk->hw->parent_names[i],
"%s: invalid NULL in %s's .parent_names\n",
- __func__, clk->name);
+ __func__, clk->hw->name);
/*
* Allocate an array of struct clk *'s to avoid unnecessary string
@@ -1226,8 +1230,8 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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),
+ if (clk->hw->num_parents && !clk->parents) {
+ clk->parents = kmalloc((sizeof(struct clk*) * clk->hw->num_parents),
GFP_KERNEL);
/*
* __clk_lookup returns NULL for parents that have not been
@@ -1236,9 +1240,9 @@ void __clk_init(struct device *dev, struct clk *clk)
* missing parents later on.
*/
if (clk->parents)
- for (i = 0; i < clk->num_parents; i++)
+ for (i = 0; i < clk->hw->num_parents; i++)
clk->parents[i] =
- __clk_lookup(clk->parent_names[i]);
+ __clk_lookup(clk->hw->parent_names[i]);
}
clk->parent = __clk_init_parent(clk);
@@ -1256,7 +1260,7 @@ void __clk_init(struct device *dev, struct clk *clk)
if (clk->parent)
hlist_add_head(&clk->child_node,
&clk->parent->children);
- else if (clk->flags & CLK_IS_ROOT)
+ else if (clk->hw->flags & CLK_IS_ROOT)
hlist_add_head(&clk->child_node, &clk_root_list);
else
hlist_add_head(&clk->child_node, &clk_orphan_list);
@@ -1267,8 +1271,8 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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,
+ if (clk->hw->ops->recalc_rate)
+ clk->rate = clk->hw->ops->recalc_rate(clk->hw,
__clk_get_rate(clk->parent));
else if (clk->parent)
clk->rate = clk->parent->rate;
@@ -1280,8 +1284,9 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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])) {
+ for (i = 0; i < orphan->hw->num_parents; i++)
+ if (!strcmp(clk->hw->name,
+ orphan->hw->parent_names[i])) {
__clk_reparent(orphan, clk);
break;
}
@@ -1294,8 +1299,8 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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);
+ if (clk->hw->ops->init)
+ clk->hw->ops->init(clk->hw);
clk_debug_register(clk);
@@ -1320,9 +1325,7 @@ out:
* 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_register(struct device *dev, struct clk_hw *hw)
{
struct clk *clk;
@@ -1330,12 +1333,7 @@ struct clk *clk_register(struct device *dev, const char *name,
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);
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 5e4312b..f70860d 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -26,16 +26,11 @@
#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;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5508897..f032e49 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -26,6 +26,11 @@
*/
struct clk_hw {
struct clk *clk;
+ const char *name;
+ const struct clk_ops *ops;
+ char **parent_names;
+ u8 num_parents;
+ unsigned long flags;
};
/*
@@ -272,9 +277,7 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
* 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_register(struct device *dev, struct clk_hw *hw);
/* helper functions */
const char *__clk_get_name(struct clk *clk);
--
1.7.8.3
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 3:38 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 3:38 UTC (permalink / raw)
To: linux-arm-kernel
This has a couple of advantages:
* Completely hides struct clk from many clock platform drivers and static
clock initialization code.
* Simplifies the generic clk_register() function and allows adding optional
fields in the future without modifying the function signature.
* Allows for simpler static initialization of clocks on all platforms by
removing the need for forward delcarations.
* Halves the number of symbols added for each static clock initialization.
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: 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>
---
drivers/clk/clk-divider.c | 12 ++-
drivers/clk/clk-fixed-rate.c | 12 ++-
drivers/clk/clk-gate.c | 12 ++-
drivers/clk/clk-mux.c | 9 ++-
drivers/clk/clk.c | 170 +++++++++++++++++++++---------------------
include/linux/clk-private.h | 5 -
include/linux/clk-provider.h | 9 ++-
7 files changed, 118 insertions(+), 111 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index d5ac6a7..68b69ed 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -184,11 +184,13 @@ struct clk *clk_register_divider(struct device *dev, const char *name,
goto out;
}
- clk = clk_register(dev, name,
- &clk_divider_ops, &div->hw,
- div->parent,
- (parent_name ? 1 : 0),
- flags);
+ div->hw.name = name;
+ div->hw.ops = &clk_divider_ops;
+ div->hw.flags = flags;
+ div->hw.parent_names = div->parent;
+ div->hw.num_parents = (parent_name ? 1 : 0);
+
+ clk = clk_register(dev, &div->hw);
if (clk)
return clk;
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index 6423ae9..42a0156 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -73,11 +73,13 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
strncpy(parent_names[0], parent_name, len);
}
- return clk_register(dev, name,
- &clk_fixed_rate_ops, &fixed->hw,
- parent_names,
- (parent_name ? 1 : 0),
- flags);
+ fixed->hw.name = name;
+ fixed->hw.ops = &clk_fixed_rate_ops;
+ fixed->hw.flags = flags;
+ fixed->hw.parent_names = parent_names;
+ fixed->hw.num_parents = (parent_name ? 1 : 0);
+
+ return clk_register(dev, &fixed->hw);
fail_str:
kfree(parent_names);
fail_ptr:
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index b5902e2..cb515c7 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -135,11 +135,13 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
goto out;
}
- clk = clk_register(dev, name,
- &clk_gate_ops, &gate->hw,
- gate->parent,
- (parent_name ? 1 : 0),
- flags);
+ gate->hw.name = name;
+ gate->hw.ops = &clk_gate_ops;
+ gate->hw.flags = flags;
+ gate->hw.parent_names = gate->parent;
+ gate->hw.num_parents = (parent_name ? 1 : 0);
+
+ clk = clk_register(dev, &gate->hw);
if (clk)
return clk;
out:
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c71ad1f..1c88230 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -111,6 +111,11 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
mux->flags = clk_mux_flags;
mux->lock = lock;
- return clk_register(dev, name, &clk_mux_ops, &mux->hw,
- parent_names, num_parents, flags);
+ mux->hw.name = name;
+ mux->hw.ops = &clk_mux_ops;
+ mux->hw.flags = flags;
+ mux->hw.parent_names = parent_names;
+ mux->hw.num_parents = num_parents;
+
+ return clk_register(dev, &mux->hw);
}
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 9cf6f59..c448809 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -10,6 +10,7 @@
*/
#include <linux/clk-private.h>
+#include <linux/clk-provider.h>
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
@@ -44,7 +45,7 @@ static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
goto out;
}
- d = debugfs_create_dir(clk->name, pdentry);
+ d = debugfs_create_dir(clk->hw->name, pdentry);
if (!d)
goto out;
@@ -56,7 +57,7 @@ static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
goto err_out;
d = debugfs_create_x32("clk_flags", S_IRUGO, clk->dentry,
- (u32 *)&clk->flags);
+ (u32 *)&clk->hw->flags);
if (!d)
goto err_out;
@@ -134,7 +135,7 @@ static int clk_debug_register(struct clk *clk)
* safe to add this clk to debugfs
*/
if (!parent)
- if (clk->flags & CLK_IS_ROOT)
+ if (clk->hw->flags & CLK_IS_ROOT)
pdentry = rootdir;
else
pdentry = orphandir;
@@ -215,11 +216,11 @@ static void clk_disable_unused_subtree(struct clk *clk)
if (clk->enable_count)
goto unlock_out;
- if (clk->flags & CLK_IGNORE_UNUSED)
+ if (clk->hw->flags & CLK_IGNORE_UNUSED)
goto unlock_out;
- if (__clk_is_enabled(clk) && clk->ops->disable)
- clk->ops->disable(clk->hw);
+ if (__clk_is_enabled(clk) && clk->hw->ops->disable)
+ clk->hw->ops->disable(clk->hw);
unlock_out:
spin_unlock_irqrestore(&enable_lock, flags);
@@ -254,7 +255,7 @@ static inline int clk_disable_unused(struct clk *clk) { return 0; }
inline const char *__clk_get_name(struct clk *clk)
{
- return !clk ? NULL : clk->name;
+ return !clk ? NULL : clk->hw->name;
}
inline struct clk_hw *__clk_get_hw(struct clk *clk)
@@ -264,7 +265,7 @@ inline struct clk_hw *__clk_get_hw(struct clk *clk)
inline u8 __clk_get_num_parents(struct clk *clk)
{
- return !clk ? -EINVAL : clk->num_parents;
+ return !clk ? -EINVAL : clk->hw->num_parents;
}
inline struct clk *__clk_get_parent(struct clk *clk)
@@ -293,7 +294,7 @@ unsigned long __clk_get_rate(struct clk *clk)
ret = clk->rate;
- if (clk->flags & CLK_IS_ROOT)
+ if (clk->hw->flags & CLK_IS_ROOT)
goto out;
if (!clk->parent)
@@ -305,7 +306,7 @@ out:
inline unsigned long __clk_get_flags(struct clk *clk)
{
- return !clk ? -EINVAL : clk->flags;
+ return !clk ? -EINVAL : clk->hw->flags;
}
int __clk_is_enabled(struct clk *clk)
@@ -319,12 +320,12 @@ int __clk_is_enabled(struct clk *clk)
* .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) {
+ if (!clk->hw->ops->is_enabled) {
ret = clk->enable_count ? 1 : 0;
goto out;
}
- ret = clk->ops->is_enabled(clk->hw);
+ ret = clk->hw->ops->is_enabled(clk->hw);
out:
return ret;
}
@@ -335,7 +336,7 @@ static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
struct clk *ret;
struct hlist_node *tmp;
- if (!strcmp(clk->name, name))
+ if (!strcmp(clk->hw->name, name))
return clk;
hlist_for_each_entry(child, tmp, &clk->children, child_node) {
@@ -388,8 +389,8 @@ void __clk_unprepare(struct clk *clk)
WARN_ON(clk->enable_count > 0);
- if (clk->ops->unprepare)
- clk->ops->unprepare(clk->hw);
+ if (clk->hw->ops->unprepare)
+ clk->hw->ops->unprepare(clk->hw);
__clk_unprepare(clk->parent);
}
@@ -425,8 +426,8 @@ int __clk_prepare(struct clk *clk)
if (ret)
return ret;
- if (clk->ops->prepare) {
- ret = clk->ops->prepare(clk->hw);
+ if (clk->hw->ops->prepare) {
+ ret = clk->hw->ops->prepare(clk->hw);
if (ret) {
__clk_unprepare(clk->parent);
return ret;
@@ -474,8 +475,8 @@ static void __clk_disable(struct clk *clk)
if (--clk->enable_count > 0)
return;
- if (clk->ops->disable)
- clk->ops->disable(clk->hw);
+ if (clk->hw->ops->disable)
+ clk->hw->ops->disable(clk->hw);
__clk_disable(clk->parent);
}
@@ -518,8 +519,8 @@ static int __clk_enable(struct clk *clk)
if (ret)
return ret;
- if (clk->ops->enable) {
- ret = clk->ops->enable(clk->hw);
+ if (clk->hw->ops->enable) {
+ ret = clk->hw->ops->enable(clk->hw);
if (ret) {
__clk_disable(clk->parent);
return ret;
@@ -589,13 +590,13 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
if (!clk)
return -EINVAL;
- if (!clk->ops->round_rate)
+ if (!clk->hw->ops->round_rate)
return clk->rate;
- if (clk->flags & CLK_SET_RATE_PARENT)
- return clk->ops->round_rate(clk->hw, rate, &unused);
+ if (clk->hw->flags & CLK_SET_RATE_PARENT)
+ return clk->hw->ops->round_rate(clk->hw, rate, &unused);
else
- return clk->ops->round_rate(clk->hw, rate, NULL);
+ return clk->hw->ops->round_rate(clk->hw, rate, NULL);
}
/**
@@ -681,8 +682,8 @@ static void __clk_recalc_rates(struct clk *clk, unsigned long msg)
if (clk->parent)
parent_rate = clk->parent->rate;
- if (clk->ops->recalc_rate)
- clk->rate = clk->ops->recalc_rate(clk->hw, parent_rate);
+ if (clk->hw->ops->recalc_rate)
+ clk->rate = clk->hw->ops->recalc_rate(clk->hw, parent_rate);
else
clk->rate = parent_rate;
@@ -720,8 +721,8 @@ static int __clk_speculate_rates(struct clk *clk, unsigned long parent_rate)
unsigned long new_rate;
int ret = NOTIFY_DONE;
- if (clk->ops->recalc_rate)
- new_rate = clk->ops->recalc_rate(clk->hw, parent_rate);
+ if (clk->hw->ops->recalc_rate)
+ new_rate = clk->hw->ops->recalc_rate(clk->hw, parent_rate);
else
new_rate = parent_rate;
@@ -750,8 +751,8 @@ static void clk_calc_subtree(struct clk *clk, unsigned long new_rate)
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);
+ if (child->hw->ops->recalc_rate)
+ child->new_rate = child->hw->ops->recalc_rate(child->hw, new_rate);
else
child->new_rate = new_rate;
clk_calc_subtree(child, child->new_rate);
@@ -767,23 +768,24 @@ 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;
+ unsigned long flags = clk->hw->flags;
- if (!clk->ops->round_rate && !(clk->flags & CLK_SET_RATE_PARENT)) {
+ if (!clk->hw->ops->round_rate && !(flags & CLK_SET_RATE_PARENT)) {
clk->new_rate = clk->rate;
return NULL;
}
- if (!clk->ops->round_rate && (clk->flags & CLK_SET_RATE_PARENT)) {
+ if (!clk->hw->ops->round_rate && (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);
+ if (flags & CLK_SET_RATE_PARENT)
+ new_rate = clk->hw->ops->round_rate(clk->hw, rate, &best_parent_rate);
else
- new_rate = clk->ops->round_rate(clk->hw, rate, NULL);
+ new_rate = clk->hw->ops->round_rate(clk->hw, rate, NULL);
if (best_parent_rate != clk->parent->rate) {
top = clk_calc_new_rates(clk->parent, best_parent_rate);
@@ -838,11 +840,11 @@ static void clk_change_rate(struct clk *clk)
old_rate = clk->rate;
- if (clk->ops->set_rate)
- clk->ops->set_rate(clk->hw, clk->new_rate);
+ if (clk->hw->ops->set_rate)
+ clk->hw->ops->set_rate(clk->hw, clk->new_rate);
- if (clk->ops->recalc_rate)
- clk->rate = clk->ops->recalc_rate(clk->hw,
+ if (clk->hw->ops->recalc_rate)
+ clk->rate = clk->hw->ops->recalc_rate(clk->hw,
clk->parent->rate);
else
clk->rate = clk->parent->rate;
@@ -917,7 +919,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
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);
+ fail_clk->hw->name);
clk_propagate_rate_change(top, ABORT_RATE_CHANGE);
ret = -EBUSY;
goto out;
@@ -970,18 +972,19 @@ static struct clk *__clk_init_parent(struct clk *clk)
/* handle the trivial cases */
- if (!clk->num_parents)
+ if (!clk->hw->num_parents)
goto out;
- if (clk->num_parents == 1) {
+ if (clk->hw->num_parents == 1) {
if (IS_ERR_OR_NULL(clk->parent))
- ret = clk->parent = __clk_lookup(clk->parent_names[0]);
+ ret = clk->parent =
+ __clk_lookup(clk->hw->parent_names[0]);
ret = clk->parent;
goto out;
}
- if (!clk->ops->get_parent) {
- WARN(!clk->ops->get_parent,
+ if (!clk->hw->ops->get_parent) {
+ WARN(!clk->hw->ops->get_parent,
"%s: multi-parent clocks must implement .get_parent\n",
__func__);
goto out;
@@ -993,18 +996,18 @@ static struct clk *__clk_init_parent(struct clk *clk)
* clk->parent here; that is done by the calling function
*/
- index = clk->ops->get_parent(clk->hw);
+ index = clk->hw->ops->get_parent(clk->hw);
if (!clk->parents)
clk->parents =
- kmalloc((sizeof(struct clk*) * clk->num_parents),
+ kmalloc((sizeof(struct clk*) * clk->hw->num_parents),
GFP_KERNEL);
if (!clk->parents)
- ret = __clk_lookup(clk->parent_names[index]);
+ ret = __clk_lookup(clk->hw->parent_names[index]);
else if (!clk->parents[index])
ret = clk->parents[index] =
- __clk_lookup(clk->parent_names[index]);
+ __clk_lookup(clk->hw->parent_names[index]);
else
ret = clk->parents[index];
@@ -1039,12 +1042,12 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
new_parent_d = orphandir;
d = debugfs_rename(clk->dentry->d_parent, clk->dentry,
- new_parent_d, clk->name);
+ new_parent_d, clk->hw->name);
if (d)
clk->dentry = d;
else
pr_debug("%s: failed to rename debugfs entry for %s\n",
- __func__, clk->name);
+ __func__, clk->hw->name);
out:
#endif
@@ -1063,7 +1066,7 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
old_parent = clk->parent;
/* find index of new parent clock using cached parent ptrs */
- for (i = 0; i < clk->num_parents; i++)
+ for (i = 0; i < clk->hw->num_parents; i++)
if (clk->parents[i] == parent)
break;
@@ -1071,16 +1074,17 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
* 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);
+ if (i == clk->hw->num_parents)
+ for (i = 0; i < clk->hw->num_parents; i++)
+ if (!strcmp(clk->hw->parent_names[i],
+ parent->hw->name)) {
+ clk->parents[i] = __clk_lookup(parent->hw->name);
break;
}
- if (i == clk->num_parents) {
+ if (i == clk->hw->num_parents) {
pr_debug("%s: clock %s is not a possible parent of clock %s\n",
- __func__, parent->name, clk->name);
+ __func__, parent->hw->name, clk->hw->name);
goto out;
}
@@ -1095,7 +1099,7 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent)
spin_unlock_irqrestore(&enable_lock, flags);
/* change clock input source */
- ret = clk->ops->set_parent(clk->hw, i);
+ ret = clk->hw->ops->set_parent(clk->hw, i);
/* clean up old prepare and enable */
spin_lock_irqsave(&enable_lock, flags);
@@ -1126,10 +1130,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
{
int ret = 0;
- if (!clk || !clk->ops)
+ if (!clk || !clk->hw->ops)
return -EINVAL;
- if (!clk->ops->set_parent)
+ if (!clk->hw->ops->set_parent)
return -ENOSYS;
/* prevent racing with updates to the clock topology */
@@ -1147,7 +1151,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
goto out;
/* only re-parent if the clock is not in use */
- if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count)
+ if ((clk->hw->flags & CLK_SET_PARENT_GATE) && clk->prepare_count)
ret = -EBUSY;
else
ret = __clk_set_parent(clk, parent);
@@ -1207,14 +1211,14 @@ void __clk_init(struct device *dev, struct clk *clk)
mutex_lock(&prepare_lock);
/* check to see if a clock with this name is already registered */
- if (__clk_lookup(clk->name))
+ if (__clk_lookup(clk->hw->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],
+ for (i = 0; i < clk->hw->num_parents; i++)
+ WARN(!clk->hw->parent_names[i],
"%s: invalid NULL in %s's .parent_names\n",
- __func__, clk->name);
+ __func__, clk->hw->name);
/*
* Allocate an array of struct clk *'s to avoid unnecessary string
@@ -1226,8 +1230,8 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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),
+ if (clk->hw->num_parents && !clk->parents) {
+ clk->parents = kmalloc((sizeof(struct clk*) * clk->hw->num_parents),
GFP_KERNEL);
/*
* __clk_lookup returns NULL for parents that have not been
@@ -1236,9 +1240,9 @@ void __clk_init(struct device *dev, struct clk *clk)
* missing parents later on.
*/
if (clk->parents)
- for (i = 0; i < clk->num_parents; i++)
+ for (i = 0; i < clk->hw->num_parents; i++)
clk->parents[i] =
- __clk_lookup(clk->parent_names[i]);
+ __clk_lookup(clk->hw->parent_names[i]);
}
clk->parent = __clk_init_parent(clk);
@@ -1256,7 +1260,7 @@ void __clk_init(struct device *dev, struct clk *clk)
if (clk->parent)
hlist_add_head(&clk->child_node,
&clk->parent->children);
- else if (clk->flags & CLK_IS_ROOT)
+ else if (clk->hw->flags & CLK_IS_ROOT)
hlist_add_head(&clk->child_node, &clk_root_list);
else
hlist_add_head(&clk->child_node, &clk_orphan_list);
@@ -1267,8 +1271,8 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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,
+ if (clk->hw->ops->recalc_rate)
+ clk->rate = clk->hw->ops->recalc_rate(clk->hw,
__clk_get_rate(clk->parent));
else if (clk->parent)
clk->rate = clk->parent->rate;
@@ -1280,8 +1284,9 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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])) {
+ for (i = 0; i < orphan->hw->num_parents; i++)
+ if (!strcmp(clk->hw->name,
+ orphan->hw->parent_names[i])) {
__clk_reparent(orphan, clk);
break;
}
@@ -1294,8 +1299,8 @@ void __clk_init(struct device *dev, struct clk *clk)
* 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);
+ if (clk->hw->ops->init)
+ clk->hw->ops->init(clk->hw);
clk_debug_register(clk);
@@ -1320,9 +1325,7 @@ out:
* 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_register(struct device *dev, struct clk_hw *hw)
{
struct clk *clk;
@@ -1330,12 +1333,7 @@ struct clk *clk_register(struct device *dev, const char *name,
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);
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 5e4312b..f70860d 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -26,16 +26,11 @@
#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;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5508897..f032e49 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -26,6 +26,11 @@
*/
struct clk_hw {
struct clk *clk;
+ const char *name;
+ const struct clk_ops *ops;
+ char **parent_names;
+ u8 num_parents;
+ unsigned long flags;
};
/*
@@ -272,9 +277,7 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
* 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_register(struct device *dev, struct clk_hw *hw);
/* helper functions */
const char *__clk_get_name(struct clk *clk);
--
1.7.8.3
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-20 3:38 ` Saravana Kannan
@ 2012-03-20 7:19 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 7:19 UTC (permalink / raw)
To: Saravana Kannan
Cc: Mike Turquette, Arnd Bergman, linux-arm-kernel, linux-kernel,
linux-arm-msm, Andrew Lunn, Rob Herring, Russell King,
Jeremy Kerr, Thomas Gleixner, Paul Walmsley, Shawn Guo,
Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown, Linus Walleij,
Stephen Boyd, Amit Kucheria, Deepak Saxena, Grant Likely
On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
> If memory allocation for the parents array or the parent string fails, then
> fail the registration immediately instead of calling clk_register and
> hoping it fails there.
>
> Return -ENOMEM on failure.
>
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: 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>
> ---
> There are still some memory free issues when clk_register() fails, but I will
> fix it when I fixed the other register() fns to return ENOMEM of alloc
> failure instead of a NULL.
>
> drivers/clk/clk-fixed-rate.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
> index 90c79fb..6423ae9 100644
> --- a/drivers/clk/clk-fixed-rate.c
> +++ b/drivers/clk/clk-fixed-rate.c
> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>
> if (! parent_names)
> - goto out;
> + goto fail_ptr;
>
> len = sizeof(char) * strlen(parent_name);
>
> parent_names[0] = kmalloc(len, GFP_KERNEL);
>
> if (!parent_names[0])
> - goto out;
> + goto fail_str;
>
> strncpy(parent_names[0], parent_name, len);
> }
It's easier to add a char *parent to struct clk_fixed and pass it to
clk_register with &fixed->parent. This saves you a kmalloc call and
makes the error path simpler. It's the same way already done in the
divider.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-20 7:19 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 7:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
> If memory allocation for the parents array or the parent string fails, then
> fail the registration immediately instead of calling clk_register and
> hoping it fails there.
>
> Return -ENOMEM on failure.
>
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: 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>
> ---
> There are still some memory free issues when clk_register() fails, but I will
> fix it when I fixed the other register() fns to return ENOMEM of alloc
> failure instead of a NULL.
>
> drivers/clk/clk-fixed-rate.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
> index 90c79fb..6423ae9 100644
> --- a/drivers/clk/clk-fixed-rate.c
> +++ b/drivers/clk/clk-fixed-rate.c
> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>
> if (! parent_names)
> - goto out;
> + goto fail_ptr;
>
> len = sizeof(char) * strlen(parent_name);
>
> parent_names[0] = kmalloc(len, GFP_KERNEL);
>
> if (!parent_names[0])
> - goto out;
> + goto fail_str;
>
> strncpy(parent_names[0], parent_name, len);
> }
It's easier to add a char *parent to struct clk_fixed and pass it to
clk_register with &fixed->parent. This saves you a kmalloc call and
makes the error path simpler. It's the same way already done in the
divider.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 3:38 ` Saravana Kannan
@ 2012-03-20 7:20 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 7:20 UTC (permalink / raw)
To: Saravana Kannan
Cc: Mike Turquette, Arnd Bergman, linux-arm-kernel, linux-kernel,
linux-arm-msm, Andrew Lunn, Rob Herring, Russell King,
Jeremy Kerr, Thomas Gleixner, Paul Walmsley, Shawn Guo,
Sascha Hauer, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
> This has a couple of advantages:
> * Completely hides struct clk from many clock platform drivers and static
> clock initialization code.
> * Simplifies the generic clk_register() function and allows adding optional
> fields in the future without modifying the function signature.
> * Allows for simpler static initialization of clocks on all platforms by
> removing the need for forward delcarations.
> * Halves the number of symbols added for each static clock initialization.
>
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
I agree this is a reasonable move. But while you simplify the interface
of clk_register(), why not making a further step to simplify the
following interfaces simple too?
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 *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 *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 *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);
Otherwise,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 7:20 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 7:20 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
> This has a couple of advantages:
> * Completely hides struct clk from many clock platform drivers and static
> clock initialization code.
> * Simplifies the generic clk_register() function and allows adding optional
> fields in the future without modifying the function signature.
> * Allows for simpler static initialization of clocks on all platforms by
> removing the need for forward delcarations.
> * Halves the number of symbols added for each static clock initialization.
>
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
I agree this is a reasonable move. But while you simplify the interface
of clk_register(), why not making a further step to simplify the
following interfaces simple too?
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 *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 *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 *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);
Otherwise,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-20 7:19 ` Sascha Hauer
(?)
@ 2012-03-20 7:46 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 7:46 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>> If memory allocation for the parents array or the parent string fails,
>> then
>> fail the registration immediately instead of calling clk_register and
>> hoping it fails there.
>>
>> Return -ENOMEM on failure.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> Cc: Mike Turquette <mturquette@linaro.org>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: 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>
>> ---
>> There are still some memory free issues when clk_register() fails, but I
>> will
>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>> failure instead of a NULL.
>>
>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>> index 90c79fb..6423ae9 100644
>> --- a/drivers/clk/clk-fixed-rate.c
>> +++ b/drivers/clk/clk-fixed-rate.c
>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>> *dev, const char *name,
>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>
>> if (! parent_names)
>> - goto out;
>> + goto fail_ptr;
>>
>> len = sizeof(char) * strlen(parent_name);
>>
>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>
>> if (!parent_names[0])
>> - goto out;
>> + goto fail_str;
>>
>> strncpy(parent_names[0], parent_name, len);
>> }
>
> It's easier to add a char *parent to struct clk_fixed and pass it to
> clk_register with &fixed->parent. This saves you a kmalloc call and
> makes the error path simpler. It's the same way already done in the
> divider.
I thought about that since I saw the same was done for gated and divider
(I think). Here is my guess at Mike's reasoning for this:
Gated and divider clocks have to have a parent. There's nothing to gate
otherwise. But fixed rate clocks might not have a parent. It could be XO's
or PLLs running off of always on XOs not controlled by the SoC. So, it's
arguable to not have a parent. I don't have a strong opinion on this --
since Mike took the time to write it, it left it to his subjective
preference.
I sent this patch first since it was around the place I was cleaning up. I
didn't want to actually just shuffle around a bug. As I mentioned, this
patch still leaves a bug open -- what if clk_register() fails. I plan to
fix that once my two patches are picked up (hopefully).
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-20 7:46 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 7:46 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>> If memory allocation for the parents array or the parent string fails,
>> then
>> fail the registration immediately instead of calling clk_register and
>> hoping it fails there.
>>
>> Return -ENOMEM on failure.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> Cc: Mike Turquette <mturquette@linaro.org>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: 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>
>> ---
>> There are still some memory free issues when clk_register() fails, but I
>> will
>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>> failure instead of a NULL.
>>
>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>> index 90c79fb..6423ae9 100644
>> --- a/drivers/clk/clk-fixed-rate.c
>> +++ b/drivers/clk/clk-fixed-rate.c
>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>> *dev, const char *name,
>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>
>> if (! parent_names)
>> - goto out;
>> + goto fail_ptr;
>>
>> len = sizeof(char) * strlen(parent_name);
>>
>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>
>> if (!parent_names[0])
>> - goto out;
>> + goto fail_str;
>>
>> strncpy(parent_names[0], parent_name, len);
>> }
>
> It's easier to add a char *parent to struct clk_fixed and pass it to
> clk_register with &fixed->parent. This saves you a kmalloc call and
> makes the error path simpler. It's the same way already done in the
> divider.
I thought about that since I saw the same was done for gated and divider
(I think). Here is my guess at Mike's reasoning for this:
Gated and divider clocks have to have a parent. There's nothing to gate
otherwise. But fixed rate clocks might not have a parent. It could be XO's
or PLLs running off of always on XOs not controlled by the SoC. So, it's
arguable to not have a parent. I don't have a strong opinion on this --
since Mike took the time to write it, it left it to his subjective
preference.
I sent this patch first since it was around the place I was cleaning up. I
didn't want to actually just shuffle around a bug. As I mentioned, this
patch still leaves a bug open -- what if clk_register() fails. I plan to
fix that once my two patches are picked up (hopefully).
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-20 7:46 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 7:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>> If memory allocation for the parents array or the parent string fails,
>> then
>> fail the registration immediately instead of calling clk_register and
>> hoping it fails there.
>>
>> Return -ENOMEM on failure.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> Cc: Mike Turquette <mturquette@linaro.org>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: 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>
>> ---
>> There are still some memory free issues when clk_register() fails, but I
>> will
>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>> failure instead of a NULL.
>>
>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>> index 90c79fb..6423ae9 100644
>> --- a/drivers/clk/clk-fixed-rate.c
>> +++ b/drivers/clk/clk-fixed-rate.c
>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>> *dev, const char *name,
>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>
>> if (! parent_names)
>> - goto out;
>> + goto fail_ptr;
>>
>> len = sizeof(char) * strlen(parent_name);
>>
>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>
>> if (!parent_names[0])
>> - goto out;
>> + goto fail_str;
>>
>> strncpy(parent_names[0], parent_name, len);
>> }
>
> It's easier to add a char *parent to struct clk_fixed and pass it to
> clk_register with &fixed->parent. This saves you a kmalloc call and
> makes the error path simpler. It's the same way already done in the
> divider.
I thought about that since I saw the same was done for gated and divider
(I think). Here is my guess at Mike's reasoning for this:
Gated and divider clocks have to have a parent. There's nothing to gate
otherwise. But fixed rate clocks might not have a parent. It could be XO's
or PLLs running off of always on XOs not controlled by the SoC. So, it's
arguable to not have a parent. I don't have a strong opinion on this --
since Mike took the time to write it, it left it to his subjective
preference.
I sent this patch first since it was around the place I was cleaning up. I
didn't want to actually just shuffle around a bug. As I mentioned, this
patch still leaves a bug open -- what if clk_register() fails. I plan to
fix that once my two patches are picked up (hopefully).
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 7:20 ` Shawn Guo
(?)
@ 2012-03-20 7:54 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 7:54 UTC (permalink / raw)
To: Shawn Guo
Cc: Saravana Kannan, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Sascha Hauer, Jamie Iles, Richard Zhao, Magnus Damm,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena
On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
> On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
>> This has a couple of advantages:
>> * Completely hides struct clk from many clock platform drivers and
>> static
>> clock initialization code.
>> * Simplifies the generic clk_register() function and allows adding
>> optional
>> fields in the future without modifying the function signature.
>> * Allows for simpler static initialization of clocks on all platforms by
>> removing the need for forward delcarations.
>> * Halves the number of symbols added for each static clock
>> initialization.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>
> I agree this is a reasonable move. But while you simplify the interface
> of clk_register(), why not making a further step to simplify the
> following interfaces simple too?
>
> 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 *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 *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 *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);
If you simplify those functions further. They would just become
clk_register(). I'm not sure I see a value in them in at that point or
even in their current form. But if others see (I'm guessing since they
acked or didn't nack it), I'm not going to ask to remove them. If everyone
agrees that we should just remove them, I would be glad to.
It's arguable that these functions for the common hardware types saves the
need to deal with the kalloc in every platform driver. But it's not clear
to me where they would get these parameters in the first place. Most
likely form some sort of static array. At which point, it might as well be
a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
of a platform specific struct to hold these initializers.
Btw, I need to fix the macros too. Or may be even delete them. Will see
the overall response before I send out v2 to do that.
>
> Otherwise,
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 7:54 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 7:54 UTC (permalink / raw)
To: Shawn Guo
Cc: Saravana Kannan, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Sascha Hauer, Jamie Iles, Richard Zhao, Magnus Damm,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Grant Likely
On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
> On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
>> This has a couple of advantages:
>> * Completely hides struct clk from many clock platform drivers and
>> static
>> clock initialization code.
>> * Simplifies the generic clk_register() function and allows adding
>> optional
>> fields in the future without modifying the function signature.
>> * Allows for simpler static initialization of clocks on all platforms by
>> removing the need for forward delcarations.
>> * Halves the number of symbols added for each static clock
>> initialization.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>
> I agree this is a reasonable move. But while you simplify the interface
> of clk_register(), why not making a further step to simplify the
> following interfaces simple too?
>
> 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 *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 *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 *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);
If you simplify those functions further. They would just become
clk_register(). I'm not sure I see a value in them in at that point or
even in their current form. But if others see (I'm guessing since they
acked or didn't nack it), I'm not going to ask to remove them. If everyone
agrees that we should just remove them, I would be glad to.
It's arguable that these functions for the common hardware types saves the
need to deal with the kalloc in every platform driver. But it's not clear
to me where they would get these parameters in the first place. Most
likely form some sort of static array. At which point, it might as well be
a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
of a platform specific struct to hold these initializers.
Btw, I need to fix the macros too. Or may be even delete them. Will see
the overall response before I send out v2 to do that.
>
> Otherwise,
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 7:54 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 7:54 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
> On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
>> This has a couple of advantages:
>> * Completely hides struct clk from many clock platform drivers and
>> static
>> clock initialization code.
>> * Simplifies the generic clk_register() function and allows adding
>> optional
>> fields in the future without modifying the function signature.
>> * Allows for simpler static initialization of clocks on all platforms by
>> removing the need for forward delcarations.
>> * Halves the number of symbols added for each static clock
>> initialization.
>>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>
> I agree this is a reasonable move. But while you simplify the interface
> of clk_register(), why not making a further step to simplify the
> following interfaces simple too?
>
> 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 *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 *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 *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);
If you simplify those functions further. They would just become
clk_register(). I'm not sure I see a value in them in at that point or
even in their current form. But if others see (I'm guessing since they
acked or didn't nack it), I'm not going to ask to remove them. If everyone
agrees that we should just remove them, I would be glad to.
It's arguable that these functions for the common hardware types saves the
need to deal with the kalloc in every platform driver. But it's not clear
to me where they would get these parameters in the first place. Most
likely form some sort of static array. At which point, it might as well be
a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
of a platform specific struct to hold these initializers.
Btw, I need to fix the macros too. Or may be even delete them. Will see
the overall response before I send out v2 to do that.
>
> Otherwise,
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 7:54 ` Saravana Kannan
@ 2012-03-20 8:13 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 8:13 UTC (permalink / raw)
To: Saravana Kannan
Cc: Mike Turquette, Arnd Bergman, linux-arm-kernel, linux-kernel,
linux-arm-msm, Andrew Lunn, Rob Herring, Russell King,
Jeremy Kerr, Thomas Gleixner, Paul Walmsley, Shawn Guo,
Sascha Hauer, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>
> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
...
> > 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 *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 *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 *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);
>
> If you simplify those functions further. They would just become
> clk_register(). I'm not sure I see a value in them in at that point or
> even in their current form. But if others see (I'm guessing since they
> acked or didn't nack it), I'm not going to ask to remove them. If everyone
> agrees that we should just remove them, I would be glad to.
>
> It's arguable that these functions for the common hardware types saves the
> need to deal with the kalloc in every platform driver. But it's not clear
> to me where they would get these parameters in the first place. Most
> likely form some sort of static array. At which point, it might as well be
> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
> of a platform specific struct to hold these initializers.
I share the save view on this, so would vote to remove these
registration functions for basic clks completely.
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 8:13 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 8:13 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>
> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
...
> > 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 *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 *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 *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);
>
> If you simplify those functions further. They would just become
> clk_register(). I'm not sure I see a value in them in at that point or
> even in their current form. But if others see (I'm guessing since they
> acked or didn't nack it), I'm not going to ask to remove them. If everyone
> agrees that we should just remove them, I would be glad to.
>
> It's arguable that these functions for the common hardware types saves the
> need to deal with the kalloc in every platform driver. But it's not clear
> to me where they would get these parameters in the first place. Most
> likely form some sort of static array. At which point, it might as well be
> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
> of a platform specific struct to hold these initializers.
I share the save view on this, so would vote to remove these
registration functions for basic clks completely.
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 7:54 ` Saravana Kannan
@ 2012-03-20 9:40 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 9:40 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>
> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
> > On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
> >> This has a couple of advantages:
> >> * Completely hides struct clk from many clock platform drivers and
> >> static
> >> clock initialization code.
> >> * Simplifies the generic clk_register() function and allows adding
> >> optional
> >> fields in the future without modifying the function signature.
> >> * Allows for simpler static initialization of clocks on all platforms by
> >> removing the need for forward delcarations.
> >> * Halves the number of symbols added for each static clock
> >> initialization.
> >>
> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> >
> > I agree this is a reasonable move. But while you simplify the interface
> > of clk_register(), why not making a further step to simplify the
> > following interfaces simple too?
> >
> > 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 *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 *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 *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);
>
> If you simplify those functions further. They would just become
> clk_register(). I'm not sure I see a value in them in at that point or
> even in their current form. But if others see (I'm guessing since they
> acked or didn't nack it), I'm not going to ask to remove them. If everyone
> agrees that we should just remove them, I would be glad to.
>
> It's arguable that these functions for the common hardware types saves the
> need to deal with the kalloc in every platform driver. But it's not clear
> to me where they would get these parameters in the first place. Most
> likely form some sort of static array. At which point, it might as well be
> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
> of a platform specific struct to hold these initializers.
I am using these functions and don't need a static array, I just call
the functions with the desired parameters.
Overall the clock framework was written in a way that we have to expose
as little information about the internally used structs as necessary. It
seems your patches are pulling in the opposite direction now.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 9:40 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 9:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>
> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
> > On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
> >> This has a couple of advantages:
> >> * Completely hides struct clk from many clock platform drivers and
> >> static
> >> clock initialization code.
> >> * Simplifies the generic clk_register() function and allows adding
> >> optional
> >> fields in the future without modifying the function signature.
> >> * Allows for simpler static initialization of clocks on all platforms by
> >> removing the need for forward delcarations.
> >> * Halves the number of symbols added for each static clock
> >> initialization.
> >>
> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> >
> > I agree this is a reasonable move. But while you simplify the interface
> > of clk_register(), why not making a further step to simplify the
> > following interfaces simple too?
> >
> > 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 *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 *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 *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);
>
> If you simplify those functions further. They would just become
> clk_register(). I'm not sure I see a value in them in at that point or
> even in their current form. But if others see (I'm guessing since they
> acked or didn't nack it), I'm not going to ask to remove them. If everyone
> agrees that we should just remove them, I would be glad to.
>
> It's arguable that these functions for the common hardware types saves the
> need to deal with the kalloc in every platform driver. But it's not clear
> to me where they would get these parameters in the first place. Most
> likely form some sort of static array. At which point, it might as well be
> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc instead
> of a platform specific struct to hold these initializers.
I am using these functions and don't need a static array, I just call
the functions with the desired parameters.
Overall the clock framework was written in a way that we have to expose
as little information about the internally used structs as necessary. It
seems your patches are pulling in the opposite direction now.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 9:40 ` Sascha Hauer
(?)
@ 2012-03-20 10:17 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 10:17 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Shawn Guo, Mike Turquette, Arnd Bergman,
linux-arm-kernel, linux-kernel, linux-arm-msm, Andrew Lunn,
Rob Herring, Russell King, Jeremy Kerr, Thomas Gleixner,
Paul Walmsley, Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Gra
On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>>
>> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
>> > On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
>> >> This has a couple of advantages:
>> >> * Completely hides struct clk from many clock platform drivers and
>> >> static
>> >> clock initialization code.
>> >> * Simplifies the generic clk_register() function and allows adding
>> >> optional
>> >> fields in the future without modifying the function signature.
>> >> * Allows for simpler static initialization of clocks on all platforms
>> by
>> >> removing the need for forward delcarations.
>> >> * Halves the number of symbols added for each static clock
>> >> initialization.
>> >>
>> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> >
>> > I agree this is a reasonable move. But while you simplify the
>> interface
>> > of clk_register(), why not making a further step to simplify the
>> > following interfaces simple too?
>> >
>> > 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 *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 *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 *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);
>>
>> If you simplify those functions further. They would just become
>> clk_register(). I'm not sure I see a value in them in at that point or
>> even in their current form. But if others see (I'm guessing since they
>> acked or didn't nack it), I'm not going to ask to remove them. If
>> everyone
>> agrees that we should just remove them, I would be glad to.
>>
>> It's arguable that these functions for the common hardware types saves
>> the
>> need to deal with the kalloc in every platform driver. But it's not
>> clear
>> to me where they would get these parameters in the first place. Most
>> likely form some sort of static array. At which point, it might as well
>> be
>> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc
>> instead
>> of a platform specific struct to hold these initializers.
>
> I am using these functions and don't need a static array, I just call
> the functions with the desired parameters.
Sure, then let's leave it in. Curious, where do you get the desired
parameters from? Is it static date in code or is it from DT? You somehow
probe it?
> Overall the clock framework was written in a way that we have to expose
> as little information about the internally used structs as necessary. It
> seems your patches are pulling in the opposite direction now.
I'm not exposing anything that you don't already pass from the platform
driver. Also, you realize that this is very similar to what you suggested
with clk_initializer right? If there is a strong push, we can make a copy
of these inside the struct clk, but for these few init fields I don't see
a point (see earlier email).
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 10:17 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 10:17 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Shawn Guo, Mike Turquette, Arnd Bergman,
linux-arm-kernel, linux-kernel, linux-arm-msm, Andrew Lunn,
Rob Herring, Russell King, Jeremy Kerr, Thomas Gleixner,
Paul Walmsley, Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm,
Mark Brown, Linus Walleij, Stephen Boyd, Amit Kucheria,
Deepak Saxena, Grant Likely
On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>>
>> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
>> > On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
>> >> This has a couple of advantages:
>> >> * Completely hides struct clk from many clock platform drivers and
>> >> static
>> >> clock initialization code.
>> >> * Simplifies the generic clk_register() function and allows adding
>> >> optional
>> >> fields in the future without modifying the function signature.
>> >> * Allows for simpler static initialization of clocks on all platforms
>> by
>> >> removing the need for forward delcarations.
>> >> * Halves the number of symbols added for each static clock
>> >> initialization.
>> >>
>> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> >
>> > I agree this is a reasonable move. But while you simplify the
>> interface
>> > of clk_register(), why not making a further step to simplify the
>> > following interfaces simple too?
>> >
>> > 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 *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 *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 *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);
>>
>> If you simplify those functions further. They would just become
>> clk_register(). I'm not sure I see a value in them in at that point or
>> even in their current form. But if others see (I'm guessing since they
>> acked or didn't nack it), I'm not going to ask to remove them. If
>> everyone
>> agrees that we should just remove them, I would be glad to.
>>
>> It's arguable that these functions for the common hardware types saves
>> the
>> need to deal with the kalloc in every platform driver. But it's not
>> clear
>> to me where they would get these parameters in the first place. Most
>> likely form some sort of static array. At which point, it might as well
>> be
>> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc
>> instead
>> of a platform specific struct to hold these initializers.
>
> I am using these functions and don't need a static array, I just call
> the functions with the desired parameters.
Sure, then let's leave it in. Curious, where do you get the desired
parameters from? Is it static date in code or is it from DT? You somehow
probe it?
> Overall the clock framework was written in a way that we have to expose
> as little information about the internally used structs as necessary. It
> seems your patches are pulling in the opposite direction now.
I'm not exposing anything that you don't already pass from the platform
driver. Also, you realize that this is very similar to what you suggested
with clk_initializer right? If there is a strong push, we can make a copy
of these inside the struct clk, but for these few init fields I don't see
a point (see earlier email).
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 10:17 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 10:17 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>>
>> On Tue, March 20, 2012 12:20 am, Shawn Guo wrote:
>> > On Mon, Mar 19, 2012 at 08:38:26PM -0700, Saravana Kannan wrote:
>> >> This has a couple of advantages:
>> >> * Completely hides struct clk from many clock platform drivers and
>> >> static
>> >> clock initialization code.
>> >> * Simplifies the generic clk_register() function and allows adding
>> >> optional
>> >> fields in the future without modifying the function signature.
>> >> * Allows for simpler static initialization of clocks on all platforms
>> by
>> >> removing the need for forward delcarations.
>> >> * Halves the number of symbols added for each static clock
>> >> initialization.
>> >>
>> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> >
>> > I agree this is a reasonable move. But while you simplify the
>> interface
>> > of clk_register(), why not making a further step to simplify the
>> > following interfaces simple too?
>> >
>> > 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 *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 *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 *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);
>>
>> If you simplify those functions further. They would just become
>> clk_register(). I'm not sure I see a value in them in at that point or
>> even in their current form. But if others see (I'm guessing since they
>> acked or didn't nack it), I'm not going to ask to remove them. If
>> everyone
>> agrees that we should just remove them, I would be glad to.
>>
>> It's arguable that these functions for the common hardware types saves
>> the
>> need to deal with the kalloc in every platform driver. But it's not
>> clear
>> to me where they would get these parameters in the first place. Most
>> likely form some sort of static array. At which point, it might as well
>> be
>> a static array of pointers to clk_gated.hw, clk_fixed_rate.hw, etc
>> instead
>> of a platform specific struct to hold these initializers.
>
> I am using these functions and don't need a static array, I just call
> the functions with the desired parameters.
Sure, then let's leave it in. Curious, where do you get the desired
parameters from? Is it static date in code or is it from DT? You somehow
probe it?
> Overall the clock framework was written in a way that we have to expose
> as little information about the internally used structs as necessary. It
> seems your patches are pulling in the opposite direction now.
I'm not exposing anything that you don't already pass from the platform
driver. Also, you realize that this is very similar to what you suggested
with clk_initializer right? If there is a strong push, we can make a copy
of these inside the struct clk, but for these few init fields I don't see
a point (see earlier email).
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-16 6:11 ` Mike Turquette
@ 2012-03-20 14:02 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 14:02 UTC (permalink / raw)
To: Mike Turquette
Cc: Russell King, Paul Walmsley, Linus Walleij, patches,
Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Saravana Kannan, linaro-dev, Jeremy Kerr,
Arnd Bergman, linux-arm-kernel
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);
> +};
--
Regards,
Shawn
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-20 14:02 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 14:02 UTC (permalink / raw)
To: linux-arm-kernel
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);
> +};
--
Regards,
Shawn
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 9:40 ` Sascha Hauer
@ 2012-03-20 14:18 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 14:18 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
...
> I am using these functions and don't need a static array, I just call
> the functions with the desired parameters.
>
With this patch getting in, you do not have to use them then. I feel
a static array will be much more readable than a long list of function
calls with a long list of hardcoded arguments to each.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 14:18 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-20 14:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
...
> I am using these functions and don't need a static array, I just call
> the functions with the desired parameters.
>
With this patch getting in, you do not have to use them then. I feel
a static array will be much more readable than a long list of function
calls with a long list of hardcoded arguments to each.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-20 14:02 ` Shawn Guo
@ 2012-03-20 17:46 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 17:46 UTC (permalink / raw)
To: Shawn Guo
Cc: Mike Turquette, Russell King, Paul Walmsley, Linus Walleij,
patches, Stephen Boyd, Sascha Hauer, Mark Brown, Magnus Damm,
linux-kernel, Saravana Kannan, linaro-dev, Jeremy Kerr,
Arnd Bergman, linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-20 17:46 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 17:46 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 14:18 ` Shawn Guo
@ 2012-03-20 18:10 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 18:10 UTC (permalink / raw)
To: Shawn Guo
Cc: Saravana Kannan, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
> ...
> > I am using these functions and don't need a static array, I just call
> > the functions with the desired parameters.
> >
> With this patch getting in, you do not have to use them then. I feel
> a static array will be much more readable than a long list of function
> calls with a long list of hardcoded arguments to each.
I'm also not a fan of long argument lists; a divider like defined in my
tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
border I think it's still acceptable.
What I like in terms of readability is one line per clock which makes
for quite short clock files.
So when we use structs to initialize the clocks we'll probably have
something like this:
static struct clk_divider somediv = {
.reg = CCM_BASE + 0x14,
.width = 3,
.shift = 17,
.lock = &ccm_lock,
.hw.parent = "someotherdiv",
.hw.flags = CLK_SET_RATE_PARENT,
};
This will make a 4000 line file out of a 500 line file. Now when for
some reason struct clk_divider changes we end with big patches. If the
clk core gets a new fancy CLK_ flag which we want to have then again
we end up with big patches. Then there's also the possibility that
someone finds out that .lock and .hw.flags are common to all dividers
and comes up with a #define DEFINE_CLK_DIVIDER again to share common
fields.
All this can be solved when we introduce a small wrapper function and
use it in the clock files:
static inline struct clk *imx_clk_divider(const char *name, const char *parent,
void __iomem *reg, u8 shift, u8 width)
{
return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
reg, shift, width, 0, &imx_ccm_lock);
}
It decouples us from the structs used by the clock framework, we can
add our preferred flags and still can share common fields like the lock.
While this was not the intention when I first converted from struct
initializers to function initializers I am confident that it will make
a good job.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 18:10 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 18:10 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
> ...
> > I am using these functions and don't need a static array, I just call
> > the functions with the desired parameters.
> >
> With this patch getting in, you do not have to use them then. I feel
> a static array will be much more readable than a long list of function
> calls with a long list of hardcoded arguments to each.
I'm also not a fan of long argument lists; a divider like defined in my
tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
border I think it's still acceptable.
What I like in terms of readability is one line per clock which makes
for quite short clock files.
So when we use structs to initialize the clocks we'll probably have
something like this:
static struct clk_divider somediv = {
.reg = CCM_BASE + 0x14,
.width = 3,
.shift = 17,
.lock = &ccm_lock,
.hw.parent = "someotherdiv",
.hw.flags = CLK_SET_RATE_PARENT,
};
This will make a 4000 line file out of a 500 line file. Now when for
some reason struct clk_divider changes we end with big patches. If the
clk core gets a new fancy CLK_ flag which we want to have then again
we end up with big patches. Then there's also the possibility that
someone finds out that .lock and .hw.flags are common to all dividers
and comes up with a #define DEFINE_CLK_DIVIDER again to share common
fields.
All this can be solved when we introduce a small wrapper function and
use it in the clock files:
static inline struct clk *imx_clk_divider(const char *name, const char *parent,
void __iomem *reg, u8 shift, u8 width)
{
return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
reg, shift, width, 0, &imx_ccm_lock);
}
It decouples us from the structs used by the clock framework, we can
add our preferred flags and still can share common fields like the lock.
While this was not the intention when I first converted from struct
initializers to function initializers I am confident that it will make
a good job.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 10:17 ` Saravana Kannan
@ 2012-03-20 18:14 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 18:14 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 03:17:10AM -0700, Saravana Kannan wrote:
>
> On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> > On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
> >>
> > I am using these functions and don't need a static array, I just call
> > the functions with the desired parameters.
>
> Sure, then let's leave it in. Curious, where do you get the desired
> parameters from? Is it static date in code or is it from DT? You somehow
> probe it?
It's not from DT. See this thread:
http://www.spinics.net/lists/arm-kernel/msg165839.html
>
> > Overall the clock framework was written in a way that we have to expose
> > as little information about the internally used structs as necessary. It
> > seems your patches are pulling in the opposite direction now.
>
> I'm not exposing anything that you don't already pass from the platform
> driver. Also, you realize that this is very similar to what you suggested
> with clk_initializer right? If there is a strong push, we can make a copy
> of these inside the struct clk, but for these few init fields I don't see
> a point (see earlier email).
The difference is that a struct clk_initializer is only used to
initialize a clock and not actively used by the clock framework. But as
you already mentioned using a copy inside the clock framework has the
same effect.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 18:14 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 18:14 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 03:17:10AM -0700, Saravana Kannan wrote:
>
> On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> > On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
> >>
> > I am using these functions and don't need a static array, I just call
> > the functions with the desired parameters.
>
> Sure, then let's leave it in. Curious, where do you get the desired
> parameters from? Is it static date in code or is it from DT? You somehow
> probe it?
It's not from DT. See this thread:
http://www.spinics.net/lists/arm-kernel/msg165839.html
>
> > Overall the clock framework was written in a way that we have to expose
> > as little information about the internally used structs as necessary. It
> > seems your patches are pulling in the opposite direction now.
>
> I'm not exposing anything that you don't already pass from the platform
> driver. Also, you realize that this is very similar to what you suggested
> with clk_initializer right? If there is a strong push, we can make a copy
> of these inside the struct clk, but for these few init fields I don't see
> a point (see earlier email).
The difference is that a struct clk_initializer is only used to
initialize a clock and not actively used by the clock framework. But as
you already mentioned using a copy inside the clock framework has the
same effect.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 18:10 ` Sascha Hauer
@ 2012-03-20 20:06 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 20:06 UTC (permalink / raw)
To: Sascha Hauer
Cc: Shawn Guo, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On 03/20/2012 11:10 AM, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>> ...
>>> I am using these functions and don't need a static array, I just call
>>> the functions with the desired parameters.
>>>
>> With this patch getting in, you do not have to use them then. I feel
>> a static array will be much more readable than a long list of function
>> calls with a long list of hardcoded arguments to each.
>
> I'm also not a fan of long argument lists; a divider like defined in my
> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
> border I think it's still acceptable.
>
> What I like in terms of readability is one line per clock which makes
> for quite short clock files.
It certainly makes for short clock files, but it's definitely less
readable that the expanded struct. For the original author the "one line
per clock" looks readable since they wrote it. But for someone looking
at the code to modify it, the expanded one would be much easier to read.
Also, you can always declare your own macro if you really want to follow
the one line approach.
> So when we use structs to initialize the clocks we'll probably have
> something like this:
>
> static struct clk_divider somediv = {
> .reg = CCM_BASE + 0x14,
> .width = 3,
> .shift = 17,
> .lock =&ccm_lock,
> .hw.parent = "someotherdiv",
> .hw.flags = CLK_SET_RATE_PARENT,
> };
Taken from your patches:
imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
ARRAY_SIZE(spll_sel_clks));
Compare the struct to the one line call. Now tell me, what does "1"
represent? No clue. But in the struct, I can immediately tell what each
one of the parameters are.
Anyway, my patch certainly isn't forcing you to use multiple lines. So,
hopefully this won't be a point of contention.
> This will make a 4000 line file out of a 500 line file. Now when for
> some reason struct clk_divider changes we end with big patches. If the
> clk core gets a new fancy CLK_ flag which we want to have then again
> we end up with big patches. Then there's also the possibility that
> someone finds out that .lock and .hw.flags are common to all dividers
> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> fields.
This patch won't prevent you from doing any of that. You can still
create macros for that (there are already one for that). Also, what you
are pointing out is a bigger problem for the current clk_register()
function since you might have to change the no. of params of all the
callers even if a new field is optional.
> All this can be solved when we introduce a small wrapper function and
> use it in the clock files:
>
> static inline struct clk *imx_clk_divider(const char *name, const char *parent,
> void __iomem *reg, u8 shift, u8 width)
> {
> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
> reg, shift, width, 0,&imx_ccm_lock);
> }
>
> It decouples us from the structs used by the clock framework, we can
> add our preferred flags and still can share common fields like the lock.
>
> While this was not the intention when I first converted from struct
> initializers to function initializers I am confident that it will make
> a good job.
Now I'm confused -- it's not clear if you are leaning towards my patch
or away from it?
I also think we are talking about issues orthogonal to my patch. I don't
think my patch prevents you from doing any of this as long as you are up
for wrapper fns or macros.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 20:06 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 20:06 UTC (permalink / raw)
To: linux-arm-kernel
On 03/20/2012 11:10 AM, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>> ...
>>> I am using these functions and don't need a static array, I just call
>>> the functions with the desired parameters.
>>>
>> With this patch getting in, you do not have to use them then. I feel
>> a static array will be much more readable than a long list of function
>> calls with a long list of hardcoded arguments to each.
>
> I'm also not a fan of long argument lists; a divider like defined in my
> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
> border I think it's still acceptable.
>
> What I like in terms of readability is one line per clock which makes
> for quite short clock files.
It certainly makes for short clock files, but it's definitely less
readable that the expanded struct. For the original author the "one line
per clock" looks readable since they wrote it. But for someone looking
at the code to modify it, the expanded one would be much easier to read.
Also, you can always declare your own macro if you really want to follow
the one line approach.
> So when we use structs to initialize the clocks we'll probably have
> something like this:
>
> static struct clk_divider somediv = {
> .reg = CCM_BASE + 0x14,
> .width = 3,
> .shift = 17,
> .lock =&ccm_lock,
> .hw.parent = "someotherdiv",
> .hw.flags = CLK_SET_RATE_PARENT,
> };
Taken from your patches:
imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
ARRAY_SIZE(spll_sel_clks));
Compare the struct to the one line call. Now tell me, what does "1"
represent? No clue. But in the struct, I can immediately tell what each
one of the parameters are.
Anyway, my patch certainly isn't forcing you to use multiple lines. So,
hopefully this won't be a point of contention.
> This will make a 4000 line file out of a 500 line file. Now when for
> some reason struct clk_divider changes we end with big patches. If the
> clk core gets a new fancy CLK_ flag which we want to have then again
> we end up with big patches. Then there's also the possibility that
> someone finds out that .lock and .hw.flags are common to all dividers
> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> fields.
This patch won't prevent you from doing any of that. You can still
create macros for that (there are already one for that). Also, what you
are pointing out is a bigger problem for the current clk_register()
function since you might have to change the no. of params of all the
callers even if a new field is optional.
> All this can be solved when we introduce a small wrapper function and
> use it in the clock files:
>
> static inline struct clk *imx_clk_divider(const char *name, const char *parent,
> void __iomem *reg, u8 shift, u8 width)
> {
> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
> reg, shift, width, 0,&imx_ccm_lock);
> }
>
> It decouples us from the structs used by the clock framework, we can
> add our preferred flags and still can share common fields like the lock.
>
> While this was not the intention when I first converted from struct
> initializers to function initializers I am confident that it will make
> a good job.
Now I'm confused -- it's not clear if you are leaning towards my patch
or away from it?
I also think we are talking about issues orthogonal to my patch. I don't
think my patch prevents you from doing any of this as long as you are up
for wrapper fns or macros.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 18:14 ` Sascha Hauer
@ 2012-03-20 20:14 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 20:14 UTC (permalink / raw)
To: Sascha Hauer
Cc: Shawn Guo, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On 03/20/2012 11:14 AM, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 03:17:10AM -0700, Saravana Kannan wrote:
>>
>> On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
>>> On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>>>>
>>> I am using these functions and don't need a static array, I just call
>>> the functions with the desired parameters.
>>
>> Sure, then let's leave it in. Curious, where do you get the desired
>> parameters from? Is it static date in code or is it from DT? You somehow
>> probe it?
>
> It's not from DT. See this thread:
>
> http://www.spinics.net/lists/arm-kernel/msg165839.html
Ah, I see. That's a lot of functions calls. I think it would be much
more efficient if you just have an array and loop over it. With my
patch, you can just call a single register function for all these clocks.
>>
>>> Overall the clock framework was written in a way that we have to expose
>>> as little information about the internally used structs as necessary. It
>>> seems your patches are pulling in the opposite direction now.
>>
>> I'm not exposing anything that you don't already pass from the platform
>> driver. Also, you realize that this is very similar to what you suggested
>> with clk_initializer right? If there is a strong push, we can make a copy
>> of these inside the struct clk, but for these few init fields I don't see
>> a point (see earlier email).
>
> The difference is that a struct clk_initializer is only used to
> initialize a clock and not actively used by the clock framework. But as
> you already mentioned using a copy inside the clock framework has the
> same effect.
My opinion on this is to follow a wait and watch approach on the "flags"
field. I really can't think of a safe way anyone can misuse it. If
people start doing that, we can just do the copy and let them deal with
their broken code. Until that happens, I don't want to waste time/space
by copying it. The rest of the fields aren't actively used by the common
clock code after init.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 20:14 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-20 20:14 UTC (permalink / raw)
To: linux-arm-kernel
On 03/20/2012 11:14 AM, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 03:17:10AM -0700, Saravana Kannan wrote:
>>
>> On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
>>> On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
>>>>
>>> I am using these functions and don't need a static array, I just call
>>> the functions with the desired parameters.
>>
>> Sure, then let's leave it in. Curious, where do you get the desired
>> parameters from? Is it static date in code or is it from DT? You somehow
>> probe it?
>
> It's not from DT. See this thread:
>
> http://www.spinics.net/lists/arm-kernel/msg165839.html
Ah, I see. That's a lot of functions calls. I think it would be much
more efficient if you just have an array and loop over it. With my
patch, you can just call a single register function for all these clocks.
>>
>>> Overall the clock framework was written in a way that we have to expose
>>> as little information about the internally used structs as necessary. It
>>> seems your patches are pulling in the opposite direction now.
>>
>> I'm not exposing anything that you don't already pass from the platform
>> driver. Also, you realize that this is very similar to what you suggested
>> with clk_initializer right? If there is a strong push, we can make a copy
>> of these inside the struct clk, but for these few init fields I don't see
>> a point (see earlier email).
>
> The difference is that a struct clk_initializer is only used to
> initialize a clock and not actively used by the clock framework. But as
> you already mentioned using a copy inside the clock framework has the
> same effect.
My opinion on this is to follow a wait and watch approach on the "flags"
field. I really can't think of a safe way anyone can misuse it. If
people start doing that, we can just do the copy and let them deal with
their broken code. Until that happens, I don't want to waste time/space
by copying it. The rest of the fields aren't actively used by the common
clock code after init.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 20:14 ` Saravana Kannan
@ 2012-03-20 22:40 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 22:40 UTC (permalink / raw)
To: Saravana Kannan
Cc: Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Mike Turquette, Magnus Damm, Deepak Saxena, linux-arm-kernel,
Arnd Bergman, linux-arm-msm, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Paul Walmsley,
Linus Walleij, Mark Brown, Stephen Boyd, linux-kernel,
Amit Kucheria, Shawn Guo
On Tue, Mar 20, 2012 at 01:14:51PM -0700, Saravana Kannan wrote:
> On 03/20/2012 11:14 AM, Sascha Hauer wrote:
> >On Tue, Mar 20, 2012 at 03:17:10AM -0700, Saravana Kannan wrote:
> >>
> >>On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> >>>On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
> >>>>
> >>>I am using these functions and don't need a static array, I just call
> >>>the functions with the desired parameters.
> >>
> >>Sure, then let's leave it in. Curious, where do you get the desired
> >>parameters from? Is it static date in code or is it from DT? You somehow
> >>probe it?
> >
> >It's not from DT. See this thread:
> >
> >http://www.spinics.net/lists/arm-kernel/msg165839.html
>
> Ah, I see. That's a lot of functions calls. I think it would be much
> more efficient if you just have an array and loop over it. With my
> patch, you can just call a single register function for all these
> clocks.
I was curious and gave it a try. I registered a fixed clock and 100
gates as child clocks. I tried both DEFINE_CLK_GATE and
clk_register_gate. It turned out there was no difference in speed.
>
> >
> >The difference is that a struct clk_initializer is only used to
> >initialize a clock and not actively used by the clock framework. But as
> >you already mentioned using a copy inside the clock framework has the
> >same effect.
>
> My opinion on this is to follow a wait and watch approach on the
> "flags" field. I really can't think of a safe way anyone can misuse
> it. If people start doing that, we can just do the copy and let them
> deal with their broken code. Until that happens, I don't want to
> waste time/space by copying it. The rest of the fields aren't
> actively used by the common clock code after init.
Actually you will save space by copying it because you can put the
initializers in __initdata and throw the initializers of unused SoCs
compiled into the kernel away during runtime.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 22:40 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 22:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 01:14:51PM -0700, Saravana Kannan wrote:
> On 03/20/2012 11:14 AM, Sascha Hauer wrote:
> >On Tue, Mar 20, 2012 at 03:17:10AM -0700, Saravana Kannan wrote:
> >>
> >>On Tue, March 20, 2012 2:40 am, Sascha Hauer wrote:
> >>>On Tue, Mar 20, 2012 at 12:54:55AM -0700, Saravana Kannan wrote:
> >>>>
> >>>I am using these functions and don't need a static array, I just call
> >>>the functions with the desired parameters.
> >>
> >>Sure, then let's leave it in. Curious, where do you get the desired
> >>parameters from? Is it static date in code or is it from DT? You somehow
> >>probe it?
> >
> >It's not from DT. See this thread:
> >
> >http://www.spinics.net/lists/arm-kernel/msg165839.html
>
> Ah, I see. That's a lot of functions calls. I think it would be much
> more efficient if you just have an array and loop over it. With my
> patch, you can just call a single register function for all these
> clocks.
I was curious and gave it a try. I registered a fixed clock and 100
gates as child clocks. I tried both DEFINE_CLK_GATE and
clk_register_gate. It turned out there was no difference in speed.
>
> >
> >The difference is that a struct clk_initializer is only used to
> >initialize a clock and not actively used by the clock framework. But as
> >you already mentioned using a copy inside the clock framework has the
> >same effect.
>
> My opinion on this is to follow a wait and watch approach on the
> "flags" field. I really can't think of a safe way anyone can misuse
> it. If people start doing that, we can just do the copy and let them
> deal with their broken code. Until that happens, I don't want to
> waste time/space by copying it. The rest of the fields aren't
> actively used by the common clock code after init.
Actually you will save space by copying it because you can put the
initializers in __initdata and throw the initializers of unused SoCs
compiled into the kernel away during runtime.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 20:06 ` Saravana Kannan
@ 2012-03-20 23:12 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 23:12 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Mike Turquette, Arnd Bergman, linux-arm-kernel,
linux-kernel, linux-arm-msm, Andrew Lunn, Rob Herring,
Russell King, Jeremy Kerr, Thomas Gleixner, Paul Walmsley,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
> >On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
> >>On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
> >>...
> >>>I am using these functions and don't need a static array, I just call
> >>>the functions with the desired parameters.
> >>>
> >>With this patch getting in, you do not have to use them then. I feel
> >>a static array will be much more readable than a long list of function
> >>calls with a long list of hardcoded arguments to each.
> >
> >I'm also not a fan of long argument lists; a divider like defined in my
> >tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
> >border I think it's still acceptable.
> >
> >What I like in terms of readability is one line per clock which makes
> >for quite short clock files.
>
> It certainly makes for short clock files, but it's definitely less
> readable that the expanded struct. For the original author the "one
> line per clock" looks readable since they wrote it. But for someone
> looking at the code to modify it, the expanded one would be much
> easier to read. Also, you can always declare your own macro if you
> really want to follow the one line approach.
>
> >So when we use structs to initialize the clocks we'll probably have
> >something like this:
> >
> >static struct clk_divider somediv = {
> > .reg = CCM_BASE + 0x14,
> > .width = 3,
> > .shift = 17,
> > .lock =&ccm_lock,
> > .hw.parent = "someotherdiv",
> > .hw.flags = CLK_SET_RATE_PARENT,
> >};
>
> Taken from your patches:
>
> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
> ARRAY_SIZE(spll_sel_clks));
>
> Compare the struct to the one line call. Now tell me, what does "1"
> represent? No clue. But in the struct, I can immediately tell what
> each one of the parameters are.
>
> Anyway, my patch certainly isn't forcing you to use multiple lines.
> So, hopefully this won't be a point of contention.
>
> >This will make a 4000 line file out of a 500 line file. Now when for
> >some reason struct clk_divider changes we end with big patches. If the
> >clk core gets a new fancy CLK_ flag which we want to have then again
> >we end up with big patches. Then there's also the possibility that
> >someone finds out that .lock and .hw.flags are common to all dividers
> >and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> >fields.
>
> This patch won't prevent you from doing any of that. You can still
> create macros for that (there are already one for that). Also, what
> you are pointing out is a bigger problem for the current
> clk_register() function since you might have to change the no. of
> params of all the callers even if a new field is optional.
>
> >All this can be solved when we introduce a small wrapper function and
> >use it in the clock files:
> >
> >static inline struct clk *imx_clk_divider(const char *name, const char *parent,
> > void __iomem *reg, u8 shift, u8 width)
> >{
> > return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
> > reg, shift, width, 0,&imx_ccm_lock);
> >}
> >
> >It decouples us from the structs used by the clock framework, we can
> >add our preferred flags and still can share common fields like the lock.
> >
> >While this was not the intention when I first converted from struct
> >initializers to function initializers I am confident that it will make
> >a good job.
>
> Now I'm confused -- it's not clear if you are leaning towards my
> patch or away from it?
There was a tendency to get rid of static initializers and I like the
idea of not exposing any of the internally used members outside the
clock framework.
Now people try their best to make themselves comfortable with the
static initializers and you even discussed the possibility of removing
the clk_register_* functions (which make it possible for users not
to use any of the internal struct members). That's what I don't like
about your patches. But if we go for static initializers anyway then your
patches probably change things for the better.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 23:12 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
> >On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
> >>On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
> >>...
> >>>I am using these functions and don't need a static array, I just call
> >>>the functions with the desired parameters.
> >>>
> >>With this patch getting in, you do not have to use them then. I feel
> >>a static array will be much more readable than a long list of function
> >>calls with a long list of hardcoded arguments to each.
> >
> >I'm also not a fan of long argument lists; a divider like defined in my
> >tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
> >border I think it's still acceptable.
> >
> >What I like in terms of readability is one line per clock which makes
> >for quite short clock files.
>
> It certainly makes for short clock files, but it's definitely less
> readable that the expanded struct. For the original author the "one
> line per clock" looks readable since they wrote it. But for someone
> looking at the code to modify it, the expanded one would be much
> easier to read. Also, you can always declare your own macro if you
> really want to follow the one line approach.
>
> >So when we use structs to initialize the clocks we'll probably have
> >something like this:
> >
> >static struct clk_divider somediv = {
> > .reg = CCM_BASE + 0x14,
> > .width = 3,
> > .shift = 17,
> > .lock =&ccm_lock,
> > .hw.parent = "someotherdiv",
> > .hw.flags = CLK_SET_RATE_PARENT,
> >};
>
> Taken from your patches:
>
> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
> ARRAY_SIZE(spll_sel_clks));
>
> Compare the struct to the one line call. Now tell me, what does "1"
> represent? No clue. But in the struct, I can immediately tell what
> each one of the parameters are.
>
> Anyway, my patch certainly isn't forcing you to use multiple lines.
> So, hopefully this won't be a point of contention.
>
> >This will make a 4000 line file out of a 500 line file. Now when for
> >some reason struct clk_divider changes we end with big patches. If the
> >clk core gets a new fancy CLK_ flag which we want to have then again
> >we end up with big patches. Then there's also the possibility that
> >someone finds out that .lock and .hw.flags are common to all dividers
> >and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> >fields.
>
> This patch won't prevent you from doing any of that. You can still
> create macros for that (there are already one for that). Also, what
> you are pointing out is a bigger problem for the current
> clk_register() function since you might have to change the no. of
> params of all the callers even if a new field is optional.
>
> >All this can be solved when we introduce a small wrapper function and
> >use it in the clock files:
> >
> >static inline struct clk *imx_clk_divider(const char *name, const char *parent,
> > void __iomem *reg, u8 shift, u8 width)
> >{
> > return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
> > reg, shift, width, 0,&imx_ccm_lock);
> >}
> >
> >It decouples us from the structs used by the clock framework, we can
> >add our preferred flags and still can share common fields like the lock.
> >
> >While this was not the intention when I first converted from struct
> >initializers to function initializers I am confident that it will make
> >a good job.
>
> Now I'm confused -- it's not clear if you are leaning towards my
> patch or away from it?
There was a tendency to get rid of static initializers and I like the
idea of not exposing any of the internally used members outside the
clock framework.
Now people try their best to make themselves comfortable with the
static initializers and you even discussed the possibility of removing
the clk_register_* functions (which make it possible for users not
to use any of the internal struct members). That's what I don't like
about your patches. But if we go for static initializers anyway then your
patches probably change things for the better.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-16 23:47 ` Sascha Hauer
(?)
@ 2012-03-20 23:31 ` Paul Walmsley
-1 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:31 UTC (permalink / raw)
To: Sascha Hauer
Cc: Arnd Bergmann, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-20 23:31 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:31 UTC (permalink / raw)
To: Sascha Hauer
Cc: Arnd Bergmann, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-20 23:31 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:31 UTC (permalink / raw)
To: linux-arm-kernel
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-17 9:05 ` Arnd Bergmann
@ 2012-03-20 23:40 ` Paul Walmsley
-1 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Turquette, Mike, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-20 23:40 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:40 UTC (permalink / raw)
To: linux-arm-kernel
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
--
1.7.9.1
^ permalink raw reply related [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-20 14:02 ` Shawn Guo
@ 2012-03-20 23:46 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-20 23:46 UTC (permalink / raw)
To: Shawn Guo
Cc: Paul Walmsley, Russell King, Linus Walleij, patches, Magnus Damm,
Sascha Hauer, Mark Brown, Stephen Boyd, linux-kernel,
Saravana Kannan, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-20 23:46 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-20 23:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 18:10 ` Sascha Hauer
@ 2012-03-20 23:47 ` Paul Walmsley
-1 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:47 UTC (permalink / raw)
To: Sascha Hauer
Cc: Shawn Guo, Saravana Kannan, Mike Turquette, Arnd Bergman,
linux-arm-kernel, linux-kernel, linux-arm-msm, Andrew Lunn,
Rob Herring, Russell King, Jeremy Kerr, Thomas Gleixner,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
Hello Sascha
On Tue, 20 Mar 2012, Sascha Hauer wrote:
> [ C99 structure initializer elided ]
>
> This will make a 4000 line file out of a 500 line file. Now when for
> some reason struct clk_divider changes we end with big patches. If the
> clk core gets a new fancy CLK_ flag which we want to have then again
> we end up with big patches. Then there's also the possibility that
> someone finds out that .lock and .hw.flags are common to all dividers
> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> fields.
At least we can understand easily what is being changed. Readability,
particularly by others not familiar with the clock data, is more important
to me.
So like Saravana, I too prefer C99 structure initializers. At least there
should be a choice.
Quick quiz: in this line below:
imx_clk_divider("foo_clk", "bar_clk", CCM_BASE + 0x20, 0x5, 0x3);
which field is the bitfield shift and which is the bitfield width? :-)
- Paul
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-20 23:47 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-20 23:47 UTC (permalink / raw)
To: linux-arm-kernel
Hello Sascha
On Tue, 20 Mar 2012, Sascha Hauer wrote:
> [ C99 structure initializer elided ]
>
> This will make a 4000 line file out of a 500 line file. Now when for
> some reason struct clk_divider changes we end with big patches. If the
> clk core gets a new fancy CLK_ flag which we want to have then again
> we end up with big patches. Then there's also the possibility that
> someone finds out that .lock and .hw.flags are common to all dividers
> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> fields.
At least we can understand easily what is being changed. Readability,
particularly by others not familiar with the clock data, is more important
to me.
So like Saravana, I too prefer C99 structure initializers. At least there
should be a choice.
Quick quiz: in this line below:
imx_clk_divider("foo_clk", "bar_clk", CCM_BASE + 0x20, 0x5, 0x3);
which field is the bitfield shift and which is the bitfield width? :-)
- Paul
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-20 17:46 ` Saravana Kannan
@ 2012-03-20 23:53 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-20 23:53 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-20 23:53 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-20 23:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-20 7:46 ` Saravana Kannan
@ 2012-03-21 0:13 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 0:13 UTC (permalink / raw)
To: Saravana Kannan
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria
On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>>> If memory allocation for the parents array or the parent string fails,
>>> then
>>> fail the registration immediately instead of calling clk_register and
>>> hoping it fails there.
>>>
>>> Return -ENOMEM on failure.
>>>
>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>> Cc: Mike Turquette <mturquette@linaro.org>
>>> Cc: Andrew Lunn <andrew@lunn.ch>
>>> Cc: 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>
>>> ---
>>> There are still some memory free issues when clk_register() fails, but I
>>> will
>>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>>> failure instead of a NULL.
>>>
>>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>>> index 90c79fb..6423ae9 100644
>>> --- a/drivers/clk/clk-fixed-rate.c
>>> +++ b/drivers/clk/clk-fixed-rate.c
>>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>>> *dev, const char *name,
>>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>>
>>> if (! parent_names)
>>> - goto out;
>>> + goto fail_ptr;
>>>
>>> len = sizeof(char) * strlen(parent_name);
>>>
>>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>>
>>> if (!parent_names[0])
>>> - goto out;
>>> + goto fail_str;
>>>
>>> strncpy(parent_names[0], parent_name, len);
>>> }
>>
>> It's easier to add a char *parent to struct clk_fixed and pass it to
>> clk_register with &fixed->parent. This saves you a kmalloc call and
>> makes the error path simpler. It's the same way already done in the
>> divider.
I thought I had done this for v7... hmm looks like one got left out.
I'll line up a patch to get it in sync with the others as part of my
fixes.
> I thought about that since I saw the same was done for gated and divider
> (I think). Here is my guess at Mike's reasoning for this:
>
> Gated and divider clocks have to have a parent. There's nothing to gate
> otherwise. But fixed rate clocks might not have a parent. It could be XO's
> or PLLs running off of always on XOs not controlled by the SoC. So, it's
> arguable to not have a parent. I don't have a strong opinion on this --
> since Mike took the time to write it, it left it to his subjective
> preference.
I appreciate the thoughtfulness. Re-using the same type of mechanism
as the divider and gate clocks will still allow the fixed-rate clock
to be parentless, and it makes for cleaner code, one less allocation
and lines up with how the other single-parent basic clocks are done,
so I'll take that method in instead of your patch.
> I sent this patch first since it was around the place I was cleaning up. I
> didn't want to actually just shuffle around a bug. As I mentioned, this
> patch still leaves a bug open -- what if clk_register() fails. I plan to
> fix that once my two patches are picked up (hopefully).
Do you still find it useful to return -ENOMEM from the registration
function instead of a NULL clock? I'm always worried that people
don't check for error codes on pointers in their platform code and
only check for NULL...
Regards,
Mike
> Thanks,
> Saravana
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 0:13 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 0:13 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>>> If memory allocation for the parents array or the parent string fails,
>>> then
>>> fail the registration immediately instead of calling clk_register and
>>> hoping it fails there.
>>>
>>> Return -ENOMEM on failure.
>>>
>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>> Cc: Mike Turquette <mturquette@linaro.org>
>>> Cc: Andrew Lunn <andrew@lunn.ch>
>>> Cc: 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>
>>> ---
>>> There are still some memory free issues when clk_register() fails, but I
>>> will
>>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>>> failure instead of a NULL.
>>>
>>> ?drivers/clk/clk-fixed-rate.c | ? 10 +++++++---
>>> ?1 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>>> index 90c79fb..6423ae9 100644
>>> --- a/drivers/clk/clk-fixed-rate.c
>>> +++ b/drivers/clk/clk-fixed-rate.c
>>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>>> *dev, const char *name,
>>> ? ? ? ? ? ? ?parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>>
>>> ? ? ? ? ? ? ?if (! parent_names)
>>> - ? ? ? ? ? ? ? ? ? ?goto out;
>>> + ? ? ? ? ? ? ? ? ? ?goto fail_ptr;
>>>
>>> ? ? ? ? ? ? ?len = sizeof(char) * strlen(parent_name);
>>>
>>> ? ? ? ? ? ? ?parent_names[0] = kmalloc(len, GFP_KERNEL);
>>>
>>> ? ? ? ? ? ? ?if (!parent_names[0])
>>> - ? ? ? ? ? ? ? ? ? ?goto out;
>>> + ? ? ? ? ? ? ? ? ? ?goto fail_str;
>>>
>>> ? ? ? ? ? ? ?strncpy(parent_names[0], parent_name, len);
>>> ? ? ?}
>>
>> It's easier to add a char *parent to struct clk_fixed and pass it to
>> clk_register with &fixed->parent. This saves you a kmalloc call and
>> makes the error path simpler. It's the same way already done in the
>> divider.
I thought I had done this for v7... hmm looks like one got left out.
I'll line up a patch to get it in sync with the others as part of my
fixes.
> I thought about that since I saw the same was done for gated and divider
> (I think). Here is my guess at Mike's reasoning for this:
>
> Gated and divider clocks have to have a parent. There's nothing to gate
> otherwise. But fixed rate clocks might not have a parent. It could be XO's
> or PLLs running off of always on XOs not controlled by the SoC. So, it's
> arguable to not have a parent. I don't have a strong opinion on this --
> since Mike took the time to write it, it left it to his subjective
> preference.
I appreciate the thoughtfulness. Re-using the same type of mechanism
as the divider and gate clocks will still allow the fixed-rate clock
to be parentless, and it makes for cleaner code, one less allocation
and lines up with how the other single-parent basic clocks are done,
so I'll take that method in instead of your patch.
> I sent this patch first since it was around the place I was cleaning up. I
> didn't want to actually just shuffle around a bug. As I mentioned, this
> patch still leaves a bug open -- what if clk_register() fails. I plan to
> fix that once my two patches are picked up (hopefully).
Do you still find it useful to return -ENOMEM from the registration
function instead of a NULL clock? I'm always worried that people
don't check for error codes on pointers in their platform code and
only check for NULL...
Regards,
Mike
> Thanks,
> Saravana
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 23:12 ` Sascha Hauer
@ 2012-03-21 1:47 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 1:47 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Andrew Lunn, Grant Likely, Jamie Iles,
Jeremy Kerr, Magnus Damm, Deepak Saxena, linux-arm-kernel,
Arnd Bergman, linux-arm-msm, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Paul Walmsley,
Linus Walleij, Mark Brown, Stephen Boyd, linux-kernel,
Amit Kucheria, Shawn Guo
On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>> >On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>> >>On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>> >>...
>> >>>I am using these functions and don't need a static array, I just call
>> >>>the functions with the desired parameters.
>> >>>
>> >>With this patch getting in, you do not have to use them then. I feel
>> >>a static array will be much more readable than a long list of function
>> >>calls with a long list of hardcoded arguments to each.
>> >
>> >I'm also not a fan of long argument lists; a divider like defined in my
>> >tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
>> >border I think it's still acceptable.
>> >
>> >What I like in terms of readability is one line per clock which makes
>> >for quite short clock files.
>>
>> It certainly makes for short clock files, but it's definitely less
>> readable that the expanded struct. For the original author the "one
>> line per clock" looks readable since they wrote it. But for someone
>> looking at the code to modify it, the expanded one would be much
>> easier to read. Also, you can always declare your own macro if you
>> really want to follow the one line approach.
>>
>> >So when we use structs to initialize the clocks we'll probably have
>> >something like this:
>> >
>> >static struct clk_divider somediv = {
>> > .reg = CCM_BASE + 0x14,
>> > .width = 3,
>> > .shift = 17,
>> > .lock =&ccm_lock,
>> > .hw.parent = "someotherdiv",
>> > .hw.flags = CLK_SET_RATE_PARENT,
>> >};
>>
>> Taken from your patches:
>>
>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>> ARRAY_SIZE(spll_sel_clks));
>>
>> Compare the struct to the one line call. Now tell me, what does "1"
>> represent? No clue. But in the struct, I can immediately tell what
>> each one of the parameters are.
>>
>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>> So, hopefully this won't be a point of contention.
>>
>> >This will make a 4000 line file out of a 500 line file. Now when for
>> >some reason struct clk_divider changes we end with big patches. If the
>> >clk core gets a new fancy CLK_ flag which we want to have then again
>> >we end up with big patches. Then there's also the possibility that
>> >someone finds out that .lock and .hw.flags are common to all dividers
>> >and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>> >fields.
>>
>> This patch won't prevent you from doing any of that. You can still
>> create macros for that (there are already one for that). Also, what
>> you are pointing out is a bigger problem for the current
>> clk_register() function since you might have to change the no. of
>> params of all the callers even if a new field is optional.
>>
>> >All this can be solved when we introduce a small wrapper function and
>> >use it in the clock files:
>> >
>> >static inline struct clk *imx_clk_divider(const char *name, const char *parent,
>> > void __iomem *reg, u8 shift, u8 width)
>> >{
>> > return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>> > reg, shift, width, 0,&imx_ccm_lock);
>> >}
>> >
>> >It decouples us from the structs used by the clock framework, we can
>> >add our preferred flags and still can share common fields like the lock.
>> >
>> >While this was not the intention when I first converted from struct
>> >initializers to function initializers I am confident that it will make
>> >a good job.
>>
>> Now I'm confused -- it's not clear if you are leaning towards my
>> patch or away from it?
>
> There was a tendency to get rid of static initializers and I like the
> idea of not exposing any of the internally used members outside the
> clock framework.
I'm with Sascha on this. I feel that dividing the interface strictly
into two halves is the best way. I have an uneasy feeling about
exposing this stuff into struct clk_hw (or clk_initializer or
whatever). This stretches the data out across three structures and
just doesn't feel right to me.
> Now people try their best to make themselves comfortable with the
> static initializers and you even discussed the possibility of removing
> the clk_register_* functions (which make it possible for users not
> to use any of the internal struct members). That's what I don't like
> about your patches. But if we go for static initializers anyway then your
> patches probably change things for the better.
Static initialization is something I have fought for; in fact the
original patches provided no way to do it, so clearly what we have
today is some progress for the folks desiring static init. The patch
above doesn't actually prevent allocation from happening as it still
must call into clk_register and kmalloc struct clk, so besides
readability, I'm not sure what these patches buy us.
Assuming that C99 designated initializers (for the sole purpose of
readability) is the main draw of the above patch, please let me know
what you think about modifying the existing static init macros so that
your clock data looks like this:
DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck, &dpll_iva_x2_ck, "dpll_iva_x2_ck",
.flags = 0x0,
.reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
.shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
.width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
.flags = CLK_DIVIDER_ONE_BASED,
.lock = NULL
);
Note that the first argument is the name of this clock (and will be
properly stringified for .name = "whatever") and that the second and
third arguments are both the parent clock, used for initializing the
parent pointer and .parent_names, respectively. If that aspect of the
macro is too ugly then those can even be broken out into a separate
macro since they are independent data structure (struct clk **parents,
and char **parent_names). Or you could just open code those data
structures and only use a macro for struct clk and struct clk_foo.
This gives you the readability of C99 designated initializers while
keeping struct clk's members totally hidden from the rest of the
world.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-21 1:47 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 1:47 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>> >On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>> >>On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>> >>...
>> >>>I am using these functions and don't need a static array, I just call
>> >>>the functions with the desired parameters.
>> >>>
>> >>With this patch getting in, you do not have to use them then. ?I feel
>> >>a static array will be much more readable than a long list of function
>> >>calls with a long list of hardcoded arguments to each.
>> >
>> >I'm also not a fan of long argument lists; a divider like defined in my
>> >tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
>> >border I think it's still acceptable.
>> >
>> >What I like in terms of readability is one line per clock which makes
>> >for quite short clock files.
>>
>> It certainly makes for short clock files, but it's definitely less
>> readable that the expanded struct. For the original author the "one
>> line per clock" looks readable since they wrote it. But for someone
>> looking at the code to modify it, the expanded one would be much
>> easier to read. Also, you can always declare your own macro if you
>> really want to follow the one line approach.
>>
>> >So when we use structs to initialize the clocks we'll probably have
>> >something like this:
>> >
>> >static struct clk_divider somediv = {
>> > ? ? .reg = CCM_BASE + 0x14,
>> > ? ? .width = 3,
>> > ? ? .shift = 17,
>> > ? ? .lock =&ccm_lock,
>> > ? ? .hw.parent = "someotherdiv",
>> > ? ? .hw.flags = CLK_SET_RATE_PARENT,
>> >};
>>
>> Taken from your patches:
>>
>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>> ARRAY_SIZE(spll_sel_clks));
>>
>> Compare the struct to the one line call. Now tell me, what does "1"
>> represent? No clue. But in the struct, I can immediately tell what
>> each one of the parameters are.
>>
>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>> So, hopefully this won't be a point of contention.
>>
>> >This will make a 4000 line file out of a 500 line file. Now when for
>> >some reason struct clk_divider changes we end with big patches. If the
>> >clk core gets a new fancy CLK_ flag which we want to have then again
>> >we end up with big patches. Then there's also the possibility that
>> >someone finds out that .lock and .hw.flags are common to all dividers
>> >and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>> >fields.
>>
>> This patch won't prevent you from doing any of that. You can still
>> create macros for that (there are already one for that). Also, what
>> you are pointing out is a bigger problem for the current
>> clk_register() function since you might have to change the no. of
>> params of all the callers even if a new field is optional.
>>
>> >All this can be solved when we introduce a small wrapper function and
>> >use it in the clock files:
>> >
>> >static inline struct clk *imx_clk_divider(const char *name, const char *parent,
>> > ? ? ? ? ? ? void __iomem *reg, u8 shift, u8 width)
>> >{
>> > ? ? return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>> > ? ? ? ? ? ? ? ? ? ? reg, shift, width, 0,&imx_ccm_lock);
>> >}
>> >
>> >It decouples us from the structs used by the clock framework, we can
>> >add our preferred flags and still can share common fields like the lock.
>> >
>> >While this was not the intention when I first converted from struct
>> >initializers to function initializers I am confident that it will make
>> >a good job.
>>
>> Now I'm confused -- it's not clear if you are leaning towards my
>> patch or away from it?
>
> There was a tendency to get rid of static initializers and I like the
> idea of not exposing any of the internally used members outside the
> clock framework.
I'm with Sascha on this. I feel that dividing the interface strictly
into two halves is the best way. I have an uneasy feeling about
exposing this stuff into struct clk_hw (or clk_initializer or
whatever). This stretches the data out across three structures and
just doesn't feel right to me.
> Now people try their best to make themselves comfortable with the
> static initializers and you even discussed the possibility of removing
> the clk_register_* functions (which make it possible for users not
> to use any of the internal struct members). That's what I don't like
> about your patches. But if we go for static initializers anyway then your
> patches probably change things for the better.
Static initialization is something I have fought for; in fact the
original patches provided no way to do it, so clearly what we have
today is some progress for the folks desiring static init. The patch
above doesn't actually prevent allocation from happening as it still
must call into clk_register and kmalloc struct clk, so besides
readability, I'm not sure what these patches buy us.
Assuming that C99 designated initializers (for the sole purpose of
readability) is the main draw of the above patch, please let me know
what you think about modifying the existing static init macros so that
your clock data looks like this:
DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck, &dpll_iva_x2_ck, "dpll_iva_x2_ck",
.flags = 0x0,
.reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
.shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
.width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
.flags = CLK_DIVIDER_ONE_BASED,
.lock = NULL
);
Note that the first argument is the name of this clock (and will be
properly stringified for .name = "whatever") and that the second and
third arguments are both the parent clock, used for initializing the
parent pointer and .parent_names, respectively. If that aspect of the
macro is too ugly then those can even be broken out into a separate
macro since they are independent data structure (struct clk **parents,
and char **parent_names). Or you could just open code those data
structures and only use a macro for struct clk and struct clk_foo.
This gives you the readability of C99 designated initializers while
keeping struct clk's members totally hidden from the rest of the
world.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-21 0:13 ` Turquette, Mike
@ 2012-03-21 2:32 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 2:32 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria
On 03/20/2012 05:13 PM, Turquette, Mike wrote:
> On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
> <skannan@codeaurora.org> wrote:
>> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
>>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>>>> If memory allocation for the parents array or the parent string fails,
>>>> then
>>>> fail the registration immediately instead of calling clk_register and
>>>> hoping it fails there.
>>>>
>>>> Return -ENOMEM on failure.
>>>>
>>>> Signed-off-by: Saravana Kannan<skannan@codeaurora.org>
>>>> Cc: Mike Turquette<mturquette@linaro.org>
>>>> Cc: Andrew Lunn<andrew@lunn.ch>
>>>> Cc: 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>
>>>> ---
>>>> There are still some memory free issues when clk_register() fails, but I
>>>> will
>>>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>>>> failure instead of a NULL.
>>>>
>>>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>>>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>>>> index 90c79fb..6423ae9 100644
>>>> --- a/drivers/clk/clk-fixed-rate.c
>>>> +++ b/drivers/clk/clk-fixed-rate.c
>>>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>>>> *dev, const char *name,
>>>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>>>
>>>> if (! parent_names)
>>>> - goto out;
>>>> + goto fail_ptr;
>>>>
>>>> len = sizeof(char) * strlen(parent_name);
>>>>
>>>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>>>
>>>> if (!parent_names[0])
>>>> - goto out;
>>>> + goto fail_str;
>>>>
>>>> strncpy(parent_names[0], parent_name, len);
>>>> }
>>>
>>> It's easier to add a char *parent to struct clk_fixed and pass it to
>>> clk_register with&fixed->parent. This saves you a kmalloc call and
>>> makes the error path simpler. It's the same way already done in the
>>> divider.
>
> I thought I had done this for v7... hmm looks like one got left out.
> I'll line up a patch to get it in sync with the others as part of my
> fixes.
>
>> I thought about that since I saw the same was done for gated and divider
>> (I think). Here is my guess at Mike's reasoning for this:
>>
>> Gated and divider clocks have to have a parent. There's nothing to gate
>> otherwise. But fixed rate clocks might not have a parent. It could be XO's
>> or PLLs running off of always on XOs not controlled by the SoC. So, it's
>> arguable to not have a parent. I don't have a strong opinion on this --
>> since Mike took the time to write it, it left it to his subjective
>> preference.
>
> I appreciate the thoughtfulness. Re-using the same type of mechanism
> as the divider and gate clocks will still allow the fixed-rate clock
> to be parentless, and it makes for cleaner code, one less allocation
> and lines up with how the other single-parent basic clocks are done,
> so I'll take that method in instead of your patch.
No problem, go for it.
>
>> I sent this patch first since it was around the place I was cleaning up. I
>> didn't want to actually just shuffle around a bug. As I mentioned, this
>> patch still leaves a bug open -- what if clk_register() fails. I plan to
>> fix that once my two patches are picked up (hopefully).
>
> Do you still find it useful to return -ENOMEM from the registration
> function instead of a NULL clock? I'm always worried that people
> don't check for error codes on pointers in their platform code and
> only check for NULL...
The last discussion I remember, NULL was considered a valid clock. So, I
think on error, we shouldn't ever return NULL when the return type is
struct clk *.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 2:32 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 2:32 UTC (permalink / raw)
To: linux-arm-kernel
On 03/20/2012 05:13 PM, Turquette, Mike wrote:
> On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
> <skannan@codeaurora.org> wrote:
>> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
>>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>>>> If memory allocation for the parents array or the parent string fails,
>>>> then
>>>> fail the registration immediately instead of calling clk_register and
>>>> hoping it fails there.
>>>>
>>>> Return -ENOMEM on failure.
>>>>
>>>> Signed-off-by: Saravana Kannan<skannan@codeaurora.org>
>>>> Cc: Mike Turquette<mturquette@linaro.org>
>>>> Cc: Andrew Lunn<andrew@lunn.ch>
>>>> Cc: 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>
>>>> ---
>>>> There are still some memory free issues when clk_register() fails, but I
>>>> will
>>>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>>>> failure instead of a NULL.
>>>>
>>>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>>>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
>>>> index 90c79fb..6423ae9 100644
>>>> --- a/drivers/clk/clk-fixed-rate.c
>>>> +++ b/drivers/clk/clk-fixed-rate.c
>>>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>>>> *dev, const char *name,
>>>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>>>
>>>> if (! parent_names)
>>>> - goto out;
>>>> + goto fail_ptr;
>>>>
>>>> len = sizeof(char) * strlen(parent_name);
>>>>
>>>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>>>
>>>> if (!parent_names[0])
>>>> - goto out;
>>>> + goto fail_str;
>>>>
>>>> strncpy(parent_names[0], parent_name, len);
>>>> }
>>>
>>> It's easier to add a char *parent to struct clk_fixed and pass it to
>>> clk_register with&fixed->parent. This saves you a kmalloc call and
>>> makes the error path simpler. It's the same way already done in the
>>> divider.
>
> I thought I had done this for v7... hmm looks like one got left out.
> I'll line up a patch to get it in sync with the others as part of my
> fixes.
>
>> I thought about that since I saw the same was done for gated and divider
>> (I think). Here is my guess at Mike's reasoning for this:
>>
>> Gated and divider clocks have to have a parent. There's nothing to gate
>> otherwise. But fixed rate clocks might not have a parent. It could be XO's
>> or PLLs running off of always on XOs not controlled by the SoC. So, it's
>> arguable to not have a parent. I don't have a strong opinion on this --
>> since Mike took the time to write it, it left it to his subjective
>> preference.
>
> I appreciate the thoughtfulness. Re-using the same type of mechanism
> as the divider and gate clocks will still allow the fixed-rate clock
> to be parentless, and it makes for cleaner code, one less allocation
> and lines up with how the other single-parent basic clocks are done,
> so I'll take that method in instead of your patch.
No problem, go for it.
>
>> I sent this patch first since it was around the place I was cleaning up. I
>> didn't want to actually just shuffle around a bug. As I mentioned, this
>> patch still leaves a bug open -- what if clk_register() fails. I plan to
>> fix that once my two patches are picked up (hopefully).
>
> Do you still find it useful to return -ENOMEM from the registration
> function instead of a NULL clock? I'm always worried that people
> don't check for error codes on pointers in their platform code and
> only check for NULL...
The last discussion I remember, NULL was considered a valid clock. So, I
think on error, we shouldn't ever return NULL when the return type is
struct clk *.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-21 1:47 ` Turquette, Mike
@ 2012-03-21 3:01 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:01 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 03/20/2012 06:47 PM, Turquette, Mike wrote:
> On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de> wrote:
>> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>>>>> ...
>>>>>> I am using these functions and don't need a static array, I just call
>>>>>> the functions with the desired parameters.
>>>>>>
>>>>> With this patch getting in, you do not have to use them then. I feel
>>>>> a static array will be much more readable than a long list of function
>>>>> calls with a long list of hardcoded arguments to each.
>>>>
>>>> I'm also not a fan of long argument lists; a divider like defined in my
>>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
>>>> border I think it's still acceptable.
>>>>
>>>> What I like in terms of readability is one line per clock which makes
>>>> for quite short clock files.
>>>
>>> It certainly makes for short clock files, but it's definitely less
>>> readable that the expanded struct. For the original author the "one
>>> line per clock" looks readable since they wrote it. But for someone
>>> looking at the code to modify it, the expanded one would be much
>>> easier to read. Also, you can always declare your own macro if you
>>> really want to follow the one line approach.
>>>
>>>> So when we use structs to initialize the clocks we'll probably have
>>>> something like this:
>>>>
>>>> static struct clk_divider somediv = {
>>>> .reg = CCM_BASE + 0x14,
>>>> .width = 3,
>>>> .shift = 17,
>>>> .lock =&ccm_lock,
>>>> .hw.parent = "someotherdiv",
>>>> .hw.flags = CLK_SET_RATE_PARENT,
>>>> };
>>>
>>> Taken from your patches:
>>>
>>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>>> ARRAY_SIZE(spll_sel_clks));
>>>
>>> Compare the struct to the one line call. Now tell me, what does "1"
>>> represent? No clue. But in the struct, I can immediately tell what
>>> each one of the parameters are.
>>>
>>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>>> So, hopefully this won't be a point of contention.
>>>
>>>> This will make a 4000 line file out of a 500 line file. Now when for
>>>> some reason struct clk_divider changes we end with big patches. If the
>>>> clk core gets a new fancy CLK_ flag which we want to have then again
>>>> we end up with big patches. Then there's also the possibility that
>>>> someone finds out that .lock and .hw.flags are common to all dividers
>>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>>>> fields.
>>>
>>> This patch won't prevent you from doing any of that. You can still
>>> create macros for that (there are already one for that). Also, what
>>> you are pointing out is a bigger problem for the current
>>> clk_register() function since you might have to change the no. of
>>> params of all the callers even if a new field is optional.
>>>
>>>> All this can be solved when we introduce a small wrapper function and
>>>> use it in the clock files:
>>>>
>>>> static inline struct clk *imx_clk_divider(const char *name, const char *parent,
>>>> void __iomem *reg, u8 shift, u8 width)
>>>> {
>>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>>>> reg, shift, width, 0,&imx_ccm_lock);
>>>> }
>>>>
>>>> It decouples us from the structs used by the clock framework, we can
>>>> add our preferred flags and still can share common fields like the lock.
>>>>
>>>> While this was not the intention when I first converted from struct
>>>> initializers to function initializers I am confident that it will make
>>>> a good job.
>>>
>>> Now I'm confused -- it's not clear if you are leaning towards my
>>> patch or away from it?
>>
>> There was a tendency to get rid of static initializers and I like the
>> idea of not exposing any of the internally used members outside the
>> clock framework.
>
> I'm with Sascha on this. I feel that dividing the interface strictly
> into two halves is the best way.
I addressed this concern in my earlier comments. We can make a copy or
we can agree the fields I moved to clk_hw aren't really useful wrt
writing hacky code and call it a day. Can you please clarify why neither
of these options are acceptable?
> I have an uneasy feeling about
> exposing this stuff into struct clk_hw (or clk_initializer or
> whatever). This stretches the data out across three structures and
> just doesn't feel right to me.
Wrt this discussion, there are three distinct classes of data:
1) Those specific to the platform driver that the common code shouldn't
care about.
2) Those specific to the common code that the platform driver shouldn't
care about.
3) Stuff that's shared/passed between common code and the platform driver.
When we have three classes of data, I don't what's wrong with having
three struct types to contain them. If anything, it's better than the
current approach of exposing the common clock code specific data (struct
clk) to code outside of common clock code just because we want to allow
static initialization. The end goal should be to move struct clk inside
clk.c.
I think this patch just takes us one step close to that since IMX and
MSM won't have to include clk-private.h in any of our platform specific
files while also allowing OMAP to include it for the near term.
>> Now people try their best to make themselves comfortable with the
>> static initializers and you even discussed the possibility of removing
>> the clk_register_* functions (which make it possible for users not
>> to use any of the internal struct members). That's what I don't like
>> about your patches. But if we go for static initializers anyway then your
>> patches probably change things for the better.
>
> Static initialization is something I have fought for; in fact the
> original patches provided no way to do it, so clearly what we have
> today is some progress for the folks desiring static init.
I too desire static init. Sorry if I was unclear and gave people the
misconception that I wanted to remove static init.
> The patch
> above doesn't actually prevent allocation from happening as it still
> must call into clk_register and kmalloc struct clk,
Correct.
> so besides
> readability, I'm not sure what these patches buy us.
I think readability is very important and if this buys us nothing but
readability, we should still take this patch. But there are other
benefits too -- I mentioned them in the commit text.
> Assuming that C99 designated initializers (for the sole purpose of
> readability) is the main draw of the above patch, please let me know
> what you think about modifying the existing static init macros so that
> your clock data looks like this:
>
> DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck",
> .flags = 0x0,
> .reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
> .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
> .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
> .flags = CLK_DIVIDER_ONE_BASED,
> .lock = NULL
> );
>
> Note that the first argument is the name of this clock (and will be
> properly stringified for .name = "whatever") and that the second and
> third arguments are both the parent clock, used for initializing the
> parent pointer and .parent_names, respectively. If that aspect of the
> macro is too ugly then those can even be broken out into a separate
> macro since they are independent data structure (struct clk **parents,
> and char **parent_names). Or you could just open code those data
> structures and only use a macro for struct clk and struct clk_foo.
>
> This gives you the readability of C99 designated initializers while
> keeping struct clk's members totally hidden from the rest of the
> world.
But it still leaves the struct clk exposed to people who do static init
of the clock tree. I think agreeing that the name, parent names, flags
and ops are not used to hack with or just making a copy of all of them
(and mark the originals as __init if that's doable). is a better
solution than trying to go with macros and leave struct clk exposed to
everyone who want to do static init of the clock tree.
At a later point when we are ready to move struct clk inside clk.c, with
this patch applied right now, IMX and MSM won't have to churn their code.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-21 3:01 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:01 UTC (permalink / raw)
To: linux-arm-kernel
On 03/20/2012 06:47 PM, Turquette, Mike wrote:
> On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de> wrote:
>> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>>>>> ...
>>>>>> I am using these functions and don't need a static array, I just call
>>>>>> the functions with the desired parameters.
>>>>>>
>>>>> With this patch getting in, you do not have to use them then. I feel
>>>>> a static array will be much more readable than a long list of function
>>>>> calls with a long list of hardcoded arguments to each.
>>>>
>>>> I'm also not a fan of long argument lists; a divider like defined in my
>>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the
>>>> border I think it's still acceptable.
>>>>
>>>> What I like in terms of readability is one line per clock which makes
>>>> for quite short clock files.
>>>
>>> It certainly makes for short clock files, but it's definitely less
>>> readable that the expanded struct. For the original author the "one
>>> line per clock" looks readable since they wrote it. But for someone
>>> looking at the code to modify it, the expanded one would be much
>>> easier to read. Also, you can always declare your own macro if you
>>> really want to follow the one line approach.
>>>
>>>> So when we use structs to initialize the clocks we'll probably have
>>>> something like this:
>>>>
>>>> static struct clk_divider somediv = {
>>>> .reg = CCM_BASE + 0x14,
>>>> .width = 3,
>>>> .shift = 17,
>>>> .lock =&ccm_lock,
>>>> .hw.parent = "someotherdiv",
>>>> .hw.flags = CLK_SET_RATE_PARENT,
>>>> };
>>>
>>> Taken from your patches:
>>>
>>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>>> ARRAY_SIZE(spll_sel_clks));
>>>
>>> Compare the struct to the one line call. Now tell me, what does "1"
>>> represent? No clue. But in the struct, I can immediately tell what
>>> each one of the parameters are.
>>>
>>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>>> So, hopefully this won't be a point of contention.
>>>
>>>> This will make a 4000 line file out of a 500 line file. Now when for
>>>> some reason struct clk_divider changes we end with big patches. If the
>>>> clk core gets a new fancy CLK_ flag which we want to have then again
>>>> we end up with big patches. Then there's also the possibility that
>>>> someone finds out that .lock and .hw.flags are common to all dividers
>>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>>>> fields.
>>>
>>> This patch won't prevent you from doing any of that. You can still
>>> create macros for that (there are already one for that). Also, what
>>> you are pointing out is a bigger problem for the current
>>> clk_register() function since you might have to change the no. of
>>> params of all the callers even if a new field is optional.
>>>
>>>> All this can be solved when we introduce a small wrapper function and
>>>> use it in the clock files:
>>>>
>>>> static inline struct clk *imx_clk_divider(const char *name, const char *parent,
>>>> void __iomem *reg, u8 shift, u8 width)
>>>> {
>>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>>>> reg, shift, width, 0,&imx_ccm_lock);
>>>> }
>>>>
>>>> It decouples us from the structs used by the clock framework, we can
>>>> add our preferred flags and still can share common fields like the lock.
>>>>
>>>> While this was not the intention when I first converted from struct
>>>> initializers to function initializers I am confident that it will make
>>>> a good job.
>>>
>>> Now I'm confused -- it's not clear if you are leaning towards my
>>> patch or away from it?
>>
>> There was a tendency to get rid of static initializers and I like the
>> idea of not exposing any of the internally used members outside the
>> clock framework.
>
> I'm with Sascha on this. I feel that dividing the interface strictly
> into two halves is the best way.
I addressed this concern in my earlier comments. We can make a copy or
we can agree the fields I moved to clk_hw aren't really useful wrt
writing hacky code and call it a day. Can you please clarify why neither
of these options are acceptable?
> I have an uneasy feeling about
> exposing this stuff into struct clk_hw (or clk_initializer or
> whatever). This stretches the data out across three structures and
> just doesn't feel right to me.
Wrt this discussion, there are three distinct classes of data:
1) Those specific to the platform driver that the common code shouldn't
care about.
2) Those specific to the common code that the platform driver shouldn't
care about.
3) Stuff that's shared/passed between common code and the platform driver.
When we have three classes of data, I don't what's wrong with having
three struct types to contain them. If anything, it's better than the
current approach of exposing the common clock code specific data (struct
clk) to code outside of common clock code just because we want to allow
static initialization. The end goal should be to move struct clk inside
clk.c.
I think this patch just takes us one step close to that since IMX and
MSM won't have to include clk-private.h in any of our platform specific
files while also allowing OMAP to include it for the near term.
>> Now people try their best to make themselves comfortable with the
>> static initializers and you even discussed the possibility of removing
>> the clk_register_* functions (which make it possible for users not
>> to use any of the internal struct members). That's what I don't like
>> about your patches. But if we go for static initializers anyway then your
>> patches probably change things for the better.
>
> Static initialization is something I have fought for; in fact the
> original patches provided no way to do it, so clearly what we have
> today is some progress for the folks desiring static init.
I too desire static init. Sorry if I was unclear and gave people the
misconception that I wanted to remove static init.
> The patch
> above doesn't actually prevent allocation from happening as it still
> must call into clk_register and kmalloc struct clk,
Correct.
> so besides
> readability, I'm not sure what these patches buy us.
I think readability is very important and if this buys us nothing but
readability, we should still take this patch. But there are other
benefits too -- I mentioned them in the commit text.
> Assuming that C99 designated initializers (for the sole purpose of
> readability) is the main draw of the above patch, please let me know
> what you think about modifying the existing static init macros so that
> your clock data looks like this:
>
> DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck",
> .flags = 0x0,
> .reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
> .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
> .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
> .flags = CLK_DIVIDER_ONE_BASED,
> .lock = NULL
> );
>
> Note that the first argument is the name of this clock (and will be
> properly stringified for .name = "whatever") and that the second and
> third arguments are both the parent clock, used for initializing the
> parent pointer and .parent_names, respectively. If that aspect of the
> macro is too ugly then those can even be broken out into a separate
> macro since they are independent data structure (struct clk **parents,
> and char **parent_names). Or you could just open code those data
> structures and only use a macro for struct clk and struct clk_foo.
>
> This gives you the readability of C99 designated initializers while
> keeping struct clk's members totally hidden from the rest of the
> world.
But it still leaves the struct clk exposed to people who do static init
of the clock tree. I think agreeing that the name, parent names, flags
and ops are not used to hack with or just making a copy of all of them
(and mark the originals as __init if that's doable). is a better
solution than trying to go with macros and leave struct clk exposed to
everyone who want to do static init of the clock tree.
At a later point when we are ready to move struct clk inside clk.c, with
this patch applied right now, IMX and MSM won't have to churn their code.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-20 23:53 ` Turquette, Mike
@ 2012-03-21 3:10 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:10 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-21 3:10 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:10 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-20 23:31 ` Paul Walmsley
(?)
@ 2012-03-21 3:15 ` Nicolas Pitre
-1 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-21 3:15 UTC (permalink / raw)
To: Paul Walmsley
Cc: Sascha Hauer, Arnd Bergmann, linux-arm-kernel, Amit Kucheria,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 3:15 ` Nicolas Pitre
0 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-21 3:15 UTC (permalink / raw)
To: Paul Walmsley
Cc: Sascha Hauer, Arnd Bergmann, linux-arm-kernel, Amit Kucheria,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 3:15 ` Nicolas Pitre
0 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-21 3:15 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 3:15 ` Nicolas Pitre
(?)
@ 2012-03-21 3:26 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:26 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Paul Walmsley, Sascha Hauer, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 3:26 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:26 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Paul Walmsley, Sascha Hauer, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 3:26 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 3:26 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-21 2:32 ` Saravana Kannan
@ 2012-03-21 5:45 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 5:45 UTC (permalink / raw)
To: Saravana Kannan
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria
On Tue, Mar 20, 2012 at 7:32 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 03/20/2012 05:13 PM, Turquette, Mike wrote:
>>
>> On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
>> <skannan@codeaurora.org> wrote:
>>>
>>> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
>>>>
>>>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>>>>>
>>>>> If memory allocation for the parents array or the parent string fails,
>>>>> then
>>>>> fail the registration immediately instead of calling clk_register and
>>>>> hoping it fails there.
>>>>>
>>>>> Return -ENOMEM on failure.
>>>>>
>>>>> Signed-off-by: Saravana Kannan<skannan@codeaurora.org>
>>>>> Cc: Mike Turquette<mturquette@linaro.org>
>>>>> Cc: Andrew Lunn<andrew@lunn.ch>
>>>>> Cc: 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>
>>>>> ---
>>>>> There are still some memory free issues when clk_register() fails, but
>>>>> I
>>>>> will
>>>>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>>>>> failure instead of a NULL.
>>>>>
>>>>> drivers/clk/clk-fixed-rate.c | 10 +++++++---
>>>>> 1 files changed, 7 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/clk/clk-fixed-rate.c
>>>>> b/drivers/clk/clk-fixed-rate.c
>>>>> index 90c79fb..6423ae9 100644
>>>>> --- a/drivers/clk/clk-fixed-rate.c
>>>>> +++ b/drivers/clk/clk-fixed-rate.c
>>>>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>>>>> *dev, const char *name,
>>>>> parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>>>>
>>>>> if (! parent_names)
>>>>> - goto out;
>>>>> + goto fail_ptr;
>>>>>
>>>>> len = sizeof(char) * strlen(parent_name);
>>>>>
>>>>> parent_names[0] = kmalloc(len, GFP_KERNEL);
>>>>>
>>>>> if (!parent_names[0])
>>>>> - goto out;
>>>>> + goto fail_str;
>>>>>
>>>>> strncpy(parent_names[0], parent_name, len);
>>>>> }
>>>>
>>>>
>>>> It's easier to add a char *parent to struct clk_fixed and pass it to
>>>> clk_register with&fixed->parent. This saves you a kmalloc call and
>>>>
>>>> makes the error path simpler. It's the same way already done in the
>>>> divider.
>>
>>
>> I thought I had done this for v7... hmm looks like one got left out.
>> I'll line up a patch to get it in sync with the others as part of my
>> fixes.
>>
>>> I thought about that since I saw the same was done for gated and divider
>>> (I think). Here is my guess at Mike's reasoning for this:
>>>
>>> Gated and divider clocks have to have a parent. There's nothing to gate
>>> otherwise. But fixed rate clocks might not have a parent. It could be
>>> XO's
>>> or PLLs running off of always on XOs not controlled by the SoC. So, it's
>>> arguable to not have a parent. I don't have a strong opinion on this --
>>> since Mike took the time to write it, it left it to his subjective
>>> preference.
>>
>>
>> I appreciate the thoughtfulness. Re-using the same type of mechanism
>> as the divider and gate clocks will still allow the fixed-rate clock
>> to be parentless, and it makes for cleaner code, one less allocation
>> and lines up with how the other single-parent basic clocks are done,
>> so I'll take that method in instead of your patch.
>
>
> No problem, go for it.
>
>
>>
>>> I sent this patch first since it was around the place I was cleaning up.
>>> I
>>> didn't want to actually just shuffle around a bug. As I mentioned, this
>>> patch still leaves a bug open -- what if clk_register() fails. I plan to
>>> fix that once my two patches are picked up (hopefully).
>>
>>
>> Do you still find it useful to return -ENOMEM from the registration
>> function instead of a NULL clock? I'm always worried that people
>> don't check for error codes on pointers in their platform code and
>> only check for NULL...
>
>
> The last discussion I remember, NULL was considered a valid clock. So, I
> think on error, we shouldn't ever return NULL when the return type is struct
> clk *.
IIRC, that discussion was with respect to the .parent member of struct
clk. It was decided that having .parent = NULL does not imply that a
clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
can't think of any other instance where a NULL clk when returned from
a registration function would be useful.
Regards,
Mike
> Thanks,
> Saravana
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 5:45 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 5:45 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 7:32 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 03/20/2012 05:13 PM, Turquette, Mike wrote:
>>
>> On Tue, Mar 20, 2012 at 12:46 AM, Saravana Kannan
>> <skannan@codeaurora.org> ?wrote:
>>>
>>> On Tue, March 20, 2012 12:19 am, Sascha Hauer wrote:
>>>>
>>>> On Mon, Mar 19, 2012 at 08:38:25PM -0700, Saravana Kannan wrote:
>>>>>
>>>>> If memory allocation for the parents array or the parent string fails,
>>>>> then
>>>>> fail the registration immediately instead of calling clk_register and
>>>>> hoping it fails there.
>>>>>
>>>>> Return -ENOMEM on failure.
>>>>>
>>>>> Signed-off-by: Saravana Kannan<skannan@codeaurora.org>
>>>>> Cc: Mike Turquette<mturquette@linaro.org>
>>>>> Cc: Andrew Lunn<andrew@lunn.ch>
>>>>> Cc: 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>
>>>>> ---
>>>>> There are still some memory free issues when clk_register() fails, but
>>>>> I
>>>>> will
>>>>> fix it when I fixed the other register() fns to return ENOMEM of alloc
>>>>> failure instead of a NULL.
>>>>>
>>>>> ?drivers/clk/clk-fixed-rate.c | ? 10 +++++++---
>>>>> ?1 files changed, 7 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/clk/clk-fixed-rate.c
>>>>> b/drivers/clk/clk-fixed-rate.c
>>>>> index 90c79fb..6423ae9 100644
>>>>> --- a/drivers/clk/clk-fixed-rate.c
>>>>> +++ b/drivers/clk/clk-fixed-rate.c
>>>>> @@ -61,22 +61,26 @@ struct clk *clk_register_fixed_rate(struct device
>>>>> *dev, const char *name,
>>>>> ? ? ? ? ? ? ?parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
>>>>>
>>>>> ? ? ? ? ? ? ?if (! parent_names)
>>>>> - ? ? ? ? ? ? ? ? ? ?goto out;
>>>>> + ? ? ? ? ? ? ? ? ? ?goto fail_ptr;
>>>>>
>>>>> ? ? ? ? ? ? ?len = sizeof(char) * strlen(parent_name);
>>>>>
>>>>> ? ? ? ? ? ? ?parent_names[0] = kmalloc(len, GFP_KERNEL);
>>>>>
>>>>> ? ? ? ? ? ? ?if (!parent_names[0])
>>>>> - ? ? ? ? ? ? ? ? ? ?goto out;
>>>>> + ? ? ? ? ? ? ? ? ? ?goto fail_str;
>>>>>
>>>>> ? ? ? ? ? ? ?strncpy(parent_names[0], parent_name, len);
>>>>> ? ? ?}
>>>>
>>>>
>>>> It's easier to add a char *parent to struct clk_fixed and pass it to
>>>> clk_register with&fixed->parent. This saves you a kmalloc call and
>>>>
>>>> makes the error path simpler. It's the same way already done in the
>>>> divider.
>>
>>
>> I thought I had done this for v7... hmm looks like one got left out.
>> I'll line up a patch to get it in sync with the others as part of my
>> fixes.
>>
>>> I thought about that since I saw the same was done for gated and divider
>>> (I think). Here is my guess at Mike's reasoning for this:
>>>
>>> Gated and divider clocks have to have a parent. There's nothing to gate
>>> otherwise. But fixed rate clocks might not have a parent. It could be
>>> XO's
>>> or PLLs running off of always on XOs not controlled by the SoC. So, it's
>>> arguable to not have a parent. I don't have a strong opinion on this --
>>> since Mike took the time to write it, it left it to his subjective
>>> preference.
>>
>>
>> I appreciate the thoughtfulness. ?Re-using the same type of mechanism
>> as the divider and gate clocks will still allow the fixed-rate clock
>> to be parentless, and it makes for cleaner code, one less allocation
>> and lines up with how the other single-parent basic clocks are done,
>> so I'll take that method in instead of your patch.
>
>
> No problem, go for it.
>
>
>>
>>> I sent this patch first since it was around the place I was cleaning up.
>>> I
>>> didn't want to actually just shuffle around a bug. As I mentioned, this
>>> patch still leaves a bug open -- what if clk_register() fails. I plan to
>>> fix that once my two patches are picked up (hopefully).
>>
>>
>> Do you still find it useful to return -ENOMEM from the registration
>> function instead of a NULL clock? ?I'm always worried that people
>> don't check for error codes on pointers in their platform code and
>> only check for NULL...
>
>
> The last discussion I remember, NULL was considered a valid clock. So, I
> think on error, we shouldn't ever return NULL when the return type is struct
> clk *.
IIRC, that discussion was with respect to the .parent member of struct
clk. It was decided that having .parent = NULL does not imply that a
clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
can't think of any other instance where a NULL clk when returned from
a registration function would be useful.
Regards,
Mike
> Thanks,
> Saravana
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-20 23:46 ` Turquette, Mike
@ 2012-03-21 5:46 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-21 5:46 UTC (permalink / raw)
To: Turquette, Mike
Cc: Paul Walmsley, Russell King, Linus Walleij, patches, Magnus Damm,
Sascha Hauer, Mark Brown, Stephen Boyd, linux-kernel,
Saravana Kannan, linaro-dev, Jeremy Kerr, Arnd Bergman,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-21 5:46 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-21 5:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-21 5:45 ` Turquette, Mike
(?)
@ 2012-03-21 6:33 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 6:33 UTC (permalink / raw)
To: Turquette, Mike
Cc: Saravana Kannan, Sascha Hauer, Andrew Lunn, Grant Likely,
Jamie Iles, Jeremy Kerr, Magnus Damm, Deepak Saxena,
linux-arm-kernel, Arnd Bergman, linux-arm-msm, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel, Amit Kucheria
On Tue, March 20, 2012 10:45 pm, Turquette, Mike wrote:
> IIRC, that discussion was with respect to the .parent member of struct
> clk. It was decided that having .parent = NULL does not imply that a
> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
> can't think of any other instance where a NULL clk when returned from
> a registration function would be useful.
I wasn't referring to a discussion with regards to this patch series. I'm
referring to what I believe was a discussion with Russell King on whether
a NULL from clk_get() should be considered a clock and whether it should
be usable as a "clock" with the clock APIs. That's the reason clk_get()
returns -ENOENT instead of NULL.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 6:33 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 6:33 UTC (permalink / raw)
To: Turquette, Mike
Cc: Saravana Kannan, Sascha Hauer, Andrew Lunn, Grant Likely,
Jamie Iles, Jeremy Kerr, Magnus Damm, Deepak Saxena,
linux-arm-kernel, Arnd Bergman, linux-arm-msm, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel, Amit Kucheria
On Tue, March 20, 2012 10:45 pm, Turquette, Mike wrote:
> IIRC, that discussion was with respect to the .parent member of struct
> clk. It was decided that having .parent = NULL does not imply that a
> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
> can't think of any other instance where a NULL clk when returned from
> a registration function would be useful.
I wasn't referring to a discussion with regards to this patch series. I'm
referring to what I believe was a discussion with Russell King on whether
a NULL from clk_get() should be considered a clock and whether it should
be usable as a "clock" with the clock APIs. That's the reason clk_get()
returns -ENOENT instead of NULL.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 6:33 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 6:33 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, March 20, 2012 10:45 pm, Turquette, Mike wrote:
> IIRC, that discussion was with respect to the .parent member of struct
> clk. It was decided that having .parent = NULL does not imply that a
> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
> can't think of any other instance where a NULL clk when returned from
> a registration function would be useful.
I wasn't referring to a discussion with regards to this patch series. I'm
referring to what I believe was a discussion with Russell King on whether
a NULL from clk_get() should be considered a clock and whether it should
be usable as a "clock" with the clock APIs. That's the reason clk_get()
returns -ENOENT instead of NULL.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 3:15 ` Nicolas Pitre
(?)
@ 2012-03-21 7:30 ` Paul Walmsley
-1 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-21 7:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sascha Hauer, Arnd Bergmann, linux-arm-kernel, Amit Kucheria,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 7:30 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-21 7:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sascha Hauer, Arnd Bergmann, linux-arm-kernel, Amit Kucheria,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 7:30 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-21 7:30 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 3:26 ` Saravana Kannan
(?)
@ 2012-03-21 7:44 ` Paul Walmsley
-1 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-21 7:44 UTC (permalink / raw)
To: Saravana Kannan
Cc: Nicolas Pitre, Sascha Hauer, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 7:44 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-21 7:44 UTC (permalink / raw)
To: Saravana Kannan
Cc: Nicolas Pitre, Sascha Hauer, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 7:44 ` Paul Walmsley
0 siblings, 0 replies; 242+ messages in thread
From: Paul Walmsley @ 2012-03-21 7:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-20 23:40 ` Paul Walmsley
@ 2012-03-21 8:59 ` Arnd Bergmann
-1 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-21 8:59 UTC (permalink / raw)
To: Paul Walmsley
Cc: Turquette, Mike, linux-arm-kernel, Amit Kucheria, Nicolas Pitre,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Magnus Damm, Deepak Saxena, patches, Sascha Hauer,
Rob Herring, Russell King, Thomas Gleixner, Richard Zhao,
Shawn Guo, Linus Walleij, Mark Brown, Stephen Boyd, linux-omap,
linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 8:59 ` Arnd Bergmann
0 siblings, 0 replies; 242+ messages in thread
From: Arnd Bergmann @ 2012-03-21 8:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-21 5:45 ` Turquette, Mike
@ 2012-03-21 9:07 ` Russell King - ARM Linux
-1 siblings, 0 replies; 242+ messages in thread
From: Russell King - ARM Linux @ 2012-03-21 9:07 UTC (permalink / raw)
To: Turquette, Mike
Cc: Saravana Kannan, Sascha Hauer, Andrew Lunn, Grant Likely,
Jamie Iles, Jeremy Kerr, Magnus Damm, Deepak Saxena,
linux-arm-kernel, Arnd Bergman, linux-arm-msm, Rob Herring,
Thomas Gleixner, Richard Zhao, Shawn Guo, Paul Walmsley,
Linus Walleij, Mark Brown, Stephen Boyd, linux-kernel,
Amit Kucheria
On Tue, Mar 20, 2012 at 10:45:36PM -0700, Turquette, Mike wrote:
> IIRC, that discussion was with respect to the .parent member of struct
> clk. It was decided that having .parent = NULL does not imply that a
> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
> can't think of any other instance where a NULL clk when returned from
> a registration function would be useful.
No. What I've been saying is that in _drivers_ which use clk_get(),
the error range is defined by IS_ERR(clk). Every other value of
clk must be assumed by the driver to be valid, no ifs or buts.
What the clk API assumes about struct clk is its own business. If it
wishes to interpret the NULL clk in a specific way, that's its business
to do so. But it's still not the drivers business to then go and
interpret NULL as being any different from any other valid clock.
This is part of the clk API contract, which is as I said in the first
paragraph, and I keep on saying. I'm not sure what's so difficult
about this.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 9:07 ` Russell King - ARM Linux
0 siblings, 0 replies; 242+ messages in thread
From: Russell King - ARM Linux @ 2012-03-21 9:07 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 10:45:36PM -0700, Turquette, Mike wrote:
> IIRC, that discussion was with respect to the .parent member of struct
> clk. It was decided that having .parent = NULL does not imply that a
> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
> can't think of any other instance where a NULL clk when returned from
> a registration function would be useful.
No. What I've been saying is that in _drivers_ which use clk_get(),
the error range is defined by IS_ERR(clk). Every other value of
clk must be assumed by the driver to be valid, no ifs or buts.
What the clk API assumes about struct clk is its own business. If it
wishes to interpret the NULL clk in a specific way, that's its business
to do so. But it's still not the drivers business to then go and
interpret NULL as being any different from any other valid clock.
This is part of the clk API contract, which is as I said in the first
paragraph, and I keep on saying. I'm not sure what's so difficult
about this.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 9:10 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-21 9:10 UTC (permalink / raw)
To: Paul Walmsley
Cc: Saravana Kannan, Nicolas Pitre, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 9:10 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-21 9:10 UTC (permalink / raw)
To: Paul Walmsley
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Thomas Gleixner,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Mark Brown,
Stephen Boyd, linux-kernel-u79uwXL29TY76Z2rM5mHXA
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 9:10 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-21 9:10 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 23:47 ` Paul Walmsley
@ 2012-03-21 9:16 ` Sascha Hauer
-1 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-21 9:16 UTC (permalink / raw)
To: Paul Walmsley
Cc: Shawn Guo, Saravana Kannan, Mike Turquette, Arnd Bergman,
linux-arm-kernel, linux-kernel, linux-arm-msm, Andrew Lunn,
Rob Herring, Russell King, Jeremy Kerr, Thomas Gleixner,
Shawn Guo, Jamie Iles, Richard Zhao, Magnus Damm, Mark Brown,
Linus Walleij, Stephen Boyd, Amit Kucheria, Deepak Saxena,
Grant Likely
On Tue, Mar 20, 2012 at 05:47:42PM -0600, Paul Walmsley wrote:
> Hello Sascha
>
> On Tue, 20 Mar 2012, Sascha Hauer wrote:
>
> > [ C99 structure initializer elided ]
> >
> > This will make a 4000 line file out of a 500 line file. Now when for
> > some reason struct clk_divider changes we end with big patches. If the
> > clk core gets a new fancy CLK_ flag which we want to have then again
> > we end up with big patches. Then there's also the possibility that
> > someone finds out that .lock and .hw.flags are common to all dividers
> > and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> > fields.
>
> At least we can understand easily what is being changed. Readability,
> particularly by others not familiar with the clock data, is more important
> to me.
>
> So like Saravana, I too prefer C99 structure initializers. At least there
> should be a choice.
>
> Quick quiz: in this line below:
>
> imx_clk_divider("foo_clk", "bar_clk", CCM_BASE + 0x20, 0x5, 0x3);
>
> which field is the bitfield shift and which is the bitfield width? :-)
I can't even remember the argument order in memset, but I never voted
for a struct memset_init ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-21 9:16 ` Sascha Hauer
0 siblings, 0 replies; 242+ messages in thread
From: Sascha Hauer @ 2012-03-21 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 05:47:42PM -0600, Paul Walmsley wrote:
> Hello Sascha
>
> On Tue, 20 Mar 2012, Sascha Hauer wrote:
>
> > [ C99 structure initializer elided ]
> >
> > This will make a 4000 line file out of a 500 line file. Now when for
> > some reason struct clk_divider changes we end with big patches. If the
> > clk core gets a new fancy CLK_ flag which we want to have then again
> > we end up with big patches. Then there's also the possibility that
> > someone finds out that .lock and .hw.flags are common to all dividers
> > and comes up with a #define DEFINE_CLK_DIVIDER again to share common
> > fields.
>
> At least we can understand easily what is being changed. Readability,
> particularly by others not familiar with the clock data, is more important
> to me.
>
> So like Saravana, I too prefer C99 structure initializers. At least there
> should be a choice.
>
> Quick quiz: in this line below:
>
> imx_clk_divider("foo_clk", "bar_clk", CCM_BASE + 0x20, 0x5, 0x3);
>
> which field is the bitfield shift and which is the bitfield width? :-)
I can't even remember the argument order in memset, but I never voted
for a struct memset_init ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 13:23 ` Nicolas Pitre
0 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-21 13:23 UTC (permalink / raw)
To: Paul Walmsley
Cc: Sascha Hauer, Arnd Bergmann, linux-arm-kernel, Amit Kucheria,
linaro-dev, Linus Walleij, Grant Likely, Saravana Kannan,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 13:23 ` Nicolas Pitre
0 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-21 13:23 UTC (permalink / raw)
To: Paul Walmsley
Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw, Saravana Kannan, Jeremy Kerr,
Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 13:23 ` Nicolas Pitre
0 siblings, 0 replies; 242+ messages in thread
From: Nicolas Pitre @ 2012-03-21 13:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 7:44 ` Paul Walmsley
(?)
@ 2012-03-21 18:38 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 18:38 UTC (permalink / raw)
To: Paul Walmsley
Cc: Nicolas Pitre, Sascha Hauer, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap, linux-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 18:38 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 18:38 UTC (permalink / raw)
To: Paul Walmsley
Cc: Nicolas Pitre, Sascha Hauer, Arnd Bergmann, linux-arm-kernel,
Amit Kucheria, linaro-dev, Linus Walleij, Grant Likely,
Jeremy Kerr, Mike Turquette, Mike Turquette, Magnus Damm,
Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Mark Brown, Stephen Boyd, linux-omap
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 18:38 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 18:38 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 18:38 ` Saravana Kannan
(?)
@ 2012-03-21 19:07 ` Mark Brown
-1 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 19:07 UTC (permalink / raw)
To: Saravana Kannan
Cc: Paul Walmsley, Nicolas Pitre, Sascha Hauer, Arnd Bergmann,
linux-arm-kernel, Amit Kucheria, linaro-dev, Linus Walleij,
Grant Likely, Jeremy Kerr, Mike Turquette, Mike Turquette,
Magnus Damm, Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Stephen Boyd, linux-omap, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:07 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 19:07 UTC (permalink / raw)
To: Saravana Kannan
Cc: Paul Walmsley, Nicolas Pitre, Sascha Hauer, Arnd Bergmann,
linux-arm-kernel, Amit Kucheria, linaro-dev, Linus Walleij,
Grant Likely, Jeremy Kerr, Mike Turquette, Mike Turquette,
Magnus Damm, Deepak Saxena, patches, Rob Herring, Russell King,
Thomas Gleixner, Richard Zhao, Shawn Guo, Linus Walleij,
Stephen Boyd, linux-omap, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:07 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 19:07 UTC (permalink / raw)
To: linux-arm-kernel
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120321/b5747b79/attachment-0001.sig>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:33 ` Tony Lindgren
0 siblings, 0 replies; 242+ messages in thread
From: Tony Lindgren @ 2012-03-21 19:33 UTC (permalink / raw)
To: Mark Brown
Cc: Saravana Kannan, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap, linux-kernel
* 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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:33 ` Tony Lindgren
0 siblings, 0 replies; 242+ messages in thread
From: Tony Lindgren @ 2012-03-21 19:33 UTC (permalink / raw)
To: Mark Brown
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw,
Saravana Kannan, Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Paul Walmsley, Linus Walleij, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
* Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> [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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:33 ` Tony Lindgren
0 siblings, 0 replies; 242+ messages in thread
From: Tony Lindgren @ 2012-03-21 19:33 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 19:33 ` Tony Lindgren
(?)
@ 2012-03-21 19:41 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 19:41 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Brown, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap, linux-kernel
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> * 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:41 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 19:41 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Brown, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> * 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:41 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 19:41 UTC (permalink / raw)
To: linux-arm-kernel
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> * 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
2012-03-21 9:07 ` Russell King - ARM Linux
@ 2012-03-21 19:56 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 19:56 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Saravana Kannan, Sascha Hauer, Andrew Lunn, Grant Likely,
Jamie Iles, Jeremy Kerr, Magnus Damm, Deepak Saxena,
linux-arm-kernel, Arnd Bergman, linux-arm-msm, Rob Herring,
Thomas Gleixner, Richard Zhao, Shawn Guo, Paul Walmsley,
Linus Walleij, Mark Brown, Stephen Boyd, linux-kernel,
Amit Kucheria
On Wed, Mar 21, 2012 at 2:07 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Mar 20, 2012 at 10:45:36PM -0700, Turquette, Mike wrote:
>> IIRC, that discussion was with respect to the .parent member of struct
>> clk. It was decided that having .parent = NULL does not imply that a
>> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. I
>> can't think of any other instance where a NULL clk when returned from
>> a registration function would be useful.
>
> No. What I've been saying is that in _drivers_ which use clk_get(),
> the error range is defined by IS_ERR(clk). Every other value of
> clk must be assumed by the driver to be valid, no ifs or buts.
Drivers certainly might make calls to clk_register_foo, despite it
being outside of the traditional clock api. For the sake of
consistency I'll convert the clk_register_foo functions to return
error codes.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn
@ 2012-03-21 19:56 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-21 19:56 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 21, 2012 at 2:07 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Mar 20, 2012 at 10:45:36PM -0700, Turquette, Mike wrote:
>> IIRC, that discussion was with respect to the .parent member of struct
>> clk. ?It was decided that having .parent = NULL does not imply that a
>> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag. ?I
>> can't think of any other instance where a NULL clk when returned from
>> a registration function would be useful.
>
> No. ?What I've been saying is that in _drivers_ which use clk_get(),
> the error range is defined by IS_ERR(clk). ?Every other value of
> clk must be assumed by the driver to be valid, no ifs or buts.
Drivers certainly might make calls to clk_register_foo, despite it
being outside of the traditional clock api. For the sake of
consistency I'll convert the clk_register_foo functions to return
error codes.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:56 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 19:56 UTC (permalink / raw)
To: Saravana Kannan
Cc: Tony Lindgren, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> >* Mark Brown<broonie@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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:56 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 19:56 UTC (permalink / raw)
To: Saravana Kannan
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw, Tony Lindgren,
Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Paul Walmsley, Linus Walleij, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1.1: Type: text/plain, Size: 798 bytes --]
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> >* Mark Brown<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> [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.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 175 bytes --]
_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 19:56 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 19:56 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> >* Mark Brown<broonie@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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120321/008e43d2/attachment.sig>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
2012-03-21 19:56 ` Mark Brown
(?)
@ 2012-03-21 20:04 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 20:04 UTC (permalink / raw)
To: Mark Brown
Cc: Tony Lindgren, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap, linux-kernel
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 Brown<broonie@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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 20:04 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 20:04 UTC (permalink / raw)
To: Mark Brown
Cc: Tony Lindgren, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap
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 Brown<broonie@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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 20:04 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-21 20:04 UTC (permalink / raw)
To: linux-arm-kernel
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 Brown<broonie@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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 20:10 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 20:10 UTC (permalink / raw)
To: Saravana Kannan
Cc: Tony Lindgren, Paul Walmsley, Nicolas Pitre, Sascha Hauer,
Arnd Bergmann, linux-arm-kernel, Amit Kucheria, linaro-dev,
Linus Walleij, Grant Likely, Jeremy Kerr, Mike Turquette,
Mike Turquette, Magnus Damm, Deepak Saxena, patches, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 20:10 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 20:10 UTC (permalink / raw)
To: Saravana Kannan
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw, Tony Lindgren,
Jeremy Kerr, Russell King, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Paul Walmsley, Linus Walleij, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]
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.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 175 bytes --]
_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-21 20:10 ` Mark Brown
0 siblings, 0 replies; 242+ messages in thread
From: Mark Brown @ 2012-03-21 20:10 UTC (permalink / raw)
To: linux-arm-kernel
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120321/698cf6b8/attachment.sig>
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-22 0:42 ` Russell King - ARM Linux
0 siblings, 0 replies; 242+ messages in thread
From: Russell King - ARM Linux @ 2012-03-22 0:42 UTC (permalink / raw)
To: Saravana Kannan
Cc: Tony Lindgren, Mark Brown, Paul Walmsley, Nicolas Pitre,
Sascha Hauer, Arnd Bergmann, linux-arm-kernel, Amit Kucheria,
linaro-dev, Linus Walleij, Grant Likely, Jeremy Kerr,
Mike Turquette, Mike Turquette, Magnus Damm, Deepak Saxena,
patches, Rob Herring, Thomas Gleixner, Richard Zhao, Shawn Guo,
Linus Walleij, Stephen Boyd, linux-omap, linux-kernel
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-22 0:42 ` Russell King - ARM Linux
0 siblings, 0 replies; 242+ messages in thread
From: Russell King - ARM Linux @ 2012-03-22 0:42 UTC (permalink / raw)
To: Saravana Kannan
Cc: Nicolas Pitre, linaro-dev-cunTk1MwBs8s++Sfvej+rw, Tony Lindgren,
Jeremy Kerr, Magnus Damm,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
patches-QSEj5FYQhm4dnm+yROfE0A, Sascha Hauer, Rob Herring,
Thomas Gleixner, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 1/3] Documentation: common clk API
@ 2012-03-22 0:42 ` Russell King - ARM Linux
0 siblings, 0 replies; 242+ messages in thread
From: Russell King - ARM Linux @ 2012-03-22 0:42 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-20 22:40 ` Sascha Hauer
@ 2012-03-22 3:23 ` Shawn Guo
-1 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-22 3:23 UTC (permalink / raw)
To: Sascha Hauer
Cc: Saravana Kannan, Andrew Lunn, Grant Likely, Jamie Iles,
Jeremy Kerr, Mike Turquette, Magnus Damm, Deepak Saxena,
linux-arm-kernel, Arnd Bergman, linux-arm-msm, Rob Herring,
Russell King, Thomas Gleixner, Richard Zhao, Shawn Guo,
Paul Walmsley, Linus Walleij, Mark Brown, Stephen Boyd,
linux-kernel, Amit Kucheria
On Tue, Mar 20, 2012 at 11:40:21PM +0100, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 01:14:51PM -0700, Saravana Kannan wrote:
...
> > Ah, I see. That's a lot of functions calls. I think it would be much
> > more efficient if you just have an array and loop over it. With my
> > patch, you can just call a single register function for all these
> > clocks.
>
> I was curious and gave it a try. I registered a fixed clock and 100
> gates as child clocks. I tried both DEFINE_CLK_GATE and
> clk_register_gate. It turned out there was no difference in speed.
>
While there is no difference in speed efficiency, I think we will
gain space efficiency if we can have Saravana's patch to copy the
clk_hw fields and make the static array __initdata as you mentioned.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-22 3:23 ` Shawn Guo
0 siblings, 0 replies; 242+ messages in thread
From: Shawn Guo @ 2012-03-22 3:23 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 20, 2012 at 11:40:21PM +0100, Sascha Hauer wrote:
> On Tue, Mar 20, 2012 at 01:14:51PM -0700, Saravana Kannan wrote:
...
> > Ah, I see. That's a lot of functions calls. I think it would be much
> > more efficient if you just have an array and loop over it. With my
> > patch, you can just call a single register function for all these
> > clocks.
>
> I was curious and gave it a try. I registered a fixed clock and 100
> gates as child clocks. I tried both DEFINE_CLK_GATE and
> clk_register_gate. It turned out there was no difference in speed.
>
While there is no difference in speed efficiency, I think we will
gain space efficiency if we can have Saravana's patch to copy the
clk_hw fields and make the static array __initdata as you mentioned.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-21 3:10 ` Saravana Kannan
@ 2012-03-23 21:33 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 21:33 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 21:33 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 21:33 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 21:33 ` Saravana Kannan
@ 2012-03-23 21:39 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-23 21:39 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 21:39 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-23 21:39 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 21:39 ` Turquette, Mike
@ 2012-03-23 21:51 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 21:51 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
> 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?
>
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 21:51 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 21:51 UTC (permalink / raw)
To: linux-arm-kernel
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
> 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?
>
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 21:39 ` Turquette, Mike
@ 2012-03-23 22:12 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 22:12 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
> 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?
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 22:12 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 22:12 UTC (permalink / raw)
To: linux-arm-kernel
On 03/23/2012 02:39 PM, Turquette, Mike wrote:
> 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?
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 22:12 ` Saravana Kannan
@ 2012-03-23 22:32 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-23 22:32 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 22:32 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-23 22:32 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 22:32 ` Turquette, Mike
@ 2012-03-23 23:04 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 23:04 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
On 03/23/2012 03:32 PM, Turquette, Mike wrote:
> 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 23:04 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-23 23:04 UTC (permalink / raw)
To: linux-arm-kernel
On 03/23/2012 03:32 PM, Turquette, Mike wrote:
> 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.
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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 23:04 ` Saravana Kannan
@ 2012-03-23 23:28 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-23 23:28 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-23 23:28 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-23 23:28 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-21 3:01 ` Saravana Kannan
@ 2012-03-27 4:35 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-27 4:35 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
Mike,
(*nudge*) (*nudge*)
-Saravana
On 03/20/2012 08:01 PM, Saravana Kannan wrote:
> On 03/20/2012 06:47 PM, Turquette, Mike wrote:
>> On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de>
>> wrote:
>>> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>>>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>>>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>>>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>>>>>> ...
>>>>>>> I am using these functions and don't need a static array, I just
>>>>>>> call
>>>>>>> the functions with the desired parameters.
>>>>>>>
>>>>>> With this patch getting in, you do not have to use them then. I feel
>>>>>> a static array will be much more readable than a long list of
>>>>>> function
>>>>>> calls with a long list of hardcoded arguments to each.
>>>>>
>>>>> I'm also not a fan of long argument lists; a divider like defined
>>>>> in my
>>>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at
>>>>> the
>>>>> border I think it's still acceptable.
>>>>>
>>>>> What I like in terms of readability is one line per clock which makes
>>>>> for quite short clock files.
>>>>
>>>> It certainly makes for short clock files, but it's definitely less
>>>> readable that the expanded struct. For the original author the "one
>>>> line per clock" looks readable since they wrote it. But for someone
>>>> looking at the code to modify it, the expanded one would be much
>>>> easier to read. Also, you can always declare your own macro if you
>>>> really want to follow the one line approach.
>>>>
>>>>> So when we use structs to initialize the clocks we'll probably have
>>>>> something like this:
>>>>>
>>>>> static struct clk_divider somediv = {
>>>>> .reg = CCM_BASE + 0x14,
>>>>> .width = 3,
>>>>> .shift = 17,
>>>>> .lock =&ccm_lock,
>>>>> .hw.parent = "someotherdiv",
>>>>> .hw.flags = CLK_SET_RATE_PARENT,
>>>>> };
>>>>
>>>> Taken from your patches:
>>>>
>>>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>>>> ARRAY_SIZE(spll_sel_clks));
>>>>
>>>> Compare the struct to the one line call. Now tell me, what does "1"
>>>> represent? No clue. But in the struct, I can immediately tell what
>>>> each one of the parameters are.
>>>>
>>>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>>>> So, hopefully this won't be a point of contention.
>>>>
>>>>> This will make a 4000 line file out of a 500 line file. Now when for
>>>>> some reason struct clk_divider changes we end with big patches. If the
>>>>> clk core gets a new fancy CLK_ flag which we want to have then again
>>>>> we end up with big patches. Then there's also the possibility that
>>>>> someone finds out that .lock and .hw.flags are common to all dividers
>>>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>>>>> fields.
>>>>
>>>> This patch won't prevent you from doing any of that. You can still
>>>> create macros for that (there are already one for that). Also, what
>>>> you are pointing out is a bigger problem for the current
>>>> clk_register() function since you might have to change the no. of
>>>> params of all the callers even if a new field is optional.
>>>>
>>>>> All this can be solved when we introduce a small wrapper function and
>>>>> use it in the clock files:
>>>>>
>>>>> static inline struct clk *imx_clk_divider(const char *name, const
>>>>> char *parent,
>>>>> void __iomem *reg, u8 shift, u8 width)
>>>>> {
>>>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>>>>> reg, shift, width, 0,&imx_ccm_lock);
>>>>> }
>>>>>
>>>>> It decouples us from the structs used by the clock framework, we can
>>>>> add our preferred flags and still can share common fields like the
>>>>> lock.
>>>>>
>>>>> While this was not the intention when I first converted from struct
>>>>> initializers to function initializers I am confident that it will make
>>>>> a good job.
>>>>
>>>> Now I'm confused -- it's not clear if you are leaning towards my
>>>> patch or away from it?
>>>
>>> There was a tendency to get rid of static initializers and I like the
>>> idea of not exposing any of the internally used members outside the
>>> clock framework.
>>
>> I'm with Sascha on this. I feel that dividing the interface strictly
>> into two halves is the best way.
>
> I addressed this concern in my earlier comments. We can make a copy or
> we can agree the fields I moved to clk_hw aren't really useful wrt
> writing hacky code and call it a day. Can you please clarify why neither
> of these options are acceptable?
>
>> I have an uneasy feeling about
>> exposing this stuff into struct clk_hw (or clk_initializer or
>> whatever). This stretches the data out across three structures and
>> just doesn't feel right to me.
>
> Wrt this discussion, there are three distinct classes of data:
> 1) Those specific to the platform driver that the common code shouldn't
> care about.
> 2) Those specific to the common code that the platform driver shouldn't
> care about.
> 3) Stuff that's shared/passed between common code and the platform driver.
>
> When we have three classes of data, I don't what's wrong with having
> three struct types to contain them. If anything, it's better than the
> current approach of exposing the common clock code specific data (struct
> clk) to code outside of common clock code just because we want to allow
> static initialization. The end goal should be to move struct clk inside
> clk.c.
>
> I think this patch just takes us one step close to that since IMX and
> MSM won't have to include clk-private.h in any of our platform specific
> files while also allowing OMAP to include it for the near term.
>
>>> Now people try their best to make themselves comfortable with the
>>> static initializers and you even discussed the possibility of removing
>>> the clk_register_* functions (which make it possible for users not
>>> to use any of the internal struct members). That's what I don't like
>>> about your patches. But if we go for static initializers anyway then
>>> your
>>> patches probably change things for the better.
>>
>> Static initialization is something I have fought for; in fact the
>> original patches provided no way to do it, so clearly what we have
>> today is some progress for the folks desiring static init.
>
> I too desire static init. Sorry if I was unclear and gave people the
> misconception that I wanted to remove static init.
>
>> The patch
>> above doesn't actually prevent allocation from happening as it still
>> must call into clk_register and kmalloc struct clk,
>
> Correct.
>
>> so besides
>> readability, I'm not sure what these patches buy us.
>
> I think readability is very important and if this buys us nothing but
> readability, we should still take this patch. But there are other
> benefits too -- I mentioned them in the commit text.
>
>> Assuming that C99 designated initializers (for the sole purpose of
>> readability) is the main draw of the above patch, please let me know
>> what you think about modifying the existing static init macros so that
>> your clock data looks like this:
>>
>> DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck",
>> .flags = 0x0,
>> .reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
>> .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
>> .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
>> .flags = CLK_DIVIDER_ONE_BASED,
>> .lock = NULL
>> );
>>
>> Note that the first argument is the name of this clock (and will be
>> properly stringified for .name = "whatever") and that the second and
>> third arguments are both the parent clock, used for initializing the
>> parent pointer and .parent_names, respectively. If that aspect of the
>> macro is too ugly then those can even be broken out into a separate
>> macro since they are independent data structure (struct clk **parents,
>> and char **parent_names). Or you could just open code those data
>> structures and only use a macro for struct clk and struct clk_foo.
>>
>> This gives you the readability of C99 designated initializers while
>> keeping struct clk's members totally hidden from the rest of the
>> world.
>
> But it still leaves the struct clk exposed to people who do static init
> of the clock tree. I think agreeing that the name, parent names, flags
> and ops are not used to hack with or just making a copy of all of them
> (and mark the originals as __init if that's doable). is a better
> solution than trying to go with macros and leave struct clk exposed to
> everyone who want to do static init of the clock tree.
>
> At a later point when we are ready to move struct clk inside clk.c, with
> this patch applied right now, IMX and MSM won't have to churn their code.
>
> 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-27 4:35 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-27 4:35 UTC (permalink / raw)
To: linux-arm-kernel
Mike,
(*nudge*) (*nudge*)
-Saravana
On 03/20/2012 08:01 PM, Saravana Kannan wrote:
> On 03/20/2012 06:47 PM, Turquette, Mike wrote:
>> On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de>
>> wrote:
>>> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>>>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>>>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>>>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>>>>>> ...
>>>>>>> I am using these functions and don't need a static array, I just
>>>>>>> call
>>>>>>> the functions with the desired parameters.
>>>>>>>
>>>>>> With this patch getting in, you do not have to use them then. I feel
>>>>>> a static array will be much more readable than a long list of
>>>>>> function
>>>>>> calls with a long list of hardcoded arguments to each.
>>>>>
>>>>> I'm also not a fan of long argument lists; a divider like defined
>>>>> in my
>>>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at
>>>>> the
>>>>> border I think it's still acceptable.
>>>>>
>>>>> What I like in terms of readability is one line per clock which makes
>>>>> for quite short clock files.
>>>>
>>>> It certainly makes for short clock files, but it's definitely less
>>>> readable that the expanded struct. For the original author the "one
>>>> line per clock" looks readable since they wrote it. But for someone
>>>> looking at the code to modify it, the expanded one would be much
>>>> easier to read. Also, you can always declare your own macro if you
>>>> really want to follow the one line approach.
>>>>
>>>>> So when we use structs to initialize the clocks we'll probably have
>>>>> something like this:
>>>>>
>>>>> static struct clk_divider somediv = {
>>>>> .reg = CCM_BASE + 0x14,
>>>>> .width = 3,
>>>>> .shift = 17,
>>>>> .lock =&ccm_lock,
>>>>> .hw.parent = "someotherdiv",
>>>>> .hw.flags = CLK_SET_RATE_PARENT,
>>>>> };
>>>>
>>>> Taken from your patches:
>>>>
>>>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>>>> ARRAY_SIZE(spll_sel_clks));
>>>>
>>>> Compare the struct to the one line call. Now tell me, what does "1"
>>>> represent? No clue. But in the struct, I can immediately tell what
>>>> each one of the parameters are.
>>>>
>>>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>>>> So, hopefully this won't be a point of contention.
>>>>
>>>>> This will make a 4000 line file out of a 500 line file. Now when for
>>>>> some reason struct clk_divider changes we end with big patches. If the
>>>>> clk core gets a new fancy CLK_ flag which we want to have then again
>>>>> we end up with big patches. Then there's also the possibility that
>>>>> someone finds out that .lock and .hw.flags are common to all dividers
>>>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>>>>> fields.
>>>>
>>>> This patch won't prevent you from doing any of that. You can still
>>>> create macros for that (there are already one for that). Also, what
>>>> you are pointing out is a bigger problem for the current
>>>> clk_register() function since you might have to change the no. of
>>>> params of all the callers even if a new field is optional.
>>>>
>>>>> All this can be solved when we introduce a small wrapper function and
>>>>> use it in the clock files:
>>>>>
>>>>> static inline struct clk *imx_clk_divider(const char *name, const
>>>>> char *parent,
>>>>> void __iomem *reg, u8 shift, u8 width)
>>>>> {
>>>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>>>>> reg, shift, width, 0,&imx_ccm_lock);
>>>>> }
>>>>>
>>>>> It decouples us from the structs used by the clock framework, we can
>>>>> add our preferred flags and still can share common fields like the
>>>>> lock.
>>>>>
>>>>> While this was not the intention when I first converted from struct
>>>>> initializers to function initializers I am confident that it will make
>>>>> a good job.
>>>>
>>>> Now I'm confused -- it's not clear if you are leaning towards my
>>>> patch or away from it?
>>>
>>> There was a tendency to get rid of static initializers and I like the
>>> idea of not exposing any of the internally used members outside the
>>> clock framework.
>>
>> I'm with Sascha on this. I feel that dividing the interface strictly
>> into two halves is the best way.
>
> I addressed this concern in my earlier comments. We can make a copy or
> we can agree the fields I moved to clk_hw aren't really useful wrt
> writing hacky code and call it a day. Can you please clarify why neither
> of these options are acceptable?
>
>> I have an uneasy feeling about
>> exposing this stuff into struct clk_hw (or clk_initializer or
>> whatever). This stretches the data out across three structures and
>> just doesn't feel right to me.
>
> Wrt this discussion, there are three distinct classes of data:
> 1) Those specific to the platform driver that the common code shouldn't
> care about.
> 2) Those specific to the common code that the platform driver shouldn't
> care about.
> 3) Stuff that's shared/passed between common code and the platform driver.
>
> When we have three classes of data, I don't what's wrong with having
> three struct types to contain them. If anything, it's better than the
> current approach of exposing the common clock code specific data (struct
> clk) to code outside of common clock code just because we want to allow
> static initialization. The end goal should be to move struct clk inside
> clk.c.
>
> I think this patch just takes us one step close to that since IMX and
> MSM won't have to include clk-private.h in any of our platform specific
> files while also allowing OMAP to include it for the near term.
>
>>> Now people try their best to make themselves comfortable with the
>>> static initializers and you even discussed the possibility of removing
>>> the clk_register_* functions (which make it possible for users not
>>> to use any of the internal struct members). That's what I don't like
>>> about your patches. But if we go for static initializers anyway then
>>> your
>>> patches probably change things for the better.
>>
>> Static initialization is something I have fought for; in fact the
>> original patches provided no way to do it, so clearly what we have
>> today is some progress for the folks desiring static init.
>
> I too desire static init. Sorry if I was unclear and gave people the
> misconception that I wanted to remove static init.
>
>> The patch
>> above doesn't actually prevent allocation from happening as it still
>> must call into clk_register and kmalloc struct clk,
>
> Correct.
>
>> so besides
>> readability, I'm not sure what these patches buy us.
>
> I think readability is very important and if this buys us nothing but
> readability, we should still take this patch. But there are other
> benefits too -- I mentioned them in the commit text.
>
>> Assuming that C99 designated initializers (for the sole purpose of
>> readability) is the main draw of the above patch, please let me know
>> what you think about modifying the existing static init macros so that
>> your clock data looks like this:
>>
>> DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck",
>> .flags = 0x0,
>> .reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
>> .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
>> .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
>> .flags = CLK_DIVIDER_ONE_BASED,
>> .lock = NULL
>> );
>>
>> Note that the first argument is the name of this clock (and will be
>> properly stringified for .name = "whatever") and that the second and
>> third arguments are both the parent clock, used for initializing the
>> parent pointer and .parent_names, respectively. If that aspect of the
>> macro is too ugly then those can even be broken out into a separate
>> macro since they are independent data structure (struct clk **parents,
>> and char **parent_names). Or you could just open code those data
>> structures and only use a macro for struct clk and struct clk_foo.
>>
>> This gives you the readability of C99 designated initializers while
>> keeping struct clk's members totally hidden from the rest of the
>> world.
>
> But it still leaves the struct clk exposed to people who do static init
> of the clock tree. I think agreeing that the name, parent names, flags
> and ops are not used to hack with or just making a copy of all of them
> (and mark the originals as __init if that's doable). is a better
> solution than trying to go with macros and leave struct clk exposed to
> everyone who want to do static init of the clock tree.
>
> At a later point when we are ready to move struct clk inside clk.c, with
> this patch applied right now, IMX and MSM won't have to churn their code.
>
> 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-27 4:35 ` Saravana Kannan
@ 2012-03-27 18:49 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-27 18:49 UTC (permalink / raw)
To: Saravana Kannan
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> Mike,
>
> (*nudge*) (*nudge*)
Hi Saravana,
I spent some time mulling over the ideas this weekend and I agree that
we have 3 types of data, so having the three structs makes some sense.
I'm checking this patch out more earnestly today.
Regards,
Mike
> -Saravana
>
>
>
> On 03/20/2012 08:01 PM, Saravana Kannan wrote:
>>
>> On 03/20/2012 06:47 PM, Turquette, Mike wrote:
>>>
>>> On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de>
>>> wrote:
>>>>
>>>> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>>>>>
>>>>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>>>>>>
>>>>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>>>>>>>
>>>>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>>>>>>> ...
>>>>>>>>
>>>>>>>> I am using these functions and don't need a static array, I just
>>>>>>>> call
>>>>>>>> the functions with the desired parameters.
>>>>>>>>
>>>>>>> With this patch getting in, you do not have to use them then. I feel
>>>>>>> a static array will be much more readable than a long list of
>>>>>>> function
>>>>>>> calls with a long list of hardcoded arguments to each.
>>>>>>
>>>>>>
>>>>>> I'm also not a fan of long argument lists; a divider like defined
>>>>>> in my
>>>>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at
>>>>>> the
>>>>>> border I think it's still acceptable.
>>>>>>
>>>>>> What I like in terms of readability is one line per clock which makes
>>>>>> for quite short clock files.
>>>>>
>>>>>
>>>>> It certainly makes for short clock files, but it's definitely less
>>>>> readable that the expanded struct. For the original author the "one
>>>>> line per clock" looks readable since they wrote it. But for someone
>>>>> looking at the code to modify it, the expanded one would be much
>>>>> easier to read. Also, you can always declare your own macro if you
>>>>> really want to follow the one line approach.
>>>>>
>>>>>> So when we use structs to initialize the clocks we'll probably have
>>>>>> something like this:
>>>>>>
>>>>>> static struct clk_divider somediv = {
>>>>>> .reg = CCM_BASE + 0x14,
>>>>>> .width = 3,
>>>>>> .shift = 17,
>>>>>> .lock =&ccm_lock,
>>>>>> .hw.parent = "someotherdiv",
>>>>>> .hw.flags = CLK_SET_RATE_PARENT,
>>>>>> };
>>>>>
>>>>>
>>>>> Taken from your patches:
>>>>>
>>>>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>>>>> ARRAY_SIZE(spll_sel_clks));
>>>>>
>>>>> Compare the struct to the one line call. Now tell me, what does "1"
>>>>> represent? No clue. But in the struct, I can immediately tell what
>>>>> each one of the parameters are.
>>>>>
>>>>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>>>>> So, hopefully this won't be a point of contention.
>>>>>
>>>>>> This will make a 4000 line file out of a 500 line file. Now when for
>>>>>> some reason struct clk_divider changes we end with big patches. If the
>>>>>> clk core gets a new fancy CLK_ flag which we want to have then again
>>>>>> we end up with big patches. Then there's also the possibility that
>>>>>> someone finds out that .lock and .hw.flags are common to all dividers
>>>>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>>>>>> fields.
>>>>>
>>>>>
>>>>> This patch won't prevent you from doing any of that. You can still
>>>>> create macros for that (there are already one for that). Also, what
>>>>> you are pointing out is a bigger problem for the current
>>>>> clk_register() function since you might have to change the no. of
>>>>> params of all the callers even if a new field is optional.
>>>>>
>>>>>> All this can be solved when we introduce a small wrapper function and
>>>>>> use it in the clock files:
>>>>>>
>>>>>> static inline struct clk *imx_clk_divider(const char *name, const
>>>>>> char *parent,
>>>>>> void __iomem *reg, u8 shift, u8 width)
>>>>>> {
>>>>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>>>>>> reg, shift, width, 0,&imx_ccm_lock);
>>>>>> }
>>>>>>
>>>>>> It decouples us from the structs used by the clock framework, we can
>>>>>> add our preferred flags and still can share common fields like the
>>>>>> lock.
>>>>>>
>>>>>> While this was not the intention when I first converted from struct
>>>>>> initializers to function initializers I am confident that it will make
>>>>>> a good job.
>>>>>
>>>>>
>>>>> Now I'm confused -- it's not clear if you are leaning towards my
>>>>> patch or away from it?
>>>>
>>>>
>>>> There was a tendency to get rid of static initializers and I like the
>>>> idea of not exposing any of the internally used members outside the
>>>> clock framework.
>>>
>>>
>>> I'm with Sascha on this. I feel that dividing the interface strictly
>>> into two halves is the best way.
>>
>>
>> I addressed this concern in my earlier comments. We can make a copy or
>> we can agree the fields I moved to clk_hw aren't really useful wrt
>> writing hacky code and call it a day. Can you please clarify why neither
>> of these options are acceptable?
>>
>>> I have an uneasy feeling about
>>> exposing this stuff into struct clk_hw (or clk_initializer or
>>> whatever). This stretches the data out across three structures and
>>> just doesn't feel right to me.
>>
>>
>> Wrt this discussion, there are three distinct classes of data:
>> 1) Those specific to the platform driver that the common code shouldn't
>> care about.
>> 2) Those specific to the common code that the platform driver shouldn't
>> care about.
>> 3) Stuff that's shared/passed between common code and the platform driver.
>>
>> When we have three classes of data, I don't what's wrong with having
>> three struct types to contain them. If anything, it's better than the
>> current approach of exposing the common clock code specific data (struct
>> clk) to code outside of common clock code just because we want to allow
>> static initialization. The end goal should be to move struct clk inside
>> clk.c.
>>
>> I think this patch just takes us one step close to that since IMX and
>> MSM won't have to include clk-private.h in any of our platform specific
>> files while also allowing OMAP to include it for the near term.
>>
>>>> Now people try their best to make themselves comfortable with the
>>>> static initializers and you even discussed the possibility of removing
>>>> the clk_register_* functions (which make it possible for users not
>>>> to use any of the internal struct members). That's what I don't like
>>>> about your patches. But if we go for static initializers anyway then
>>>> your
>>>> patches probably change things for the better.
>>>
>>>
>>> Static initialization is something I have fought for; in fact the
>>> original patches provided no way to do it, so clearly what we have
>>> today is some progress for the folks desiring static init.
>>
>>
>> I too desire static init. Sorry if I was unclear and gave people the
>> misconception that I wanted to remove static init.
>>
>>> The patch
>>> above doesn't actually prevent allocation from happening as it still
>>> must call into clk_register and kmalloc struct clk,
>>
>>
>> Correct.
>>
>>> so besides
>>> readability, I'm not sure what these patches buy us.
>>
>>
>> I think readability is very important and if this buys us nothing but
>> readability, we should still take this patch. But there are other
>> benefits too -- I mentioned them in the commit text.
>>
>>> Assuming that C99 designated initializers (for the sole purpose of
>>> readability) is the main draw of the above patch, please let me know
>>> what you think about modifying the existing static init macros so that
>>> your clock data looks like this:
>>>
>>> DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck",
>>> .flags = 0x0,
>>> .reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
>>> .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
>>> .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
>>> .flags = CLK_DIVIDER_ONE_BASED,
>>> .lock = NULL
>>> );
>>>
>>> Note that the first argument is the name of this clock (and will be
>>> properly stringified for .name = "whatever") and that the second and
>>> third arguments are both the parent clock, used for initializing the
>>> parent pointer and .parent_names, respectively. If that aspect of the
>>> macro is too ugly then those can even be broken out into a separate
>>> macro since they are independent data structure (struct clk **parents,
>>> and char **parent_names). Or you could just open code those data
>>> structures and only use a macro for struct clk and struct clk_foo.
>>>
>>> This gives you the readability of C99 designated initializers while
>>> keeping struct clk's members totally hidden from the rest of the
>>> world.
>>
>>
>> But it still leaves the struct clk exposed to people who do static init
>> of the clock tree. I think agreeing that the name, parent names, flags
>> and ops are not used to hack with or just making a copy of all of them
>> (and mark the originals as __init if that's doable). is a better
>> solution than trying to go with macros and leave struct clk exposed to
>> everyone who want to do static init of the clock tree.
>>
>> At a later point when we are ready to move struct clk inside clk.c, with
>> this patch applied right now, IMX and MSM won't have to churn their code.
>>
>> 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-27 18:49 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-27 18:49 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> Mike,
>
> (*nudge*) (*nudge*)
Hi Saravana,
I spent some time mulling over the ideas this weekend and I agree that
we have 3 types of data, so having the three structs makes some sense.
I'm checking this patch out more earnestly today.
Regards,
Mike
> -Saravana
>
>
>
> On 03/20/2012 08:01 PM, Saravana Kannan wrote:
>>
>> On 03/20/2012 06:47 PM, Turquette, Mike wrote:
>>>
>>> On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de>
>>> wrote:
>>>>
>>>> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote:
>>>>>
>>>>> On 03/20/2012 11:10 AM, Sascha Hauer wrote:
>>>>>>
>>>>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote:
>>>>>>>
>>>>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote:
>>>>>>> ...
>>>>>>>>
>>>>>>>> I am using these functions and don't need a static array, I just
>>>>>>>> call
>>>>>>>> the functions with the desired parameters.
>>>>>>>>
>>>>>>> With this patch getting in, you do not have to use them then. I feel
>>>>>>> a static array will be much more readable than a long list of
>>>>>>> function
>>>>>>> calls with a long list of hardcoded arguments to each.
>>>>>>
>>>>>>
>>>>>> I'm also not a fan of long argument lists; a divider like defined
>>>>>> in my
>>>>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at
>>>>>> the
>>>>>> border I think it's still acceptable.
>>>>>>
>>>>>> What I like in terms of readability is one line per clock which makes
>>>>>> for quite short clock files.
>>>>>
>>>>>
>>>>> It certainly makes for short clock files, but it's definitely less
>>>>> readable that the expanded struct. For the original author the "one
>>>>> line per clock" looks readable since they wrote it. But for someone
>>>>> looking at the code to modify it, the expanded one would be much
>>>>> easier to read. Also, you can always declare your own macro if you
>>>>> really want to follow the one line approach.
>>>>>
>>>>>> So when we use structs to initialize the clocks we'll probably have
>>>>>> something like this:
>>>>>>
>>>>>> static struct clk_divider somediv = {
>>>>>> .reg = CCM_BASE + 0x14,
>>>>>> .width = 3,
>>>>>> .shift = 17,
>>>>>> .lock =&ccm_lock,
>>>>>> .hw.parent = "someotherdiv",
>>>>>> .hw.flags = CLK_SET_RATE_PARENT,
>>>>>> };
>>>>>
>>>>>
>>>>> Taken from your patches:
>>>>>
>>>>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks,
>>>>> ARRAY_SIZE(spll_sel_clks));
>>>>>
>>>>> Compare the struct to the one line call. Now tell me, what does "1"
>>>>> represent? No clue. But in the struct, I can immediately tell what
>>>>> each one of the parameters are.
>>>>>
>>>>> Anyway, my patch certainly isn't forcing you to use multiple lines.
>>>>> So, hopefully this won't be a point of contention.
>>>>>
>>>>>> This will make a 4000 line file out of a 500 line file. Now when for
>>>>>> some reason struct clk_divider changes we end with big patches. If the
>>>>>> clk core gets a new fancy CLK_ flag which we want to have then again
>>>>>> we end up with big patches. Then there's also the possibility that
>>>>>> someone finds out that .lock and .hw.flags are common to all dividers
>>>>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common
>>>>>> fields.
>>>>>
>>>>>
>>>>> This patch won't prevent you from doing any of that. You can still
>>>>> create macros for that (there are already one for that). Also, what
>>>>> you are pointing out is a bigger problem for the current
>>>>> clk_register() function since you might have to change the no. of
>>>>> params of all the callers even if a new field is optional.
>>>>>
>>>>>> All this can be solved when we introduce a small wrapper function and
>>>>>> use it in the clock files:
>>>>>>
>>>>>> static inline struct clk *imx_clk_divider(const char *name, const
>>>>>> char *parent,
>>>>>> void __iomem *reg, u8 shift, u8 width)
>>>>>> {
>>>>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
>>>>>> reg, shift, width, 0,&imx_ccm_lock);
>>>>>> }
>>>>>>
>>>>>> It decouples us from the structs used by the clock framework, we can
>>>>>> add our preferred flags and still can share common fields like the
>>>>>> lock.
>>>>>>
>>>>>> While this was not the intention when I first converted from struct
>>>>>> initializers to function initializers I am confident that it will make
>>>>>> a good job.
>>>>>
>>>>>
>>>>> Now I'm confused -- it's not clear if you are leaning towards my
>>>>> patch or away from it?
>>>>
>>>>
>>>> There was a tendency to get rid of static initializers and I like the
>>>> idea of not exposing any of the internally used members outside the
>>>> clock framework.
>>>
>>>
>>> I'm with Sascha on this. I feel that dividing the interface strictly
>>> into two halves is the best way.
>>
>>
>> I addressed this concern in my earlier comments. We can make a copy or
>> we can agree the fields I moved to clk_hw aren't really useful wrt
>> writing hacky code and call it a day. Can you please clarify why neither
>> of these options are acceptable?
>>
>>> I have an uneasy feeling about
>>> exposing this stuff into struct clk_hw (or clk_initializer or
>>> whatever). This stretches the data out across three structures and
>>> just doesn't feel right to me.
>>
>>
>> Wrt this discussion, there are three distinct classes of data:
>> 1) Those specific to the platform driver that the common code shouldn't
>> care about.
>> 2) Those specific to the common code that the platform driver shouldn't
>> care about.
>> 3) Stuff that's shared/passed between common code and the platform driver.
>>
>> When we have three classes of data, I don't what's wrong with having
>> three struct types to contain them. If anything, it's better than the
>> current approach of exposing the common clock code specific data (struct
>> clk) to code outside of common clock code just because we want to allow
>> static initialization. The end goal should be to move struct clk inside
>> clk.c.
>>
>> I think this patch just takes us one step close to that since IMX and
>> MSM won't have to include clk-private.h in any of our platform specific
>> files while also allowing OMAP to include it for the near term.
>>
>>>> Now people try their best to make themselves comfortable with the
>>>> static initializers and you even discussed the possibility of removing
>>>> the clk_register_* functions (which make it possible for users not
>>>> to use any of the internal struct members). That's what I don't like
>>>> about your patches. But if we go for static initializers anyway then
>>>> your
>>>> patches probably change things for the better.
>>>
>>>
>>> Static initialization is something I have fought for; in fact the
>>> original patches provided no way to do it, so clearly what we have
>>> today is some progress for the folks desiring static init.
>>
>>
>> I too desire static init. Sorry if I was unclear and gave people the
>> misconception that I wanted to remove static init.
>>
>>> The patch
>>> above doesn't actually prevent allocation from happening as it still
>>> must call into clk_register and kmalloc struct clk,
>>
>>
>> Correct.
>>
>>> so besides
>>> readability, I'm not sure what these patches buy us.
>>
>>
>> I think readability is very important and if this buys us nothing but
>> readability, we should still take this patch. But there are other
>> benefits too -- I mentioned them in the commit text.
>>
>>> Assuming that C99 designated initializers (for the sole purpose of
>>> readability) is the main draw of the above patch, please let me know
>>> what you think about modifying the existing static init macros so that
>>> your clock data looks like this:
>>>
>>> DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck",
>>> .flags = 0x0,
>>> .reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
>>> .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT,
>>> .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH,
>>> .flags = CLK_DIVIDER_ONE_BASED,
>>> .lock = NULL
>>> );
>>>
>>> Note that the first argument is the name of this clock (and will be
>>> properly stringified for .name = "whatever") and that the second and
>>> third arguments are both the parent clock, used for initializing the
>>> parent pointer and .parent_names, respectively. If that aspect of the
>>> macro is too ugly then those can even be broken out into a separate
>>> macro since they are independent data structure (struct clk **parents,
>>> and char **parent_names). Or you could just open code those data
>>> structures and only use a macro for struct clk and struct clk_foo.
>>>
>>> This gives you the readability of C99 designated initializers while
>>> keeping struct clk's members totally hidden from the rest of the
>>> world.
>>
>>
>> But it still leaves the struct clk exposed to people who do static init
>> of the clock tree. I think agreeing that the name, parent names, flags
>> and ops are not used to hack with or just making a copy of all of them
>> (and mark the originals as __init if that's doable). is a better
>> solution than trying to go with macros and leave struct clk exposed to
>> everyone who want to do static init of the clock tree.
>>
>> At a later point when we are ready to move struct clk inside clk.c, with
>> this patch applied right now, IMX and MSM won't have to churn their code.
>>
>> 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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-27 18:49 ` Turquette, Mike
@ 2012-03-27 22:27 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-27 22:27 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 03/27/2012 11:49 AM, Turquette, Mike wrote:
> On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> Mike,
>>
>> (*nudge*) (*nudge*)
>
> Hi Saravana,
>
> I spent some time mulling over the ideas this weekend and I agree that
> we have 3 types of data, so having the three structs makes some sense.
> I'm checking this patch out more earnestly today.
>
Thanks Mike. The patch has a few things to clean up. I would be glad to
send out a cleaned up patch once we have an approximate consensus on
what to copy/not copy.
Thanks,
Saravana
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-03-27 22:27 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-27 22:27 UTC (permalink / raw)
To: linux-arm-kernel
On 03/27/2012 11:49 AM, Turquette, Mike wrote:
> On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> Mike,
>>
>> (*nudge*) (*nudge*)
>
> Hi Saravana,
>
> I spent some time mulling over the ideas this weekend and I agree that
> we have 3 types of data, so having the three structs makes some sense.
> I'm checking this patch out more earnestly today.
>
Thanks Mike. The patch has a few things to clean up. I would be glad to
send out a cleaned up patch once we have an approximate consensus on
what to copy/not copy.
Thanks,
Saravana
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-23 23:28 ` Turquette, Mike
@ 2012-03-28 3:06 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-28 3:06 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
On 03/23/2012 04:28 PM, Turquette, Mike wrote:
> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> On 03/23/2012 03:32 PM, Turquette, Mike wrote:
>>> .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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-28 3:06 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-28 3:06 UTC (permalink / raw)
To: linux-arm-kernel
On 03/23/2012 04:28 PM, Turquette, Mike wrote:
> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> On 03/23/2012 03:32 PM, Turquette, Mike wrote:
>>> .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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-28 3:06 ` Saravana Kannan
@ 2012-03-28 17:08 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-28 17:08 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 03/23/2012 04:28 PM, Turquette, Mike wrote:
>> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan<skannan@codeaurora.org>
>> wrote:
>>> On 03/23/2012 03:32 PM, Turquette, Mike wrote:
>>> How does a child (or grand child) clock (not a driver using the clock)
>>> reject a rate change if it know it can't handle that freq from the
>>> parent? I
>>> won't claim to know this part of the code thoroughly, but I can't find an
>>> easy way to do this.
>>
>>
>> Technically you could subscribe a notifier to your grand-child clock,
>> even if there is no driver for it. The same code that implements your
>> platform's clock operations could register the notifier handler.
>
>>
>>
>> You can see how this works in clk_propagate_rate_change. That usage
>> is certainly targeted more at drivers but could be made to work for
>> your case. Let me know what you think; this is an interesting issue.
>
>
> I think notifications should be left to drivers. Notifications are too heavy
> handed for enforcing requirements of the clock tree.
Agreed. I'm working on a "clock dependency" design at the moment,
which should hopefully answer your question.
> Also, clk_hw to clk
> might no longer be a 1-1 mapping in the future. It's quite possible that
> each clk_get() would get a different struct clk based on the caller to keep
> track of their constraints separately. So, clock drivers shouldn't ever use
> them to identify a clock.
I'm also working on this same thing! Lots to keep me busy these days.
snip
> I think there is still a problem with not being able to differentiate
> between pre-change recalc and post-change recalc. This applies for any set
> parent and set rate on a clock that has children.
>
> Consider this simple example:
> * Divider clock B is fed from clock A.
> * Clock B can never output > 120 MHz due to downstream
> HW/clock limitations.
> * Clock A is running at 200 MHz
> * Clock B divider is set to 2.
>
> Now, say the rate of clock A is changing from 200 MHz to 300 MHz (due to set
> rate or set parent). In this case, the clock B divider should be set to 3
> pre-rate change to guarantee that the output of clock B is never > 120 MHz.
> So the rate of clock B will go from 100 MHz (200/2) to 66 MHz (200/3) to 100
> MHz (300/3) and everything is good.
>
> Assume we somehow managed to do the above. So, now clock A is at 300 MHz,
> clock B divider is at 3 and the clock B output is 100 MHz.
>
> Now, say the rate of clock A changes from 300 MHz to 100 MHz. In this case
> the clock B divider should only be changed post rate change. If we do it pre
> rate change, then the output will go from 100 MHz (300/3) to 150 MHz (300/1)
> to 100 MHz (100/1). We went past the 120 MHz limit of clock B's output rate.
>
> If we do this post rate change, we can do this without exceeding the max
> output limit of clock B. It will go from 100 MHz (300/3) to 33 MHz (100/3)
> to 100 MHz (100/1). We never went past the 120 MHz limit.
>
> So, at least for this reason above, I think we need to pass a pre/post
> parameter to the recalc ops.
>
> While we are at it, we should probably just add a failure option for recalc
> to make it easy to reject unacceptable rate changes. To keep the clock
> framework code simpler, you could decide to allow errors only for the
> pre-change recalc calls. That way, the error case roll back code won't be
> crazy.
recalc is too late to catch this. I think you mean round_rate. We
want to determine which rate changes are out-of-spec during
clk_calc_new_rates (for clk_set_rate) which involves round_rate being
a bit smarter about what it can and cannot do.
Anyways I'm looking at ways to do this in my clk-dependencies branch.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-28 17:08 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-28 17:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 03/23/2012 04:28 PM, Turquette, Mike wrote:
>> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan<skannan@codeaurora.org>
>> ?wrote:
>>> On 03/23/2012 03:32 PM, Turquette, Mike wrote:
>>> How does a child (or grand child) clock (not a driver using the clock)
>>> reject a rate change if it know it can't handle that freq from the
>>> parent? I
>>> won't claim to know this part of the code thoroughly, but I can't find an
>>> easy way to do this.
>>
>>
>> Technically you could subscribe a notifier to your grand-child clock,
>> even if there is no driver for it. ?The same code that implements your
>> platform's clock operations could register the notifier handler.
>
>>
>>
>> You can see how this works in clk_propagate_rate_change. ?That usage
>> is certainly targeted more at drivers but could be made to work for
>> your case. ?Let me know what you think; this is an interesting issue.
>
>
> I think notifications should be left to drivers. Notifications are too heavy
> handed for enforcing requirements of the clock tree.
Agreed. I'm working on a "clock dependency" design at the moment,
which should hopefully answer your question.
> Also, clk_hw to clk
> might no longer be a 1-1 mapping in the future. It's quite possible that
> each clk_get() would get a different struct clk based on the caller to keep
> track of their constraints separately. So, clock drivers shouldn't ever use
> them to identify a clock.
I'm also working on this same thing! Lots to keep me busy these days.
snip
> I think there is still a problem with not being able to differentiate
> between pre-change recalc and post-change recalc. This applies for any set
> parent and set rate on a clock that has children.
>
> Consider this simple example:
> * Divider clock B is fed from clock A.
> * Clock B can never output > 120 MHz due to downstream
> ?HW/clock limitations.
> * Clock A is running at 200 MHz
> * Clock B divider is set to 2.
>
> Now, say the rate of clock A is changing from 200 MHz to 300 MHz (due to set
> rate or set parent). In this case, the clock B divider should be set to 3
> pre-rate change to guarantee that the output of clock B is never > 120 MHz.
> So the rate of clock B will go from 100 MHz (200/2) to 66 MHz (200/3) to 100
> MHz (300/3) and everything is good.
>
> Assume we somehow managed to do the above. So, now clock A is at 300 MHz,
> clock B divider is at 3 and the clock B output is 100 MHz.
>
> Now, say the rate of clock A changes from 300 MHz to 100 MHz. In this case
> the clock B divider should only be changed post rate change. If we do it pre
> rate change, then the output will go from 100 MHz (300/3) to 150 MHz (300/1)
> to 100 MHz (100/1). We went past the 120 MHz limit of clock B's output rate.
>
> If we do this post rate change, we can do this without exceeding the max
> output limit of clock B. It will go from 100 MHz (300/3) to 33 MHz (100/3)
> to 100 MHz (100/1). We never went past the 120 MHz limit.
>
> So, at least for this reason above, I think we need to pass a pre/post
> parameter to the recalc ops.
>
> While we are at it, we should probably just add a failure option for recalc
> to make it easy to reject unacceptable rate changes. To keep the clock
> framework code simpler, you could decide to allow errors only for the
> pre-change recalc calls. That way, the error case roll back code won't be
> crazy.
recalc is too late to catch this. I think you mean round_rate. We
want to determine which rate changes are out-of-spec during
clk_calc_new_rates (for clk_set_rate) which involves round_rate being
a bit smarter about what it can and cannot do.
Anyways I'm looking at ways to do this in my clk-dependencies branch.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-28 17:08 ` Turquette, Mike
@ 2012-03-28 22:25 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-28 22:25 UTC (permalink / raw)
To: Turquette, Mike
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
On 03/28/2012 10:08 AM, Turquette, Mike wrote:
> On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan<skannan@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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-28 22:25 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-03-28 22:25 UTC (permalink / raw)
To: linux-arm-kernel
On 03/28/2012 10:08 AM, Turquette, Mike wrote:
> On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan<skannan@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
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH v7 2/3] clk: introduce the common clock framework
2012-03-28 22:25 ` Saravana Kannan
@ 2012-03-28 23:49 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-28 23:49 UTC (permalink / raw)
To: Saravana Kannan
Cc: Shawn Guo, Paul Walmsley, Russell King, Linus Walleij, patches,
Magnus Damm, Sascha Hauer, Mark Brown, Stephen Boyd,
linux-kernel, linaro-dev, Jeremy Kerr, linux-arm-kernel,
Arnd Bergman
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 Kannan<skannan@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
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH v7 2/3] clk: introduce the common clock framework
@ 2012-03-28 23:49 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-03-28 23:49 UTC (permalink / raw)
To: linux-arm-kernel
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 Kannan<skannan@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
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-03-27 18:49 ` Turquette, Mike
@ 2012-04-06 1:30 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-06 1:30 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 03/27/2012 11:49 AM, Turquette, Mike wrote:
> On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> Mike,
>>
>> (*nudge*) (*nudge*)
>
> Hi Saravana,
>
> I spent some time mulling over the ideas this weekend and I agree that
> we have 3 types of data, so having the three structs makes some sense.
> I'm checking this patch out more earnestly today.
(*nudge*) (*nudge*) again :-)
Sorry to keep nudging you on this often. The longer we wait for this,
the more churn it will cause later on. That's why I'm being persistent
on this. Also, once this goes in, I can start working on upstreaming MSM
clock support.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-06 1:30 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-06 1:30 UTC (permalink / raw)
To: linux-arm-kernel
On 03/27/2012 11:49 AM, Turquette, Mike wrote:
> On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> Mike,
>>
>> (*nudge*) (*nudge*)
>
> Hi Saravana,
>
> I spent some time mulling over the ideas this weekend and I agree that
> we have 3 types of data, so having the three structs makes some sense.
> I'm checking this patch out more earnestly today.
(*nudge*) (*nudge*) again :-)
Sorry to keep nudging you on this often. The longer we wait for this,
the more churn it will cause later on. That's why I'm being persistent
on this. Also, once this goes in, I can start working on upstreaming MSM
clock support.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-04-06 1:30 ` Saravana Kannan
@ 2012-04-11 17:59 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-04-11 17:59 UTC (permalink / raw)
To: Saravana Kannan
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 03/27/2012 11:49 AM, Turquette, Mike wrote:
>>
>> On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan<skannan@codeaurora.org>
>> wrote:
>>>
>>> Mike,
>>>
>>> (*nudge*) (*nudge*)
>>
>>
>> Hi Saravana,
>>
>> I spent some time mulling over the ideas this weekend and I agree that
>> we have 3 types of data, so having the three structs makes some sense.
>> I'm checking this patch out more earnestly today.
>
>
> (*nudge*) (*nudge*) again :-)
>
> Sorry to keep nudging you on this often. The longer we wait for this, the
> more churn it will cause later on. That's why I'm being persistent on this.
> Also, once this goes in, I can start working on upstreaming MSM clock
> support.
Sorry for the long wait Saravana. I've been swamped the past few days.
I thought about splitting this interface further (basically making the
statically initialized stuff visible to code that includes
clk-provider.h) and it seems like the benefits outweight the negative
stuff.
However I want to advance the cause of __initdata clock initializers,
so I think the final version of this change should have the core
perform a copy of the initializer data into struct clk_hw. It's been
a while since I looked at Sascha's clk_initalizer patches but I think
that it is essentially the same idea.
TL;DR: I think a combination of your change to expose the
not-so-private parts of struct clk into struct clk_hw are OK and have
real benefits for the clk-provider.h code. However we need to
implement it such that all the statically initialized data can be
__initdata.
My only concern with this series is that platform clock code will
access struct clk_hw members without the appropriate lock held (namely
prepare_lock). I'm a bit worried that there might be a case where
some clock code access clk_hw->name when clk_hw has somehow been
destroyed/altered (e.g. if clk_put every finally gets implemented...).
Besides clk_put are there any real instances where this might happen?
I'll be pushing my fixes branch out to the list soon. Do you want to
rebase this change on top of it taking into account the __initdata
bits?
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-11 17:59 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-04-11 17:59 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 03/27/2012 11:49 AM, Turquette, Mike wrote:
>>
>> On Mon, Mar 26, 2012 at 9:35 PM, Saravana Kannan<skannan@codeaurora.org>
>> ?wrote:
>>>
>>> Mike,
>>>
>>> (*nudge*) (*nudge*)
>>
>>
>> Hi Saravana,
>>
>> I spent some time mulling over the ideas this weekend and I agree that
>> we have 3 types of data, so having the three structs makes some sense.
>> ?I'm checking this patch out more earnestly today.
>
>
> (*nudge*) (*nudge*) again :-)
>
> Sorry to keep nudging you on this often. The longer we wait for this, the
> more churn it will cause later on. That's why I'm being persistent on this.
> Also, once this goes in, I can start working on upstreaming MSM clock
> support.
Sorry for the long wait Saravana. I've been swamped the past few days.
I thought about splitting this interface further (basically making the
statically initialized stuff visible to code that includes
clk-provider.h) and it seems like the benefits outweight the negative
stuff.
However I want to advance the cause of __initdata clock initializers,
so I think the final version of this change should have the core
perform a copy of the initializer data into struct clk_hw. It's been
a while since I looked at Sascha's clk_initalizer patches but I think
that it is essentially the same idea.
TL;DR: I think a combination of your change to expose the
not-so-private parts of struct clk into struct clk_hw are OK and have
real benefits for the clk-provider.h code. However we need to
implement it such that all the statically initialized data can be
__initdata.
My only concern with this series is that platform clock code will
access struct clk_hw members without the appropriate lock held (namely
prepare_lock). I'm a bit worried that there might be a case where
some clock code access clk_hw->name when clk_hw has somehow been
destroyed/altered (e.g. if clk_put every finally gets implemented...).
Besides clk_put are there any real instances where this might happen?
I'll be pushing my fixes branch out to the list soon. Do you want to
rebase this change on top of it taking into account the __initdata
bits?
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-04-11 17:59 ` Turquette, Mike
(?)
@ 2012-04-11 19:57 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-11 19:57 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 04/11/2012 10:59 AM, Turquette, Mike wrote:
> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> (*nudge*) (*nudge*) again :-)
>>
>> Sorry to keep nudging you on this often. The longer we wait for this, the
>> more churn it will cause later on. That's why I'm being persistent on this.
>> Also, once this goes in, I can start working on upstreaming MSM clock
>> support.
<SNIP>
> TL;DR: I think a combination of your change to expose the
> not-so-private parts of struct clk into struct clk_hw are OK and have
> real benefits for the clk-provider.h code. However we need to
> implement it such that all the statically initialized data can be
> __initdata.
Sounds like a reasonable compromise.
> My only concern with this series is that platform clock code will
> access struct clk_hw members without the appropriate lock held (namely
> prepare_lock). I'm a bit worried that there might be a case where
> some clock code access clk_hw->name when clk_hw has somehow been
> destroyed/altered (e.g. if clk_put every finally gets implemented...).
> Besides clk_put are there any real instances where this might happen?
This problem is true for any struct/field marked as __init_data. So, I
don't think this is a real problem. If someone is stupid enough to mark
their data as __init_data and access them later, then there is not much
we can do. Also, I believe the compiler throws out some warning when you
try to access __init_data from non-init code.
> I'll be pushing my fixes branch out to the list soon. Do you want to
> rebase this change on top of it taking into account the __initdata
> bits?
I thought it might be easier for you to base your changes on top of my
patch. But I can try to rebase mine on top of your changes. Hopefully
your fixes aren't crazy big/complex.
This is a busy week for me at work. I will try to send a patch in a day
or two.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-11 19:57 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-11 19:57 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 04/11/2012 10:59 AM, Turquette, Mike wrote:
> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> (*nudge*) (*nudge*) again :-)
>>
>> Sorry to keep nudging you on this often. The longer we wait for this, the
>> more churn it will cause later on. That's why I'm being persistent on this.
>> Also, once this goes in, I can start working on upstreaming MSM clock
>> support.
<SNIP>
> TL;DR: I think a combination of your change to expose the
> not-so-private parts of struct clk into struct clk_hw are OK and have
> real benefits for the clk-provider.h code. However we need to
> implement it such that all the statically initialized data can be
> __initdata.
Sounds like a reasonable compromise.
> My only concern with this series is that platform clock code will
> access struct clk_hw members without the appropriate lock held (namely
> prepare_lock). I'm a bit worried that there might be a case where
> some clock code access clk_hw->name when clk_hw has somehow been
> destroyed/altered (e.g. if clk_put every finally gets implemented...).
> Besides clk_put are there any real instances where this might happen?
This problem is true for any struct/field marked as __init_data. So, I
don't think this is a real problem. If someone is stupid enough to mark
their data as __init_data and access them later, then there is not much
we can do. Also, I believe the compiler throws out some warning when you
try to access __init_data from non-init code.
> I'll be pushing my fixes branch out to the list soon. Do you want to
> rebase this change on top of it taking into account the __initdata
> bits?
I thought it might be easier for you to base your changes on top of my
patch. But I can try to rebase mine on top of your changes. Hopefully
your fixes aren't crazy big/complex.
This is a busy week for me at work. I will try to send a patch in a day
or two.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-11 19:57 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-11 19:57 UTC (permalink / raw)
To: linux-arm-kernel
On 04/11/2012 10:59 AM, Turquette, Mike wrote:
> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org> wrote:
>> (*nudge*) (*nudge*) again :-)
>>
>> Sorry to keep nudging you on this often. The longer we wait for this, the
>> more churn it will cause later on. That's why I'm being persistent on this.
>> Also, once this goes in, I can start working on upstreaming MSM clock
>> support.
<SNIP>
> TL;DR: I think a combination of your change to expose the
> not-so-private parts of struct clk into struct clk_hw are OK and have
> real benefits for the clk-provider.h code. However we need to
> implement it such that all the statically initialized data can be
> __initdata.
Sounds like a reasonable compromise.
> My only concern with this series is that platform clock code will
> access struct clk_hw members without the appropriate lock held (namely
> prepare_lock). I'm a bit worried that there might be a case where
> some clock code access clk_hw->name when clk_hw has somehow been
> destroyed/altered (e.g. if clk_put every finally gets implemented...).
> Besides clk_put are there any real instances where this might happen?
This problem is true for any struct/field marked as __init_data. So, I
don't think this is a real problem. If someone is stupid enough to mark
their data as __init_data and access them later, then there is not much
we can do. Also, I believe the compiler throws out some warning when you
try to access __init_data from non-init code.
> I'll be pushing my fixes branch out to the list soon. Do you want to
> rebase this change on top of it taking into account the __initdata
> bits?
I thought it might be easier for you to base your changes on top of my
patch. But I can try to rebase mine on top of your changes. Hopefully
your fixes aren't crazy big/complex.
This is a busy week for me at work. I will try to send a patch in a day
or two.
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.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-04-11 19:57 ` Saravana Kannan
@ 2012-04-11 20:17 ` Turquette, Mike
-1 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-04-11 20:17 UTC (permalink / raw)
To: Saravana Kannan
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On Wed, Apr 11, 2012 at 12:57 PM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On 04/11/2012 10:59 AM, Turquette, Mike wrote:
>> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org>
>> My only concern with this series is that platform clock code will
>> access struct clk_hw members without the appropriate lock held (namely
>> prepare_lock). I'm a bit worried that there might be a case where
>> some clock code access clk_hw->name when clk_hw has somehow been
>> destroyed/altered (e.g. if clk_put every finally gets implemented...).
>> Besides clk_put are there any real instances where this might happen?
>
> This problem is true for any struct/field marked as __init_data. So, I don't
> think this is a real problem. If someone is stupid enough to mark their data
> as __init_data and access them later, then there is not much we can do.
> Also, I believe the compiler throws out some warning when you try to access
> __init_data from non-init code.
I'm referring to platform clock code accessing clk_hw->name or
clk_hw->parent_names AFTER the core code has copied the initialization
data. So this isn't an __initdata problem as much as it is a design
issue with exposing some members of struct clk_hw. I think that this
is basically OK since the benefits of not having to use so many
helpers functions in platform clock code is obvious and if a platform
gets bitten by this then they will learn the hard way to honor the
locking semantics outlined in Documentation/clk.txt
>> I'll be pushing my fixes branch out to the list soon. Do you want to
>> rebase this change on top of it taking into account the __initdata
>> bits?
>
> I thought it might be easier for you to base your changes on top of my
> patch. But I can try to rebase mine on top of your changes. Hopefully your
> fixes aren't crazy big/complex.
I don't think the fixes are a big deal, especially in the core code.
> This is a busy week for me at work. I will try to send a patch in a day or
> two.
OK. I might take a swing at it myself if I have time.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-11 20:17 ` Turquette, Mike
0 siblings, 0 replies; 242+ messages in thread
From: Turquette, Mike @ 2012-04-11 20:17 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 11, 2012 at 12:57 PM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On 04/11/2012 10:59 AM, Turquette, Mike wrote:
>> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org>
>> My only concern with this series is that platform clock code will
>> access struct clk_hw members without the appropriate lock held (namely
>> prepare_lock). ?I'm a bit worried that there might be a case where
>> some clock code access clk_hw->name when clk_hw has somehow been
>> destroyed/altered (e.g. if clk_put every finally gets implemented...).
>> ?Besides clk_put are there any real instances where this might happen?
>
> This problem is true for any struct/field marked as __init_data. So, I don't
> think this is a real problem. If someone is stupid enough to mark their data
> as __init_data and access them later, then there is not much we can do.
> Also, I believe the compiler throws out some warning when you try to access
> __init_data from non-init code.
I'm referring to platform clock code accessing clk_hw->name or
clk_hw->parent_names AFTER the core code has copied the initialization
data. So this isn't an __initdata problem as much as it is a design
issue with exposing some members of struct clk_hw. I think that this
is basically OK since the benefits of not having to use so many
helpers functions in platform clock code is obvious and if a platform
gets bitten by this then they will learn the hard way to honor the
locking semantics outlined in Documentation/clk.txt
>> I'll be pushing my fixes branch out to the list soon. ?Do you want to
>> rebase this change on top of it taking into account the __initdata
>> bits?
>
> I thought it might be easier for you to base your changes on top of my
> patch. But I can try to rebase mine on top of your changes. Hopefully your
> fixes aren't crazy big/complex.
I don't think the fixes are a big deal, especially in the core code.
> This is a busy week for me at work. I will try to send a patch in a day or
> two.
OK. I might take a swing at it myself if I have time.
Regards,
Mike
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
2012-04-11 20:17 ` Turquette, Mike
(?)
@ 2012-04-11 20:21 ` Saravana Kannan
-1 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-11 20:21 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 04/11/2012 01:17 PM, Turquette, Mike wrote:
> On Wed, Apr 11, 2012 at 12:57 PM, Saravana Kannan
> <skannan@codeaurora.org> wrote:
>> On 04/11/2012 10:59 AM, Turquette, Mike wrote:
>>> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org>
>>> My only concern with this series is that platform clock code will
>>> access struct clk_hw members without the appropriate lock held (namely
>>> prepare_lock). I'm a bit worried that there might be a case where
>>> some clock code access clk_hw->name when clk_hw has somehow been
>>> destroyed/altered (e.g. if clk_put every finally gets implemented...).
>>> Besides clk_put are there any real instances where this might happen?
>>
>> This problem is true for any struct/field marked as __init_data. So, I don't
>> think this is a real problem. If someone is stupid enough to mark their data
>> as __init_data and access them later, then there is not much we can do.
>> Also, I believe the compiler throws out some warning when you try to access
>> __init_data from non-init code.
>
> I'm referring to platform clock code accessing clk_hw->name or
> clk_hw->parent_names AFTER the core code has copied the initialization
> data. So this isn't an __initdata problem as much as it is a design
> issue with exposing some members of struct clk_hw. I think that this
> is basically OK since the benefits of not having to use so many
> helpers functions in platform clock code is obvious and if a platform
> gets bitten by this then they will learn the hard way to honor the
> locking semantics outlined in Documentation/clk.txt
That's what I meant too. The platform code and the static init data will
most likely be written by the same dev. So, hopefully they know what
they are doing.
>
>>> I'll be pushing my fixes branch out to the list soon. Do you want to
>>> rebase this change on top of it taking into account the __initdata
>>> bits?
>>
>> I thought it might be easier for you to base your changes on top of my
>> patch. But I can try to rebase mine on top of your changes. Hopefully your
>> fixes aren't crazy big/complex.
>
> I don't think the fixes are a big deal, especially in the core code.
>
>> This is a busy week for me at work. I will try to send a patch in a day or
>> two.
>
> OK. I might take a swing at it myself if I have time.
I still need to make the changes to add the copying part. So, don't
bother with taking a swing at it. If you want to help out, help with
rebasing it on top of your fixes would be appreciated. But based on what
you said, it should be hard.
TLDR: Just wait for me to send out the patches. :)
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-11 20:21 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-11 20:21 UTC (permalink / raw)
To: Turquette, Mike
Cc: Sascha Hauer, Andrew Lunn, Grant Likely, Jamie Iles, Jeremy Kerr,
Magnus Damm, Deepak Saxena, linux-arm-kernel, Arnd Bergman,
linux-arm-msm, Rob Herring, Russell King, Thomas Gleixner,
Richard Zhao, Shawn Guo, Paul Walmsley, Linus Walleij,
Mark Brown, Stephen Boyd, linux-kernel, Amit Kucheria, Shawn Guo
On 04/11/2012 01:17 PM, Turquette, Mike wrote:
> On Wed, Apr 11, 2012 at 12:57 PM, Saravana Kannan
> <skannan@codeaurora.org> wrote:
>> On 04/11/2012 10:59 AM, Turquette, Mike wrote:
>>> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org>
>>> My only concern with this series is that platform clock code will
>>> access struct clk_hw members without the appropriate lock held (namely
>>> prepare_lock). I'm a bit worried that there might be a case where
>>> some clock code access clk_hw->name when clk_hw has somehow been
>>> destroyed/altered (e.g. if clk_put every finally gets implemented...).
>>> Besides clk_put are there any real instances where this might happen?
>>
>> This problem is true for any struct/field marked as __init_data. So, I don't
>> think this is a real problem. If someone is stupid enough to mark their data
>> as __init_data and access them later, then there is not much we can do.
>> Also, I believe the compiler throws out some warning when you try to access
>> __init_data from non-init code.
>
> I'm referring to platform clock code accessing clk_hw->name or
> clk_hw->parent_names AFTER the core code has copied the initialization
> data. So this isn't an __initdata problem as much as it is a design
> issue with exposing some members of struct clk_hw. I think that this
> is basically OK since the benefits of not having to use so many
> helpers functions in platform clock code is obvious and if a platform
> gets bitten by this then they will learn the hard way to honor the
> locking semantics outlined in Documentation/clk.txt
That's what I meant too. The platform code and the static init data will
most likely be written by the same dev. So, hopefully they know what
they are doing.
>
>>> I'll be pushing my fixes branch out to the list soon. Do you want to
>>> rebase this change on top of it taking into account the __initdata
>>> bits?
>>
>> I thought it might be easier for you to base your changes on top of my
>> patch. But I can try to rebase mine on top of your changes. Hopefully your
>> fixes aren't crazy big/complex.
>
> I don't think the fixes are a big deal, especially in the core code.
>
>> This is a busy week for me at work. I will try to send a patch in a day or
>> two.
>
> OK. I might take a swing at it myself if I have time.
I still need to make the changes to add the copying part. So, don't
bother with taking a swing at it. If you want to help out, help with
rebasing it on top of your fixes would be appreciated. But based on what
you said, it should be hard.
TLDR: Just wait for me to send out the patches. :)
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
* [PATCH 2/2] clk: Move init fields from clk to clk_hw
@ 2012-04-11 20:21 ` Saravana Kannan
0 siblings, 0 replies; 242+ messages in thread
From: Saravana Kannan @ 2012-04-11 20:21 UTC (permalink / raw)
To: linux-arm-kernel
On 04/11/2012 01:17 PM, Turquette, Mike wrote:
> On Wed, Apr 11, 2012 at 12:57 PM, Saravana Kannan
> <skannan@codeaurora.org> wrote:
>> On 04/11/2012 10:59 AM, Turquette, Mike wrote:
>>> On Thu, Apr 5, 2012 at 6:30 PM, Saravana Kannan<skannan@codeaurora.org>
>>> My only concern with this series is that platform clock code will
>>> access struct clk_hw members without the appropriate lock held (namely
>>> prepare_lock). I'm a bit worried that there might be a case where
>>> some clock code access clk_hw->name when clk_hw has somehow been
>>> destroyed/altered (e.g. if clk_put every finally gets implemented...).
>>> Besides clk_put are there any real instances where this might happen?
>>
>> This problem is true for any struct/field marked as __init_data. So, I don't
>> think this is a real problem. If someone is stupid enough to mark their data
>> as __init_data and access them later, then there is not much we can do.
>> Also, I believe the compiler throws out some warning when you try to access
>> __init_data from non-init code.
>
> I'm referring to platform clock code accessing clk_hw->name or
> clk_hw->parent_names AFTER the core code has copied the initialization
> data. So this isn't an __initdata problem as much as it is a design
> issue with exposing some members of struct clk_hw. I think that this
> is basically OK since the benefits of not having to use so many
> helpers functions in platform clock code is obvious and if a platform
> gets bitten by this then they will learn the hard way to honor the
> locking semantics outlined in Documentation/clk.txt
That's what I meant too. The platform code and the static init data will
most likely be written by the same dev. So, hopefully they know what
they are doing.
>
>>> I'll be pushing my fixes branch out to the list soon. Do you want to
>>> rebase this change on top of it taking into account the __initdata
>>> bits?
>>
>> I thought it might be easier for you to base your changes on top of my
>> patch. But I can try to rebase mine on top of your changes. Hopefully your
>> fixes aren't crazy big/complex.
>
> I don't think the fixes are a big deal, especially in the core code.
>
>> This is a busy week for me at work. I will try to send a patch in a day or
>> two.
>
> OK. I might take a swing at it myself if I have time.
I still need to make the changes to add the copying part. So, don't
bother with taking a swing at it. If you want to help out, help with
rebasing it on top of your fixes would be appreciated. But based on what
you said, it should be hard.
TLDR: Just wait for me to send out the patches. :)
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 242+ messages in thread
end of thread, other threads:[~2012-04-11 20:21 UTC | newest]
Thread overview: 242+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-16 6:11 [PATCH v7 0/3] common clk framework Mike Turquette
2012-03-16 6:11 ` Mike Turquette
2012-03-16 6:11 ` [PATCH v7 1/3] Documentation: common clk API Mike Turquette
2012-03-16 6:11 ` Mike Turquette
2012-03-16 8:25 ` Linus Walleij
2012-03-16 8:25 ` Linus Walleij
2012-03-16 10:29 ` Thomas Gleixner
2012-03-16 10:29 ` Thomas Gleixner
2012-03-16 11:14 ` Amit Kucheria
2012-03-16 11:14 ` Amit Kucheria
2012-03-16 12:18 ` Arnd Bergmann
2012-03-16 12:18 ` Arnd Bergmann
2012-03-16 20:57 ` Arnd Bergmann
2012-03-16 20:57 ` Arnd Bergmann
2012-03-16 21:40 ` Turquette, Mike
2012-03-16 21:40 ` Turquette, Mike
2012-03-16 21:50 ` Nicolas Pitre
2012-03-16 21:50 ` Nicolas Pitre
2012-03-16 22:21 ` Paul Walmsley
2012-03-16 22:21 ` Paul Walmsley
2012-03-16 22:21 ` Paul Walmsley
2012-03-16 22:33 ` Turquette, Mike
2012-03-16 22:33 ` Turquette, Mike
2012-03-17 9:05 ` Arnd Bergmann
2012-03-17 9:05 ` Arnd Bergmann
2012-03-17 9:05 ` Arnd Bergmann
2012-03-17 18:02 ` Turquette, Mike
2012-03-17 18:02 ` Turquette, Mike
2012-03-17 18:02 ` Turquette, Mike
2012-03-17 18:33 ` Arnd Bergmann
2012-03-17 18:33 ` Arnd Bergmann
2012-03-17 18:33 ` Arnd Bergmann
2012-03-17 20:29 ` Sascha Hauer
2012-03-17 20:29 ` Sascha Hauer
2012-03-17 20:29 ` Sascha Hauer
2012-03-17 21:13 ` Arnd Bergmann
2012-03-17 21:13 ` Arnd Bergmann
2012-03-17 21:13 ` Arnd Bergmann
2012-03-20 23:40 ` Paul Walmsley
2012-03-20 23:40 ` Paul Walmsley
2012-03-21 8:59 ` Arnd Bergmann
2012-03-21 8:59 ` Arnd Bergmann
2012-03-16 23:47 ` Sascha Hauer
2012-03-16 23:47 ` Sascha Hauer
2012-03-16 23:47 ` Sascha Hauer
2012-03-17 0:54 ` Rob Herring
2012-03-17 0:54 ` Rob Herring
2012-03-17 0:54 ` Rob Herring
2012-03-17 3:38 ` Saravana Kannan
2012-03-17 3:38 ` Saravana Kannan
2012-03-17 3:38 ` Saravana Kannan
2012-03-20 23:31 ` Paul Walmsley
2012-03-20 23:31 ` Paul Walmsley
2012-03-20 23:31 ` Paul Walmsley
2012-03-21 3:15 ` Nicolas Pitre
2012-03-21 3:15 ` Nicolas Pitre
2012-03-21 3:15 ` Nicolas Pitre
2012-03-21 3:26 ` Saravana Kannan
2012-03-21 3:26 ` Saravana Kannan
2012-03-21 3:26 ` Saravana Kannan
2012-03-21 7:44 ` Paul Walmsley
2012-03-21 7:44 ` Paul Walmsley
2012-03-21 7:44 ` Paul Walmsley
2012-03-21 9:10 ` Sascha Hauer
2012-03-21 9:10 ` Sascha Hauer
2012-03-21 9:10 ` Sascha Hauer
2012-03-21 18:38 ` Saravana Kannan
2012-03-21 18:38 ` Saravana Kannan
2012-03-21 18:38 ` Saravana Kannan
2012-03-21 19:07 ` Mark Brown
2012-03-21 19:07 ` Mark Brown
2012-03-21 19:07 ` Mark Brown
2012-03-21 19:33 ` Tony Lindgren
2012-03-21 19:33 ` Tony Lindgren
2012-03-21 19:33 ` Tony Lindgren
2012-03-21 19:41 ` Saravana Kannan
2012-03-21 19:41 ` Saravana Kannan
2012-03-21 19:41 ` Saravana Kannan
2012-03-21 19:56 ` Mark Brown
2012-03-21 19:56 ` Mark Brown
2012-03-21 19:56 ` Mark Brown
2012-03-21 20:04 ` Saravana Kannan
2012-03-21 20:04 ` Saravana Kannan
2012-03-21 20:04 ` Saravana Kannan
2012-03-21 20:10 ` Mark Brown
2012-03-21 20:10 ` Mark Brown
2012-03-21 20:10 ` Mark Brown
2012-03-22 0:42 ` Russell King - ARM Linux
2012-03-22 0:42 ` Russell King - ARM Linux
2012-03-22 0:42 ` Russell King - ARM Linux
2012-03-21 7:30 ` Paul Walmsley
2012-03-21 7:30 ` Paul Walmsley
2012-03-21 7:30 ` Paul Walmsley
2012-03-21 13:23 ` Nicolas Pitre
2012-03-21 13:23 ` Nicolas Pitre
2012-03-21 13:23 ` Nicolas Pitre
2012-03-16 6:11 ` [PATCH v7 2/3] clk: introduce the common clock framework Mike Turquette
2012-03-16 6:11 ` Mike Turquette
2012-03-17 3:28 ` Saravana Kannan
2012-03-17 3:28 ` Saravana Kannan
2012-03-19 18:56 ` Turquette, Mike
2012-03-19 18:56 ` Turquette, Mike
2012-03-19 19:13 ` Saravana Kannan
2012-03-19 19:13 ` Saravana Kannan
2012-03-19 19:33 ` Turquette, Mike
2012-03-19 19:33 ` Turquette, Mike
2012-03-19 19:49 ` Saravana Kannan
2012-03-19 19:49 ` Saravana Kannan
2012-03-20 3:38 ` [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn Saravana Kannan
2012-03-20 3:38 ` Saravana Kannan
2012-03-20 3:38 ` [PATCH 2/2] clk: Move init fields from clk to clk_hw Saravana Kannan
2012-03-20 3:38 ` Saravana Kannan
2012-03-20 7:20 ` Shawn Guo
2012-03-20 7:20 ` Shawn Guo
2012-03-20 7:54 ` Saravana Kannan
2012-03-20 7:54 ` Saravana Kannan
2012-03-20 7:54 ` Saravana Kannan
2012-03-20 8:13 ` Shawn Guo
2012-03-20 8:13 ` Shawn Guo
2012-03-20 9:40 ` Sascha Hauer
2012-03-20 9:40 ` Sascha Hauer
2012-03-20 10:17 ` Saravana Kannan
2012-03-20 10:17 ` Saravana Kannan
2012-03-20 10:17 ` Saravana Kannan
2012-03-20 18:14 ` Sascha Hauer
2012-03-20 18:14 ` Sascha Hauer
2012-03-20 20:14 ` Saravana Kannan
2012-03-20 20:14 ` Saravana Kannan
2012-03-20 22:40 ` Sascha Hauer
2012-03-20 22:40 ` Sascha Hauer
2012-03-22 3:23 ` Shawn Guo
2012-03-22 3:23 ` Shawn Guo
2012-03-20 14:18 ` Shawn Guo
2012-03-20 14:18 ` Shawn Guo
2012-03-20 18:10 ` Sascha Hauer
2012-03-20 18:10 ` Sascha Hauer
2012-03-20 20:06 ` Saravana Kannan
2012-03-20 20:06 ` Saravana Kannan
2012-03-20 23:12 ` Sascha Hauer
2012-03-20 23:12 ` Sascha Hauer
2012-03-21 1:47 ` Turquette, Mike
2012-03-21 1:47 ` Turquette, Mike
2012-03-21 3:01 ` Saravana Kannan
2012-03-21 3:01 ` Saravana Kannan
2012-03-27 4:35 ` Saravana Kannan
2012-03-27 4:35 ` Saravana Kannan
2012-03-27 18:49 ` Turquette, Mike
2012-03-27 18:49 ` Turquette, Mike
2012-03-27 22:27 ` Saravana Kannan
2012-03-27 22:27 ` Saravana Kannan
2012-04-06 1:30 ` Saravana Kannan
2012-04-06 1:30 ` Saravana Kannan
2012-04-11 17:59 ` Turquette, Mike
2012-04-11 17:59 ` Turquette, Mike
2012-04-11 19:57 ` Saravana Kannan
2012-04-11 19:57 ` Saravana Kannan
2012-04-11 19:57 ` Saravana Kannan
2012-04-11 20:17 ` Turquette, Mike
2012-04-11 20:17 ` Turquette, Mike
2012-04-11 20:21 ` Saravana Kannan
2012-04-11 20:21 ` Saravana Kannan
2012-04-11 20:21 ` Saravana Kannan
2012-03-20 23:47 ` Paul Walmsley
2012-03-20 23:47 ` Paul Walmsley
2012-03-21 9:16 ` Sascha Hauer
2012-03-21 9:16 ` Sascha Hauer
2012-03-20 7:19 ` [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn Sascha Hauer
2012-03-20 7:19 ` Sascha Hauer
2012-03-20 7:46 ` Saravana Kannan
2012-03-20 7:46 ` Saravana Kannan
2012-03-20 7:46 ` Saravana Kannan
2012-03-21 0:13 ` Turquette, Mike
2012-03-21 0:13 ` Turquette, Mike
2012-03-21 2:32 ` Saravana Kannan
2012-03-21 2:32 ` Saravana Kannan
2012-03-21 5:45 ` Turquette, Mike
2012-03-21 5:45 ` Turquette, Mike
2012-03-21 6:33 ` Saravana Kannan
2012-03-21 6:33 ` Saravana Kannan
2012-03-21 6:33 ` Saravana Kannan
2012-03-21 9:07 ` Russell King - ARM Linux
2012-03-21 9:07 ` Russell King - ARM Linux
2012-03-21 19:56 ` Turquette, Mike
2012-03-21 19:56 ` Turquette, Mike
2012-03-18 13:46 ` [PATCH v7 2/3] clk: introduce the common clock framework Shawn Guo
2012-03-18 13:46 ` Shawn Guo
2012-03-19 18:58 ` Turquette, Mike
2012-03-19 18:58 ` Turquette, Mike
2012-03-18 14:07 ` Shawn Guo
2012-03-18 14:07 ` Shawn Guo
2012-03-19 19:00 ` Turquette, Mike
2012-03-19 19:00 ` Turquette, Mike
2012-03-19 11:22 ` Rajendra Nayak
2012-03-19 11:22 ` Rajendra Nayak
2012-03-19 11:28 ` Sascha Hauer
2012-03-19 11:28 ` Sascha Hauer
2012-03-19 19:09 ` Turquette, Mike
2012-03-19 19:09 ` Turquette, Mike
2012-03-19 19:53 ` Turquette, Mike
2012-03-19 19:53 ` Turquette, Mike
2012-03-20 14:02 ` Shawn Guo
2012-03-20 14:02 ` Shawn Guo
2012-03-20 17:46 ` Saravana Kannan
2012-03-20 17:46 ` Saravana Kannan
2012-03-20 23:53 ` Turquette, Mike
2012-03-20 23:53 ` Turquette, Mike
2012-03-21 3:10 ` Saravana Kannan
2012-03-21 3:10 ` Saravana Kannan
2012-03-23 21:33 ` Saravana Kannan
2012-03-23 21:33 ` Saravana Kannan
2012-03-23 21:39 ` Turquette, Mike
2012-03-23 21:39 ` Turquette, Mike
2012-03-23 21:51 ` Saravana Kannan
2012-03-23 21:51 ` Saravana Kannan
2012-03-23 22:12 ` Saravana Kannan
2012-03-23 22:12 ` Saravana Kannan
2012-03-23 22:32 ` Turquette, Mike
2012-03-23 22:32 ` Turquette, Mike
2012-03-23 23:04 ` Saravana Kannan
2012-03-23 23:04 ` Saravana Kannan
2012-03-23 23:28 ` Turquette, Mike
2012-03-23 23:28 ` Turquette, Mike
2012-03-28 3:06 ` Saravana Kannan
2012-03-28 3:06 ` Saravana Kannan
2012-03-28 17:08 ` Turquette, Mike
2012-03-28 17:08 ` Turquette, Mike
2012-03-28 22:25 ` Saravana Kannan
2012-03-28 22:25 ` Saravana Kannan
2012-03-28 23:49 ` Turquette, Mike
2012-03-28 23:49 ` Turquette, Mike
2012-03-20 23:46 ` Turquette, Mike
2012-03-20 23:46 ` Turquette, Mike
2012-03-21 5:46 ` Shawn Guo
2012-03-21 5:46 ` Shawn Guo
2012-03-16 6:11 ` [PATCH v7 3/3] clk: basic clock hardware types Mike Turquette
2012-03-16 6:11 ` Mike Turquette
2012-03-16 12:25 ` Richard Zhao
2012-03-16 12:25 ` Richard Zhao
2012-03-16 16:51 ` Turquette, Mike
2012-03-16 16:51 ` Turquette, Mike
2012-03-16 10:57 ` [PATCH v7 0/3] common clk framework Sascha Hauer
2012-03-16 10:57 ` Sascha Hauer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.