On Thu, May 22, 2014 at 09:36:09PM +0530, Viresh Kumar wrote:
On 22 May 2014 21:04, Frederic Weisbecker fweisbec@gmail.com wrote:
On Thu, May 22, 2014 at 06:38:29PM +0530, Viresh Kumar wrote:
A clockevent device can be stopped, or its events can be masked, if next event is expected at KTIME_MAX, i.e. no events are required for very long time.
This normally happens with NO_HZ_FULL (when tick-sched timer is removed and we don't have any more timers scheduled for long), not sure if it can happen otherwise.
This should also happen with NO_HZ_IDLE. It's rather a wide NO_HZ concern.
How exactly? I would have seen these fake interrupts in normal boot if that's the case as we go in and out of idle again and again.. The reason I can think of why it isn't happening for NO_HZ is: clockevent devices are normally part of CPU block (Atleast on ARM), and when CPU goes into some power down state, the even device goes as well..
Though there is one way it can happen for NO_HZ_IDLE, probably Preeti or Daniel told me this earlier and I forgot to mention it. i.e. the case of external event device.
@@ -105,7 +105,14 @@ void clockevents_set_mode(struct clock_event_device *dev, enum clock_event_mode mode) { if (dev->mode != mode) {
dev->set_mode(mode, dev);
if (dev->set_dev_mode) {
/* WARN: Currently available modes shouldn't fail */
if (WARN_ON(dev->set_dev_mode(mode, dev)))
Rather use WARN_ON_ONCE(), in general it's much better.
Sure..
Also probably the error handling should be done in this patchset?
What kind of error handling ? Do we need to return the error code? Thomas rather asked us to do error handling here only and I am not sure what else we can do here apart from a WARN.
So clockevents_set_mode() returns void so for now I don't know. But __clockevents_update_freq() can return errors.