From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] ARM: tegra: cpu-tegra: explicitly manage re-parenting
Date: Mon, 10 Sep 2012 23:43:37 -0600 [thread overview]
Message-ID: <504ECF89.5050809@wwwdotorg.org> (raw)
In-Reply-To: <20120911044530.20289.8165@nucleus>
On 09/10/2012 10:45 PM, Mike Turquette wrote:
> Quoting Stephen Warren (2012-09-10 16:12:38)
>> From: Stephen Warren <swarren@nvidia•com>
>>
>> When changing a PLL's rate, it must have no active children. The CPU
>> clock cannot be stopped, and CPU clock's divider is not used. The old
>> clock driver used to handle this by internally reparenting the CPU clock
>> onto a different PLL when changing the CPU clock rate. However, the new
>> common-clock based clock driver does not do this, and probably cannot do
>> this due to the locking issues it would cause.
>>
>
> This is possible today. Clock drivers can call __clk_reparent to update
> the common clk bookkeeping to reflect changes in parent muxing. There
> are some examples of this out in the wild, and the unmerged OMAP port
> certainly uses this during the PLL relock sequence.
The CPU clock's set_rate needs to both __clk_reparent() /and/ set the
rate of the parent PLL. I think a (non-static) __clk_set_rate() is
missing? (although perhaps that could be easily solved if desired).
>> To solve this, have the Tegra cpufreq driver explicitly perform the
>> reparenting operations itself. This is probably reasonable anyway,
>> since such reparenting is somewhat a matter of policy (e.g. which
>> alternate clock source to use, whether to leave the CPU clock a child
>> of the alternate clock source if it's running at the desired rate),
>> and hence is something more appropriate for the cpufreq driver than
>> the core clock driver anyway.
>
> I definitely agree about the policy. Just FYI I'm hacking on an RFC to
> make reparenting clocks from a call to clk_set_rate even easier, but
> perhaps in your case it is better the cpufreq driver knows the clock
> tree topology details.
OK, sounds fine to me:-)
next prev parent reply other threads:[~2012-09-11 5:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 23:12 [PATCH 1/2] ARM: tegra: fix overflow in tegra20_pll_clk_round_rate() Stephen Warren
2012-09-10 23:12 ` [PATCH 2/2] ARM: tegra: cpu-tegra: explicitly manage re-parenting Stephen Warren
2012-09-11 4:45 ` Mike Turquette
2012-09-11 5:43 ` Stephen Warren [this message]
[not found] ` <504F22E6.9040307@nvidia.com>
2012-09-11 17:20 ` Mike Turquette
2012-09-12 4:10 ` Shawn Guo
2012-09-12 3:57 ` Turquette, Mike
2012-09-11 6:19 ` [PATCH 1/2] ARM: tegra: fix overflow in tegra20_pll_clk_round_rate() Prashant Gaikwad
2012-09-11 16:38 ` Stephen Warren
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=504ECF89.5050809@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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