From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer Date: Thu, 05 Apr 2012 14:33:01 -0700 Message-ID: <87hawxkgoi.fsf@ti.com> References: <87sjgmt211.fsf@ti.com> <79CD15C6BA57404B839C016229A409A8318461E8@DBDE01.ent.ti.com> <79CD15C6BA57404B839C016229A409A83184846A@DBDE01.ent.ti.com> <20120405095221.GC25053@n2100.arm.linux.org.uk> <79CD15C6BA57404B839C016229A409A831848621@DBDE01.ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog130.obsmtp.com ([74.125.149.143]:55431 "EHLO na3sys009amx259.postini.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754018Ab2DEVdG (ORCPT ); Thu, 5 Apr 2012 17:33:06 -0400 Received: by dang27 with SMTP id g27so2378785dan.15 for ; Thu, 05 Apr 2012 14:33:03 -0700 (PDT) In-Reply-To: <79CD15C6BA57404B839C016229A409A831848621@DBDE01.ent.ti.com> (Vaibhav Hiremath's message of "Thu, 5 Apr 2012 10:31:34 +0000") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Hiremath, Vaibhav" Cc: Russell King - ARM Linux , "Shilimkar, Santosh" , Ming Lei , Tony Lindgren , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "marc.zyngier@arm.com" , "johnstul@us.ibm.com" , "Balbi, Felipe" , "Cousson, Benoit" , Paul Walmsley , "DebBarma, Tarun Kanti" "Hiremath, Vaibhav" writes: > On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote: >> On Thu, Apr 05, 2012 at 09:36:00AM +0000, Hiremath, Vaibhav wrote: >> > There seems to be limitation for ARM architecture, it is restricted by >> > sched_clock implementation present in "arch/arm/kernel/sched_clock.c". >> > Natively, clocksource framework does support change in rate/frequency for >> > registered timer, using, >> >> Any kind of switching of timing sources introduces loss of time issues >> by the mere fact that you can't instantly know the counter values of >> both timing sources at precisely the same instant - because CPUs can >> only do one thing at a time. So any kind of repeated dynamic switching >> _will_ result in a gradual loss of time - which will be indeterminant >> as it depends on the frequency of the switching and the relative delta >> between the two. >> >> To put it another way - it is not possible to maintain high precision >> and accuracy while dynamically switching your timing sources. >> >> I'm not about to lift the restriction that there's only one source for >> sched_clock() just for OMAP. That'd require a lot of additional code - >> it's not just about adjusting the multiplier and shift, you also have to >> correct the returned ns value as well, which means synchronizing against >> two counters. (And as I've pointed out above, that's impossible to do >> accurately.) >> > > Thanks a ton Russell for confirming on this, > > I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for. > > So this means, we have to use compile time option, as existing > implementation in "arch/arm/mach-omap2/timer.c". Not exactly. A compile time option isn't (yet) the only option. Russell points out the various problems with dynamic switching of clocksources, which is true. However, we're not trying to dynamically switch clocksources. What we need is only one-time selection at boot based on presence (or not) of various timers. IOW, we still only ever need to call setup_sched_clock() once based on which HW timers are available. Why not just delay the setup_sched_clock() until the clocksource is decided? Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Thu, 05 Apr 2012 14:33:01 -0700 Subject: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer In-Reply-To: <79CD15C6BA57404B839C016229A409A831848621@DBDE01.ent.ti.com> (Vaibhav Hiremath's message of "Thu, 5 Apr 2012 10:31:34 +0000") References: <87sjgmt211.fsf@ti.com> <79CD15C6BA57404B839C016229A409A8318461E8@DBDE01.ent.ti.com> <79CD15C6BA57404B839C016229A409A83184846A@DBDE01.ent.ti.com> <20120405095221.GC25053@n2100.arm.linux.org.uk> <79CD15C6BA57404B839C016229A409A831848621@DBDE01.ent.ti.com> Message-ID: <87hawxkgoi.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org "Hiremath, Vaibhav" writes: > On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote: >> On Thu, Apr 05, 2012 at 09:36:00AM +0000, Hiremath, Vaibhav wrote: >> > There seems to be limitation for ARM architecture, it is restricted by >> > sched_clock implementation present in "arch/arm/kernel/sched_clock.c". >> > Natively, clocksource framework does support change in rate/frequency for >> > registered timer, using, >> >> Any kind of switching of timing sources introduces loss of time issues >> by the mere fact that you can't instantly know the counter values of >> both timing sources at precisely the same instant - because CPUs can >> only do one thing at a time. So any kind of repeated dynamic switching >> _will_ result in a gradual loss of time - which will be indeterminant >> as it depends on the frequency of the switching and the relative delta >> between the two. >> >> To put it another way - it is not possible to maintain high precision >> and accuracy while dynamically switching your timing sources. >> >> I'm not about to lift the restriction that there's only one source for >> sched_clock() just for OMAP. That'd require a lot of additional code - >> it's not just about adjusting the multiplier and shift, you also have to >> correct the returned ns value as well, which means synchronizing against >> two counters. (And as I've pointed out above, that's impossible to do >> accurately.) >> > > Thanks a ton Russell for confirming on this, > > I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for. > > So this means, we have to use compile time option, as existing > implementation in "arch/arm/mach-omap2/timer.c". Not exactly. A compile time option isn't (yet) the only option. Russell points out the various problems with dynamic switching of clocksources, which is true. However, we're not trying to dynamically switch clocksources. What we need is only one-time selection at boot based on presence (or not) of various timers. IOW, we still only ever need to call setup_sched_clock() once based on which HW timers are available. Why not just delay the setup_sched_clock() until the clocksource is decided? Kevin