> > 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. >> >> + >> +#define PREALLOCATED_CONSTRAINTS 512 >> +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. /Jonas
