On Fri, Dec 14, 2012 at 02:56:51PM -0700, Jason Gunthorpe wrote: > On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote: > > > Although from a timekeeping perspective, the read_persistent_clock() > > interface is actually *much* preferred over the rtc HCTOSYS device. > > > > Since read_persistent_clock() has the requirement that its safe to > > call with IRQs disabled, we can use it in the timekeeping > > suspend/resume code, which allows for better time accuracy. > > 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. Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
