From patchwork Thu Jul 19 12:43:40 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shinya Kuribayashi X-Patchwork-Id: 1216531 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 822DF3FC33 for ; Thu, 19 Jul 2012 12:48:39 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Srq5E-0004pa-S5; Thu, 19 Jul 2012 12:43:56 +0000 Received: from relmlor1.renesas.com ([210.160.252.171]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1Srq57-0004oY-EW for linux-arm-kernel@lists.infradead.org; Thu, 19 Jul 2012 12:43:52 +0000 Received: from relmlir3.idc.renesas.com ([10.200.68.153]) by relmlor1.idc.renesas.com ( SJSMS) with ESMTP id <0M7E00JCWRCVJ640@relmlor1.idc.renesas.com> for linux-arm-kernel@lists.infradead.org; Thu, 19 Jul 2012 21:43:43 +0900 (JST) Received: from relmlac4.idc.renesas.com ([10.200.69.24]) by relmlir3.idc.renesas.com ( SJSMS) with ESMTP id <0M7E0036IRCVN6D0@relmlir3.idc.renesas.com> for linux-arm-kernel@lists.infradead.org; Thu, 19 Jul 2012 21:43:43 +0900 (JST) Received: by relmlac4.idc.renesas.com (Postfix, from userid 0) id 763BE480A4; Thu, 19 Jul 2012 21:43:43 +0900 (JST) Received: from relmlac4.idc.renesas.com (localhost [127.0.0.1]) by relmlac4.idc.renesas.com (Postfix) with ESMTP id 74AF9480A6; Thu, 19 Jul 2012 21:43:43 +0900 (JST) Received: from relmlii2.idc.renesas.com [10.200.68.66] by relmlac4.idc.renesas.com with ESMTP id XAF05892; Thu, 19 Jul 2012 21:43:43 +0900 X-IronPort-AV: E=Sophos; i="4.77,615,1336316400"; d="scan'208"; a="91074899" Received: from unknown (HELO [10.161.69.127]) ([10.161.69.127]) by relmlii2.idc.renesas.com with ESMTP; Thu, 19 Jul 2012 21:43:41 +0900 Message-id: <500800FC.40002@renesas.com> Date: Thu, 19 Jul 2012 21:43:40 +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: <20120712084432.GA2816@mudshark.cambridge.arm.com> <4FFE9A69.3060301@renesas.com> <4FFEFDE3.5000403@codeaurora.org> <4FFF8509.2050302@renesas.com> <20120713085746.GA18079@mudshark.cambridge.arm.com> <20120713111337.GH18079@mudshark.cambridge.arm.com> <5004D78E.4050606@renesas.com> <5005176C.6050904@renesas.com> <20120717090541.GA14624@mudshark.cambridge.arm.com> In-reply-to: <20120717090541.GA14624@mudshark.cambridge.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, santosh.shilimkar@ti.com, 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, Have not gone through your new mail yet, sorry.. On 7/17/2012 6:05 PM, Will Deacon wrote: > I assume the reason you've done it like this is because your timer isn't up > and running until after the delay loop has been calibrated? In which case, > I'd really rather not duplicate the calibration here -- is there no way you > can ensure the timer is available earlier? If not, then I'm not sure we > should be using it as the delay source. Of course not :-) My timers get started and running from time_init() point, before calibrate_delay(). And don't get me wrong, I just tried to provide a working example to skip calibrate_delay() in response to Santosh request: > Thanks for the detailed explanation. CPU clock detection is indeed the > nit way to skip the calibration overhead and this was one of the comment > when I tried to push the skipping of calibration for secondary CPUs. > > Looks like you have a working patch for the clock detection. Will > you able to post that patch so that this long pending calibration > for secondary CPUs gets optimized. ... with keeping the following points in mind: 1. skip the calibration for secondary CPUs (that is, for SMP use) 2. can work without init_current_timer_delay() help; calculating lpj from the CPU clock speed, not from current timer If I understand Santosh request correctly, he requested a patch that could be tested on non-A15 SMP systems (may be A9). We know that A15 comes with the architected timer and does not require any additional patches apart from already provided ones. Also he said he gave a try to "the suggested change + two patches" and confirmed it worked. As for lpj_early variable, I just wanted to reserve lpj_fine for real "timer" use, and did not want to mix with CPU frequency thing. That being said, I have to admit that rewriting using lpj_fine looks much simpler, and should have done so from the beginning: diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c index 395d5fb..b9874a3 100644 --- a/arch/arm/lib/delay.c +++ b/arch/arm/lib/delay.c @@ -65,6 +65,13 @@ void __init init_current_timer_delay(unsigned long freq) arm_delay_ops.udelay = __timer_udelay; } +void __init calibrate_delay_early(unsigned long rate) +{ + pr_info("Calibrating delay using CPU frequency.. %lu Hz\n", rate); + lpj_fine = (rate + (HZ/2)) / HZ; + loops_per_jiffy = lpj_fine; +} + unsigned long __cpuinit calibrate_delay_is_known(void) { return lpj_fine;