[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190109015124.GO5544@atomide.com>
Date: Tue, 8 Jan 2019 17:51:24 -0800
From: Tony Lindgren <tony@...mide.com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
"open list:THERMAL" <linux-pm@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
LAK <linux-arm-kernel@...ts.infradead.org>,
linux-omap@...r.kernel.org
Subject: Re: Regression in v5.0-rc1 with autosuspend hrtimers
* Vincent Guittot <vincent.guittot@...aro.org> [190109 01:42]:
> Le Tuesday 08 Jan 2019 à 13:37:43 (-0800), Tony Lindgren a écrit :
> > Lowering the autosuspend_delay_ms to 2100 ms makes things work again.
> > Anything higher than 2200 ms seems to somehow time out immediately
> > now :)
>
> This is quite close to the max ns of an int on arm 32bits
>
> Could you try the patch below ?
Yup great thanks, that's it:
Tested-by: Tony Lindgren <tony@...mide.com>
> ---
> drivers/base/power/runtime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 7062469..44c5c76 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -141,7 +141,7 @@ u64 pm_runtime_autosuspend_expiration(struct device *dev)
>
> last_busy = READ_ONCE(dev->power.last_busy);
>
> - expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
> + expires = last_busy + (u64)(autosuspend_delay) * NSEC_PER_MSEC;
> if (expires <= now)
> expires = 0; /* Already expired. */
>
> --
> 2.7.4
>
>
> >
> > Regards,
> >
> > Tony
Powered by blists - more mailing lists