[lkml]   [2013]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
On 04/23/2013 06:34 PM, Kay Sievers wrote:
> Hey,
> what's the intention of:
> e90c83f757fffdacec8b3c5eee5617dcc038338f ?
> x86: Select HAS_PERSISTENT_CLOCK on x86
> It unconditionally sets:
> but:
> got a depends on !HAS_PERSISTENT_CLOCK
> This makes it impossible to sync the system time from the RTC on x86.
> What's going on here?

So I suspect just some confusion, but let me know if thats wrong and
you're actually seeing an issue.

SYSTOHC is what *sets the RTC* to the system time when we're synced with

HCTOSYS is what sets the system time from the RTC.

In the past, we've used the update_persistent_clock() interface to set
the CMOS clock when we're synced with NTP, but now we've got an
interface that can sync the RTC interface for systems that don't support

We've always used the persistent_clock code (or what persistent_clock
abstracted) on x86, but for awhile there was also ways to configure the
kernel to also use the generic RTC infrastructure, which could cause odd
behavior like the time being set/adjusted twice at boot and resume. This
was mostly avoided in code, but we figured we could also avoid these
duplicative paths at build time. Thus if HAS_PERSISTENT_CLOCK is
enabled, we can remove some extra checks that can slow down the resume path.

Now, the persistent_clock and RTC infrastructure are annoyingly
duplicitive, but have very different constraints. We're hopefully (and
likely slowly) working to consolidate some of the logic here.

My goal is eventually to remove the use of the persistent_clock() for
time initialization, instead using the generic RTC infrastructure.

Then I want to morph the persistent_clock infrastructure to really be
only for measuring suspend time by the timekeeping core at resume. This
can be done via clocksources that continue to count via suspend, or via
the RTC layer, however we need a special RTC hook to allow us to read
the RTC time when interrupts are disabled (not all RTCs support this).
Then only should both of those options fail, fall back to the late (and
more error prone) rtc resume hook for suspend timing.

But of course, I don't have patches for this transition yet, and I'm not
sure when in the near term I'll get time to focus on this cleanup.

However, if you are seeing a issue/regression with the existing code in
your config, please let me know and I'll make sure we address it.


 \ /
  Last update: 2013-04-24 05:01    [W:0.067 / U:1.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site