On Thu, May 14, 2015 at 07:29:38PM +0530, Viresh Kumar wrote: > On 14 May 2015 at 18:36, Mason <slash.tmp@xxxxxxx> wrote: > > When I execute "echo 18500 > scaling_max_freq" > > the system is supposed to change the CPU frequency to 18.5 MHz > > (I might have a bug lurking there) and PERIPHCLK is 1/2 of that, > > i.e 9.25 MHz. > > So at least we are on the right path. But it looks to me that this > call is not getting propagated well. > > >From the attachment you gave initially, the event handler for > twd-timers is: tick_handle_periodic(). i.e. you are running in > periodic mode and not onshot... > > why ? If it's in periodic mode, the update should still be propagated to the hardware, assuming the generic time keeping code doesn't produce an error. twd_update_frequency `-clockevents_update_freq `-__clockevents_update_freq `-__clockevents_set_state(, CLOCK_EVT_STATE_PERIODIC) `-dev->set_mode (twd_set_mode) That re-writes the TWD_TIMER_LOAD register based on twd_timer_rate, which would have been updated by twd_update_frequency(). The question I posed earlier remains: is clockevents_update_freq() failing? We don't know, because we never check its return value. Another thing to look at is whether we reach twd_set_mode(). Lastly, printing the values of the TWD_TIMER_LOAD and TWD_TIMER_COUNTER after twd_set_mode() has written TWD_TIMER_LOAD might provide some hints as to what's going on. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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