From: mturquette@ti.com (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: moving Tegra30 to the common clock framework
Date: Sun, 6 May 2012 17:03:29 -0700 [thread overview]
Message-ID: <20120507000329.GB14559@gmail.com> (raw)
In-Reply-To: <20120503161311.GG20304@tbergstrom-lnx.Nvidia.com>
On 20120503-19:13, Peter De Schrijver wrote:
> Hi,
>
> I started looking into what would be needed to move our tegra30 clock code
> to the common clock framework. The tegra30 clocktree is rather flat. Basically
> there are a bunch of sources (13 PLLs, external audio clocks, osc and 32Khz)
> and peripheral clocks which have a mux (with 4 or more inputs), a divider and
> a gate. So almost every peripheral clock can have multiple parents.
>
> Some questions:
>
> 1) should these peripheral clocks be modelled as 3 different clocks
> (mux -> divider -> gate) or would it be better to make a new clock type for
> this?
>
That is really for you to decide. If the semantics of the existing mux,
divider and gate in drivers/clk/clk-*.c work well for you then I think
the answer is "yes". There is infrastructure for register-access
locking in those common types which might help your complex clocks.
Thanks to the parent rate propagation stuff in clk_set_rate it should be
possible for your drivers to only be aware of the gate and call
clk_set_rate on only that clock, which propagates up to the divider and,
if necessary, again propagates up to the mux.
I encourage you to try that first. But if you find the semantics of
those basic clock types aren't cutting it for you then you must create a
type which is platform-specific.
> 2) how to define the default parent? in many cases the hw reset value isn't
> a very sensible choice, so the kernel probably needs to set a parent of
> many of them if we don't want to rely on bootloader configuration.
The only related thing handled at the framework level is _discovery_ of
the parent during clock registration/initialization. If you don't trust
the bootloader and want to set things up as soon as possible (a wise
move) then I suggest you do so from your platform clock code at the same
time that you register your clocks with the framework. Something like:
struct clk *c;
c = clk_register(...);
if (IS_ERR(c))
omg_fail();
clk_set_parent(c, b);
Where 'b' is a parent of 'c'. Register your clock tree top-down and you
can re-parent as you go.
Regards,
Mike
next prev parent reply other threads:[~2012-05-07 0:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 16:13 moving Tegra30 to the common clock framework Peter De Schrijver
2012-05-07 0:03 ` Mike Turquette [this message]
2012-05-07 15:39 ` Stephen Warren
2012-05-07 16:12 ` Turquette, Mike
2012-05-08 5:07 ` zhoujie wu
2012-05-08 17:15 ` Turquette, Mike
2012-05-09 0:41 ` Saravana Kannan
2012-05-09 2:20 ` skannan at codeaurora.org
2012-05-09 6:21 ` Turquette, Mike
2012-05-10 0:02 ` Saravana Kannan
2012-05-09 10:36 ` Peter De Schrijver
2012-05-12 2:58 ` Saravana Kannan
2012-05-13 4:31 ` Stephen Warren
2012-05-14 11:08 ` Peter De Schrijver
2012-05-15 0:10 ` Saravana Kannan
2012-05-14 21:36 ` Turquette, Mike
2012-05-14 23:48 ` Saravana Kannan
2012-05-15 2:00 ` Mike Turquette
2012-05-15 4:20 ` Saravana Kannan
2012-05-16 5:36 ` Turquette, Mike
2012-05-09 11:13 ` Peter De Schrijver
2012-05-09 16:49 ` Mike Turquette
2012-05-10 11:36 ` Peter De Schrijver
2012-05-12 18:04 ` Mark Brown
2012-05-14 12:29 ` Peter De Schrijver
2012-05-14 12:36 ` Peter De Schrijver
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=20120507000329.GB14559@gmail.com \
--to=mturquette@ti.com \
--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).