From patchwork Thu Jun 2 09:46:22 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King - ARM Linux X-Patchwork-Id: 843182 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p529kxVK003881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Jun 2011 09:47:20 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QS4UL-000160-Ff; Thu, 02 Jun 2011 09:46:49 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QS4UL-0003YJ-9F; Thu, 02 Jun 2011 09:46:49 +0000 Received: from [2002:4e20:1eda::1] (helo=caramon.arm.linux.org.uk) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QS4UG-0003Y0-RU for linux-arm-kernel@lists.infradead.org; Thu, 02 Jun 2011 09:46:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=caramon; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=+cbDB42rPpHxRNi58uWzVNy3tJzCq4Rwi2WjUyhiyp8=; b=SPSM9MEr3UL1R50kzZH36XVZfMEGP83Bzs8R1l4YUJZBZN0pvWnfueLgynYrgjAni4e0ANxuiyLhEqMaYcP1i2xig3bG0N+JDnpwRX+3ukD/tx/FGR4ttpyopsvOQQEni9MKJFcENQ5JOtvlyqAZwQtqvwb77I3fWJD3n7hTr/w=; Received: from n2100.arm.linux.org.uk ([2002:4e20:1eda:1:214:fdff:fe10:4f86]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QS4Tw-0002jq-9Z; Thu, 02 Jun 2011 10:46:24 +0100 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.72) (envelope-from ) id 1QS4Tu-0000oc-Rh; Thu, 02 Jun 2011 10:46:22 +0100 Date: Thu, 2 Jun 2011 10:46:22 +0100 From: Russell King - ARM Linux To: Mattias Wallin Subject: Re: [PATCHv2 0/3] clocksource: add db8500 PRCMU timer Message-ID: <20110602094622.GS3660@n2100.arm.linux.org.uk> References: <1307007271-1004-1-git-send-email-mattias.wallin@stericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1307007271-1004-1-git-send-email-mattias.wallin@stericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110602_054645_591502_73879A04 X-CRM114-Status: GOOD ( 17.17 ) X-Spam-Score: 1.2 (+) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (1.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS Cc: Thomas Gleixner , Lee Jones , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Thu, 02 Jun 2011 09:47:23 +0000 (UTC) On Thu, Jun 02, 2011 at 11:34:31AM +0200, Mattias Wallin wrote: > The Multi Timer Unit (MTU) is currently used as clocksource and sched_clk > for the u8500 machine. The MTU block loose power during cpuidle sleep states > so an alternate clocksource is needed and these patches adds the db8500 PRCMU > timer. Why don't we just find a way of fixing sched_clock so that the value doesn't reset over a suspend/resume cycle? IOW, lets fix the problem for _everyone_ rather than only fixing it for one platform at a time. Could you try this patch to check whether sched_clock() behaves better across a suspend/resume cycle please? arch/arm/kernel/sched_clock.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c index 9a46370..4be4019 100644 --- a/arch/arm/kernel/sched_clock.c +++ b/arch/arm/kernel/sched_clock.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -72,3 +73,20 @@ void __init sched_clock_postinit(void) { sched_clock_poll(sched_clock_timer.data); } + +static int sched_clock_suspend(void) +{ + sched_clock_poll(sched_clock_timer.data); + return 0; +} + +static struct syscore_ops sched_clock_ops = { + .suspend = sched_clock_suspend, +}; + +static int __init sched_clock_syscore_init(void) +{ + register_syscore_ops(&sched_clock_ops); + return 0; +} +device_initcall(sched_clock_syscore_init);