From: mturquette@ti.com (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: COMMON_CLK_DISABLE_UNUSED
Date: Tue, 1 May 2012 15:44:35 -0700 [thread overview]
Message-ID: <20120501224435.GA17311@gmail.com> (raw)
In-Reply-To: <4F843778.8050506@gmail.com>
On 20120410-08:36, Rob Herring wrote:
> On 04/09/2012 06:04 PM, Turquette, Mike wrote:
> > On Mon, Apr 9, 2012 at 3:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> I think it would be good to consider deleting this config option and
> >> just have the code always enabled.
> >
> > I agree. We already support the CLK_IGNORE_UNUSED flag, so any
> > platforms that don't want this functionality wholesale can set that
> > bit for every clock.
> >
> > I'll pull out that option.
> >
>
> CLK_IGNORE_UNUSED looks a bit broken to me. If you don't have the flag
> set on the whole chain of parents, then a parent could be turned off.
> This could happen at boot time or when another child get disabled and
> the common parent's ref count goes to 0 and gets disabled.
>
> I think a better solution would be a force enable or enable on boot flag
> that sets ref counts correctly. Otherwise, each platform has to call
> clk_prepare and clk_enable for all the clocks it wants to keep on.
>
> Here's a simple case that needs work. You have a cpu clock controlled by
> cpufreq driver. If the cpufreq driver is not loaded, we want the cpu
> clock always enabled and don't want the clk infrastructure turning it
> off. If the cpufreq driver is loaded, then we potentially want it to be
> able to enable and disable the cpu clock if we switch parents. I guess
> the easiest solution is the cpufreq driver needs to assume the cpu clock
> is already enabled with a ref count of 1.
>
Hi Rob,
Apologies for the late reply.
I think having any driver (including a cpufreq driver) assume anything
about the usecount is broken. Most code should follow the
tried-and-true pattern:
clk_get()
clk_prepare()
clk_enable()
cpufreq is no exception to this pattern. The only concern that has been
raised to date is that of "re-enabling" a clock that is already enabled
in hardware (which the cpufreq driver would do). That case is only
theoretical and no platform that I am aware of has a problem re-setting
the bit to enable a clock (or i2c message, or whatever).
Thanks,
Mike
> Rob
WARNING: multiple messages have this Message-ID (diff)
From: Mike Turquette <mturquette@ti.com>
To: Rob Herring <robherring2@gmail.com>
Cc: mturquette@linaro.org, arnd.bergmann@linaro.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: COMMON_CLK_DISABLE_UNUSED
Date: Tue, 1 May 2012 15:44:35 -0700 [thread overview]
Message-ID: <20120501224435.GA17311@gmail.com> (raw)
In-Reply-To: <4F843778.8050506@gmail.com>
On 20120410-08:36, Rob Herring wrote:
> On 04/09/2012 06:04 PM, Turquette, Mike wrote:
> > On Mon, Apr 9, 2012 at 3:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> I think it would be good to consider deleting this config option and
> >> just have the code always enabled.
> >
> > I agree. We already support the CLK_IGNORE_UNUSED flag, so any
> > platforms that don't want this functionality wholesale can set that
> > bit for every clock.
> >
> > I'll pull out that option.
> >
>
> CLK_IGNORE_UNUSED looks a bit broken to me. If you don't have the flag
> set on the whole chain of parents, then a parent could be turned off.
> This could happen at boot time or when another child get disabled and
> the common parent's ref count goes to 0 and gets disabled.
>
> I think a better solution would be a force enable or enable on boot flag
> that sets ref counts correctly. Otherwise, each platform has to call
> clk_prepare and clk_enable for all the clocks it wants to keep on.
>
> Here's a simple case that needs work. You have a cpu clock controlled by
> cpufreq driver. If the cpufreq driver is not loaded, we want the cpu
> clock always enabled and don't want the clk infrastructure turning it
> off. If the cpufreq driver is loaded, then we potentially want it to be
> able to enable and disable the cpu clock if we switch parents. I guess
> the easiest solution is the cpufreq driver needs to assume the cpu clock
> is already enabled with a ref count of 1.
>
Hi Rob,
Apologies for the late reply.
I think having any driver (including a cpufreq driver) assume anything
about the usecount is broken. Most code should follow the
tried-and-true pattern:
clk_get()
clk_prepare()
clk_enable()
cpufreq is no exception to this pattern. The only concern that has been
raised to date is that of "re-enabling" a clock that is already enabled
in hardware (which the cpufreq driver would do). That case is only
theoretical and no platform that I am aware of has a problem re-setting
the bit to enable a clock (or i2c message, or whatever).
Thanks,
Mike
> Rob
next prev parent reply other threads:[~2012-05-01 22:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-09 22:29 COMMON_CLK_DISABLE_UNUSED Andrew Lunn
2012-04-09 22:29 ` COMMON_CLK_DISABLE_UNUSED Andrew Lunn
2012-04-09 23:04 ` COMMON_CLK_DISABLE_UNUSED Turquette, Mike
2012-04-09 23:04 ` COMMON_CLK_DISABLE_UNUSED Turquette, Mike
2012-04-10 13:36 ` COMMON_CLK_DISABLE_UNUSED Rob Herring
2012-04-10 13:36 ` COMMON_CLK_DISABLE_UNUSED Rob Herring
2012-04-17 22:05 ` COMMON_CLK_DISABLE_UNUSED Turquette, Mike
2012-04-17 22:05 ` COMMON_CLK_DISABLE_UNUSED Turquette, Mike
2012-05-01 22:44 ` Mike Turquette [this message]
2012-05-01 22:44 ` COMMON_CLK_DISABLE_UNUSED Mike Turquette
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=20120501224435.GA17311@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 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.