On 4 June 2014 13:02, Preeti U Murthy preeti@linux.vnet.ibm.com wrote:
You might want to remove the brackets around "on expires == KTIME_MAX". Its quite a while since we mentioned that this is the case we are solving, so best to mention it as a part of the main sentence.
Okay.
clockevent device, this can be a fake interrupt at tick-rate.. (When driver is emulating ONESHOT over PERIODIC mode. This was observed on at least one implementation: arm_arch_timer.c).
A simple (yet hacky) solution to get this fixed could be: update hrtimer_force_reprogram() to always reprogram clockevent device and update clockevent drivers to STOP generating events (or delay it to max time), when 'expires' is set to KTIME_MAX. But the drawback here is that every clockevent driver has to be hacked for this particular case and its very easy for new ones to miss this.
However, Thomas suggested to add an optional mode: ONESHOT_STOPPED (lkml.org/lkml/2014/5/9/508) to solve this problem.
With this proposal, introducing a new ONESHOT_STOPPED mode would require the core to know whether the platform implements this mode so it could be reprogrammed later.
The core would need to know if the platform implements this mode so as to warn the callers if the mode is not implemented.
No, this mode is optional. Core would need to reconfigure ONESHOT mode later if ONESHOT_STOPPED has happened.
We will be handling the ONESHOT_STOPPED devices in the same way whether the platform implements this mode or not right? In either case we would need to reprogram the clock devices when necessary.
We would need to reprogram the next event later but mode will be required to be reconfigured if mode is changed to ONESHOT_STOPPED earlier.
-- viresh