All of lore.kernel.org
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 0/3] clocksource: add db8500 PRCMU timer
Date: Thu, 02 Jun 2011 18:46:32 +0530	[thread overview]
Message-ID: <4DE78D30.6020900@ti.com> (raw)
In-Reply-To: <20110602130406.GW3660@n2100.arm.linux.org.uk>

On 6/2/2011 6:34 PM, Russell King - ARM Linux wrote:
> On Thu, Jun 02, 2011 at 06:27:22PM +0530, Santosh Shilimkar wrote:
>> Earlier this year at ELC SFO, I had a discussion with
>> John and Thomas on how to have a high-resolution clock-source
>> and a low-resolution clock-source working together to cover
>> the low power scenario and still manage to get the highest
>> timer resolution.
>> The idea was to do dynamic switching of clock-source
>> which initially looked simple. Here the idea was to
>> have this working for suspend and as well as cupidle.
>
> I don't think you can do this, because you'll lose precision whenever you
> switch from the high resolution clocksource to the low resolution
> clocksource.
>
> While you can quickly update the current time of day from the highres one,
> the lowres may or may not be a long way from its next tick rollover.  So
> you lose the precision whenever you switch.
>
> However, over a suspend/resume cycle, the precision loss is normally very
> small compared to the time which you have been suspended, so the %age
> error also becomes very small.
>
> With cpuidle, it becomes a completely different matter.  Here, the %age
> error is much larger because of the smaller sleep periods, and chances
> are we can't wait for the low-res timer to change.
>
> So if you're using cpuidle, you really need a clocksource which runs
> continuously, even in whatever states cpuidle drops you into.

According to John, that's what the meta-clock source will for.
It will be continuous and will make use of underneath high res,
low res clock-sources based on the availability.

I let John comment on this on details but I think any other
method would have shortcoming.

Regards
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Mattias Wallin <mattias.wallin@stericsson.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Lee Jones <lee.jones@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	john stultz <johnstul@us.ibm.com>
Subject: Re: [PATCHv2 0/3] clocksource: add db8500 PRCMU timer
Date: Thu, 02 Jun 2011 18:46:32 +0530	[thread overview]
Message-ID: <4DE78D30.6020900@ti.com> (raw)
In-Reply-To: <20110602130406.GW3660@n2100.arm.linux.org.uk>

On 6/2/2011 6:34 PM, Russell King - ARM Linux wrote:
> On Thu, Jun 02, 2011 at 06:27:22PM +0530, Santosh Shilimkar wrote:
>> Earlier this year at ELC SFO, I had a discussion with
>> John and Thomas on how to have a high-resolution clock-source
>> and a low-resolution clock-source working together to cover
>> the low power scenario and still manage to get the highest
>> timer resolution.
>> The idea was to do dynamic switching of clock-source
>> which initially looked simple. Here the idea was to
>> have this working for suspend and as well as cupidle.
>
> I don't think you can do this, because you'll lose precision whenever you
> switch from the high resolution clocksource to the low resolution
> clocksource.
>
> While you can quickly update the current time of day from the highres one,
> the lowres may or may not be a long way from its next tick rollover.  So
> you lose the precision whenever you switch.
>
> However, over a suspend/resume cycle, the precision loss is normally very
> small compared to the time which you have been suspended, so the %age
> error also becomes very small.
>
> With cpuidle, it becomes a completely different matter.  Here, the %age
> error is much larger because of the smaller sleep periods, and chances
> are we can't wait for the low-res timer to change.
>
> So if you're using cpuidle, you really need a clocksource which runs
> continuously, even in whatever states cpuidle drops you into.

According to John, that's what the meta-clock source will for.
It will be continuous and will make use of underneath high res,
low res clock-sources based on the availability.

I let John comment on this on details but I think any other
method would have shortcoming.

Regards
Santosh




  reply	other threads:[~2011-06-02 13:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02  9:34 [PATCHv2 0/3] clocksource: add db8500 PRCMU timer Mattias Wallin
2011-06-02  9:34 ` Mattias Wallin
2011-06-02  9:46 ` Russell King - ARM Linux
2011-06-02  9:46   ` Russell King - ARM Linux
2011-06-02 10:18   ` Mattias Wallin
2011-06-02 10:18     ` Mattias Wallin
2011-06-02 11:01     ` Russell King - ARM Linux
2011-06-02 11:01       ` Russell King - ARM Linux
2011-06-02 12:10       ` Mattias Wallin
2011-06-02 12:10         ` Mattias Wallin
2011-06-02 12:57         ` Santosh Shilimkar
2011-06-02 12:57           ` Santosh Shilimkar
2011-06-02 13:04           ` Russell King - ARM Linux
2011-06-02 13:04             ` Russell King - ARM Linux
2011-06-02 13:16             ` Santosh Shilimkar [this message]
2011-06-02 13:16               ` Santosh Shilimkar
2011-06-02 18:47           ` john stultz
2011-06-02 18:47             ` john stultz
2011-06-08 13:44             ` Mattias Wallin
2011-06-08 13:44               ` Mattias Wallin
2011-06-09 21:59               ` Russell King - ARM Linux
2011-06-09 21:59                 ` Russell King - ARM Linux
2011-06-10  8:54                 ` Mattias Wallin
2011-06-10  8:54                   ` Mattias Wallin
2011-06-10 16:00                   ` Mattias Wallin
2011-06-10 16:00                     ` Mattias Wallin
2011-07-10 14:19   ` Russell King - ARM Linux
2011-07-10 14:19     ` Russell King - ARM Linux
2012-02-04 12:30   ` Russell King - ARM Linux
2012-02-04 12:30     ` Russell King - ARM Linux
2012-02-05 15:11     ` Linus Walleij
2012-02-05 15:11       ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DE78D30.6020900@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.