Re: [PATCH][2.6.7-mm1] perfctr ppc32 update

[Mikael Pettersson <mikpe@csd.uu.se>]

Benjamin Herrenschmidt writes:
 > 
 > > So what you're saying is that PLL_CFG may not reflect the true
 > > relationship between the TB frequency and the core frequency?
 > 
 > Right.
 > 
 > > That shouldn't be a problem as long as there's _some_ in-kernel
 > > interface for finding that out. If querying OF isn't the correct
 > > approach, then what is?
 > 
 > What do you need exactly ? The TB one or the core one ? the core
 > I suppose ? Well, we should probably define an ppc_get_cpu_core_frequency
 > or something like that that uses the cpufreq callback like the pmac code
 > when cpufreq is enabled or default to the old parsing when not. Look at
 > the pmac code. You may also want to install a cpufreq notifier callback
 > to be informed of core frequency changes.

I want both TB and core speeds, but TB is more important.

Originally, I used and sampled the x86 time-stamp counter to
provide an additional clock-like register for measurements.
On x86, observable TSC freq == core freq, so the CPU speed
I report to users coincides with TSC speed. This is then
used to derive high-resolution actual time from TSC counts.

When adding PPC32 support, I used TB for the clock-like
entity, but had to introduce a TB-to-core multiplier to
maintain the notion that clock*multiplier == core speed.

If TB speed is constant but core speed is not, then this
was a mistake and I should instead report TB speed only,
and let user-space convert TB counts to time directly
without conversion via core speed.

So can I assume constant TB speed? In that case I don't
really care about core speed changes.

/Mikael