All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: John Stultz <johnstul@us.ibm.com>
Cc: Russell King <linux@arm.linux.org.uk>,
	Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Stephen Warren <swarren@nvidia.com>,
	Mike Frysinger <vapier@gentoo.org>,
	Mikael Starvik <starvik@axis.com>,
	Hirokazu Takata <takata@linux-m32r.org>
Subject: Re: [PATCH V2 2/11] time: convert arch_gettimeoffset to a pointer
Date: Tue, 13 Nov 2012 10:14:32 -0700	[thread overview]
Message-ID: <50A27FF8.3080905@wwwdotorg.org> (raw)
In-Reply-To: <50A16BD3.5010707@us.ibm.com>

On 11/12/2012 02:36 PM, John Stultz wrote:
> On 11/12/2012 12:51 PM, Stephen Warren wrote:
>> Currently, whenever CONFIG_ARCH_USES_GETTIMEOFFSET is enabled, each
>> arch core provides a single implementation of arch_gettimeoffset(). In
>> many cases, different sub-architectures, different machines, or
>> different timer providers exist, and so the arch ends up implementing
>> arch_gettimeoffset() as a call-through-pointer anyway. Examples are
>> ARM, Cris, M68K, and it's arguable that the remaining architectures,
>> M32R and Blackfin, should be doing this anyway.
>>
>> Modify arch_gettimeoffset so that it itself is a function pointer, which
>> the arch initializes. This will allow later changes to move the
>> initialization of this function into individual machine support or timer
>> drivers. This is particularly useful for code in drivers/clocksource
>> which should rely on an arch-independant mechanism to register their
>> implementation of arch_gettimeoffset().
...
> One last thing to watch out for: If you're trying to build a kernel that
> mixes clocksource support with get_arch_timeoffset, you'll need to
> rework the #ifdef in update_wall_time(), since we currently assume with
> get_arch_timeoffset() that you're using tick + interpolation, so every
> call to update_wall_time() only moves time forward by one jiffy.

OK. I don't have any immediate plans to do that, although I wouldn't be
surprised if we (the ARM community in general) end up wanting to do that
at some point. It all depends on which ARM sub-architectures end up
getting converted to the multi-platform zImage support I guess.

> Otherwise, thanks for the name tweak. Going through the arm-soc tree is
> fine with me.
> 
> Acked-by: John Stultz <johnstul@us.ibm.com>

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/11] time: convert arch_gettimeoffset to a pointer
Date: Tue, 13 Nov 2012 10:14:32 -0700	[thread overview]
Message-ID: <50A27FF8.3080905@wwwdotorg.org> (raw)
In-Reply-To: <50A16BD3.5010707@us.ibm.com>

On 11/12/2012 02:36 PM, John Stultz wrote:
> On 11/12/2012 12:51 PM, Stephen Warren wrote:
>> Currently, whenever CONFIG_ARCH_USES_GETTIMEOFFSET is enabled, each
>> arch core provides a single implementation of arch_gettimeoffset(). In
>> many cases, different sub-architectures, different machines, or
>> different timer providers exist, and so the arch ends up implementing
>> arch_gettimeoffset() as a call-through-pointer anyway. Examples are
>> ARM, Cris, M68K, and it's arguable that the remaining architectures,
>> M32R and Blackfin, should be doing this anyway.
>>
>> Modify arch_gettimeoffset so that it itself is a function pointer, which
>> the arch initializes. This will allow later changes to move the
>> initialization of this function into individual machine support or timer
>> drivers. This is particularly useful for code in drivers/clocksource
>> which should rely on an arch-independant mechanism to register their
>> implementation of arch_gettimeoffset().
...
> One last thing to watch out for: If you're trying to build a kernel that
> mixes clocksource support with get_arch_timeoffset, you'll need to
> rework the #ifdef in update_wall_time(), since we currently assume with
> get_arch_timeoffset() that you're using tick + interpolation, so every
> call to update_wall_time() only moves time forward by one jiffy.

OK. I don't have any immediate plans to do that, although I wouldn't be
surprised if we (the ARM community in general) end up wanting to do that
at some point. It all depends on which ARM sub-architectures end up
getting converted to the multi-platform zImage support I guess.

> Otherwise, thanks for the name tweak. Going through the arm-soc tree is
> fine with me.
> 
> Acked-by: John Stultz <johnstul@us.ibm.com>

Thanks.

  reply	other threads:[~2012-11-13 17:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-12 20:51 [PATCH V2 2/11] time: convert arch_gettimeoffset to a pointer Stephen Warren
2012-11-12 20:51 ` Stephen Warren
2012-11-12 20:51 ` Stephen Warren
2012-11-12 20:51 ` Stephen Warren
2012-11-12 21:36 ` John Stultz
2012-11-12 21:36   ` John Stultz
2012-11-13 17:14   ` Stephen Warren [this message]
2012-11-13 17:14     ` Stephen Warren
2012-11-13 21:52     ` Arnd Bergmann
2012-11-13 21:52       ` Arnd Bergmann

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=50A27FF8.3080905@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=arnd@arndb.de \
    --cc=johnstul@us.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=starvik@axis.com \
    --cc=swarren@nvidia.com \
    --cc=takata@linux-m32r.org \
    --cc=tglx@linutronix.de \
    --cc=vapier@gentoo.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.