On Mon, 2015-02-09 at 08:45AM +0100, Michal Simek wrote: > + Soren > > >> $ grep -rn ARM_GLOBAL_TIMER | grep -v SCHED_CLOCK > >> arch/arm/mach-vexpress/Kconfig:7: select ARM_GLOBAL_TIMER > >> arch/arm/mach-bcm/Kconfig:87: select ARM_GLOBAL_TIMER > >> arch/arm/mach-bcm/Kconfig:108: select ARM_GLOBAL_TIMER > >> arch/arm/mach-rockchip/Kconfig:14: select ARM_GLOBAL_TIMER > >> arch/arm/mach-sti/Kconfig:4: select ARM_GLOBAL_TIMER > >> arch/arm/mach-zynq/Kconfig:6: select ARM_GLOBAL_TIMER if !CPU_FREQ > >> > >> There are indeed a few users; also I wonder why mach-zynq enables > >> ARM_GLOBAL_TIMER only if !CPU_FREQ. (Could it be that they have > >> the CPU CLOCK driving PERIPHCLK?) > > > > I'm afraid I don't know. > > The reason is that cpu clock input and global timer clock input are not independent > that's why changing clock for cpu also affect global timer freq which is wrong. > It is caused by incorrect hw design. > Soren can give you more detail information if you need. Right, it is a (broken) attempt to avoid usage of the global timer in case cpufreq is enabled. On Zynq, all timer's clock inputs are derived from the CPU clock. Hence they all do change when cpufreq scales the CPU clock. I wrote a fragile construct of clk notifiers for our cadence TTC which compensates for those changes. But the TTC is fairly narrow and slow, hence to guarantee it becomes the selected clocksource, I tried to blacklist the global timer this way (which obviously fails when something else selects the timer). Thanks, Soren -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
