linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	r-woodruff2@ti.com, Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH E 11/14] OMAP clock: track child clocks
Date: Sat, 14 Feb 2009 11:23:25 +0000	[thread overview]
Message-ID: <20090214112325.GA17965@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <alpine.DEB.2.00.0902122345160.14667@utopia.booyaka.com>

On Fri, Feb 13, 2009 at 12:01:37AM -0700, Paul Walmsley wrote:
> (cc'ing Richard Woodruff)
> 
> Hello Russell,
> 
> On Mon, 9 Feb 2009, Russell King - ARM Linux wrote:
> 
> > On Thu, Jan 29, 2009 at 10:06:08PM +0000, Russell King - ARM Linux wrote:
> > > @@ -780,7 +780,7 @@ int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
> > >  	if (clk->usecount > 0)
> > >  		_omap2_clk_enable(clk);
> > >  
> > > -	clk->parent = new_parent;
> > > +	clk_reparent(clk, new_parent);
> > 
> > While looking at the DPLL patches, I've realised that omap2_clk_set_parent()
> > is buggy, as are any other places which reparent the clock (thankfully
> > the only other place is in the initialisation code where it doesn't
> > matter.)
> > 
> > Consider what happens when a clock is enabled - we walk up the tree
> > enabling all parents.  If we then change the clock's parent, and
> > then disable the child, we will again walk up the tree, but since
> > we've reparented it, it will be a different clock tree.  The result
> > is that the ancestors clock usage counts, and therefore their enable
> > status, will end up getting screwed up.
> 
> Agreed.
> 
> > This brings up a question: what we currently do here is:
> > 
> > - disable the child
> > - program clksel
> > - enable the child
> > - change child->parent
> > 
> > If we add in the parent handling, there are two possibilities:
> > 
> > - disable the child
> > - enable the new parent tree
> > - program clksel
> > - change child->parent
> > - disable the old parent tree
> > - enable the child
> > 
> > OR
> > 
> > - disable the child and the old parent tree
> > - program clksel
> > - change child->parent
> > - enable the new parent tree and the child
> > 
> > (note those 'and's have implied ordering).
> > 
> > Is there anything which dictates one approach over the other?
> > Obviously the latter approach results in something smaller and
> > cleaner, but might not be technically correct.
> 
> I don't know of any hardware reason to prefer one approach over the other, 
> but Richard might know better.

I'll need an answer on this before I can commit the updated bypass clock
support patch.

However, looking a little deeper, there's more issues in the reparenting
area.  I don't think this code has been tested at all...  In
_omap2_clksel_get_src_field, there is this:

	for (clkr = clks->rates; clkr->div; clkr++) {
		if (clkr->flags & (cpu_mask | DEFAULT_RATE))
			break; /* Found the default rate for this platform */
	}

which is bogus - it will find the first entry which is _either_ marked
as a default rate _or_ is supported by the SoC.  This means (for
instance) that:

static const struct clksel_rate core_l3_core_rates[] = {
        { .div = 1, .val = 1, .flags = RATE_IN_24XX },
        { .div = 2, .val = 2, .flags = RATE_IN_242X },
        { .div = 4, .val = 4, .flags = RATE_IN_24XX | DEFAULT_RATE },

will give us divisor 1 rather than presumably the one we want, that being
divisor 4.  I think the test above should be:

	for (clkr = clks->rates; clkr->div; clkr++) {
		if (clkr->flags & cpu_mask &&
		    clkr->flags & DEFAULT_RATE)
			break; /* Found the default rate for this platform */
	}

so we find an entry which is supported _and_ is the default for the SoC.

There's also a second issue - the comments before omap2_divisor_to_clksel()
indicate that this function returns 0xffffffff on error.  Unfortunately,
this is not so, it actually returns zero on error.  Moreover, we test
the result of the function against ~0, so we'll never deal with the error
case.  This really should be fixed so that we return the right value for
the error case.  (Further comments on this in a follow up.)

So, below is a patch which fixes both of these issues.

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5020cb1..f87501b 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -636,7 +636,7 @@ u32 omap2_clksel_to_divisor(struct clk *clk, u32 field_val)
  *
  * Given a struct clk of a rate-selectable clksel clock, and a clock divisor,
  * find the corresponding register field value.  The return register value is
- * the value before left-shifting.  Returns 0xffffffff on error
+ * the value before left-shifting.  Returns ~0 on error
  */
 u32 omap2_divisor_to_clksel(struct clk *clk, u32 div)
 {
@@ -648,7 +648,7 @@ u32 omap2_divisor_to_clksel(struct clk *clk, u32 div)
 
 	clks = omap2_get_clksel_by_parent(clk, clk->parent);
 	if (!clks)
-		return 0;
+		return ~0;
 
 	for (clkr = clks->rates; clkr->div; clkr++) {
 		if ((clkr->flags & cpu_mask) && (clkr->div == div))
@@ -659,7 +659,7 @@ u32 omap2_divisor_to_clksel(struct clk *clk, u32 div)
 		printk(KERN_ERR "clock: Could not find divisor %d for "
 		       "clock %s parent %s\n", div, clk->name,
 		       clk->parent->name);
-		return 0;
+		return ~0;
 	}
 
 	return clkr->val;
@@ -747,7 +747,7 @@ static u32 _omap2_clksel_get_src_field(struct clk *src_clk, struct clk *clk,
 		return 0;
 
 	for (clkr = clks->rates; clkr->div; clkr++) {
-		if (clkr->flags & (cpu_mask | DEFAULT_RATE))
+		if (clkr->flags & cpu_mask && clkr->flags & DEFAULT_RATE)
 			break; /* Found the default rate for this platform */
 	}
 

  reply	other threads:[~2009-02-14 11:23 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-28 19:27 [PATCH E 00/14] OMAP clock, E of F: SDRAM fixes, clock optimization Paul Walmsley
2009-01-28 19:27 ` [PATCH E 01/14] OMAP2 SDRC: move mach-omap2/memory.h into include/asm-arm/arch-omap/sdrc.h Paul Walmsley
2009-01-28 19:27 ` [PATCH E 02/14] OMAP2 SDRC: rename memory.c to sdrc2xxx.c Paul Walmsley
2009-01-28 19:27 ` [PATCH E 03/14] OMAP2 SDRC: separate common OMAP2/3 code from OMAP2xxx code Paul Walmsley
2009-01-28 19:27 ` [PATCH E 04/14] OMAP2 SDRC: add SDRAM timing parameter infrastructure Paul Walmsley
2009-01-28 19:27 ` [PATCH E 05/14] OMAP3 clock: add omap3_core_dpll_m2_set_rate() Paul Walmsley
2009-01-28 19:27 ` [PATCH E 06/14] PM: OMAP3: Make sure clk_disable_unused() order is correct Paul Walmsley
2009-01-28 19:27 ` [PATCH E 07/14] OMAP2/3 clock: use standard set_rate fn in omap2_clk_arch_init() Paul Walmsley
2009-01-28 19:27 ` [PATCH E 08/14] OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c Paul Walmsley
2009-01-29 17:41   ` Russell King - ARM Linux
2009-01-30  8:42     ` Paul Walmsley
2009-01-30  8:52       ` Russell King - ARM Linux
2009-01-30 14:23         ` Woodruff, Richard
2009-01-31 11:40           ` Russell King - ARM Linux
2009-02-03  8:42             ` Paul Walmsley
2009-02-03  9:45             ` Paul Walmsley
2009-02-02  7:13       ` Paul Walmsley
2009-02-03 13:18         ` Russell King - ARM Linux
2009-01-28 19:27 ` [PATCH E 09/14] OMAP2/3 clock: drop recalc function pointers from fixed rate clocks Paul Walmsley
2009-01-28 19:27 ` [PATCH E 10/14] OMAP clock: support "dry run" rate and parent changes Paul Walmsley
2009-02-08 13:17   ` Russell King - ARM Linux
2009-02-08 19:48     ` David Brownell
2009-02-11  7:53     ` Paul Walmsley
2009-02-08 15:53   ` Russell King - ARM Linux
2009-02-11  8:18     ` Paul Walmsley
2009-01-28 19:27 ` [PATCH E 11/14] OMAP clock: track child clocks Paul Walmsley
2009-01-29 15:14   ` Russell King - ARM Linux
2009-01-29 22:06     ` Russell King - ARM Linux
2009-01-30  8:35       ` Paul Walmsley
2009-02-02  4:57       ` Paul Walmsley
2009-02-09 14:11       ` Russell King - ARM Linux
2009-02-13  7:01         ` Paul Walmsley
2009-02-14 11:23           ` Russell King - ARM Linux [this message]
2009-02-14 11:36             ` Russell King - ARM Linux
2009-02-25  9:45               ` Paul Walmsley
2009-02-19 12:19             ` Russell King - ARM Linux
2009-02-20  0:50               ` Woodruff, Richard
2009-02-23 16:03                 ` Russell King - ARM Linux
2009-02-24 12:35                   ` Woodruff, Richard
2009-03-02 23:02                   ` Paul Walmsley
2009-03-03 16:45                     ` Russell King - ARM Linux
2009-02-22 23:37             ` Paul Walmsley
2009-02-24  9:43               ` Russell King - ARM Linux
2009-01-29 19:52   ` Russell King - ARM Linux
2009-02-02  7:57     ` Paul Walmsley
2009-01-28 19:28 ` [PATCH E 12/14] OMAP clock: unnecessary clock flag removal fiesta Paul Walmsley
2009-02-23 15:50   ` Russell King - ARM Linux
2009-03-02 22:35     ` Paul Walmsley
2009-01-28 19:28 ` [PATCH E 13/14] OMAP2/3 clock: remove clk->owner Paul Walmsley
2009-01-28 19:28 ` [PATCH E 14/14] OMAP clock: rearrange clock.h structure order Paul Walmsley

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=20090214112325.GA17965@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=r-woodruff2@ti.com \
    --cc=tony@atomide.com \
    /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).