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

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

On Fri, Dec 14, 2012 at 11:13:30AM +0800, Feng Tang wrote:

> > 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.
> 
> Interesting to know this, thanks for the info. For the x86 desktop
> and mobile processors I've used, the read_persistent_clock and rtc
> are the same on-board device (always power on), so I see many time
> related code are execuated twice, like init/suspend/resume if
> HCTOSYS config is enabled, that's why I came up with the patches.

Ah, I see, there is some duplication here, my earlier comments about
update_persistent_clock are not quite right, some places like PCs
stick a RTC driver and then continue to access the same hardware
directly outside the rtc driver context! That seems ugly :|

I see the PC CMOS rtc driver does not implement the set_mmss
operation, instead running that code through update_persistent_clock..
That seems like a cleanup waiting to happen.

Regarding your problem - IMHO, it would be fantastic if the class RTC
driver could be used instead of read_persistent_clock on PC.

John mentioned that read_persistent_clock had a requirement to work
with IRQs off - that seems like it would be easy to incorporate into
class rtc - for hardware that supports it (and PC is not the only RTC
HW that can do this) Is that the only reason it still exists on pc?

I have to feel the long term direction should be to remove
*_persistent_clock in favor of class RTC?

> > Maybe Feng would be better off adjusting read_persistent_clock to
> > return ENODEV in such cases??
> 
> For mach's without read_persistent_clock capability, there is already
> a weakly defined 

This is used for arch's without the functionality, mach's are arch
specific things. ARM provides a function pointer indirection for it's
read_persistent_clock implementation.

Jason