Hi Jason, On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote: > > > make the HCTOSYS option be dependent on !HAS_PERSISTENT_CLOCK. This > > way we avoid having configs where there are conflicting paths that > > we chose from. > > On ARM the read_presistent_clock is used to access a true monotonic > counter that is divorced from the system RTC - look at > arch/arm/plat-omap/counter_32k.c for instance. > > This seems like a great use of that hardware resource, and no doubt > those mach's also have a class RTC driver available talking to > different hardware. > > For mach's without that functionality ARM returns a fixed 0 value > from read_persistent_clock, persumably the kernel detects this and > falls back to using class rtc functions?
I read the counter_32k.c and the read_persistent_clock() magic for ARM, and got a question: for the omap platforms using the counter_32k.c's read_persistent_clock, why will they also calles the time service from RTC device like the rtc_suspend/resume? I thought usually we just need to use the time source with the better accuracy. Thanks, Feng > > Maybe Feng would be better off adjusting read_persistent_clock to > return ENODEV in such cases?? > > So, I think you have to keep your test as a run time test. To support > the single image ARM boot you can't make the distinction with kconfig. > > Regards, > Jason -- 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/
