On Mon, Dec 17, 2012 at 11:22:02AM -0700, Jason Gunthorpe wrote: > 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.
No, it's not about my concern (actually I don't have concerns :), my 3 patches are just some optimization). My point is the "driver/rtc" or "drivers/rtc/class.c" can't be ganrateeded to be built for all kernels, myself saw several cases, under which the read_persistent_clock is still needed. If you want drivers/rtc code to take the priority, first thing you have to do is to make those codes always "obj-y=xxx.o" 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/
