linux-stable.git/drivers/clocksource/arm_arch_timer.c, branch v3.16.78 Linux kernel stable tree clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64 2015-02-04T10:58:31+00:00 Catalin Marinas catalin.marinas@arm.com 2014-12-10T11:02:09+00:00 552b7a455c1c1a9a5b73bf195a51edccd3a53c86 commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream. Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical timers when requested) introduces the use of physical counters in the ARM architected timer driver. However, he arm64 kernel uses CNTVCT in VDSO. When booting in EL2, the kernel switches to the physical timers to make things easier for KVM but it continues to use the virtual counter both in user and kernel. While in such scenario CNTVCT == CNTPCT (since CNTVOFF is initialised by the kernel to 0), we want to spot firmware bugs corrupting CNTVOFF early (which would affect CNTVCT). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com> 
commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream.

Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical
timers when requested) introduces the use of physical counters in the
ARM architected timer driver. However, he arm64 kernel uses CNTVCT in
VDSO. When booting in EL2, the kernel switches to the physical timers to
make things easier for KVM but it continues to use the virtual counter
both in user and kernel. While in such scenario CNTVCT == CNTPCT (since
CNTVOFF is initialised by the kernel to 0), we want to spot firmware
bugs corrupting CNTVOFF early (which would affect CNTVCT).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
clocksource: arch_timer: Fix code to use physical timers when requested 2015-01-15T10:43:32+00:00 Sonny Rao sonnyrao@chromium.org 2014-11-24T07:02:44+00:00 fdd1710f81c181b8970e3a3e2dc865584706d89a commit 0b46b8a718c6e90910a1b1b0fe797be3c167e186 upstream. This is a bug fix for using physical arch timers when the arch_timer_use_virtual boolean is false. It restores the arch_counter_get_cntpct() function after removal in 0d651e4e "clocksource: arch_timer: use virtual counters" We need this on certain ARMv7 systems which are architected like this: * The firmware doesn't know and doesn't care about hypervisor mode and we don't want to add the complexity of hypervisor there. * The firmware isn't involved in SMP bringup or resume. * The ARCH timer come up with an uninitialized offset between the virtual and physical counters. Each core gets a different random offset. * The device boots in "Secure SVC" mode. * Nothing has touched the reset value of CNTHCTL.PL1PCEN or CNTHCTL.PL1PCTEN (both default to 1 at reset) One example of such as system is RK3288 where it is much simpler to use the physical counter since there's nobody managing the offset and each time a core goes down and comes back up it will get reinitialized to some other random value. Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters") Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> [ luis: backported to 3.16: adjusted context ] Signed-off-by: Luis Henriques <luis.henriques@canonical.com> 
commit 0b46b8a718c6e90910a1b1b0fe797be3c167e186 upstream.

This is a bug fix for using physical arch timers when
the arch_timer_use_virtual boolean is false.  It restores the
arch_counter_get_cntpct() function after removal in

0d651e4e "clocksource: arch_timer: use virtual counters"

We need this on certain ARMv7 systems which are architected like this:

* The firmware doesn't know and doesn't care about hypervisor mode and
  we don't want to add the complexity of hypervisor there.

* The firmware isn't involved in SMP bringup or resume.

* The ARCH timer come up with an uninitialized offset between the
  virtual and physical counters.  Each core gets a different random
  offset.

* The device boots in "Secure SVC" mode.

* Nothing has touched the reset value of CNTHCTL.PL1PCEN or
  CNTHCTL.PL1PCTEN (both default to 1 at reset)

One example of such as system is RK3288 where it is much simpler to
use the physical counter since there's nobody managing the offset and
each time a core goes down and comes back up it will get reinitialized
to some other random value.

Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
clocksource: arm_arch_timer: Change clocksource name if CP15 unavailable 2015-01-15T10:43:31+00:00 Nathan Lynch nathan_lynch@mentor.com 2014-09-28T23:50:06+00:00 489f04a3b25ea8477c4f3b0d90c7ac706f2e2299 commit 423bd69e69f565167ba14e2fe61df76c3c4a0d26 upstream. The arm and arm64 VDSOs need CP15 access to the architected counter. If this is unavailable (which is allowed by ARM v7), indicate this by changing the clocksource name to "arch_mem_counter" before registering the clocksource. Suggested by Stephen Boyd. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com> 
commit 423bd69e69f565167ba14e2fe61df76c3c4a0d26 upstream.

The arm and arm64 VDSOs need CP15 access to the architected counter.
If this is unavailable (which is allowed by ARM v7), indicate this by
changing the clocksource name to "arch_mem_counter" before registering
the clocksource.

Suggested by Stephen Boyd.

Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue 2014-04-29T13:06:36+00:00 Lorenzo Pieralisi lorenzo.pieralisi@arm.com 2014-04-08T09:04:32+00:00 82a5619410d4c4df65c04272db198eca5a867c18 ARM arch timers are tightly coupled with the CPU logic and lose context on platform implementing HW power management when cores are powered down at run-time. Marking the arch timers as C3STOP regardless of power management capabilities causes issues on platforms with no power management, since in that case the arch timers cannot possibly enter states where the timer loses context at runtime and therefore can always be used as a high resolution clockevent device. In order to fix the C3STOP issue in a way compliant with how real HW works, this patch adds a boolean property to the arch timer bindings to define if the arch timer is managed by an always-on power domain. This power domain is present on all ARM platforms to date, and manages HW that must not be turned off, whatever the state of other HW components (eg power controller). On platforms with no power management capabilities, it is the only power domain present, which encompasses and manages power supply for all HW components in the system. If the timer is powered by the always-on power domain, the always-on property must be present in the bindings which means that the timer cannot be shutdown at runtime, so it is not a C3STOP clockevent device. If the timer binding does not contain the always-on property, the timer is assumed to be power-gateable, hence it must be defined as a C3STOP clockevent device. Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Magnus Damm <damm@opensource.se> Cc: Marc Carino <marc.ceeeee@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> 
ARM arch timers are tightly coupled with the CPU logic and lose context
on platform implementing HW power management when cores are powered
down at run-time. Marking the arch timers as C3STOP regardless of power
management capabilities causes issues on platforms with no power management,
since in that case the arch timers cannot possibly enter states where the
timer loses context at runtime and therefore can always be used as a high
resolution clockevent device.

In order to fix the C3STOP issue in a way compliant with how real HW
works, this patch adds a boolean property to the arch timer bindings
to define if the arch timer is managed by an always-on power domain.

This power domain is present on all ARM platforms to date, and manages
HW that must not be turned off, whatever the state of other HW
components (eg power controller). On platforms with no power management
capabilities, it is the only power domain present, which encompasses
and manages power supply for all HW components in the system.

If the timer is powered by the always-on power domain, the always-on
property must be present in the bindings which means that the timer cannot
be shutdown at runtime, so it is not a C3STOP clockevent device.
If the timer binding does not contain the always-on property, the timer is
assumed to be power-gateable, hence it must be defined as a C3STOP
clockevent device.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Marc Carino <marc.ceeeee@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
clocksource: arch_timer: Set dynamic irq affinity on mmio clockevent 2014-03-11T22:04:39+00:00 Stephen Boyd sboyd@codeaurora.org 2014-01-06T22:56:17+00:00 7b52ad2efa4926ca7f399e5e63cf9a587396cd87 Set the CLOCK_EVT_FEAT_DYNIRQ flag on the memory mapped clockevent so that we save power by waking up the CPU with the next event when this timer is used in broadcast mode. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> 
Set the CLOCK_EVT_FEAT_DYNIRQ flag on the memory mapped
clockevent so that we save power by waking up the CPU with the
next event when this timer is used in broadcast mode.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
clocksource: arch_timer: Do not register arch_sys_counter twice 2013-10-16T06:30:03+00:00 Thierry Reding thierry.reding@gmail.com 2013-10-15T13:31:51+00:00 4a7d3e8a9939cf8073c247286d81cbe0ae48eba2 Commit: 65cd4f6 ("arch_timer: Move to generic sched_clock framework") added code to register the arch_sys_counter in arch_timer_register(), but it is already registered in arch_counter_register(). This results in the timer being added to the clocksource list twice, therefore causing an infinite loop in the list. Remove the duplicate registration and register the scheduler clock after the original registration instead. This fixes a hang during boot on Tegra114 (Cortex-A15). [ While I've only tested this on Tegra114, I suspect the same hang during boot happens for all processors that use this clock source. ] Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: John Stultz <john.stultz@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: linux-arm-kernel@lists.infradead.org Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/1381843911-31962-1-git-send-email-treding@nvidia.com Signed-off-by: Ingo Molnar <mingo@kernel.org> 
Commit:

   65cd4f6 ("arch_timer: Move to generic sched_clock framework")

added code to register the arch_sys_counter in arch_timer_register(),
but it is already registered in arch_counter_register().

This results in the timer being added to the clocksource list twice,
therefore causing an infinite loop in the list.

Remove the duplicate registration and register the scheduler
clock after the original registration instead.

This fixes a hang during boot on Tegra114 (Cortex-A15).

[ While I've only tested this on Tegra114, I suspect the same hang
  during boot happens for all processors that use this clock source. ]

Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: http://lkml.kernel.org/r/1381843911-31962-1-git-send-email-treding@nvidia.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge branch 'fortglx/3.13/time' of git://git.linaro.org/people/jstultz/linux into timers/core 2013-10-10T04:25:23+00:00 Ingo Molnar mingo@kernel.org 2013-10-10T04:25:23+00:00 8a749de5e32d2b72def93f7bd7a2745580d75872 Pull more timekeeping items for v3.13 from John Stultz: * Small cleanup in the clocksource code. * Fix for rtc-pl031 to let it work with alarmtimers. * Move arm64 to using the generic sched_clock framework & resulting cleanup in the generic sched_clock code. Signed-off-by: Ingo Molnar <mingo@kernel.org> 
Pull more timekeeping items for v3.13 from John Stultz:

  * Small cleanup in the clocksource code.

  * Fix for rtc-pl031 to let it work with alarmtimers.

  * Move arm64 to using the generic sched_clock framework & resulting
    cleanup in the generic sched_clock code.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
arch_timer: Move to generic sched_clock framework 2013-10-09T23:54:10+00:00 Stephen Boyd sboyd@codeaurora.org 2013-07-18T23:21:18+00:00 65cd4f6c99c1170bd0114dbd71b978012ea44d28 Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports. Cc: Christopher Covington <cov@codeaurora.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: John Stultz <john.stultz@linaro.org> 
Register with the generic sched_clock framework now that it
supports 64 bits. This fixes two problems with the current
sched_clock support for machines using the architected timers.
First off, we don't subtract the start value from subsequent
sched_clock calls so we can potentially start off with
sched_clock returning gigantic numbers. Second, there is no
support for suspend/resume handling so problems such as discussed
in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during
suspend, 2012-10-23) can happen without this patch. Finally, it
allows us to move the sched_clock setup into drivers clocksource
out of the arch ports.

Cc: Christopher Covington <cov@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Merge branch 'timer_evtstrm' of git://linux-arm.org/linux-skn into clockevents/3.13 2013-10-03T14:13:51+00:00 Daniel Lezcano daniel.lezcano@linaro.org 2013-10-03T14:13:51+00:00 191124efb4d6e5e47fe073b4b97350873523e88c Adds support to configure the rate and enable the event stream for architected timer. The event streams can be used to impose a timeout on a wfe, to safeguard against any programming error in case an expected event is not generated or even to implement wfe-based timeouts for userspace locking implementations. This feature can be disabled(enabled by default). Since the timer control register is reset to zero on warm boot, CPU PM notifier is added to save and restore the value. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> 
Adds support to configure the rate and enable the event stream for architected
timer. The event streams can be used to impose a timeout on a wfe, to safeguard
against any programming error in case an expected event is not generated or
even to implement wfe-based timeouts for userspace locking implementations.
This feature can be disabled(enabled by default).

Since the timer control register is reset to zero on warm boot, CPU PM notifier
is added to save and restore the value.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
clocksource: arm_arch_timer: Use clocksource for suspend timekeeping 2013-10-02T09:43:17+00:00 Stephen Boyd sboyd@codeaurora.org 2013-09-27T20:13:12+00:00 4fbcdc813fb9c0324fcff4c75414e717569d965e The ARM architected timers keep counting during suspend so we can mark this clocksource with the CLOCK_SOURCE_SUSPEND_NONSTOP flag. This flag will indicate that this clocksource can be used for calculating suspend time and injecting sleep time into the timekeeping core. This should be more accurate than using an external RTC or architecture specific persistent clock. Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> 
The ARM architected timers keep counting during suspend so we can
mark this clocksource with the CLOCK_SOURCE_SUSPEND_NONSTOP flag.
This flag will indicate that this clocksource can be used for
calculating suspend time and injecting sleep time into the
timekeeping core. This should be more accurate than using an
external RTC or architecture specific persistent clock.

Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>