Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 12月, 2013 1 次提交
  3. 17 11月, 2013 1 次提交
    • R
      alpha: Reorganize rtc handling · 85d0b3a5
      由 Richard Henderson 提交于 
      Discontinue use of GENERIC_CMOS_UPDATE; rely on the RTC subsystem.

The marvel platform requires that the rtc only be touched from the
boot cpu.  This had been partially implemented with hooks for
get/set_rtc_time, but read/update_persistent_clock were not handled.
Move the hooks from the machine_vec to a special rtc_class_ops struct.

We had read_persistent_clock managing the epoch against which the
rtc hw is based, but this didn't apply to get_rtc_time or set_rtc_time.
This resulted in incorrect values when hwclock(8) gets involved.

Allow the epoch to be set from the kernel command-line, overriding
the autodetection, which is doomed to fail in 2020.  Further, by
implementing the rtc ioctl function, we can expose this epoch to
userland.

Elide the alarm functions that RTC_DRV_CMOS implements.  This was
highly questionable on Alpha, since the interrupt is used by the
system timer.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
      85d0b3a5
  5. 13 11月, 2013 2 次提交
  7. 12 9月, 2013 1 次提交
  9. 04 7月, 2013 2 次提交
  11. 15 5月, 2013 1 次提交
    • J
      time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons · b4f711ee
      由 John Stultz 提交于 
      Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
which enables some minor compile time optimization to avoid
uncessary code in mostly the suspend/resume path could cause
problems for userland.

In particular, the dependency for RTC_HCTOSYS on
!ALWAYS_USE_PERSISTENT_CLOCK, which avoids setting the time
twice and simplifies suspend/resume, has the side effect
of causing the /sys/class/rtc/rtcN/hctosys flag to always be
zero, and this flag is commonly used by udev to setup the
/dev/rtc symlink to /dev/rtcN, which can cause pain for
older applications.

While the udev rules could use some work to be less fragile,
breaking userland should strongly be avoided. Additionally
the compile time optimizations are fairly minor, and the code
being optimized is likely to be reworked in the future, so
lets revert this change.
Reported-by: NKay Sievers <kay@vrfy.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Cc: stable <stable@vger.kernel.org> #3.9
Cc: Feng Tang <feng.tang@intel.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Link: http://lkml.kernel.org/r/1366828376-18124-1-git-send-email-john.stultz@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      b4f711ee
  13. 12 4月, 2013 1 次提交
  15. 22 2月, 2013 5 次提交
  17. 14 2月, 2013 1 次提交
  19. 31 1月, 2013 1 次提交
  21. 30 1月, 2013 1 次提交
  23. 16 1月, 2013 2 次提交
    • F
      timekeeping: Add CONFIG_HAS_PERSISTENT_CLOCK option · 05ad717c
      由 Feng Tang 提交于 
      Make the persistent clock check a kernel config option, so that some
platform can explicitely select it, also make CONFIG_RTC_HCTOSYS and
RTC_SYSTOHC depend on its non-existence, which could prevent the
persistent clock and RTC code from doing similar thing twice during
system's init/suspend/resume phases.

If the CONFIG_HAS_PERSISTENT_CLOCK=n, then no change happens for kernel
which still does the persistent clock check in timekeeping_init().

Cc: Thomas Gleixner <tglx@linutronix.de>
Suggested-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NFeng Tang <feng.tang@intel.com>
[jstultz: Added dependency for RTC_SYSTOHC as well]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      05ad717c
    • J
      NTP: Add a CONFIG_RTC_SYSTOHC configuration · 023f333a
      由 Jason Gunthorpe 提交于 
      The purpose of this option is to allow ARM/etc systems that rely on the
class RTC subsystem to have the same kind of automatic NTP based
synchronization that we have on PC platforms. Today ARM does not
implement update_persistent_clock and makes extensive use of the class
RTC system.

When enabled CONFIG_RTC_SYSTOHC will provide a generic
rtc_update_persistent_clock that stores the current time in the RTC and
is intended complement the existing CONFIG_RTC_HCTOSYS option that loads
the RTC at boot.

Like with RTC_HCTOSYS the platform's update_persistent_clock is used
first, if it works. Platforms with mixed class RTC and non-RTC drivers
need to return ENODEV when class RTC should be used. Such an update for
PPC is included in this patch.

Long term, implementations of update_persistent_clock should migrate to
proper class RTC drivers and use CONFIG_RTC_SYSTOHC instead.

Tested on ARM kirkwood and PPC405
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      023f333a
  25. 06 1月, 2013 1 次提交
    • A
      rtc: add rtc-driver for HID sensors of type time · 62e00cb9
      由 Alexander Holler 提交于 
      This driver makes the time from HID sensors (hubs) which are offering
such available like any other RTC does.

It is necessary that all values like year, month etc, are send as
8bit values (1 byte each) and all of them in 1 report. Also the
spec HUTRR39b doesn't define the range of the year field, we
tread it as 0 - 99 because that's what most RTCs I know about are
offering.

Currently the time can only be read. Setting the time must be done
through sending a report (or a feature). The spec currently doesn't
define how and I'm not sure if I just should define something by myself.
Signed-off-by: NAlexander Holler <holler@ahsoftware.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      62e00cb9
  27. 05 1月, 2013 1 次提交
  29. 18 12月, 2012 4 次提交
  31. 11 10月, 2012 1 次提交
  33. 06 10月, 2012 8 次提交
  35. 31 7月, 2012 1 次提交
  37. 09 7月, 2012 1 次提交
  39. 30 5月, 2012 2 次提交
  41. 16 4月, 2012 1 次提交
  43. 24 3月, 2012 1 次提交