1. 16 5月, 2013 1 次提交
  2. 15 1月, 2013 1 次提交
  3. 04 9月, 2012 1 次提交
    • R
      timekeeping: Add suspend and resume of clock event devices · adc78e6b
      Rafael J. Wysocki 提交于
      Some clock event devices, for example such that belong to PM domains,
      need to be handled in a spcial way during the timekeeping suspend
      and resume (which takes place in the system core, or "syscore",
      stages of system power transitions) in analogy with clock sources.
      
      Introduce .suspend() and .resume() callbacks for clock event devices
      that will be executed by timekeeping_suspend/_resume(), respectively,
      next the the clock sources' .suspend() and .resume() callbacks.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      adc78e6b
  4. 25 5月, 2012 1 次提交
  5. 31 12月, 2011 1 次提交
  6. 22 12月, 2011 1 次提交
  7. 02 12月, 2011 1 次提交
  8. 08 9月, 2011 2 次提交
  9. 03 6月, 2011 1 次提交
    • T
      clockevents: Handle empty cpumask gracefully · 1b054b67
      Thomas Gleixner 提交于
      For UP it's stupid to request an initialized cpumask for the clock
      event devices. Though we need the mask set even on UP to avoid a
      horrible ifdeffery especially in the broadcast code.
      
      For SMP we can at least try to survive with a warning and set the
      cpumask of the cpu we're running on. That gives a decent chance to
      bring the machine up and retrieve the debug info.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Linus Walleij <linus.walleij@linaro.org
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      1b054b67
  10. 20 5月, 2011 1 次提交
  11. 19 5月, 2011 2 次提交
  12. 01 2月, 2011 1 次提交
  13. 18 1月, 2010 1 次提交
  14. 15 12月, 2009 1 次提交
  15. 11 12月, 2009 1 次提交
  16. 18 11月, 2009 1 次提交
  17. 14 11月, 2009 1 次提交
    • J
      nohz: Allow 32-bit machines to sleep for more than 2.15 seconds · 97813f2f
      Jon Hunter 提交于
      In the dynamic tick code, "max_delta_ns" (member of the
      "clock_event_device" structure) represents the maximum sleep time
      that can occur between timer events in nanoseconds.
      
      The variable, "max_delta_ns", is defined as an unsigned long
      which is a 32-bit integer for 32-bit machines and a 64-bit
      integer for 64-bit machines (if -m64 option is used for gcc).
      The value of max_delta_ns is set by calling the function
      "clockevent_delta2ns()" which returns a maximum value of LONG_MAX.
      For a 32-bit machine LONG_MAX is equal to 0x7fffffff and in
      nanoseconds this equates to ~2.15 seconds. Hence, the maximum
      sleep time for a 32-bit machine is ~2.15 seconds, where as for
      a 64-bit machine it will be many years.
      
      This patch changes the type of max_delta_ns to be "u64" instead of
      "unsigned long" so that this variable is a 64-bit type for both 32-bit
      and 64-bit machines. It also changes the maximum value returned by
      clockevent_delta2ns() to KTIME_MAX.  Hence this allows a 32-bit
      machine to sleep for longer than ~2.15 seconds. Please note that this
      patch also changes "min_delta_ns" to be "u64" too and although this is
      unnecessary, it makes the patch simpler as it avoids to fixup all
      callers of clockevent_delta2ns().
      
      [ tglx: changed "unsigned long long" to u64 as we use this data type
        	through out the time code ]
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      LKML-Reference: <1250617512-23567-3-git-send-email-jon-hunter@ti.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      97813f2f
  18. 20 8月, 2009 1 次提交
    • S
      clockevent: Prevent dead lock on clockevents_lock · f833bab8
      Suresh Siddha 提交于
      Currently clockevents_notify() is called with interrupts enabled at
      some places and interrupts disabled at some other places.
      
      This results in a deadlock in this scenario.
      
      cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
      cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
      cpu C doing set_mtrr() which will try to rendezvous of all the cpus.
      
      This will result in C and A come to the rendezvous point and waiting
      for B. B is stuck forever waiting for the spinlock and thus not
      reaching the rendezvous point.
      
      Fix the clockevents code so that clockevents_lock is taken with
      interrupts disabled and thus avoid the above deadlock.
      
      Also call lapic_timer_propagate_broadcast() on the destination cpu so
      that we avoid calling smp_call_function() in the clockevents notifier
      chain.
      
      This issue left us wondering if we need to change the MTRR rendezvous
      logic to use stop machine logic (instead of smp_call_function) or add
      a check in spinlock debug code to see if there are other spinlocks
      which gets taken under both interrupts enabled/disabled conditions.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com>
      Cc: "Brown Len" <len.brown@intel.com>
      LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f833bab8
  19. 10 7月, 2009 1 次提交
    • T
      hrtimer: Fix migration expiry check · 6ff7041d
      Thomas Gleixner 提交于
      The timer migration expiry check should prevent the migration of a
      timer to another CPU when the timer expires before the next event is
      scheduled on the other CPU. Migrating the timer might delay it because
      we can not reprogram the clock event device on the other CPU. But the
      code implementing that check has two flaws:
      
      - for !HIGHRES the check compares the expiry value with the clock
        events device expiry value which is wrong for CLOCK_REALTIME based
        timers.
      
      - the check is racy. It holds the hrtimer base lock of the target CPU,
        but the clock event device expiry value can be modified
        nevertheless, e.g. by an timer interrupt firing.
      
      The !HIGHRES case is easy to fix as we can enqueue the timer on the
      cpu which was selected by the load balancer. It runs the idle
      balancing code once per jiffy anyway. So the maximum delay for the
      timer is the same as when we keep the tick on the current cpu going.
      
      In the HIGHRES case we can get the next expiry value from the hrtimer
      cpu_base of the target CPU and serialize the update with the cpu_base
      lock. This moves the lock section in hrtimer_interrupt() so we can set
      next_event to KTIME_MAX while we are handling the expired timers and
      set it to the next expiry value after we handled the timers under the
      base lock. While the expired timers are processed timer migration is
      blocked because the expiry time of the timer is always <= KTIME_MAX.
      
      Also remove the now useless clockevents_get_next_event() function.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6ff7041d
  20. 13 5月, 2009 1 次提交
    • A
      timers: Logic to move non pinned timers · eea08f32
      Arun R Bharadwaj 提交于
      * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-04-16 12:11:36]:
      
      This patch migrates all non pinned timers and hrtimers to the current
      idle load balancer, from all the idle CPUs. Timers firing on busy CPUs
      are not migrated.
      
      While migrating hrtimers, care should be taken to check if migrating
      a hrtimer would result in a latency or not. So we compare the expiry of the
      hrtimer with the next timer interrupt on the target cpu and migrate the
      hrtimer only if it expires *after* the next interrupt on the target cpu.
      So, added a clockevents_get_next_event() helper function to return the
      next_event on the target cpu's clock_event_device.
      
      [ tglx: cleanups and simplifications ]
      Signed-off-by: NArun R Bharadwaj <arun@linux.vnet.ibm.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      eea08f32
  21. 02 5月, 2009 1 次提交
  22. 16 1月, 2009 1 次提交
    • M
      clockevents: let set_mode() setup delta information · 2d68259d
      Magnus Damm 提交于
      Allow the set_mode() clockevent callback to decide and fill in delta
      details such as shift, mult, max_delta_ns and min_delta_ns.
      
      With this change the clockevent can be registered without delta details
      which allows us to keep the parent clock disabled until the clockevent
      gets setup using set_mode().
      
      Letting set_mode() fill in or update delta details allows us to save
      power by disabling the parent clock while the clockevent is unused.
      This may however make the parent clock rate change, so next time the
      clockevent gets enabled we need let set_mode() to update the detla
      details accordingly. Doing it at registration time is not enough.
      
      Furthermore, the delta details seem unused in the case of periodic-only
      clockevent drivers, so this change also allows registration of such
      drivers without the delta details filled in.
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2d68259d
  23. 13 12月, 2008 1 次提交
  24. 17 9月, 2008 1 次提交
    • T
      clockevents: make device shutdown robust · 2344abbc
      Thomas Gleixner 提交于
      The device shut down does not cleanup the next_event variable of the
      clock event device. So when the device is reactivated the possible
      stale next_event value can prevent the device to be reprogrammed as it
      claims to wait on a event already.
      
      This is the root cause of the resurfacing suspend/resume problem,
      where systems need key press to come back to life.
      
      Fix this by setting next_event to KTIME_MAX when the device is shut
      down. Use a separate function for shutdown which takes care of that
      and only keep the direct set mode call in the broadcast code, where we
      can not touch the next_event value.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2344abbc
  25. 05 9月, 2008 1 次提交
    • V
      clockevents: prevent clockevent event_handler ending up handler_noop · 7c1e7689
      Venkatesh Pallipadi 提交于
      There is a ordering related problem with clockevents code, due to which
      clockevents_register_device() called after tickless/highres switch
      will not work. The new clockevent ends up with clockevents_handle_noop as
      event handler, resulting in no timer activity.
      
      The problematic path seems to be
      
      * old device already has hrtimer_interrupt as the event_handler
      * new clockevent device registers with a higher rating
      * tick_check_new_device() is called
        * clockevents_exchange_device() gets called
          * old->event_handler is set to clockevents_handle_noop
        * tick_setup_device() is called for the new device
          * which sets new->event_handler using the old->event_handler which is noop.
      
      Change the ordering so that new device inherits the proper handler.
      
      This does not have any issue in normal case as most likely all the clockevent
      devices are setup before the highres switch. But, can potentially be affecting
      some corner case where HPET force detect happens after the highres switch.
      This was a problem with HPET in MSI mode code that we have been experimenting
      with.
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7c1e7689
  26. 09 2月, 2008 2 次提交
  27. 30 1月, 2008 1 次提交
  28. 08 12月, 2007 1 次提交
  29. 13 10月, 2007 1 次提交
  30. 12 8月, 2007 1 次提交
  31. 17 7月, 2007 1 次提交
  32. 27 3月, 2007 1 次提交
  33. 17 2月, 2007 1 次提交
    • T
      [PATCH] clockevents: add core functionality · d316c57f
      Thomas Gleixner 提交于
      Architectures register their clock event devices, in the clock events core.
      Users of the clockevents core can get clock event devices for their use.  The
      clockevents core code provides notification mechanisms for various clock
      related management events.
      
      This allows to control the clock event devices without the architectures
      having to worry about the details of function assignment.  This is also a
      preliminary for high resolution timers and dynamic ticks to allow the core
      code to control the clock functionality without intrusive changes to the
      architecture code.
      
      [Fixes-by: Ingo Molnar <mingo@elte.hu>]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d316c57f