From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Date: Tue, 28 Jun 2011 16:04:27 -0700 Message-ID: <4E0A5DFB.9060703@ti.com> References: <1308923618-5333-1-git-send-email-premi@ti.com> <4E0A5982.8040002@ti.com> <4E0A5D27.5090709@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from na3sys009aog126.obsmtp.com ([74.125.149.155]:52900 "EHLO na3sys009aog126.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750974Ab1F1XEc (ORCPT ); Tue, 28 Jun 2011 19:04:32 -0400 Received: by gxk7 with SMTP id 7so329716gxk.7 for ; Tue, 28 Jun 2011 16:04:30 -0700 (PDT) In-Reply-To: <4E0A5D27.5090709@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Colin Cross Cc: Sanjeev Premi , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux On 6/28/2011 4:00 PM, Santosh Shilimkar wrote: > On 6/28/2011 3:53 PM, Colin Cross wrote: >> On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar >> > wrote: > > [....] > >> Can't this rewrite the loops_per_jiffy for the other CPU while it is >> in a udelay? If it has already calculated the number of loops >> necessary, and the CPU frequency increases, it could end up >> returning >> too early from udelay. >> >> There were previous discussions about polling a fixed-frequency >> timer >> for udelay on SMP systems. >> >> The udelay code doesn't use the per-cpu lpj variable. It uses the global >> lpj. Secondly the calibration of no. of loops to be done is >> precalculateed so overwrite shouldn't impact the scenario you mentioned. >> >> Though it has an issue where, pre-calculated loops can become short/long >> based on new clock change which impacts both CPU's on OMAP, when the >> other CPU is in in the middle of u-delay routine.. >> >> >> The precalculated loops is exactly the problem I described. udelay(100) >> can return in 50 microseconds if the cpu speed is doubled. On OMAP4, >> frequencies can range from 350Mhz to 1.5GHz, so udelay can be more than >> 4 times too short. That breaks the guarantees of udelay. >> > You have a point and I agree with you on above. > And to fix that scenrio, the only option is to use hardware > timer based u-delay() which can remain constant across the > CPU freq change. > Or block CPUFREQ change when any CPU which is in udelay() is done with it, which will be stupid to do :-) Regards Santosh