All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tony Lindgren <tony@atomide.com>,
	Vaibhav Bedia <vaibhav.bedia@ti.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 5/5] ARM: OMAP3: Update clocksource timer selection
Date: Thu, 31 Jan 2013 10:07:19 -0600	[thread overview]
Message-ID: <510A96B7.7010503@ti.com> (raw)
In-Reply-To: <510A3493.6050508@compulab.co.il>


On 01/31/2013 03:08 AM, Igor Grinberg wrote:
> On 01/30/13 19:04, Jon Hunter wrote:
>> When booting with device-tree for OMAP3 and AM335x devices and a gptimer
>> is used as the clocksource (which is always the case for AM335x), a
>> gptimer located in a power domain that is not always-on is selected.
>> Ideally we should use a gptimer located in a power domain that is always
>> on (such as the wake-up domain) so that time can be maintained during a
>> kernel suspend without keeping on additional power domains unnecessarily.
>>
>> In order to fix this so that we can select a gptimer located in a power
>> domain that is always-on, the following changes were made ...
>> 1. Currently, only when selecting a gptimer to use for a clockevent
>>    timer, do we pass a timer property that can be used to select a
>>    specific gptimer. Change this so that we can pass a property when
>>    selecting a gptimer to use for a clocksource timer too.
>> 2. Currently, when selecting either a gptimer to use for a clockevent
>>    timer or a clocksource timer and no timer property is passed, then
>>    the first available timer is selected regardless of the properties
>>    it has. Change this so that if no properties are passed, then a timer
>>    that does not have additional features (such as always-on, dsp-irq,
>>    pwm, and secure) is selected.
>>
>> Please note that using a gptimer for both clocksource and clockevents
>> can have a system power impact during idle. The reason being is that
>> OMAP and AMxxx devices typically only have one gptimer in a power domain
>> that is always-on. Therefore when the kernel is idle both the clocksource
>> and clockevent timers will be active and this will keep additional power
>> domains on. During kernel suspend, only the clocksource timer is active
>> and therefore, it is better to use a gptimer in a power domain that is
>> always-on for clocksource.
> 
> This should explain the gptimer number switch in the
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> section below, right?
> I would really like to see that clearly stated in the commit message.
> For instance:
> ... it is better to use a gptimer in a power domain that is
> always-on for clocksource. Therefore we switch to use the first gptimer
> for clocksource and the second for clockevents.

Yes exactly. Good point I can make that bit explicit.

>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> Apart from above,
> Acked-by: Igor Grinberg <grinberg@compulab.co.il>

Thanks
Jon

WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/5] ARM: OMAP3: Update clocksource timer selection
Date: Thu, 31 Jan 2013 10:07:19 -0600	[thread overview]
Message-ID: <510A96B7.7010503@ti.com> (raw)
In-Reply-To: <510A3493.6050508@compulab.co.il>


On 01/31/2013 03:08 AM, Igor Grinberg wrote:
> On 01/30/13 19:04, Jon Hunter wrote:
>> When booting with device-tree for OMAP3 and AM335x devices and a gptimer
>> is used as the clocksource (which is always the case for AM335x), a
>> gptimer located in a power domain that is not always-on is selected.
>> Ideally we should use a gptimer located in a power domain that is always
>> on (such as the wake-up domain) so that time can be maintained during a
>> kernel suspend without keeping on additional power domains unnecessarily.
>>
>> In order to fix this so that we can select a gptimer located in a power
>> domain that is always-on, the following changes were made ...
>> 1. Currently, only when selecting a gptimer to use for a clockevent
>>    timer, do we pass a timer property that can be used to select a
>>    specific gptimer. Change this so that we can pass a property when
>>    selecting a gptimer to use for a clocksource timer too.
>> 2. Currently, when selecting either a gptimer to use for a clockevent
>>    timer or a clocksource timer and no timer property is passed, then
>>    the first available timer is selected regardless of the properties
>>    it has. Change this so that if no properties are passed, then a timer
>>    that does not have additional features (such as always-on, dsp-irq,
>>    pwm, and secure) is selected.
>>
>> Please note that using a gptimer for both clocksource and clockevents
>> can have a system power impact during idle. The reason being is that
>> OMAP and AMxxx devices typically only have one gptimer in a power domain
>> that is always-on. Therefore when the kernel is idle both the clocksource
>> and clockevent timers will be active and this will keep additional power
>> domains on. During kernel suspend, only the clocksource timer is active
>> and therefore, it is better to use a gptimer in a power domain that is
>> always-on for clocksource.
> 
> This should explain the gptimer number switch in the
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> section below, right?
> I would really like to see that clearly stated in the commit message.
> For instance:
> ... it is better to use a gptimer in a power domain that is
> always-on for clocksource. Therefore we switch to use the first gptimer
> for clocksource and the second for clockevents.

