Re: [PATCH D 11/11] Fix omap1 clock issues

From: Paul Walmsley <paul@pwsan.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH D 11/11] Fix omap1 clock issues
Date: Fri, 6 Feb 2009 16:04:18 -0700 (MST)	[thread overview]
Message-ID: <alpine.DEB.2.00.0902061447430.26737@utopia.booyaka.com> (raw)
In-Reply-To: <20090206214450.GN13758@n2100.arm.linux.org.uk>

Hi Russell,

On Fri, 6 Feb 2009, Russell King - ARM Linux wrote:

> On Fri, Feb 06, 2009 at 02:19:34PM -0700, Paul Walmsley wrote:
> > [paul@pwsan.com: This patch has been updated to use offsets for OMAP1 
> > clock enable registers, to resolve all current sparse warnings with the 
> > clock code, and to convert most magic constants into symbolic macros.  
> 
> Wish you hadn't;

If it's the patch that is problematic, I'm certainly open to comments to 
revise it.

As you've probably seen, the OMAP1 clock control registers and memory map 
are structured quite differently than the OMAP2/3 PRCM and module layout.

> I've been avoiding the patches changing the way registers
> are accessed for the time being - until I have an opportunity to think
> about them for a bit.
>
> As can be seen in the OMAP2 updates, this approach causes additional 
> struct clk's to appear for mcbsp clocks because they have controlling 
> registers split across two subsystems.  This is contary to one of your 
> other statements about wanting the struct clk's to reflect the real 
> clock structure without virtual clocks.

I think we're just using the term "virtual clock" differently.

"Virtual clocks" in my usage are clocks that have no direct connection to 
a particular clock tree entity in the hardware, such as a gate, divider, 
source multiplexer, or oscillator source.  Examples of these virtual 
clocks are those that were created simply for convenience to switch a 
group of hardware clocks on and off (as the old McBSP clocks were).

In the medium-term, the plan here is to modify the OMAP clk_set_parent() 
and clk_set_rate() functions to walk up the clock tree if the device 
driver-supplied clock does not support parent/rate selection.  This is a 
relatively minor fix that should make parent and rate selection 
transparent for device drivers (e.g., drivers shouldn't need 
clk_get_parent() at that point).

- Paul