On secondary CPUs, the Timer Control Register is not reset
to a sane value before the timer is registered, and the TRM
doesn't seem to indicate any reset value either. In some cases,
the kernel will take an interrupt too early, depending on what
junk was present in the registers at reset time.
The fix is to set the Timer Control Register to 0 before
registering the clock_event_device and enabling the interrupt.
Problem seen on VE (Cortex A5) and Tegra.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The smp_twd clockevents driver currently enables the local timer PPI
before the clockevents device is registered. This can lead to a kernel
panic if a spurious timer interrupt is generated before registration
has completed since the kernel will treat it as an IPI timer.
This patch moves the clockevents device registration before the IRQ
unmasking so that we can always handle timer interrupts once they can
occur.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
clockevents_reconfigure was an older api that doesn't handle
updating the max time between ticks when the frequency changes.
Under some conditions, the boot value of max_delta_ns scaled
by the mult/shift values for the current frequency can result
in a value of 0x200000004 selected as the number of cycles to
program for a long tick, which gets wrapped to 0x4.
Also switch to the matching clockevents_config_and_register
function to register the clockevent, which handles converting
the min/max ticks to ns during init.
Change-Id: I6ca659c309e7bb031cdb1954767b5aa7a022ff44
Signed-off-by: Colin Cross <ccross@android.com>
The localtimer's clock changes with the cpu clock. After a
cpufreq transition, update the clockevent's frequency and
reprogram the next clock event.
Adds a clock called "smp_twd" that is used to determine the
twd frequency, which can also be used at init time to
avoid calibrating the twd frequency.
Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robherring2@gmail.com>
If ASID rollover is detected on a CPU in an SMP system, a synchronous
IPI call is made to force the secondaries to reallocate their current
ASIDs.
There is a problem where a CPU may be interrupted in the cpu_switch_mm
code with the context ID held in r1. After servicing the IPI, the
context ID register will be updated with an ASID from the previous
generation, polluting the TLB for when that ASID becomes valid in the
new generation.
This patch disables interrupts during cpu_switch_mm for SMP systems,
preventing incoming rollover broadcasts from being serviced while the
register state is inconsistent. Additionally, the context resetting code
is modified to call cpu_switch_mm, rather than setting the context ID
register directly, so that the TTBR always agrees with the ASID.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When the cpu is powered down in a low power mode, the vfp
registers may be reset.
This patch uses CPU_PM_ENTER and CPU_PM_EXIT notifiers to save
and restore the cpu's vfp registers.
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Vishwanath BS <vishwanath.bs@ti.com>