Yes exactly. Good point I can make that bit explicit.

>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> Apart from above,
> Acked-by: Igor Grinberg <grinberg@compulab.co.il>

Thanks
Jon

  reply	other threads:[~2013-01-31 16:07 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30 17:04 [PATCH 0/5] ARM: OMAP2+: System timer updates Jon Hunter
2013-01-30 17:04 ` Jon Hunter
2013-01-30 17:04 ` [PATCH 1/5] ARM: OMAP2+: Display correct system timer name Jon Hunter
2013-01-30 17:04   ` Jon Hunter
2013-02-01  8:41   ` Bedia, Vaibhav
2013-02-01  8:41     ` Bedia, Vaibhav
2013-02-01  8:53     ` Jon Hunter
2013-02-01  8:53       ` Jon Hunter
2013-02-01  9:31       ` Bedia, Vaibhav
2013-02-01  9:31         ` Bedia, Vaibhav
2013-02-01 10:34         ` Jon Hunter
2013-02-01 10:34           ` Jon Hunter
2013-01-30 17:04 ` [PATCH 2/5] ARM: OMAP2+: Remove hard-coded test on timer ID Jon Hunter
2013-01-30 17:04   ` Jon Hunter
2013-01-30 17:04 ` [PATCH 3/5] ARM: OMAP2+: Simplify system timer clock definitions Jon Hunter
2013-01-30 17:04   ` Jon Hunter
2013-01-30 17:04 ` [PATCH 4/5] ARM: OMAP2+: Simplify system timers definitions Jon Hunter
2013-01-30 17:04   ` Jon Hunter
2013-01-31  9:09   ` Igor Grinberg
2013-01-31  9:09     ` Igor Grinberg
2013-02-04 15:27   ` Jon Hunter
2013-02-04 15:27     ` Jon Hunter
2013-01-30 17:04 ` [PATCH 5/5] ARM: OMAP3: Update clocksource timer selection Jon Hunter
2013-01-30 17:04   ` Jon Hunter
2013-01-31  9:08   ` Igor Grinberg
2013-01-31  9:08     ` Igor Grinberg
2013-01-31 16:07     ` Jon Hunter [this message]
2013-01-31 16:07       ` Jon Hunter
2013-02-01  8:41   ` Bedia, Vaibhav
2013-02-01  8:41     ` Bedia, Vaibhav
2013-02-01  8:59     ` Jon Hunter
2013-02-01  8:59       ` Jon Hunter
2013-02-01  9:25       ` Jon Hunter
2013-02-01  9:25         ` Jon Hunter
2013-02-01  9:31         ` Bedia, Vaibhav
2013-02-01  9:31           ` Bedia, Vaibhav
2013-01-31  9:40 ` [PATCH 0/5] ARM: OMAP2+: System timer updates Santosh Shilimkar
2013-01-31  9:40   ` Santosh Shilimkar
2013-02-01  8:41 ` Bedia, Vaibhav
2013-02-01  8:41   ` Bedia, Vaibhav

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=510A96B7.7010503@ti.com \
    --to=jon-hunter@ti.com \
    --cc=grinberg@compulab.co.il \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=vaibhav.bedia@ti.com \
    /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.