Viresh Kumar viresh.kumar@linaro.org writes:
Hi,
Here goes the fifth version and its very much light weight compared to earlier versions. I hope I haven't missed any review comments here :)
More or less all patches are updated to get rid of all unrelated changes, like removing unsupported modes OR not disabling events for default cases..
V4->V5: don't change behavior of 'default case' apart from returning error, it must behave exactly in the same way as it was doing earlier.
Might I suggest you wait a day before sending updated versions and to be sure you've understood and addressed all the comments? You're quickly on a path to burn out reviewers.
I was typing some of the following up in reply to V4 but then noticed you already had a V5, so I'll reply here.
Here goes the mainline version of cover-letter:
A clockevent device should be stopped, or its events should be masked, if next event is expected at KTIME_MAX, i.e. no events are required for very long time.
You need to describe why KTIME_MAX is special here. You say "should be stopped" but you don't say why. This needs to be summarized better here.
This would normally happen with NO_HZ (both NO_HZ_IDLE and NO_HZ_FULL) when tick-sched timer is removed and we don't have any more timers scheduled for long.
If we don't STOP clockevent device, we are guaranteed to receive at least one spurious interrupt, as hrtimer_force_reprogram() isn't reprogramming the event device (on expires == KTIME_MAX). Depending on particular implementation of 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.
In order for the core to tell if the mode is implemented, ->set_mode() callback needs to be able to return success or failure.
To change return type of set_mode(), Thomas suggested to implement another callback: ->set_dev_mode(), with return type 'int'. We can then convert clockevent drivers to use this interface instead of existing ->set_mode() and then finally remove ->set_mode()'s support.
This patchset first adds another callback with return capability, set_dev_mode(), then it migrates all drivers one by one to it and finally removes earlier callback set_mode() when it has no more users.
FIXME: There are two issues which *may* be required to fix separately.
- Few drivers still have 'switch cases' for handling unsupported modes (like: drivers not supporting ONESHOT have a 'case: ONESHOT' with or without a WARN/BUG/pr_err/etc). As we now have a WARN() in core, we don't need these in individual drivers and they can be removed.
This is very unclear. What is the "issue" and would be the fix?
- Few clockevent drivers have disabled clock events as soon as we enter their ->set_dev_mode() callbacks and so they stay disabled for 'default case' as well. We *may* need to fix these drivers in case we don't want them to disable events in 'default case'. After this series we will never hit 'default case' as we are handling all cases separately, but it might be required to fix them before ONESHOT_STOPPED series gets in.
In general, your cover letters and change logs still mix up what things are like currently and what things will be like (or should be like) after this series. Now your adding another layer of adding things that will likely need fix *in addition to* this series. IMO, all three categories are still mixed up in the descriptions.
Kevin