[PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Ming Lei]

On Tue, Apr 10, 2012 at 5:51 PM, Shilimkar, Santosh
<santosh.shilimkar at ti.com> wrote:
> On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> 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.

Thanks,
-- 
Ming Lei