1. 20 5月, 2011 1 次提交
  2. 19 5月, 2011 3 次提交
  3. 17 5月, 2011 1 次提交
    • T
      tick: Clear broadcast active bit when switching to oneshot · 07f4beb0
      Thomas Gleixner 提交于
      The first cpu which switches from periodic to oneshot mode switches
      also the broadcast device into oneshot mode. The broadcast device
      serves as a backup for per cpu timers which stop in deeper
      C-states. To avoid starvation of the cpus which might be in idle and
      depend on broadcast mode it marks the other cpus as broadcast active
      and sets the brodcast expiry value of those cpus to the next tick.
      
      The oneshot mode broadcast bit for the other cpus is sticky and gets
      only cleared when those cpus exit idle. If a cpu was not idle while
      the bit got set in consequence the bit prevents that the broadcast
      device is armed on behalf of that cpu when it enters idle for the
      first time after it switched to oneshot mode.
      
      In most cases that goes unnoticed as one of the other cpus has usually
      a timer pending which keeps the broadcast device armed with a short
      timeout. Now if the only cpu which has a short timer active has the
      bit set then the broadcast device will not be armed on behalf of that
      cpu and will fire way after the expected timer expiry. In the case of
      Christians bug report it took ~145 seconds which is about half of the
      wrap around time of HPET (the limit for that device) due to the fact
      that all other cpus had no timers armed which expired before the 145
      seconds timeframe.
      
      The solution is simply to clear the broadcast active bit
      unconditionally when a cpu switches to oneshot mode after the first
      cpu switched the broadcast device over. It's not idle at that point
      otherwise it would not be executing that code.
      
      [ I fundamentally hate that broadcast crap. Why the heck thought some
        folks that when going into deep idle it's a brilliant concept to
        switch off the last device which brings the cpu back from that
        state? ]
      
      Thanks to Christian for providing all the valuable debug information!
      Reported-and-tested-by: NChristian Hoffmann <email@christianhoffmann.info>
      Cc: John Stultz <johnstul@us.ibm.com>
      Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.1105161105170.3078%40ionos%3E
      Cc: stable@kernel.org
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      07f4beb0
  4. 05 5月, 2011 1 次提交
  5. 03 5月, 2011 1 次提交
  6. 29 4月, 2011 2 次提交
    • J
      timers: Remove delayed irqwork from alarmtimers implementation · 7068b7a1
      John Stultz 提交于
      Thomas asked about the delayed irq work in the alarmtimers code,
      and I realized that it was a legacy from when the alarmtimer base
      lock was a mutex (due to concerns that we'd be interacting with
      the RTC device, which is protected by mutexes).
      
      Since the alarmtimer base is now protected by a spinlock, we can
      simply execute alarmtimer functions directly from the hrtimer
      callback. Should any future alarmtimer functions sleep, they can
      simply manage scheduling any delayed work themselves.
      
      CC: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      7068b7a1
    • J
      timers: Improve alarmtimer comments and minor fixes · 180bf812
      John Stultz 提交于
      This patch addresses a number of minor comment improvements and
      other minor issues from Thomas' review of the alarmtimers code.
      
      CC: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      180bf812
  7. 27 4月, 2011 3 次提交
    • J
      timers: Posix interface for alarm-timers · 9a7adcf5
      John Stultz 提交于
      This patch exposes alarm-timers to userland via the posix clock
      and timers interface, using two new clockids: CLOCK_REALTIME_ALARM
      and CLOCK_BOOTTIME_ALARM. Both clockids behave identically to
      CLOCK_REALTIME and CLOCK_BOOTTIME, respectively, but timers
      set against the _ALARM suffixed clockids will wake the system if
      it is suspended.
      
      Some background can be found here:
      	https://lwn.net/Articles/429925/
      
      The concept for Alarm-timers was inspired by the Android Alarm
      driver (by Arve Hjønnevåg) found in the Android kernel tree.
      
      See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
      
      While the in-kernel interface is pretty similar between
      alarm-timers and Android alarm driver, the user-space interface
      for the Android alarm driver is via ioctls to a new char device.
      As mentioned above, I've instead chosen to export this functionality
      via the posix interface, as it seemed a little simpler and avoids
      creating duplicate interfaces to things like CLOCK_REALTIME and
      CLOCK_MONOTONIC under alternate names (ie:ANDROID_ALARM_RTC and
      ANDROID_ALARM_SYSTEMTIME).
      
      The semantics of the Android alarm driver are different from what
      this posix interface provides. For instance, threads other then
      the thread waiting on the Android alarm driver are able to modify
      the alarm being waited on. Also this interface does not allow
      the same wakelock semantics that the Android driver provides
      (ie: kernel takes a wakelock on RTC alarm-interupt, and holds it
      through process wakeup, and while the process runs, until the
      process either closes the char device or calls back in to wait
      on a new alarm).
      
      One potential way to implement similar semantics may be via
      the timerfd infrastructure, but this needs more research.
      
      There may also need to be some sort of sysfs system level policy
      hooks that allow alarm timers to be disabled to keep them
      from firing at inappropriate times (ie: laptop in a well insulated
      bag, mid-flight).
      
      CC: Arve Hjønnevåg <arve@android.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Alessandro Zummo <a.zummo@towertech.it>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      9a7adcf5
    • J
      timers: Introduce in-kernel alarm-timer interface · ff3ead96
      John Stultz 提交于
      This provides the in kernel interface and infrastructure for
      alarm-timers.
      
      Alarm-timers are a hybrid style timer, similar to hrtimers,
      but when the system is suspended, the RTC device is set to
      fire and wake the system for when the soonest alarm-timer
      expires.
      
      The concept for Alarm-timers was inspired by the Android Alarm
      driver (by Arve Hjønnevåg) found in the Android kernel tree.
      
      See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
      
      This in-kernel interface should be fairly compatible with the
      Android alarm driver in-kernel interface, but has the advantage
      of utilizing the new RTC timerqueue code instead of doing direct
      RTC manipulation.
      
      CC: Arve Hjønnevåg <arve@android.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Alessandro Zummo <a.zummo@towertech.it>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      ff3ead96
    • J
      time: Add timekeeping_inject_sleeptime · 304529b1
      John Stultz 提交于
      Some platforms cannot implement read_persistent_clock, as
      their RTC devices are only accessible when interrupts are enabled.
      This keeps them from being used by the timekeeping code on resume
      to measure the time in suspend.
      
      The RTC layer tries to work around this, by calling do_settimeofday
      on resume after irqs are reenabled to set the time properly. However,
      this only corrects CLOCK_REALTIME, and does not properly adjust
      the sleep time value. This causes btime in /proc/stat to be incorrect
      as well as making the new CLOCK_BOTTTIME inaccurate.
      
      This patch resolves the issue by introducing a new timekeeping hook
      to allow the RTC layer to inject the sleep time on resume.
      
      The code also checks to make sure that read_persistent_clock is
      nonfunctional before setting the sleep time, so that should the RTC's
      HCTOSYS option be configured in on a system that does support
      read_persistent_clock we will not increase the total_sleep_time twice.
      
      CC: Arve Hjønnevåg <arve@android.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      304529b1
  8. 18 4月, 2011 1 次提交
  9. 04 4月, 2011 1 次提交
  10. 31 3月, 2011 1 次提交
  11. 24 3月, 2011 1 次提交
  12. 13 3月, 2011 1 次提交
    • T
      posix-clocks: Check write permissions in posix syscalls · 6e6823d1
      Torben Hohn 提交于
      pc_clock_settime() and pc_clock_adjtime() do not check whether the fd
      was opened in write mode, so a clock can be set with a read only fd.
      
      [ tglx: We deliberately do not return -EPERM as we want this to be
        	distingushable from the capability based permission check ]
      Signed-off-by: NTorben Hohn <torbenh@gmx.de>
      LKML-Reference: <1299173174-348-4-git-send-email-torbenh@gmx.de>
      Cc: Richard Cochran <richard.cochran@omicron.at>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      6e6823d1
  13. 26 2月, 2011 1 次提交
    • T
      clockevents: Prevent oneshot mode when broadcast device is periodic · 3a142a06
      Thomas Gleixner 提交于
      When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only
      can switch into oneshot mode, when the backup broadcast device
      supports oneshot mode as well. Otherwise we would try to switch the
      broadcast device into an unsupported mode unconditionally. This went
      unnoticed so far as the current available broadcast devices support
      oneshot mode. Seth unearthed this problem while debugging and working
      around an hpet related BIOS wreckage.
      
      Add the necessary check to tick_is_oneshot_available().
      Reported-and-tested-by: NSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.1102252231200.2701@localhost6.localdomain6>
      Cc: stable@kernel.org # .21 ->
      3a142a06
  14. 22 2月, 2011 2 次提交
  15. 19 2月, 2011 1 次提交
  16. 12 2月, 2011 1 次提交
  17. 02 2月, 2011 4 次提交
  18. 01 2月, 2011 2 次提交
  19. 31 1月, 2011 5 次提交
  20. 20 1月, 2011 1 次提交
    • S
      hrtimers: Notify hrtimer users of switches to NOHZ mode · 2d0640b4
      Stephen Boyd 提交于
      When NOHZ=y and high res timers are disabled (via cmdline or
      Kconfig) tick_nohz_switch_to_nohz() will notify the user about
      switching into NOHZ mode. Nothing is printed for the case where
      HIGH_RES_TIMERS=y. Fix this for the HIGH_RES_TIMERS=y case by
      duplicating the printk from the low res NOHZ path in the high
      res NOHZ path.
      
      This confused me since I was thinking 'dmesg | grep -i NOHZ' would
      tell me if NOHZ was enabled, but if I have hrtimers there is
      nothing.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1295419594-13085-1-git-send-email-sboyd@codeaurora.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2d0640b4
  21. 14 1月, 2011 2 次提交
  22. 12 1月, 2011 2 次提交
  23. 23 12月, 2010 1 次提交
  24. 17 12月, 2010 1 次提交