[lkml]   [2013]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT_CLOCK changes?
    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.024 / U:5.344 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site