From: Paul Mundt <lethal@linux-sh.org>
To: David Miller <davem@davemloft.net>
Cc: johnstul@us.ibm.com, linux-kernel@vger.kernel.org,
rth@twiddle.net, linux-alpha@vger.kernel.org,
linux-sh@vger.kernel.org, linux@arm.linux.org.uk,
hskinnemoen@atmel.com, vapier@gentoo.org, starvik@axis.com,
dhowells@redhat.com, ysato@users.sourceforge.jp,
tony.luck@intel.com, takata@linux-m32r.org, geert@linux-m68k.org,
yasutake.koichi@jp.panasonic.com, kyle@mcmartin.ca
Subject: Re: [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock
Date: Thu, 24 Dec 2009 14:10:21 +0900 [thread overview]
Message-ID: <20091224051021.GA28878@linux-sh.org> (raw)
In-Reply-To: <20091223.205415.232734959.davem@davemloft.net>
On Wed, Dec 23, 2009 at 08:54:15PM -0800, David Miller wrote:
> From: Paul Mundt <lethal@linux-sh.org>
> Date: Wed, 23 Dec 2009 14:08:10 +0900
>
> > In any event, I wonder if it might make more sense to take something like
> > the SPARC implementation that is simply a wrapper around the RTC, move
> > that out in to a more generic place, and permit architectures to select
> > an RTC class backed persistent clock instead (it seems to be only
> > platforms that haven't caught up yet in terms of generic time and RTC
> > migration that would want to define this interface on their own at all at
> > this point)?
>
> This sounds nice but don't we have a slew of RTC types that need
> to be accessed over I2C and thus you can't touch them without
> sleeping?
Yes, and SPI and so on. We do however have plenty of available room for
adding a valid-for-persistent-clock flag to permit drivers to opt-in, so
we can certainly still do better than the status quo. I'll hack something
up and see how it goes.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: David Miller <davem@davemloft.net>
Cc: johnstul@us.ibm.com, linux-kernel@vger.kernel.org,
rth@twiddle.net, linux-alpha@vger.kernel.org,
linux-sh@vger.kernel.org, linux@arm.linux.org.uk,
hskinnemoen@atmel.com, vapier@gentoo.org, starvik@axis.com,
dhowells@redhat.com, ysato@users.sourceforge.jp,
tony.luck@intel.com, takata@linux-m32r.org, geert@linux-m68k.org,
yasutake.koichi@jp.panasonic.com, kyle@mcmartin.ca
Subject: Re: [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock
Date: Thu, 24 Dec 2009 05:10:21 +0000 [thread overview]
Message-ID: <20091224051021.GA28878@linux-sh.org> (raw)
In-Reply-To: <20091223.205415.232734959.davem@davemloft.net>
On Wed, Dec 23, 2009 at 08:54:15PM -0800, David Miller wrote:
> From: Paul Mundt <lethal@linux-sh.org>
> Date: Wed, 23 Dec 2009 14:08:10 +0900
>
> > In any event, I wonder if it might make more sense to take something like
> > the SPARC implementation that is simply a wrapper around the RTC, move
> > that out in to a more generic place, and permit architectures to select
> > an RTC class backed persistent clock instead (it seems to be only
> > platforms that haven't caught up yet in terms of generic time and RTC
> > migration that would want to define this interface on their own at all at
> > this point)?
>
> This sounds nice but don't we have a slew of RTC types that need
> to be accessed over I2C and thus you can't touch them without
> sleeping?
Yes, and SPI and so on. We do however have plenty of available room for
adding a valid-for-persistent-clock flag to permit drivers to opt-in, so
we can certainly still do better than the status quo. I'll hack something
up and see how it goes.
next prev parent reply other threads:[~2009-12-24 5:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-23 3:59 [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock john stultz
2009-12-23 4:00 ` [RFC][PATCH 1/14] Convert alpha " john stultz
2009-12-23 4:01 ` [RFC][PATCH 2/14] Convert arm " john stultz
2009-12-23 4:01 ` john stultz
2009-12-23 4:03 ` [RFC][PATCH 3/14] Convert avr32 " john stultz
2009-12-23 4:04 ` [RFC][PATCH 4/14] Convert blackfin " john stultz
2009-12-23 4:05 ` [RFC][PATCH 5/14] Convert cris " john stultz
2009-12-23 4:06 ` [RFC][PATCH 6/14] Convert frv " john stultz
2009-12-23 4:08 ` [RFC][PATCH 7/14] Convert h8300 " john stultz
2009-12-23 4:09 ` [RFC][PATCH 8/14] Convert ia64 " john stultz
2009-12-23 4:09 ` john stultz
2009-12-23 4:10 ` [RFC][PATCH 9/14] Convert m32r " john stultz
2009-12-23 4:11 ` [RFC][PATCH 10/14] Convert m68k " john stultz
2009-12-23 4:11 ` john stultz
2009-12-23 4:12 ` [RFC][PATCH 11/14] Convert mn10300 " john stultz
2009-12-23 4:14 ` [RFC][PATCH 12/14] Convert parisc " john stultz
2009-12-23 4:14 ` john stultz
2009-12-23 4:15 ` [RFC][PATCH 13/14] Convert sh " john stultz
2009-12-23 4:15 ` john stultz
2009-12-23 4:16 ` [RFC][PATCH 14/14] Convert sparc " john stultz
2009-12-23 4:16 ` john stultz
2009-12-24 4:52 ` [RFC][PATCH 14/14] Convert sparc to David Miller
2009-12-24 4:52 ` [RFC][PATCH 14/14] Convert sparc to read/update_persistent_clock David Miller
2010-01-05 16:41 ` Kristoffer Glembo
2010-01-05 16:41 ` Kristoffer Glembo
2010-01-05 17:08 ` [RFC][PATCH 11/14] Convert mn10300 " David Howells
2010-01-05 16:47 ` [RFC][PATCH 6/14] Convert frv " David Howells
2009-12-24 11:09 ` [RFC][PATCH 2/14] Convert arm " Uwe Kleine-König
2009-12-24 11:09 ` Uwe Kleine-König
2009-12-23 5:08 ` [RFC][PATCH 0/14] Convert remaining arches " Paul Mundt
2009-12-23 5:08 ` Paul Mundt
2009-12-23 10:08 ` Geert Uytterhoeven
2009-12-23 10:08 ` [RFC][PATCH 0/14] Convert remaining arches to Geert Uytterhoeven
2009-12-23 22:04 ` [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock john stultz
2009-12-23 22:04 ` [RFC][PATCH 0/14] Convert remaining arches to john stultz
2009-12-24 0:27 ` [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock Dialup Jon Norstog
2009-12-24 0:27 ` Dialup Jon Norstog
2009-12-24 4:54 ` David Miller
2009-12-24 4:54 ` [RFC][PATCH 0/14] Convert remaining arches to David Miller
2009-12-24 5:10 ` Paul Mundt [this message]
2009-12-24 5:10 ` [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock Paul Mundt
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=20091224051021.GA28878@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=geert@linux-m68k.org \
--cc=hskinnemoen@atmel.com \
--cc=johnstul@us.ibm.com \
--cc=kyle@mcmartin.ca \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=rth@twiddle.net \
--cc=starvik@axis.com \
--cc=takata@linux-m32r.org \
--cc=tony.luck@intel.com \
--cc=vapier@gentoo.org \
--cc=yasutake.koichi@jp.panasonic.com \
--cc=ysato@users.sourceforge.jp \
/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.