From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756723AbbCRWGQ (ORCPT ); Wed, 18 Mar 2015 18:06:16 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:63504 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755077AbbCRWGO (ORCPT ); Wed, 18 Mar 2015 18:06:14 -0400 From: "Rafael J. Wysocki" To: Geert Uytterhoeven Cc: Kevin Hilman , Ulf Hansson , linux-pm@vger.kernel.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] PM / Domains: Skip latency measurements if timekeeping is suspended Date: Wed, 18 Mar 2015 23:30:08 +0100 Message-ID: <19573969.Pdd3px1nTO@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/3.19.0+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1426695946-21705-1-git-send-email-geert+renesas@glider.be> References: <1426695946-21705-1-git-send-email-geert+renesas@glider.be> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, March 18, 2015 05:25:46 PM Geert Uytterhoeven wrote: > The PM Domain code uses ktime_get() to perform various latency > measurements. However, if ktime_get() is called while timekeeping is > suspended, the following warning is printed: > > WARNING: CPU: 0 PID: 1340 at kernel/time/timekeeping.c:576 ktime_get+0x30/0xf4() > > This happens when resuming the PM Domain that contains the clock events > source. Chain of operations is: > > timekeeping_resume() > { > clockevents_resume() > sh_cmt_clock_event_resume() > pm_genpd_syscore_poweron() > pm_genpd_sync_poweron() > genpd_power_on() > ktime_get(), but timekeeping_suspended == 1 > ... > timekeeping_suspended = 0; > } > > Skip all latency measurements if timekeeping is suspended to fix this. I don't think that this is where we should fix it. At least using timekeeping_suspended outside of the timekeeping core would not be welcome by its maintainers. > Signed-off-by: Geert Uytterhoeven > --- > I'm not sure if this is needed for all latency measurements. > So far I only encountered it while powering-on a clock domain during > resume from s2ram. The problem seems to be that the clock domain is powered on in a syscore resume routine which happens to be called before timekeeping_resume(). It looks like we either need to force the right ordering somehow or have a special variant of GENPD_DEV_TIMED_CALLBACK() for syscore suspend/resume that won't do the latency measurement at all (which doesn't make much sense at this point, because time is effectively "frozen" then). Rafael