Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag

[Feng Tang]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/