On Wed, Apr 11, 2012 at 6:30 AM, Ming Lei <tom.leiming@xxxxxxxxx> wrote: > On Tue, Apr 10, 2012 at 5:51 PM, Shilimkar, Santosh > <santosh.shilimkar@xxxxxx> wrote: >> On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> wrote: >>> On Tue, Apr 10, 2012 at 02:27:36PM +0530, Santosh Shilimkar wrote: >>>> On Tuesday 10 April 2012 02:14 PM, Russell King - ARM Linux wrote: >>>> > On Mon, Apr 09, 2012 at 03:18:22PM -0500, Jon Hunter wrote: >>>> >> 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. >>>> > >>>> > Why? What if you want to have PM enabled, and you also want to use the >>>> > kernels high resolution timers, or you want more accurate timing than >>>> > the 30.5us tick interval of the 32k timer? >>>> >>>> You might have missed the earlier comments on the thread. High >>>> resolution GP timer(sysclk) will stop in deeper power states and >>>> hence it can't be used with PM enabled usecases. >>> >>> Which means folk should be given the choice at boot time between running >>> with the deeper power states and having a higher resolution timing source, >>> rather than denying them the higher resolution timing source when PM is >>> enabled. >> >> Good point. My point is such facilities is already part of the kernel and >> there is no need to add a new one. The last proposal was allowing user to >> choose gptimer as a clocksource and then you already have facility to >> disable C-state now so, all should work in general > > 'nohlt' in boot cmd should work to prevent CPU from entering deep C-state, > which looks enough to make gptimer working well if system suspend isn't > considered. > That's another good option Looks like we get all the needed flexibility with the reworked patch from Vaibhav to choose the command like option for high res. timer source. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
