[PATCH] RFC: clk notifications & freq constraints

Jonas Bonn jonas.bonn at gmail.com
Tue Nov 11 13:47:36 CET 2008

> Yes, however we're currently a bit stuck with cpufreq until we've
> managed to persuade other people that it really isn't the right idea
> for a number of these systems.

Has there been resistance to an approach like the one I am proposing
in the past?  The idea is that cpufreq (and cpuidle) can use the clk
API for frequency querying and manipulation.

> This is interesting, but totally the wrong place to be discussing such
> framework changes. These items would be better off being discussed on
> linux-arm-kernel or even linux-kernel itself if you want a chance of
> getting this merged.

Fair enough... I wanted to see if the Samsung ARM people were on board
first before pestering linux-kernel.  I ran this by linux-kernel once
already and got "cautiously positive" feedback in addition to the
suggestion to bolt this to the clk API instead of creating something
totally new.

>>   Parent           Clock            Child
>>   ------   Input   ------  Output   ------
>>   |    |   freq ---|    |  freq  ---|    |
>>   |    |  ----->|x?|    |  ----->|x?|    |
>>   |    |        ---|    |        ---|    |
>>   ------           ------           ------
>>                      |               |
>>                      -->DeviceA      -->DeviceC
>>                      |
>>                      -->DeviceB
> I would think of this more as a set of clock sources (such as PLL, or
> clock pin) and a series of muxes, gates and dividers. It is probably
> a better way of thinking about this and closer to how these kinds of
> hardware works.

The model I'm using is almost what you say:  it's a clock that knows
about the dividers between it's input and output.  Muxes are
implemented through reparenting of clocks, and virtual clocks can be
defined where abstraction beyond what the hardware offers is needed.

>> +
>> +static struct clk_constraint preallocated_constraints[PREALLOCATED_CONSTRAINTS];
>> +static LIST_HEAD(free_constraint_pool);
> this sounds like an job for kmem_cache.

Agreed... I had problems on the OpenMoko platform as kzalloc wasn't
ready for use when the first clocks were being registered, so I just
preallocated a bunch of constraints in order to be able to bring up
the system.

> Not sure if I like the automatic change causes by changing the parent
> of a clock.

A parent change is equivalent to a frequency change; the new input
frequency is the output frequency of the parent.  For the S3C2410,
this is like reparenting between the MPLL and the (virtual) SLOW
clock.  But as the "set_parent" function is a member of struct clk,
the frequency change can probably be made optional, anyway.

And the rest of your comments all just touch upon my "debugging stuff"
that I left in the patch as I was just aiming to get the idea across.
Sorry if that confused you... but as you didn't remark on anything
else, I take it that you find the basis sound, in any case?

Thanks for having a look at this.

More information about the openmoko-kernel mailing list