From patchwork Thu Jul 12 07:33:06 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shinya Kuribayashi X-Patchwork-Id: 1187461 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id BBB873FDAE for ; Thu, 12 Jul 2012 07:37:36 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SpDu7-0000t8-Cw; Thu, 12 Jul 2012 07:33:39 +0000 Received: from relmlor3.renesas.com ([210.160.252.173]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SpDtK-0000hr-JV for linux-arm-kernel@lists.infradead.org; Thu, 12 Jul 2012 07:32:51 +0000 Received: from relmlir2.idc.renesas.com ([10.200.68.152]) by relmlor3.idc.renesas.com ( SJSMS) with ESMTP id <0M710094AEAIBC60@relmlor3.idc.renesas.com> for linux-arm-kernel@lists.infradead.org; Thu, 12 Jul 2012 16:32:42 +0900 (JST) Received: from relmlac2.idc.renesas.com ([10.200.69.22]) by relmlir2.idc.renesas.com ( SJSMS) with ESMTP id <0M7100D4AEAIVC20@relmlir2.idc.renesas.com> for linux-arm-kernel@lists.infradead.org; Thu, 12 Jul 2012 16:32:42 +0900 (JST) Received: by relmlac2.idc.renesas.com (Postfix, from userid 0) id 5D7F8280A3; Thu, 12 Jul 2012 16:32:42 +0900 (JST) Received: from relmlac2.idc.renesas.com (localhost [127.0.0.1]) by relmlac2.idc.renesas.com (Postfix) with ESMTP id 58A15280A1; Thu, 12 Jul 2012 16:32:42 +0900 (JST) Received: from relmlii1.idc.renesas.com [10.200.68.65] by relmlac2.idc.renesas.com with ESMTP id SAD08321; Thu, 12 Jul 2012 16:32:42 +0900 X-IronPort-AV: E=Sophos; i="4.77,573,1336316400"; d="scan'208"; a="89979789" Received: from unknown (HELO [10.161.69.127]) ([10.161.69.127]) by relmlii1.idc.renesas.com with ESMTP; Thu, 12 Jul 2012 16:32:42 +0900 Message-id: <4FFE7DB2.4040702@renesas.com> Date: Thu, 12 Jul 2012 16:33:06 +0900 From: Shinya Kuribayashi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-version: 1.0 To: will.deacon@arm.com Subject: Re: [PATCH v2 2/2] ARM: delay: allow timer-based delay implementation to be selected References: <1340991231-17682-1-git-send-email-will.deacon@arm.com> <1340991231-17682-3-git-send-email-will.deacon@arm.com> In-reply-to: <1340991231-17682-3-git-send-email-will.deacon@arm.com> 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: sboyd@codeaurora.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 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 Hi Will, Stephen, On 6/30/2012 2:33 AM, Will Deacon wrote: > +void __init init_current_timer_delay(unsigned long freq) > +{ > + pr_info("Switching to timer-based delay loop\n"); > + lpj_fine = freq / HZ; > + arm_delay_ops.delay = __timer_delay; > + arm_delay_ops.const_udelay = __timer_const_udelay; > + arm_delay_ops.udelay = __timer_udelay; > +} Once this function is processed, the udelay() behavior changes _immediately_ from loop-based delay to timer-based one, without waiting for 'loops_per_jiffy' itself being corrected in calibrate_delay(). As a result, actual udelay()s may be toooo long than expected, in particular udelay()s used between init_current_timer_delay() and calibrate_delay(). It's unlikely be short, as the frequency of a counter for read_current_timer is typically slower than CPU frequency. I'm not sure udelay()s used in this period are legitimate, but if it's there we'll in trouble somehow. This is not so great. If this assumption is correct, it might be better to adjust / correct loops_per_jiffy itself along with lpj_fine, prior to calibrate_delay(). What do you think? Am I missing something? Shinya diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c index cb881c3..9065d30 100644 --- a/arch/arm/lib/delay.c +++ b/arch/arm/lib/delay.c @@ -57,7 +57,7 @@ static void __timer_udelay(unsigned long usecs) void __init init_current_timer_delay(unsigned long freq) { - lpj_fine = (freq + HZ/2) / HZ; + loops_per_jiffy = lpj_fine = (freq + HZ/2) / HZ; arm_delay_ops.delay = __timer_delay; arm_delay_ops.const_udelay = __timer_const_udelay; arm_delay_ops.udelay = __timer_udelay;