From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/4] clk: introduce the common clock framework
Date: Tue, 6 Mar 2012 20:00:39 +0100 [thread overview]
Message-ID: <20120306190039.GJ3852@pengutronix.de> (raw)
In-Reply-To: <CAJOA=zMs75ZQ24g5PXpSLV3AJzWEo12g86G8+4+ryQR_cTYpzA@mail.gmail.com>
On Mon, Mar 05, 2012 at 12:03:15PM -0800, Turquette, Mike wrote:
> On Sun, Mar 4, 2012 at 11:38 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Sun, Mar 04, 2012 at 04:12:21PM -0800, Turquette, Mike wrote:
> >> >>
> >> >> I believe this patch already does what you suggest, but I might be
> >> >> missing your point.
> >> >
> >> > In include/linux/clk-private.h you expose struct clk outside the core.
> >> > This has to be done to make static initializers possible. There is a big
> >> > warning in this file that it must not be included from files implementing
> >> > struct clk_ops. You can simply avoid this warning by declaring struct clk
> >> > with only a single member:
> >> >
> >> > include/linux/clk.h:
> >> >
> >> > struct clk {
> >> > ? ? ? ?struct clk_internal *internal;
> >> > };
> >> >
> >> > This way everybody knows struct clk (thus can embed it in their static
> >> > initializers), but doesn't know anything about the internal members. Now
> >> > in drivers/clk/clk.c you declare struct clk_internal exactly like struct
> >> > clk was declared before:
> >> >
> >> > struct clk_internal {
> >> > ? ? ? ?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 ? ? ? ? ? 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
> >> > };
> >> >
> >> > An instance of struct clk_internal will be allocated in
> >> > __clk_init/clk_register. Now the private data stays completely inside
> >> > the core and noone can abuse it.
> >>
> >> Hi Sascha,
> >>
> >> I see the disconnect here. ?For OMAP (and possibly other platforms) at
> >> least some clock data is necessary during early boot, before the
> >> regular allocation methods are available (timers for instance).
> >
> > We had this problem on i.MX aswell. It turned out that the timer clock
> > is the only clock that is needed so early. We solved this by moving the
> > clock init to the system timer init function.
>
> When you say "mov[ed] the clock init to the system timer init
> function" do you mean that you statically allocated struct clk and
> used the clk framework api, or instead you just did some direct
> register writes to initialize things properly?
I meant that on i.MX we do the clock tree initialization when kmalloc is
available, see the attached patch for omap4 based on your branch which
does the same for Omap. The first clock you need is the one for the
timer, so you can initialize the clocktree at the beginning of
time_init() and don't need statically initialized clocks anymore.
> >
> > Well, the file is work in progress, you probably fix this before sending
> > it out, but I bet people will include clk-private.h and nobody else
> > notices it.
>
> clock44xx_data.c does not violate that rule. None of the logic that
> implements ops for those clocks is present clock44xx_data.c.
Indeed, I missed that. It only has the ops but not the individual
functions.
> All of
> the code in that file is simply initialization and registration of
> OMAP4 clocks. Many of the clocks are basic clock types (divider,
> multiplexer and fixed-rate are used in that file) with protected code
> drivers/clk/clk-*.c and the remaining clocks are of the struct
> clk_hw_omap variety, which has code spread across several files:
>
> arch/arm/mach-omap2/clock.c
> arch/arm/mach-omap2/clock.h
> arch/arm/mach-omap2/clkt_dpll.c
> arch/arm/mach-omap2/clkt_clksel.c
> arch/arm/mach-omap2/dpll3xxx.c
> arch/arm/mach-omap2/dpll4xxx.c
>
> All of the above files include linux/clk-provider.h, not
> linux/clk-private.h. That code makes heavy use of the
> __clk_get_whatever helpers and shows how a platform might honor the
> layer of separation between struct clk and stuct clk_ops/struct
> clk_foo. You are correct that the code is a work-in-progress, but
> there are no layering violations that I can see.
>
> I also think we are talking past each other to some degree. One point
> I would like to make (and maybe you already know this from code
> review) is that it is unnecessary to have pointers to your parent
> struct clk*'s when either initializing or registering your clocks. In
> fact the existing clk_register_foo functions don't even allow you to
> pass in parent pointers and rely wholly on string name matching. I
> just wanted to point that out in case it went unnoticed, as it is a
> new way of doing things from the previous series and was born out of
> Thomas' review of V4 and multi-parent handling. This also keeps
> device-tree in mind where we might not know the struct clk *pointer at
> compile time for "connecting" discrete devices.
Yes, I've seen this and I really like it. Also the change that
multiplexers return an index to an array instead of the parent
clock is very nice.
Sascha
8<-----------------------------------------------------
ARM omap4: move clocktree init to timer init time so we don't need static clocks
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-omap2/clock44xx_data.c | 4 +++-
arch/arm/mach-omap2/io.c | 1 -
arch/arm/mach-omap2/timer.c | 3 +++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 7f833a7..5aa8dd2 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -6032,7 +6032,9 @@ int __init omap4xxx_clk_init(void)
}
# else
clkdev_add(c);
- __clk_init(NULL, c->clk);
+
+ clk_register(NULL, c->clk->name, c->clk->ops, c->clk->hw,
+ c->clk->parent_names, c->clk->num_parents, c->clk->flags);
#endif
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index eb50c29..8db4380 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -476,7 +476,6 @@ void __init omap4430_init_early(void)
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
omap_hwmod_init_postsetup();
- omap4xxx_clk_init();
}
#endif
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5c9acea..2cca796 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -323,9 +323,12 @@ OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
OMAP_SYS_TIMER(3_secure)
#endif
+int __init omap4xxx_clk_init(void);
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_timer_init(void)
{
+ omap4xxx_clk_init();
#ifdef CONFIG_LOCAL_TIMERS
twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
BUG_ON(!twd_base);
--
1.7.9.1
--
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 |
next prev parent reply other threads:[~2012-03-06 19:00 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-03 8:28 [PATCH v5 0/4] common clk framework Mike Turquette
2012-03-03 8:28 ` [PATCH v5 1/4] Documentation: common clk API Mike Turquette
2012-03-03 8:28 ` [PATCH v5 2/4] clk: Kconfig: add entry for HAVE_CLK_PREPARE Mike Turquette
2012-03-05 2:04 ` Richard Zhao
2012-03-05 19:46 ` Turquette, Mike
2012-03-03 8:29 ` [PATCH v5 3/4] clk: introduce the common clock framework Mike Turquette
2012-03-03 13:31 ` Sascha Hauer
2012-03-03 17:14 ` Turquette, Mike
2012-03-04 11:52 ` Sascha Hauer
2012-03-05 0:12 ` Turquette, Mike
2012-03-05 7:38 ` Sascha Hauer
2012-03-05 20:03 ` Turquette, Mike
2012-03-06 19:00 ` Sascha Hauer [this message]
2012-03-07 21:20 ` Turquette, Mike
2012-03-08 6:27 ` Andrew Lunn
2012-03-08 23:25 ` Sascha Hauer
2012-03-09 7:57 ` Andrew Lunn
2012-03-09 18:25 ` Turquette, Mike
2012-03-19 7:01 ` Shawn Guo
2012-03-19 11:22 ` Sascha Hauer
2012-03-09 18:18 ` Turquette, Mike
2012-03-09 0:51 ` Thomas Gleixner
2012-03-17 3:23 ` Saravana Kannan
2012-03-19 5:38 ` Shawn Guo
2012-03-19 7:42 ` Shawn Guo
2012-03-05 9:22 ` Richard Zhao
2012-03-14 2:03 ` Turquette, Mike
2012-03-13 11:24 ` Sascha Hauer
2012-03-13 23:43 ` Turquette, Mike
2012-03-14 8:48 ` Sascha Hauer
2012-03-14 20:47 ` Turquette, Mike
2012-03-14 21:28 ` Thomas Gleixner
2012-03-14 22:13 ` Turquette, Mike
2012-03-14 22:18 ` Thomas Gleixner
2012-03-03 8:29 ` [PATCH v5 4/4] clk: basic clock hardware types Mike Turquette
2012-03-04 14:26 ` Andrew Lunn
2012-03-04 14:35 ` Andrew Lunn
2012-03-05 0:15 ` Turquette, Mike
2012-03-04 17:42 ` Andrew Lunn
2012-03-05 0:30 ` Turquette, Mike
2012-03-05 8:48 ` Andrew Lunn
2012-03-05 9:29 ` Sascha Hauer
2012-03-05 10:17 ` Andrew Lunn
2012-03-09 23:38 ` Turquette, Mike
2012-03-04 20:33 ` [PATCH] clk: Fix compile errors in DEFINE_CLK_GATE Andrew Lunn
2012-03-05 0:31 ` Turquette, Mike
2012-03-07 21:20 ` [PATCH v5 4/4] clk: basic clock hardware types Sascha Hauer
2012-03-09 22:50 ` Turquette, Mike
2012-03-09 2:34 ` [PATCH v5 0/4] common clk framework Richard Zhao
2012-03-09 9:19 ` Sascha Hauer
2012-03-09 18:35 ` Turquette, Mike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120306190039.GJ3852@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).