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

Jon Hunter jon-hunter at ti.com
Tue Apr 10 17:03:17 EDT 2012


On 04/10/2012 04:51 AM, Shilimkar, Santosh 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

Actually, thinking about this some more, you do not even need to disable 
c-states. By using a gptimer1 and configuring it to use the SYSCLK as it 
source, as long as the gptimer1 is not disabled, it will prevent SYSCLK 
from ever turning off.

Probably for good measure in this case we should also disable auto clock 
gating of SYSCLK via the PRM_CLKSRC_CTRL (OMAP2/3) or PRM_CLKREQCTRL 
(OMAP4).

Sounds like a good approach.

Jon



More information about the linux-arm-kernel mailing list