[PATCH] RFC: clk notifications & freq constraints

Jonas Bonn jonas.bonn at gmail.com
Tue Nov 11 14:44:07 CET 2008

> One of the problems is that the clk API caters for the simplest
> implementation (eg, arch/arm/mach-imx/fb.c and the one for ixp4xx
> on this list, or even the SA11x0 which should've been similar to
> these) right up to something as complex as the OMAP implementation
> arch/arm/mach-omap*/clock* arch/arm/plat-omap/clock*)
> The people with a simple implementation won't be happy to have some
> weightful lump of code behind the clk API when all they require is
> to provide is one or even no struct clk and a single fixed frequency.
> They won't appreciate having to provide constraints and so forth.
> So yes, there is resistance to bloating the clk API and quite rightfully
> so.  Why should such examples have anything more than a minimal amount
> of code to support their simple drivers?

I've been careful with my implementation to do it in a manner that
does not change the semantics for current users of the code.  I know
my post doesn't reflect this as well I would have liked...

The frequency notifiers and clock constraints can be done as
config-options... I haven't done it this way in the code I posted, but
it's been in the back of my mind the whole time and I do not think
I've introduced anything that cannot be made a compile-time option.

Largely, this is about adding some additional functionality to clocks,
not necessarily about changing what we have today.  A system with a
single clock does not face the issues we have with the S3C24xx;
conversely, things like cpufreq do not work well for what we have with
the S3C24xx.

To the clk API (clk.h), I've added 4 "device" functions that can all
be made optional with a config-option, and 2 functions for getting
querying the frequency range that can (probably) also be made
optional.  Aside from these, everything is architecture specific.  In
the future we may move to a "generic clk" implementation (Dmitry
Baryshkov's work), and then the config-options can determine how
complex struct clk is allowed to become.

I have a couple of main concerns that I think primarily need addressing:
i)  Is the clk API _allowed_  to become "live", such that the clk
functions do actual clock manipulations up and down the hierarchy, or
is this outside of the intent of this interface?  Today I see
implementations that vary from just storing frequency data to doing
actual frequency manipulation... it's not clear to me where the
intended bounds of this interface are.  clk_set_rate can do very
different things on different platforms today already.

ii)  Is the clk API allowed to provide an interface (notifications)
that is so similar to what cpufreq already has (notifier blocks)?
It's difficult to get the S3C24xx clock scheme into cpufreq in an
elegant manner... plus we would lose the benefit of frequency
constraints that is possible via the clk API.

iii)  Am I treading on anyone else's toes with this?  cpufreq, clock
domains, power domains... there are several parallel tracks out there
doing similar things, but I don't see any that fill this particular


More information about the openmoko-kernel mailing list