From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer Date: Mon, 9 Apr 2012 15:18:22 -0500 Message-ID: <4F83440E.70502@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> <87hawxkgoi.fsf@ti.com> <79CD15C6BA57404B839C016229A409A831849432@DBDE01.ent.ti.com> <20120406180452.GB15734@atomide.com> <79CD15C6BA57404B839C016229A409A83184ABEF@DBDE01.ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:57913 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754615Ab2DIUSq (ORCPT ); Mon, 9 Apr 2012 16:18:46 -0400 In-Reply-To: <79CD15C6BA57404B839C016229A409A83184ABEF@DBDE01.ent.ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Hiremath, Vaibhav" Cc: Tony Lindgren , "Hilman, Kevin" , Paul Walmsley , Russell King - ARM Linux , "Cousson, Benoit" , "marc.zyngier@arm.com" , Ming Lei , "Balbi, Felipe" , "Shilimkar, Santosh" , "johnstul@us.ibm.com" , "linux-omap@vger.kernel.org" , "DebBarma, Tarun Kanti" , "linux-arm-kernel@lists.infradead.org" Hi Vaibhav, On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote: [...] > Let me summarize it here again, > > Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER, > to choose between 32ksync counter and gptimer; it is compile time option. > If user wants to use gptimer for HR ticks, he must build the kernel without > CONFIG_OMAP_32K_TIMER option. > > AM335x family of devices doesn't have 32ksync_counter available, only option > here is to use gptimer for kernel clocksource and clockevents. > > So in order to support, multi-omap build including devices like AM335x, we > must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource > registration perspective. > > So that means, we need to have some mechanism to handle or detect available > clocksource runtime. Options would be, > > - Use HWMOD to detect availability of 32ksync_counter, else fallback > to gptimer. [This was my original patch] > > But this restricts the use of gptimer completely on omap architecture, > where we have 32ksync counter module. True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. So we should/must restrict the use of a gptimer is CONFIG_PM is enabled for devices that have the 32ksync timer. > - So the next solution is to still keep compile time option, so that user > will get to use gptimer atleast just changing the kernel config option. > > But, still, this is going to be kernel rebuild. > > - Next option came up was, register both the timers and override using > kernel parameter. > > This will work only if, both the timers run at same rate/frequency; since > we have one more layer here setup_sched_clock(), which actually can be > called only once. > > - Next option suggested by Santosh, is to use kernel parameter as in parse > it early, to make decision on if user wants to override default > clocksource (32ksync) > > This is something will work for us and solves all above issues. What happens if PM is enabled? Can you still override the default? I don't think this should be allowed for devices with a 32ksync timer. Jon From mboxrd@z Thu Jan 1 00:00:00 1970 From: jon-hunter@ti.com (Jon Hunter) Date: Mon, 9 Apr 2012 15:18:22 -0500 Subject: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer In-Reply-To: <79CD15C6BA57404B839C016229A409A83184ABEF@DBDE01.ent.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> <87hawxkgoi.fsf@ti.com> <79CD15C6BA57404B839C016229A409A831849432@DBDE01.ent.ti.com> <20120406180452.GB15734@atomide.com> <79CD15C6BA57404B839C016229A409A83184ABEF@DBDE01.ent.ti.com> Message-ID: <4F83440E.70502@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Vaibhav, On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote: [...] > Let me summarize it here again, > > Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER, > to choose between 32ksync counter and gptimer; it is compile time option. > If user wants to use gptimer for HR ticks, he must build the kernel without > CONFIG_OMAP_32K_TIMER option. > > AM335x family of devices doesn't have 32ksync_counter available, only option > here is to use gptimer for kernel clocksource and clockevents. > > So in order to support, multi-omap build including devices like AM335x, we > must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource > registration perspective. > > So that means, we need to have some mechanism to handle or detect available > clocksource runtime. Options would be, > > - Use HWMOD to detect availability of 32ksync_counter, else fallback > to gptimer. [This was my original patch] > > But this restricts the use of gptimer completely on omap architecture, > where we have 32ksync counter module. True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used. So we should/must restrict the use of a gptimer is CONFIG_PM is enabled for devices that have the 32ksync timer. > - So the next solution is to still keep compile time option, so that user > will get to use gptimer atleast just changing the kernel config option. > > But, still, this is going to be kernel rebuild. > > - Next option came up was, register both the timers and override using > kernel parameter. > > This will work only if, both the timers run at same rate/frequency; since > we have one more layer here setup_sched_clock(), which actually can be > called only once. > > - Next option suggested by Santosh, is to use kernel parameter as in parse > it early, to make decision on if user wants to override default > clocksource (32ksync) > > This is something will work for us and solves all above issues. What happens if PM is enabled? Can you still override the default? I don't think this should be allowed for devices with a 32ksync timer. Jon