2013/3/30 Ning Jiang <ning.n.jiang@xxxxxxxxx>: > 2013/3/30 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>: >> On Sat, Mar 30, 2013 at 05:57:38PM +0800, Ning Jiang wrote: >>> 2013/3/30 Stephen Boyd <sboyd@xxxxxxxxxxxxxx>: >>> > On 03/29/13 02:24, ning.n.jiang@xxxxxxxxx wrote: >>> >> From: Ning Jiang <ning.n.jiang@xxxxxxxxx> >>> >> >>> >> Currently there are two problems when we try to stop local timer. >>> >> First, it calls set_mode function directly so mode state is not >>> >> updated for the clock event device. Second, it makes the device >>> >> unused instead of shutdown. >>> > >>> > What device is this a problem on? I believe this only matters to drivers >>> > which enable their timer in their set_next_event() callback? But even >>> > then, does anything actually happen because the interrupt should have >>> > been disabled in the local timer stop callback. >>> > >>> >>> Right. Drivers which enable timer in set_next_event() will have this problem. >>> It will not have functional problem in my case. But my device cannot enter >>> low power mode with a pending interrupt even if it is disabled. >> >> You're not telling us what you have discovered. How does set_next_event() >> get called after we've set the mode to UNUSED in the current code? > > In the current code we did not set the mode to UNUSED but only call > set_mode callback function for the clock event device. This normally > disables current clock event device. The dying CPU eventually will > switch to idle thread, call tick_nohz_idle_enter(), try to cancel the > sched_timer and reprogram the next event. Then set_next_event() gets > called. The call stack will be like: > > tick_nohz_idle_enter > -> __tick_nohz_idle_enter > -> tick_nohz_stop_sched_tick > -> hrtimer_cancel > -> hrtimer_try_to_cancel > -> remove_hrtimer > -> __remove_hrtimer > -> hrtimer_force_reprogram > -> tick_program_event > -> clockevents_program_event > -> set_next_event > > In set_next_event() we'll re-enable and re-program the clock event device. I think there are two problems here: 1. We should use clockevents_set_mode() instead of calling set_mode callback directly. This is the issue my patch was trying to fix. 2. We shouldn't program a clock event device for a dying CPU anyway. I can submit another patch if agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |