Messages in this thread | | | Date | Wed, 23 Jun 2004 00:18:46 +0200 | From | Mikael Pettersson <> | Subject | Re: [PATCH][2.6.7-mm1] perfctr ppc32 update |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |