1. 15 Dec, 2015 1 commit
    • Daniel Lezcano's avatar
      time: Define dummy functions for the generic sched clock · 364eba4b
      Daniel Lezcano authored
      When we try to compile a clocksource driver with the COMPILE_TEST option,
      we can't select the GENERIC_SCHED_CLOCK because the sched_clock() symbol
      will be duplicated with the one defined for the x86.
      In order to fix that, we don't select the GENERIC_SCHED_CLOCK in the
      driver Kconfig's file but we define some empty functions for the different
      symbols in order to prevent the unresolved ones.
      This patch fixes the COMPILE_TEST option for the compile test coverage for
      the clocksource drivers. Without this patch, we can't add the COMPILE_TEST
      option for the clocksource drivers using the GENERIC_SCHED_CLOCK.
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
  2. 22 Apr, 2014 1 commit
  3. 09 Oct, 2013 1 commit
  4. 30 Jul, 2013 1 commit
    • Stephen Boyd's avatar
      sched_clock: Add support for >32 bit sched_clock · e7e3ff1b
      Stephen Boyd authored
      The ARM architected system counter has at least 56 usable bits.
      Add support for counters with more than 32 bits to the generic
      sched_clock implementation so we can increase the time between
      wakeups due to dealing with wrap-around on these devices while
      benefiting from the irqtime accounting and suspend/resume
      handling that the generic sched_clock code already has. On my
      system using 56 bits over 32 bits changes the wraparound time
      from a few minutes to an hour. For faster running counters (GHz
      range) this is even more important because we may not be able to
      execute the timer in time to deal with the wraparound if only 32
      bits are used.
      We choose a maxsec value of 3600 seconds because we assume no
      system will go idle for more than an hour. In the future we may
      need to increase this value.
      Note: All users should switch over to the 64-bit read function so
      we can remove setup_sched_clock() in favor of sched_clock_register().
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
  5. 12 Jun, 2013 1 commit
  6. 10 Apr, 2013 1 commit
  7. 29 Oct, 2012 1 commit
    • Felipe Balbi 2's avatar
      ARM: 7565/1: sched: stop sched_clock() during suspend · 6a4dae5e
      Felipe Balbi 2 authored
      The scheduler imposes a requirement to sched_clock()
      which is to stop the clock during suspend, if we don't
      do that any RT thread will be rescheduled in the future
      which might cause any sort of problems.
      This became an issue on OMAP when we converted omap-i2c.c
      to use threaded IRQs, it turned out that depending on how
      much time we spent on suspend, the I2C IRQ thread would
      end up being rescheduled so far in the future that I2C
      transfers would timeout and, because omap_hsmmc depends
      on an I2C-connected device to detect if an MMC card is
      inserted in the slot, our rootfs would just vanish.
      arch/arm/kernel/sched_clock.c already had an optional
      implementation (sched_clock_needs_suspend()) which would
      handle scheduler's requirement properly, what this patch
      does is simply to make that implementation non-optional.
      Note that this has the side-effect that printk timings
      won't reflect the actual time spent on suspend so other
      methods to measure that will have to be used.
      This has been tested with beagleboard XM (OMAP3630) and
      pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
      after this patch.
      Thanks to Kevin Hilman for helping out with debugging.
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  8. 11 Aug, 2012 1 commit
    • Colin Cross's avatar
      ARM: 7486/1: sched_clock: update epoch_cyc on resume · 237ec6f2
      Colin Cross authored
      Many clocks that are used to provide sched_clock will reset during
      suspend.  If read_sched_clock returns 0 after suspend, sched_clock will
      appear to jump forward.  This patch resets cd.epoch_cyc to the current
      value of read_sched_clock during resume, which causes sched_clock() just
      after suspend to return the same value as sched_clock() just before
      In addition, during the window where epoch_ns has been updated before
      suspend, but epoch_cyc has not been updated after suspend, it is unknown
      whether the clock has reset or not, and sched_clock() could return a
      bogus value.  Add a suspended flag, and return the pre-suspend epoch_ns
      value during this period.
      The new behavior is triggered by calling setup_sched_clock_needs_suspend
      instead of setup_sched_clock.
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  9. 18 Dec, 2011 1 commit
  10. 11 Jan, 2011 1 commit
    • Russell King's avatar
      ARM: sched_clock: allow init_sched_clock() to be called early · 211baa70
      Russell King authored
      sched_clock is supposed to be initialized early - in the recently added
      init_early platform hook.  However, in doing so we end up calling
      mod_timer() before the timer lists are initialized, resulting in an
      Split the initialization in two - the part which the platform calls
      early which starts things off.  The addition of the timer can be
      delayed until after we have more of the kernel initialized - when the
      normal time sources are initialized.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  11. 22 Dec, 2010 1 commit