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

Paul Walmsley
2009-02-06T23:04:30Z

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