On 10/30, Tero Kristo wrote:
> 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) {
This would be the second user of timekeeping_suspended outside of
timekeeping core. Why don't we just udelay(1) every time we call
this function? The loop on ktime without any sort of delay in it
may actually spin faster, especially because we can't get
interrupted here (irqs are off). And irqs + preemption enabled is
typically where you would want to use ktime instead of counting
udelay() calls to see if you hit a timeout.
This code seems over-complicated given the constraints at the
call-sites.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
