Messages in this thread | | | Date | Mon, 17 Dec 2012 11:22:02 -0700 | From | Jason Gunthorpe <> | Subject | Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag |
| |
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
| |