From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Feng Tang <feng.tang@intel.com>
Cc: John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alessandro Zummo <a.zummo@towertech.it>,
linux-kernel@vger.kernel.org, alek.du@intel.com
Subject: Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
Date: Mon, 17 Dec 2012 11:22:02 -0700 [thread overview]
Message-ID: <20121217182202.GA10368@obsidianresearch.com> (raw)
In-Reply-To: <20121217161433.GB4762@feng-snb>
On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
> > Sure, but my view on this is that it has nothing to do with
> > read_persistent_clock. If the RTC driver can run with IRQs off is a
> > property of the RTC driver and RTC hardware - it has nothing to do
> > with the platform. ARM platforms will vary on a machine by machine
> > basis. The rtc-mv driver used on my ARM system is perfectly
> > re-entrant, lots of rtc on SOC drivers will be the same.
> >
> > If this is the only thing keeping you on read_persistent_clock, for
> > real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> > rtc_device.flags?
> >
> > Reserve read_persistent_clock for things like that very specialized
> > non-RTC ARM counter.
>
> Yes, these non-RTC device is one reason for keeping read_persistent_clock,
> one other reason I can think of is the CONFIG_RTC_LIB is not always on by
> default for all Archs, and some platforms may chose to disable it on purpose.
> When CONFIG_RTC_LIB is not set, we need the read_persistent_clock for
> time init/suspend/resume.
I thought your concern was the case where the RTC was turned on and
read_persistent_clock was also turned on. Having a flag in the RTC and
disabling read_persistent_clock for that situation would help you
avoid the double code path to the same hardware.
What is motivating having a RTC but not using RTC lib? Embedded
doesn't seem to the be the case, nearly all the interesting rtcs are
under class rtc....
Jason
next prev parent reply other threads:[~2012-12-17 18:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 2:05 [PATCH 1/3] timekeeping: Add persistent_clock_exist flag Feng Tang
2012-12-13 2:05 ` [PATCH 2/3] rtc: Skip the suspend/resume handling if persistent clock exist Feng Tang
2012-12-13 2:05 ` [PATCH 3/3] rtc: Skip setting xtime if persisent " Feng Tang
2012-12-14 1:20 ` [PATCH 1/3] timekeeping: Add persistent_clock_exist flag John Stultz
2012-12-14 1:37 ` Feng Tang
2012-12-14 2:00 ` John Stultz
2012-12-14 2:15 ` Feng Tang
2012-12-14 2:38 ` Jason Gunthorpe
2012-12-14 3:13 ` Feng Tang
2012-12-14 4:10 ` Jason Gunthorpe
2012-12-14 21:22 ` John Stultz
2012-12-14 21:56 ` Jason Gunthorpe
2012-12-14 23:23 ` John Stultz
2012-12-17 16:14 ` Feng Tang
2012-12-17 18:22 ` Jason Gunthorpe [this message]
2012-12-18 2:44 ` Feng Tang
2012-12-14 21:36 ` John Stultz
2012-12-20 7:02 ` Feng Tang
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=20121217182202.GA10368@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=a.zummo@towertech.it \
--cc=alek.du@intel.com \
--cc=feng.tang@intel.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.