[PATCH v7 3/3] clk: basic clock hardware types
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 mturque...@linaro.org
Signed-off-by: Mike Turquette mturque...@ti.com
Reviewed-by: Andrew Lunn and...@lunn.ch
Tested-by: Andrew Lunn and...@lunn.ch
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Jeremy Kerr jeremy.k...@canonical.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Arnd Bergman arnd.bergm...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Shawn Guo shawn@freescale.com
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Jamie Iles ja...@jamieiles.com
Cc: Richard Zhao richard.z...@linaro.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Deepak Saxena dsax...@linaro.org
Cc: Grant Likely grant.lik...@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 000..d5ac6a7
--- /dev/null
+++ b/drivers/clk/clk-divider.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix s.ha...@pengutronix.de
+ * Copyright (C) 2011 Richard Zhao, Linaro richard.z...@linaro.org
+ * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturque...@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
[PATCH v7 0/3] common clk framework
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v7 1/3] Documentation: common clk API
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 mturque...@linaro.org
Signed-off-by: Mike Turquette mturque...@ti.com
Reviewed-by: Andrew Lunn and...@lunn.ch
Cc: Russell King li...@arm.linux.org.uk
Cc: Jeremy Kerr jeremy.k...@canonical.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Arnd Bergman arnd.bergm...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Shawn Guo shawn@freescale.com
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Richard Zhao richard.z...@linaro.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Deepak Saxena dsax...@linaro.org
Cc: Grant Likely grant.lik...@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 000..1943fae
--- /dev/null
+++ b/Documentation/clk.txt
@@ -0,0 +1,233 @@
+ The Common Clk Framework
+ Mike Turquette mturque...@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
Re: [PATCH v6 2/3] clk: introduce the common clock framework
On Thu, Mar 15, 2012 at 2:43 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Wed, Mar 14, 2012 at 05:51:48PM -0700, Turquette, Mike wrote:
@@ -84,9 +78,9 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
for (i = 1; i = maxdiv; i++) {
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
- MULT_ROUND_UP(rate, i));
+ (rate * i));
I think MULT_ROUND_UP is the right thing to use here (not sure if this
is a good name though)
Consider we want to have an output rate of 33Hz. Now acceptable input
rates for a divider value of 3 would be 99, 100 and 101Hz, so we have
to call round_rate for the parent with 101Hz which includes 100 and
99Hz.
We're back to the point Rob brought up about .round_rate rounding up
or down. We really need a least-upper-bounds or greatest-lower-bounds
flag, similar to how CPUfreq selects target frequencies today. I'm
freezing features for this patchset now, so I'll keep your
MULT_ROUND_UP approach and some day I'll fix .round_rate for good.
If you have problems with your PLL than most likely because it does
something different on clk_round_rate than it does in clk_set_rate,
for example clk_round_rate(1) returns 1, but clk_set_rate then
sets the rate due to some rounding error. Being consistent between
round_rate and set_rate is very important for this mechanism to work
properly. It did cost me some nerves to get it right for the divider
(and even more nerves to figure out why it is correct the way it works)
What I'd like to do is request the *exact* frequency I want when
passing in a rate to my PLLs .round_rate. Due to the way that my MN
dividers are calculated, and due to some jitter avoidance code, it is
bad for me to request 60001 Hz when I really want 600MHz exactly.
Anyways I fixed this up on my end enough to work with MULT_ROUND_UP,
so that can stay for the immediate future.
now = parent_rate / i;
- if (now = rate now = best) {
+ if (now = rate now best) {
This change is an optimization, but should be unrelated to your PLL
problem, right?
MULT_ROUND_UP yields multiples of 'rate' plus an incrementing value (m
- 1). Without that incrementing value added to the rate passed into
__clk_round_rate the for loop above will always max out the divider.
To illustrate:
The rate we want is 300MHz. Without MULT_ROUND_UP the for loop will
start yielding these combinations:
__clk_round_rate(parent, 300MHz), divide-by-1
__clk_round_rate(parent, 600MHz), divide-by-2
__clk_round_rate(parent, 900MHz), divide-by-3
__clk_round_rate(parent, 1200MHz), divide-by-4
...etc...
These all yield the desired 300MHz for our divider so it just keeps
going until you max out the divider and requests some crazy rate for
the parent. On most hardware that I am aware of it is desirable to
keep the divider as low as possible so the change to the conditional
prevents us from overwriting best every single time while keeping the
divider low. So yes, it is an optimization, but it is also quite
necessary without MULT_ROUND_UP.
Anyways I've kept MULT_ROUND_UP exactly as-is with the exception that
I've added that small optimization to keep dividers low. I hope there
are no objections to that.
Regards,
Mike
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- |
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Changes to Blueprint work items in Launchpad
On 15 March 2012 21:53, Guilherme Salgado wrote: Hi there, Launchpad now supports blueprint work items natively and we've already migrated the work items from the whiteboards of most Linaro Blueprints. Most of us wouldn't even notice those changes because we still have a text field to enter work items and it uses the exact same format we used before. In the future we might improve the user experience but for now we decided to keep the same UI and format. There's a blog post with more information, if you're curious: http://blog.launchpad.net/ In practice this just means you'll enter the work items in the 'Work items' field instead of the whiteboard (the meta info [acceptance/headline] still go there, though), but the work items of some of our Blueprints could not be migrated, so I've spammed^W sent an email to the owner/assignee of each of them. It would be nice if those of you who receive that email migrated your BPs manually but even if you don't status.l.o is setup to pull work items from both the new field and the whiteboard, so you'll still see your work items there. And if you're curious why we're doing all this, it's so that we can implement the monthly engineering views in Launchpad: https://dev.launchpad.net/Projects/WorkItems Michael Hudson's LP work item editor has been updated to reflect this changes: http://bazaar.launchpad.net/~gm-dev-launchpad/launchpad-gm-scripts/master/download/head:/lp_work_item_editor.-20110831002947-b6i8m4hfj3n89bgf-1/lp_work_item_editor.user.js Cheers, -- Fathi Boudra Linaro Release Manager | Validation Project Manager Linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v10] mfd: Add anatop mfd driver
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
Anatop provides regulators and thermal.
This driver handles the address space and the operation of the mfd device.
Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org
Acked-by: Shawn Guo shawn@linaro.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Venu Byravarasu vbyravar...@nvidia.com
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Arnd Bergmann a...@arndb.de
Cc: Rob Lee rob@linaro.org
---
drivers/mfd/Kconfig|8 +++
drivers/mfd/Makefile |1 +
drivers/mfd/anatop-mfd.c | 137
include/linux/mfd/anatop.h | 40 +
4 files changed, 186 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/anatop-mfd.c
create mode 100644 include/linux/mfd/anatop.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 82da448..c3a9f31 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -846,6 +846,14 @@ config MFD_INTEL_MSIC
Passage) chip. This chip embeds audio, battery, GPIO, etc.
devices used in Intel Medfield platforms.
+config MFD_ANATOP
+ bool Support for Freescale i.MX on-chip ANATOP controller
+ depends on SOC_IMX6Q
+ help
+ Select this option to enable Freescale i.MX on-chip ANATOP
+ MFD controller. This controller embeds regulator and
+ thermal devices for Freescale i.MX platforms.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 27430d3..42c8bf6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
obj-$(CONFIG_MFD_S5M_CORE) += s5m-core.o s5m-irq.o
+obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
diff --git a/drivers/mfd/anatop-mfd.c b/drivers/mfd/anatop-mfd.c
new file mode 100644
index 000..2af4248
--- /dev/null
+++ b/drivers/mfd/anatop-mfd.c
@@ -0,0 +1,137 @@
+/*
+ * Anatop MFD driver
+ *
+ * Copyright (C) 2012 Ying-Chun Liu (PaulLiu) paul@linaro.org
+ * Copyright (C) 2012 Linaro
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_address.h
+#include linux/mfd/anatop.h
+
+u32 anatop_get_bits(struct anatop *adata, u32 addr, int bit_shift,
+ int bit_width)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 bit_width) - 1;
+
+ val = readl(adata-ioreg + addr);
+ val = (val bit_shift) mask;
+
+ return val;
+}
+EXPORT_SYMBOL_GPL(anatop_get_bits);
+
+void anatop_set_bits(struct anatop *adata, u32 addr, int bit_shift,
+int bit_width, u32 data)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 bit_width) - 1;
+
+ spin_lock(adata-reglock);
+ val = readl(adata-ioreg + addr) ~(mask bit_shift);
+ writel((data bit_shift) | val, adata-ioreg + addr);
+ spin_unlock(adata-reglock);
+}
+EXPORT_SYMBOL_GPL(anatop_set_bits);
+
+static const struct of_device_id of_anatop_match[] = {
+ { .compatible = fsl,imx6q-anatop, },
+ { },
+};
+
+static int __devinit
Another Friday, another ARM Porting Jam!
Hello, Continuing on the ARM Porting effort to fix the remaining issues with Precise, we'll be having the ARM Porting Jam this friday as well! The main focus for this Friday, besides the usual FTBFS issues described at http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-report.html, is porting the most packages we can to be multi-arch compatible. This will allow us to increase the list of packages we can easily cross-compile using multi-arch. Wookey got a quite long list of things to do at https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBuildStatus, so please have a look and make sure to get in touch with him at #linaro @ freenode if you need any extra help. Happy porting! -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v10] mfd: Add anatop mfd driver
On Friday 16 March 2012, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is a mfd chip embedded in Freescale i.MX6Q SoC. Anatop provides regulators and thermal. This driver handles the address space and the operation of the mfd device. Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org Acked-by: Shawn Guo shawn@linaro.org Reviewed-by: Arnd Bergmann a...@arndb.de ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturque...@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.wall...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 0/3] common clk framework
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.ha...@pengutronix.de Acked-by: Sascha Hauer s.ha...@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- | ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner t...@linutronix.de wrote: On Fri, 16 Mar 2012, Linus Walleij wrote: On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturque...@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.wall...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) For http access, http://git.linaro.org/gitweb?p=landing-teams/working/samsung/kernel.git;a=summary Search the mailing lists for s5p usb burst to find them. -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- With warm regards, Sachin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) That branch still needs one more patch (attached). -- Mans Rullgard / mru From 2f6d73827ed8e9ca4d815d52022e7639b33c7a3a Mon Sep 17 00:00:00 2001 From: Mans Rullgard mans.rullg...@linaro.org Date: Thu, 15 Mar 2012 13:09:06 + Subject: [PATCH] s5p-ehci: set burst_enable platform callback --- arch/arm/plat-samsung/devs.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 634835c..9d75981 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -1430,6 +1430,8 @@ void __init s5p_ehci_set_platdata(struct s5p_ehci_platdata *pd) npd-phy_init = s5p_usb_phy_init; if (!npd-phy_exit) npd-phy_exit = s5p_usb_phy_exit; + if (!npd-burst_enable) + npd-burst_enable = s5p_ehci_burst_enable; } #endif /* CONFIG_S5P_DEV_USB_EHCI */ -- 1.7.8.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Friday 16 March 2012, Amit Kucheria wrote: On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner t...@linutronix.de wrote: On Fri, 16 Mar 2012, Linus Walleij wrote: On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturque...@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.wall...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 3/3] clk: basic clock hardware types
[...]
+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;
+}
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
Hi Mans On 16 March 2012 11:50, Mans Rullgard mans.rullg...@linaro.org wrote: On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) That branch still needs one more patch (attached). Thanks for looking at this git. Initially I submitted patches with the call-back function http://www.spinics.net/lists/linux-usb/msg59212.html But maintainers don't like to use call-back function, and it was rejected. So Now LT doesn't to use this call-back function but it was -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] usb: gadget: s3c-hsotg: fix kernel panic
Fix kernel panic from s3c_hsotg_udc_stop.
if udc_is_newstyle is true, s3c_hsotg_udc_stop should not
call disconnect, unbind.
As running rmmod g_mass_storage, kernel panic happens.
(composite_unbind+0x14/0x164 [g_mass_storage])
from [c023e950] (s3c_hsotg_udc_stop)
This patch is based on Lukasz Majewski's patches:
[PATCH 0/9] USB: s3c-hsotg: USB S3C-HSOTG driver fixes and code cleanu
in order to test g_mass_storage in Origen board:
Signed-off-by: Sangwook Lee sangwook@linaro.org
---
drivers/usb/gadget/s3c-hsotg.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 4262df8..9925661 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -2883,16 +2883,12 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
for (ep = 0; ep hsotg-num_of_eps; ep++)
s3c_hsotg_ep_disable(hsotg-eps[ep].ep);
- call_gadget(hsotg, disconnect);
-
- driver-unbind(hsotg-gadget);
s3c_hsotg_phy_disable(hsotg);
regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies), hsotg-supplies);
hsotg-driver = NULL;
hsotg-gadget.speed = USB_SPEED_UNKNOWN;
-
- device_del(hsotg-gadget.dev);
+ hsotg-gadget.dev.driver = NULL;
dev_info(hsotg-dev, unregistered gadget driver '%s'\n,
driver-driver.name);
@@ -3526,7 +3522,10 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
s3c_hsotg_delete_debug(hsotg);
- usb_gadget_unregister_driver(hsotg-driver);
+ if (hsotg-driver) {
+ /* should have been done already by driver model core */
+ usb_gadget_unregister_driver(hsotg-driver);
+ }
free_irq(hsotg-irq, hsotg);
iounmap(hsotg-regs);
@@ -3540,6 +3539,7 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
clk_disable(hsotg-clk);
clk_put(hsotg-clk);
+ device_unregister(hsotg-gadget.dev);
kfree(hsotg);
return 0;
}
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 16 March 2012 12:36, Sangwook Lee sangwook@linaro.org wrote: Hi Mans On 16 March 2012 11:50, Mans Rullgard mans.rullg...@linaro.org wrote: On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) That branch still needs one more patch (attached). Thanks for looking at this git. Initially I submitted patches with the call-back function http://www.spinics.net/lists/linux-usb/msg59212.html But maintainers don't like to use call-back function, and it was rejected. So Now LT doesn't to use this call-back function Yes, I saw that, but the tracking branch in git still has the incomplete callback version. -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 16 March 2012 14:55, Mans Rullgard mans.rullg...@linaro.org wrote: On 16 March 2012 12:36, Sangwook Lee sangwook@linaro.org wrote: Hi Mans On 16 March 2012 11:50, Mans Rullgard mans.rullg...@linaro.org wrote: On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) That branch still needs one more patch (attached). Thanks for looking at this git. Initially I submitted patches with the call-back function http://www.spinics.net/lists/linux-usb/msg59212.html But maintainers don't like to use call-back function, and it was rejected. So Now LT doesn't to use this call-back function Yes, I saw that, but the tracking branch in git still has the incomplete callback version. You're right. @Tushar, we need to apply Mans's patch as well. Thanks Mans! -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 03/16/2012 03:35 PM, Sangwook Lee wrote: On 16 March 2012 14:55, Mans Rullgard mans.rullg...@linaro.org wrote: On 16 March 2012 12:36, Sangwook Lee sangwook@linaro.org wrote: Hi Mans On 16 March 2012 11:50, Mans Rullgard mans.rullg...@linaro.org wrote: On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) That branch still needs one more patch (attached). Thanks for looking at this git. Initially I submitted patches with the call-back function http://www.spinics.net/lists/linux-usb/msg59212.html But maintainers don't like to use call-back function, and it was rejected. So Now LT doesn't to use this call-back function Yes, I saw that, but the tracking branch in git still has the incomplete callback version. You're right. @Tushar, we need to apply Mans's patch as well. Thanks a lot for the responses and updates on the kernel patches, I will try to give the LT kernel from git a shot next week. - Jannis ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 3/3] clk: basic clock hardware types
On Fri, Mar 16, 2012 at 5:25 AM, Richard Zhao richard.z...@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;
+}
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v10] mfd: Add anatop mfd driver
On Fri, Mar 16, 2012 at 04:16:56PM +0800, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is a mfd chip embedded in Freescale i.MX6Q SoC. Anatop provides regulators and thermal. This driver handles the address space and the operation of the mfd device. Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linux kernel with rpmsg and possibility for compiling powervr drivers
Hi. I'm currently fumbling around in the dark, trying to find a kernel which I can use to compile the powervr drivers, as well as with rpmsg support. Ideally the rpmsg should already be in the kernel, but I can see that this might be hard, and cherry picking is an ok solution. I'm wondering if one of the ti landing team kernels might be suitable for this, and if one of these is considered a stable kernel? Last kernel I looked at was the LEB 3.1.5+ kernel, release-linux-2011-12, which worked fine for compiling the pvr drivers from rsalveti, but didn't contain rpmsg drivers. When I tried the release-linux-2012-01 kernel, 3.2.0+, it could compile the powervr driver, but didn't contain the rpmsg drivers and didn't actually run, as I got the message 'coherent pool not initialized' from the kernel when trying to allocate for the ehci-omap. The kernel will be run on a device with an omap4460 if this is of interest. I would really appreciate your help on this, as I feel quite lost in all the different branches and tags which reside in the different linaro kernels, so a repo with a stable commit would really help. As most rpmsg implementations I have seen follows the 3.2 kernel, that would really be preferable if I need to cherry pick, but if not I don't really care if it's 3.1 or 3.2. If you have any questions, please do not hesitate to ask them. Best regard Martin Ertsas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linux kernel with rpmsg and possibility for compiling powervr drivers
Sent from Samsung MobileAndy Green andy.gr...@linaro.org wrote:On 03/16/2012 10:46 PM, Somebody in the thread at some point said: If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tilt-android-tracking We also have what's currently only working on I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module. Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then. 1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor syslink. If you check out tilt-3.1 branch from our repo that has working syslink + tiler pieces needed by the mm decode pieces in Ubuntu and will build against SGX dkms. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog So what you are basically saying is forget rpmsg for the time being? Do you know if gst-ducati works with syslink then? thank you so much for your help so far.___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Fri, 16 Mar 2012, Linus Walleij wrote: On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette mturque...@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.wall...@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___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On Fri, Mar 16, 2012, Michael Hope wrote: https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration Is there a separate plan for gcc-4.5 deprecation in source releases? The triplet situation is sad; is there any hope that we fix this upstream? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linux kernel with rpmsg and possibility for compiling powervr drivers
Mertsas, On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas) mert...@cisco.com wrote: Sent from Samsung Mobile Andy Green andy.gr...@linaro.org wrote: On 03/16/2012 10:46 PM, Somebody in the thread at some point said: If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tilt-android-tracking We also have what's currently only working on I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module. Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then. 1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor syslink. If you check out tilt-3.1 branch from our repo that has working syslink + tiler pieces needed by the mm decode pieces in Ubuntu and will build against SGX dkms. I seemed to have missed some conversation here. Just wanted to check if you still have trouble getting a kernel with rpmsg and pvr? I am not aware of the pvr part of things but for the rpmsg stuff, like Andy mentioned the one tilt has is a different from the up-streamed one. You will get a lot more features in the tilt version of it. The flip side being, it is dependent on ion. Can you elaborate what you are trying to achieve with rpmsg? You definitely need tiler driver support too to get h264 decoder working. Personally, I think , you are better off moving to rpmsg, as you can expect more support in future on this. I might not be aware of all the minute details but could help you out on the rpmsg part. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog So what you are basically saying is forget rpmsg for the time being? Do you know if gst-ducati works with syslink then? thank you so much for your help so far. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Thank you and Regards Subbu ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Last call for topics for the 12.03 release of linux-linaro kernel
Greetings, If you haven't submitted your topic(s) for the 12.03 yet, but still plan to, please make sure to do this before the end of Tuesday, March 20. Otherwise the topic wouldn't get into the 12.03 release. Please also provide (attach to email) a config fragment for your topic: a config file snippet with the config options to enable the topic. Here is the current topics list: tracking-armlt-ubuntu-config tracking-unsorted tracking-linaro-android-3.3 tracking-gcl-irqdomain-next tracking-armlt-hdlcd tracking-armlt-vexpress-device-tree tracking-armlt-arm-arch-fixes tracking-armlt-mmc The linux-linaro is currently v3.3-rc7 based, though this hasn't been pushed to git://git.linaro.org/kernel/linux-linaro-tracking.git yet. Thanks, Andrey On 03/08/2012 12:07 AM, Andrey Konovalov wrote: Greetings, I've pushed the baseline for the 12.03 linux-linaro kernel tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. Currently this is v3.3-rc6 plus: - 4 topics from the ARM LT - few commits being carried over from linux-linaro-3.1 This tree is not a history one, it will be rebased fairly often. We are moving to a new process (more details will come later). That's why the call for topics, not patches. If you have something to be included into the 12.03 and the following linux-linaro kernel releases, please send me a link to the git branch to pull from. This must be a permanent location, as this topic branch will be used for all the following releases (until there is a request from the topic owner to stop tracking it). As long as the topic branch merges OK into linux-linaro, it will be present in the linux-linaro releases. The topic branch should be based on recent linux-linaro or mainline Linus tree (like v3.3-rc5 or v3.3-rc6). Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Fri, Mar 16, 2012 at 1:57 PM, Arnd Bergmann a...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote: From: Paul Walmsley p...@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 p...@pwsan.com Cc: Mike Turquette mturque...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v10] mfd: Add anatop mfd driver
Hi, On Fri, Mar 16, 2012 at 04:16:56PM +0800, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is a mfd chip embedded in Freescale i.MX6Q SoC. Anatop provides regulators and thermal. This driver handles the address space and the operation of the mfd device. I applied this one, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
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 p...@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 p...@pwsan.com Cc: Mike Turquette mturque...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
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- | ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linux kernel with rpmsg and possibility for compiling powervr drivers
On 03/17/2012 04:14 AM, Somebody in the thread at some point said: Mertsas, On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas) mert...@cisco.com wrote: Sent from Samsung Mobile Andy Green andy.gr...@linaro.org wrote: On 03/16/2012 10:46 PM, Somebody in the thread at some point said: If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tilt-android-tracking We also have what's currently only working on I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module. Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then. 1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor syslink. If you check out tilt-3.1 branch from our repo that has working syslink + tiler pieces needed by the mm decode pieces in Ubuntu and will build against SGX dkms. I seemed to have missed some conversation here. Just wanted to check if you still have trouble getting a kernel with rpmsg and pvr? I am not aware of the pvr part of things but for the rpmsg stuff, like Andy mentioned the one tilt has is a different from the up-streamed one. You will get a lot more features in the tilt version of it. The flip side being, it is dependent on ion. Can you elaborate what you are trying to achieve with rpmsg? You definitely need tiler driver support too to get h264 decoder working. Personally, I think , you are better off moving to rpmsg, as you can expect more support in future on this. I might not be aware of all the minute details but could help you out on the rpmsg part. Agreed rpmsg has deprecated syslink going on, and medium or long term planning will need to be around that. However for Ubuntu, there's not quite yet anything rpmsg-based that's workable to give him mm decode (it seems to be that he's interested in) that will provide userland pieces he can have as a normal mortal as well. Rob Clark is working on something that should bear fruit soon, Nice guys will provide matching Ubuntu pieces and TILT will integrate it into our tracking. Until then tilt-3.1 + Ubuntu packages already there seems the best choice to getting something known to work end-end quickly. Since it integrates to gstreamer already when he upgrades to rpmsg-based solution (userland too) it should hopefully be transparent. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
