re: Making cpufreq(9) per cpu

[matthew green <mrg%eterna.com.au@localhost>]

Martin Husemann writes:
> There was a recent discussion on port-sparc64 about the cpufreq(9) interface,
> and I noticed it basically is a single, global interface, which stores
> a single cookie.
> 
> This sounds a bit restrictive; for one it assumes identical cpus and available
> frequencies for all cpus (ok, that is not a very far stretch, but we do
> have working SMP setups where it would fail - if the affected CPUs would
> provide any clock changing features at all).
> 
> So wouldn't it be better to add a cpuinfo* to cpufreq_register() and
> friends (some already have it), and store the struct cpufreq (not the
> pointer to it!) in the MI part of cpuinfo?
> 
> Then maybe add the notion of "I am a secondary core and will always have same
> frequncy as cpuinfo* other". And of course some way to mark the cpufreq
> data as not initialized (that could be just NULL pointers for
> cf_{get,set}_freq).
> 
> That way ACPI could still do its global thing bound to cpu0 and all others
> as "slaves", while on sparc64 we could store the per cpu pci root bridge
> softc pointer in the cf_cookie pointer in struct cpufreq.

modern x86 allows different cores in a single package to run
at different speeds, so we need this generally anyway.

i think the idea seems reasonable.


.mrg.