This will happen on certain platforms when entering / leaving suspend
and the system attempts to disable certain clocks at very early/late
phase, burping out a warning from timekeeping core. Avoid the issue
by checking if the timekeeping is suspended and using the fallback
udelay approach for checking timeouts.
Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
---
drivers/clk/ti/clkctrl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c
index 284ba449..91ddc92 100644
--- a/drivers/clk/ti/clkctrl.c
+++ b/drivers/clk/ti/clkctrl.c
@@ -21,6 +21,7 @@
#include <linux/of_address.h>
#include <linux/clk/ti.h>
#include <linux/delay.h>
+#include <linux/timekeeping.h>
#include "clock.h"
#define NO_IDLEST 0x1
@@ -90,7 +91,7 @@ static bool _omap4_is_ready(u32 val)
static bool _omap4_is_timeout(union omap4_timeout *time, u32 timeout)
{
- if (unlikely(_early_timeout)) {
+ if (unlikely(_early_timeout || timekeeping_suspended)) {
if (time->cycles++ < timeout) {
udelay(1);
return false;
--
1.9.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
