[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090129123936.GA16644@n2100.arm.linux.org.uk>
Date: Thu, 29 Jan 2009 12:39:36 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Paul Walmsley <paul@...an.com>
Cc: linux-arm-kernel@...ts.arm.linux.org.uk,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH C 06/13] OMAP3 clock: DPLLs should enter bypass if new rate is sys_ck
On Wed, Jan 28, 2009 at 12:08:26PM -0700, Paul Walmsley wrote:
> This patch causes a DPLL to enter bypass when it is instructed to set
> its rate to that of its bypass clock. Previously this was only possible
> after setting the DPLL rate, then disabling and re-enabling it.
The more I think about this, especially with reference to patch D1, the
more I'm convinced this is not entirely the right approach.
Patch D1 introduces the necessary mechanics to make clk_get_parent()
work. If you use this on a PLL clock, and the PLL is in bypass mode,
it returns the non-bypass clock.
Now, I suspect that your first thought to resolving that would be to
add some complexity to clk_get_parent(). I advise against that.
Instead, arrange for clk->parent to _always_ point at the correct
parent clock, whether the PLL is in bypass mode or not.
In other words, encapsulate all the PLL mechanics localized inside
the PLL handling code and don't let them leak outside that code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists