Commit c4edfced authored by Uwe Kleine-König's avatar Uwe Kleine-König Committed by Uwe Kleine-Koenig

at91: warn if irqs are enabled in set_next_event

Thomas claims that irqs are disabled when set_next_event is called.  But
David and Remy claim they saw irqs being enabled here.  As both sides
don't seem to have time to investigate here, start with a warning that
might trigger if the problem still exists.
Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-By: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Bill Gatliff <bgat@billgatliff.com>
Acked-By: default avatarRemy Bohmer <linux@bohmer.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
parent 72cca72a
......@@ -141,6 +141,15 @@ clkevt32k_next_event(unsigned long delta, struct clock_event_device *dev)
/* Use "raw" primitives so we behave correctly on RT kernels. */
raw_local_irq_save(flags);
/*
* According to Thomas Gleixner irqs are already disabled here. Simply
* removing raw_local_irq_save above (and the matching
* raw_local_irq_restore) was not accepted. See
* http://thread.gmane.org/gmane.linux.ports.arm.kernel/41174
* So for now (2008-11-20) just warn once if irqs were not disabled ...
*/
WARN_ON_ONCE(!raw_irqs_disabled_flags(flags));
/* The alarm IRQ uses absolute time (now+delta), not the relative
* time (delta) in our calling convention. Like all clockevents
* using such "match" hardware, we have a race to defend against.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment