On 04/10/2012 04:51 AM, Shilimkar, Santosh wrote:
On Tue, Apr 10, 2012 at 2:59 PM, Russell King - ARM Linux
<li...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
