From patchwork Tue Feb 14 09:55:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TWljaGHFgiBXcsOzYmVs?= X-Patchwork-Id: 141085 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 3D783B6FBA for ; Tue, 14 Feb 2012 20:57:57 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1RxF6W-0004sf-3B; Tue, 14 Feb 2012 09:55:20 +0000 Received: from v031479.home.net.pl ([89.161.171.237]) by merlin.infradead.org with smtp (Exim 4.76 #1 (Red Hat Linux)) id 1RxF6S-0004sK-0P for linux-arm-kernel@lists.infradead.org; Tue, 14 Feb 2012 09:55:17 +0000 Received: from host91217224228.static.ssm.silesia.pl [91.217.224.228] (HELO mail1.flytronic.pl) by flytronic.home.pl [89.161.171.237] with SMTP (IdeaSmtpServer v0.70) id 22bbf2111bafb6a5; Tue, 14 Feb 2012 10:55:07 +0100 Received: from [192.168.100.176] (192.168.100.176) by exchange1.flytronic.local (192.168.0.42) with Microsoft SMTP Server (TLS) id 14.0.722.0; Tue, 14 Feb 2012 10:55:17 +0100 Message-ID: <4F3A2F79.6050806@flytronic.pl> Date: Tue, 14 Feb 2012 10:55:05 +0100 From: =?UTF-8?B?TWljaGHFgiBXcsOzYmVs?= Organization: Flytronic Sp. z o.o. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Subject: [PATCH RESEND] ixp4xx: clockevent set_next_event fix References: <4F394D3B.3080909@flytronic.pl> In-Reply-To: <4F394D3B.3080909@flytronic.pl> X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org IXP43x Developer's Manual [17.4.3] and IXP4[56]x Developer's Manual [18.4.3] say that for predictable operation the timer needs to be stopped before writing a new value into the reload register. Indeed, tests on IXP435 show that writing a new value into the reload register without stopping the timer first has no immediate effect on the timer. This makes hrtimers started through hrtimer_start() to be delayed until the currently earliest hrtimer expires. IXP42x Developer's Manual [14.3] says that the timer will be reloaded immediately on setting the timer reload register, so the bug probably doesn't occur on those CPUs. However, stopping the timer shouldn't have any negative side effects, so it should be safe to apply it machine-wide. Signed-off-by: Michał Wróbel --- arch/arm/mach-ixp4xx/common.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) The previous patch had a mistake in the description - wrong reference to "General-Purpose Timers" section in IXP42x Developer's Manual. diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c index 3841ab4..fd37c83 100644 --- a/arch/arm/mach-ixp4xx/common.c +++ b/arch/arm/mach-ixp4xx/common.c @@ -434,6 +434,7 @@ static int ixp4xx_set_next_event(unsigned long evt, { unsigned long opts = *IXP4XX_OSRT1 & IXP4XX_OST_RELOAD_MASK; + *IXP4XX_OSRT1 = 0; *IXP4XX_OSRT1 = (evt & ~IXP4XX_OST_RELOAD_MASK) | opts; return 0;