On 06/02/2014 10:21 PM, Kevin Hilman wrote:
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.
Yeah, really Viresh ... sounds like some of us already told you that.
We have other patchset to review also, if you flood with X versions with your patchset in a small amount of time resulting each time with comments, some of us (like I) will just give up to review and will wait a patchset to stand there without comment during some days before reviewing it. The result will be the opposite at you want: the patches will take more time to be merged.
You can resend a patchset immediately if all the patches are acked and there are a couple of trivial changes (typo or whatever). Otherwise take the time to do your *own* review. Don't "hope" you "haven't missed any review comments here".
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