1. 03 4月, 2015 1 次提交
  2. 02 4月, 2015 1 次提交
    • I
      clockevents: Clean up clockchips.h · 9eed56e8
      Ingo Molnar 提交于
      Do various cleanups on the clockchips.h file:
      
       - indent preprocessor blocks to make it more clear which block we are in,
         this also makes merge resolution easier
      
       - comment larger preprocessor blocks consistently, using the:
      
           #if FOO
           ...
           #else /* !FOO: */
           ...
           #endif /* !FOO */
      
         notation.
      
       - unbreak lines
      
       - etc.
      
      No change in functionality.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9eed56e8
  3. 01 4月, 2015 4 次提交
  4. 27 3月, 2015 2 次提交
  5. 18 2月, 2015 1 次提交
    • V
      clockevents: Introduce mode specific callbacks · bd624d75
      Viresh Kumar 提交于
      It is not possible for the clockevents core to know which modes (other than
      those with a corresponding feature flag) are supported by a particular
      implementation. And drivers are expected to handle transition to all modes
      elegantly, as ->set_mode() would be issued for them unconditionally.
      
      Now, adding support for a new mode complicates things a bit if we want to use
      the legacy ->set_mode() callback. We need to closely review all clockevents
      drivers to see if they would break on addition of a new mode. And after such
      reviews, it is found that we have to do non-trivial changes to most of the
      drivers [1].
      
      Introduce mode-specific set_mode_*() callbacks, some of which the drivers may or
      may not implement. A missing callback would clearly convey the message that the
      corresponding mode isn't supported.
      
      A driver may still choose to keep supporting the legacy ->set_mode() callback,
      but ->set_mode() wouldn't be supporting any new modes beyond RESUME. If a driver
      wants to benefit from using a new mode, it would be required to migrate to
      the mode specific callbacks.
      
      The legacy ->set_mode() callback and the newly introduced mode-specific
      callbacks are mutually exclusive. Only one of them should be supported by the
      driver.
      
      Sanity check is done at the time of registration to distinguish between optional
      and required callbacks and to make error recovery and handling simpler. If the
      legacy ->set_mode() callback is provided, all mode specific ones would be
      ignored by the core but a warning is thrown if they are present.
      
      Call sites calling ->set_mode() directly are also updated to use
      __clockevents_set_mode() instead, as ->set_mode() may not be available anymore
      for few drivers.
      
       [1] https://lkml.org/lkml/2014/12/9/605
       [2] https://lkml.org/lkml/2015/1/23/255
      
      Suggested-by: Thomas Gleixner <tglx@linutronix.de> [2]
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
      Cc: linaro-kernel@lists.linaro.org
      Cc: linaro-networking@linaro.org
      Link: http://lkml.kernel.org/r/792d59a40423f0acffc9bb0bec9de1341a06fa02.1423788565.git.viresh.kumar@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      bd624d75
  6. 09 2月, 2014 1 次提交
  7. 07 2月, 2014 3 次提交
    • T
      time: Fixup fallout from recent clockevent/tick changes · f1689bb7
      Thomas Gleixner 提交于
      Make the stub function static inline instead of static and move the
      clockevents related function into the proper ifdeffed section.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
      Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
      f1689bb7
    • P
      tick: Introduce hrtimer based broadcast · 5d1638ac
      Preeti U Murthy 提交于
      On some architectures, in certain CPU deep idle states the local timers stop.
      An external clock device is used to wakeup these CPUs. The kernel support for the
      wakeup of these CPUs is provided by the tick broadcast framework by using the
      external clock device as the wakeup source.
      
      However not all implementations of architectures provide such an external
      clock device. This patch includes support in the broadcast framework to handle
      the wakeup of the CPUs in deep idle states on such systems by queuing a hrtimer
      on one of the CPUs, which is meant to handle the wakeup of CPUs in deep idle states.
      
      This patchset introduces a pseudo clock device which can be registered by the
      archs as tick_broadcast_device in the absence of a real external clock
      device. Once registered, the broadcast framework will work as is for these
      architectures as long as the archs take care of the BROADCAST_ENTER
      notification failing for one of the CPUs. This CPU is made the stand by CPU to
      handle wakeup of the CPUs in deep idle and it *must not enter deep idle states*.
      
      The CPU with the earliest wakeup is chosen to be this CPU. Hence this way the
      stand by CPU dynamically moves around and so does the hrtimer which is queued
      to trigger at the next earliest wakeup time. This is consistent with the case where
      an external clock device is present. The smp affinity of this clock device is
      set to the CPU with the earliest wakeup. This patchset handles the hotplug of
      the stand by CPU as well by moving the hrtimer on to the CPU handling the CPU_DEAD
      notification.
      
      Originally-from: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Cc: deepthi@linux.vnet.ibm.com
      Cc: paulmck@linux.vnet.ibm.com
      Cc: fweisbec@gmail.com
      Cc: paulus@samba.org
      Cc: srivatsa.bhat@linux.vnet.ibm.com
      Cc: svaidy@linux.vnet.ibm.com
      Cc: peterz@infradead.org
      Cc: benh@kernel.crashing.org
      Cc: rafael.j.wysocki@intel.com
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/20140207080632.17187.80532.stgit@preeti.in.ibm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      5d1638ac
    • P
      time: Change the return type of clockevents_notify() to integer · da7e6f45
      Preeti U Murthy 提交于
      The broadcast framework can potentially be made use of by archs which do not have an
      external clock device as well. Then, it is required that one of the CPUs need
      to handle the broadcasting of wakeup IPIs to the CPUs in deep idle. As a
      result its local timers should remain functional all the time. For such
      a CPU, the BROADCAST_ENTER notification has to fail indicating that its clock
      device cannot be shutdown. To make way for this support, change the return
      type of tick_broadcast_oneshot_control() and hence clockevents_notify() to
      indicate such scenarios.
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Cc: deepthi@linux.vnet.ibm.com
      Cc: paulmck@linux.vnet.ibm.com
      Cc: fweisbec@gmail.com
      Cc: paulus@samba.org
      Cc: srivatsa.bhat@linux.vnet.ibm.com
      Cc: svaidy@linux.vnet.ibm.com
      Cc: peterz@infradead.org
      Cc: benh@kernel.crashing.org
      Cc: rafael.j.wysocki@intel.com
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/20140207080606.17187.78306.stgit@preeti.in.ibm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      da7e6f45
  8. 02 10月, 2013 1 次提交
  9. 16 5月, 2013 3 次提交
  10. 01 4月, 2013 1 次提交
    • D
      timer: move enum definition out of ifdef section · 4dbad816
      Daniel Lezcano 提交于
      The next patch will setup automatically the broadcast timer for
      the different cpuidle driver when one idle state stops its timer.
      This will be part of the generic code.
      
      But some ARM boards, like s3c64xx, uses cpuidle but without the
      CONFIG_GENERIC_CLOCKEVENTS_BUILD set. Hence the cpuidle framework
      will be compiled with the code supposed to be generic, that is
      with clockevents_notify and the different enum.
      
      Also the function clockevents_notify is a noop macro, this is fine
      except the usual code is:
      
      	int cpu = smp_processor_id();
      	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
      
      and that raises a warning for the variable cpu which is not used.
      
      Move the clock_event_nofitiers enum definition out of the
      CONFIG_GENERIC_CLOCKEVENTS_BUILD section to prevent a compilation
      error when these are used in the code.
      
      Change the clockevents_notify macro to a static inline noop function
      to prevent a compilation warning.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4dbad816
  11. 22 3月, 2013 1 次提交
  12. 13 3月, 2013 1 次提交
    • T
      tick: Provide a check for a forced broadcast pending · eaa907c5
      Thomas Gleixner 提交于
      On the CPU which gets woken along with the target CPU of the broadcast
      the following happens:
      
        deep_idle()
      			<-- spurious wakeup
        broadcast_exit()
          set forced bit
        
        enable interrupts
          
      			<-- Nothing happens
      
        disable interrupts
      
        broadcast_enter()
      			<-- Here we observe the forced bit is set
        deep_idle()
      
      Now after that the target CPU of the broadcast runs the broadcast
      handler and finds the other CPU in both the broadcast and the forced
      mask, sends the IPI and stuff gets back to normal.
      
      So it's not actually harmful, just more evidence for the theory, that
      hardware designers have access to very special drug supplies.
      
      Now there is no point in going back to deep idle just to wake up again
      right away via an IPI. Provide a check which allows the idle code to
      avoid the deep idle transition.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: LAK <linux-arm-kernel@lists.infradead.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Arjan van de Veen <arjan@infradead.org>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Jason Liu <liu.h.jason@gmail.com>
      Link: http://lkml.kernel.org/r/20130306111537.565418308@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      eaa907c5
  13. 07 3月, 2013 1 次提交
    • D
      tick: Dynamically set broadcast irq affinity · d2348fb6
      Daniel Lezcano 提交于
      When a cpu goes to a deep idle state where its local timer is
      shutdown, it notifies the time frame work to use the broadcast timer
      instead.  Unfortunately, the broadcast device could wake up any CPU,
      including an idle one which is not concerned by the wake up at all. So
      in the worst case an idle CPU will wake up to send an IPI to the CPU
      whose timer expired.
      
      Provide an opt-in feature CLOCK_EVT_FEAT_DYNIRQ which tells the core
      that is should set the interrupt affinity of the broadcast interrupt
      to the cpu which has the earliest expiry time. This avoids unnecessary
      spurious wakeups and IPIs.
      
      [ tglx: Adopted to cpumask rework, silenced an uninitialized warning,
        massaged changelog ]
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Cc: viresh.kumar@linaro.org
      Cc: jacob.jun.pan@linux.intel.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: santosh.shilimkar@ti.com
      Cc: linaro-kernel@lists.linaro.org
      Cc: patches@linaro.org
      Cc: rickard.andersson@stericsson.com
      Cc: vincent.guittot@linaro.org
      Cc: linus.walleij@stericsson.com
      Cc: john.stultz@linaro.org
      Link: http://lkml.kernel.org/r/1362219013-18173-3-git-send-email-daniel.lezcano@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      d2348fb6
  14. 01 2月, 2013 2 次提交
  15. 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
  16. 25 5月, 2012 1 次提交
  17. 08 9月, 2011 2 次提交
  18. 19 5月, 2011 3 次提交
  19. 13 3月, 2010 1 次提交
  20. 14 11月, 2009 3 次提交
    • 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
    • T
      clocksource: Provide a generic mult/shift factor calculation · 7d2f944a
      Thomas Gleixner 提交于
      MIPS has two functions to calculcate the mult/shift factors for clock
      sources and clock events at run time. ARM needs such functions as
      well.
      
      Implement a function which calculates the mult/shift factors based on
      the frequencies to which and from which is converted. The function
      also has a parameter to specify the minimum conversion range in
      seconds. This range is guaranteed not to produce a 64bit overflow when
      a value is multiplied with the calculated mult factor. The larger the
      conversion range the less becomes the conversion accuracy.
      
      Provide two inline wrappers which handle clock events and clock
      sources. For clock events the "from" frequency is nano seconds per
      second which corresponds to 1GHz and "to" is the device frequency. For
      clock sources "from" is the device frequency and "to" is nano seconds
      per second.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMikael Pettersson <mikpe@it.uu.se>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      LKML-Reference: <20091111134229.766673305@linutronix.de>
      7d2f944a
    • T
      clockevents: Use u32 for mult and shift factors · 23af368e
      Thomas Gleixner 提交于
      The mult and shift factors of clock events differ in their data type
      from those of clock sources for no reason. u32 is sufficient for
      both. shift is always <= 32 and mult is limited to 2^32-1 to avoid
      64bit multiplication overflows in the conversion.
      
      Preparatory patch for a generic mult/shift factor calculation
      function.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMikael Pettersson <mikpe@it.uu.se>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      LKML-Reference: <20091111134229.725664788@linutronix.de>
      23af368e
  21. 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
  22. 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
  23. 31 1月, 2009 1 次提交
    • S
      hrtimers: allow the hot-unplugging of all cpus · 94df7de0
      Sebastien Dugue 提交于
      Impact: fix CPU hotplug hang on Power6 testbox
      
      On architectures that support offlining all cpus (at least powerpc/pseries),
      hot-unpluging the tick_do_timer_cpu can result in a system hang.
      
      This comes from the fact that if the cpu going down happens to be the
      cpu doing the tick, then as the tick_do_timer_cpu handover happens after the
      cpu is dead (via the CPU_DEAD notification), we're left without ticks,
      jiffies are frozen and any task relying on timers (msleep, ...) is stuck.
      That's particularly the case for the cpu looping in __cpu_die() waiting
      for the dying cpu to be dead.
      
      This patch addresses this by having the tick_do_timer_cpu handover happen
      earlier during the CPU_DYING notification. For this, a new clockevent
      notification type is introduced (CLOCK_EVT_NOTIFY_CPU_DYING) which is triggered
      in hrtimer_cpu_notify().
      Signed-off-by: NSebastien Dugue <sebastien.dugue@bull.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      94df7de0
  24. 30 12月, 2008 1 次提交
    • S
      hrtimers: allow the hot-unplugging of all cpus · 5762ba18
      Sebastien Dugue 提交于
      Impact: fix CPU hotplug hang on Power6 testbox
      
      On architectures that support offlining all cpus (at least powerpc/pseries),
      hot-unpluging the tick_do_timer_cpu can result in a system hang.
      
      This comes from the fact that if the cpu going down happens to be the
      cpu doing the tick, then as the tick_do_timer_cpu handover happens after the
      cpu is dead (via the CPU_DEAD notification), we're left without ticks,
      jiffies are frozen and any task relying on timers (msleep, ...) is stuck.
      That's particularly the case for the cpu looping in __cpu_die() waiting
      for the dying cpu to be dead.
      
      This patch addresses this by having the tick_do_timer_cpu handover happen
      earlier during the CPU_DYING notification. For this, a new clockevent
      notification type is introduced (CLOCK_EVT_NOTIFY_CPU_DYING) which is triggered
      in hrtimer_cpu_notify().
      Signed-off-by: NSebastien Dugue <sebastien.dugue@bull.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5762ba18
  25. 13 12月, 2008 1 次提交
  26. 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