1
0
Fork 0
alistair23-linux/arch/mips/mti-malta/malta-time.c

257 lines
5.8 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* Carsten Langgaard, carstenl@mips.com
* Copyright (C) 1999,2000 MIPS Technologies, Inc. All rights reserved.
*
* Setting up the clock on the MIPS boards.
*/
#include <linux/types.h>
#include <linux/i8253.h>
#include <linux/init.h>
#include <linux/kernel_stat.h>
#include <linux/libfdt.h>
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
#include <linux/math64.h>
#include <linux/sched.h>
#include <linux/spinlock.h>
#include <linux/interrupt.h>
#include <linux/timex.h>
#include <linux/mc146818rtc.h>
#include <asm/cpu.h>
#include <asm/mipsregs.h>
#include <asm/mipsmtregs.h>
#include <asm/hardirq.h>
#include <asm/irq.h>
#include <asm/div64.h>
#include <asm/setup.h>
#include <asm/time.h>
#include <asm/mc146818-time.h>
#include <asm/msc01_ic.h>
#include <asm/mips-cps.h>
#include <asm/mips-boards/generic.h>
#include <asm/mips-boards/maltaint.h>
static int mips_cpu_timer_irq;
static int mips_cpu_perf_irq;
extern int cp0_perfcount_irq;
static unsigned int gic_frequency;
static void mips_timer_dispatch(void)
{
do_IRQ(mips_cpu_timer_irq);
}
static void mips_perf_dispatch(void)
{
do_IRQ(mips_cpu_perf_irq);
}
static unsigned int freqround(unsigned int freq, unsigned int amount)
{
freq += amount;
freq -= freq % (amount*2);
return freq;
}
/*
* Estimate CPU and GIC frequencies.
*/
static void __init estimate_frequencies(void)
{
unsigned long flags;
unsigned int count, start;
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
unsigned char secs1, secs2, ctrl;
int secs;
u64 giccount = 0, gicstart = 0;
#if defined(CONFIG_KVM_GUEST) && CONFIG_KVM_GUEST_TIMER_FREQ
mips_hpt_frequency = CONFIG_KVM_GUEST_TIMER_FREQ * 1000000;
return;
#endif
local_irq_save(flags);
if (mips_gic_present())
clear_gic_config(GIC_CONFIG_COUNTSTOP);
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
/*
* Read counters exactly on rising edge of update flag.
* This helps get an accurate reading under virtualisation.
*/
while (CMOS_READ(RTC_REG_A) & RTC_UIP);
while (!(CMOS_READ(RTC_REG_A) & RTC_UIP));
start = read_c0_count();
if (mips_gic_present())
gicstart = read_gic_counter();
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
/* Wait for falling edge before reading RTC. */
while (CMOS_READ(RTC_REG_A) & RTC_UIP);
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
secs1 = CMOS_READ(RTC_SECONDS);
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
/* Read counters again exactly on rising edge of update flag. */
while (!(CMOS_READ(RTC_REG_A) & RTC_UIP));
count = read_c0_count();
if (mips_gic_present())
giccount = read_gic_counter();
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
/* Wait for falling edge before reading RTC again. */
while (CMOS_READ(RTC_REG_A) & RTC_UIP);
secs2 = CMOS_READ(RTC_SECONDS);
ctrl = CMOS_READ(RTC_CONTROL);
local_irq_restore(flags);
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD) {
secs1 = bcd2bin(secs1);
secs2 = bcd2bin(secs2);
}
secs = secs2 - secs1;
if (secs < 1)
secs += 60;
count -= start;
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
count /= secs;
mips_hpt_frequency = count;
if (mips_gic_present()) {
MIPS: malta-time: Take seconds into account When estimating the clock frequency based on the RTC, take seconds into account in case the Update In Progress (UIP) bit wasn't seen. This can happen in virtual machines (which may get pre-empted by the hypervisor at inopportune times) with QEMU emulating the RTC (and in fact not setting the UIP bit for very long), especially on slow hosts such as FPGA systems and hardware emulators. This results in several seconds actually having elapsed before seeing the UIP bit instead of just one second, and exaggerated timer frequencies. While updating the comments, they're also fixed to match the code in that the rising edge of the update flag is detected first, not the falling edge. The rising edge gives a more precise point to read the counters in a virtualised system than the falling edge, resulting in a more accurate frequency. It does however mean that we have to also wait for the falling edge before doing the read of the RTC seconds register, otherwise it seems to be possible in slow hardware emulation to stray into the interval when the RTC time is undefined during the update (at least 244uS after the rising edge of the update flag). This can result in both seconds values reading the same, and it wrapping to 60 seconds, vastly underestimating the frequency. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13174/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-04-22 11:19:15 -06:00
giccount = div_u64(giccount - gicstart, secs);
gic_frequency = giccount;
}
}
void read_persistent_clock64(struct timespec64 *ts)
{
ts->tv_sec = mc146818_get_cmos_time();
ts->tv_nsec = 0;
}
int get_c0_fdc_int(void)
{
/*
* Some cores claim the FDC is routable through the GIC, but it doesn't
* actually seem to be connected for those Malta bitstreams.
*/
switch (current_cpu_type()) {
case CPU_INTERAPTIV:
case CPU_PROAPTIV:
return -1;
};
if (cpu_has_veic)
return -1;
else if (mips_gic_present())
return gic_get_c0_fdc_int();
else if (cp0_fdc_irq >= 0)
return MIPS_CPU_IRQ_BASE + cp0_fdc_irq;
else
return -1;
}
2014-09-18 15:47:12 -06:00
int get_c0_perfcount_int(void)
{
if (cpu_has_veic) {
set_vi_handler(MSC01E_INT_PERFCTR, mips_perf_dispatch);
mips_cpu_perf_irq = MSC01E_INT_BASE + MSC01E_INT_PERFCTR;
} else if (mips_gic_present()) {
irqchip: mips-gic: Support local interrupts The MIPS GIC supports 7 local interrupts, 2 of which are the GIC local watchdog and count/compare timer. The remainder are CPU interrupts which may optionally be re-routed through the GIC. GIC hardware IRQs 0-6 are now used for local interrupts while hardware IRQs 7+ are used for external (shared) interrupts. Note that the 5 CPU interrupts may not be re-routable through the GIC. In that case mapping will fail and the vectors reported in C0_IntCtl should be used instead. gic_get_c0_compare_int() and gic_get_c0_perfcount_int() will return the correct IRQ number to use for the C0 timer and perfcounter interrupts based on the routability of those interrupts through the GIC. A separate irq_chip, with callbacks that mask/unmask the local interrupt on all CPUs, is used for the C0 timer and performance counter interrupts since all other platforms do not use the percpu IRQ API for those interrupts. Malta, SEAD-3, and the GIC clockevent driver have been updated to use local interrupts and the R4K clockevent driver has been updated to poll for C0 timer interrupts through the GIC when the GIC is present. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Reviewed-by: Qais Yousef <qais.yousef@imgtec.com> Tested-by: Qais Yousef <qais.yousef@imgtec.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jeffrey Deans <jeffrey.deans@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Jonas Gorski <jogo@openwrt.org> Cc: John Crispin <blogic@openwrt.org> Cc: David Daney <ddaney.cavm@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7819/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-18 15:47:27 -06:00
mips_cpu_perf_irq = gic_get_c0_perfcount_int();
2014-09-18 15:47:12 -06:00
} else if (cp0_perfcount_irq >= 0) {
mips_cpu_perf_irq = MIPS_CPU_IRQ_BASE + cp0_perfcount_irq;
2014-09-18 15:47:12 -06:00
} else {
mips_cpu_perf_irq = -1;
}
2014-09-18 15:47:12 -06:00
return mips_cpu_perf_irq;
}
EXPORT_SYMBOL_GPL(get_c0_perfcount_int);
MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code commit 3747069b25e419f6b51395f48127e9812abc3596 upstream. The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. Note that some harmless section mismatch warnings may result, since notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c) and are flagged as __cpuinit -- so if we remove the __cpuinit from the arch specific callers, we will also get section mismatch warnings. As an intermediate step, we intend to turn the linux/init.h cpuinit related content into no-ops as early as possible, since that will get rid of these warnings. In any case, they are temporary and harmless. Here, we remove all the MIPS __cpuinit from C code and __CPUINIT from asm files. MIPS is interesting in this respect, because there are also uasm users hiding behind their own renamed versions of the __cpuinit macros. [1] https://lkml.org/lkml/2013/5/20/589 [ralf@linux-mips.org: Folded in Paul's followup fix.] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5494/ Patchwork: https://patchwork.linux-mips.org/patch/5495/ Patchwork: https://patchwork.linux-mips.org/patch/5509/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-06-18 07:38:59 -06:00
unsigned int get_c0_compare_int(void)
{
if (cpu_has_veic) {
set_vi_handler(MSC01E_INT_CPUCTR, mips_timer_dispatch);
mips_cpu_timer_irq = MSC01E_INT_BASE + MSC01E_INT_CPUCTR;
} else if (mips_gic_present()) {
irqchip: mips-gic: Support local interrupts The MIPS GIC supports 7 local interrupts, 2 of which are the GIC local watchdog and count/compare timer. The remainder are CPU interrupts which may optionally be re-routed through the GIC. GIC hardware IRQs 0-6 are now used for local interrupts while hardware IRQs 7+ are used for external (shared) interrupts. Note that the 5 CPU interrupts may not be re-routable through the GIC. In that case mapping will fail and the vectors reported in C0_IntCtl should be used instead. gic_get_c0_compare_int() and gic_get_c0_perfcount_int() will return the correct IRQ number to use for the C0 timer and perfcounter interrupts based on the routability of those interrupts through the GIC. A separate irq_chip, with callbacks that mask/unmask the local interrupt on all CPUs, is used for the C0 timer and performance counter interrupts since all other platforms do not use the percpu IRQ API for those interrupts. Malta, SEAD-3, and the GIC clockevent driver have been updated to use local interrupts and the R4K clockevent driver has been updated to poll for C0 timer interrupts through the GIC when the GIC is present. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Reviewed-by: Qais Yousef <qais.yousef@imgtec.com> Tested-by: Qais Yousef <qais.yousef@imgtec.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jeffrey Deans <jeffrey.deans@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Jonas Gorski <jogo@openwrt.org> Cc: John Crispin <blogic@openwrt.org> Cc: David Daney <ddaney.cavm@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/7819/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-18 15:47:27 -06:00
mips_cpu_timer_irq = gic_get_c0_compare_int();
} else {
mips_cpu_timer_irq = MIPS_CPU_IRQ_BASE + cp0_compare_irq;
}
return mips_cpu_timer_irq;
}
static void __init init_rtc(void)
{
MIPS: Malta: Don't reinitialise RTC On Malta, since commit a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot"), the RTC is reinitialised and forced into binary coded decimal (BCD) mode during init, even if the bootloader has already initialised it, and may even have already put it into binary mode (as YAMON does). This corrupts the current time, can result in the RTC seconds being an invalid BCD (e.g. 0x1a..0x1f) for up to 6 seconds, as well as confusing YAMON for a while after reset, enough for it to report timeouts when attempting to load from TFTP (it actually uses the RTC in that code). Therefore only initialise the RTC to the extent that is necessary so that Linux avoids interfering with the bootloader setup, while also allowing it to estimate the CPU frequency without hanging, without a bootloader necessarily having done anything with the RTC (for example when the kernel is loaded via EJTAG). The divider control is configured for a 32KHZ reference clock if necessary, and the SET bit of the RTC_CONTROL register is cleared if necessary without changing any other bits (this bit will be set when coming out of reset if the battery has been disconnected). Fixes: a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot") Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Paul Burton <paul.burton@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.14+ Patchwork: https://patchwork.linux-mips.org/patch/10739/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-17 08:54:41 -06:00
unsigned char freq, ctrl;
MIPS: Malta: Don't reinitialise RTC On Malta, since commit a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot"), the RTC is reinitialised and forced into binary coded decimal (BCD) mode during init, even if the bootloader has already initialised it, and may even have already put it into binary mode (as YAMON does). This corrupts the current time, can result in the RTC seconds being an invalid BCD (e.g. 0x1a..0x1f) for up to 6 seconds, as well as confusing YAMON for a while after reset, enough for it to report timeouts when attempting to load from TFTP (it actually uses the RTC in that code). Therefore only initialise the RTC to the extent that is necessary so that Linux avoids interfering with the bootloader setup, while also allowing it to estimate the CPU frequency without hanging, without a bootloader necessarily having done anything with the RTC (for example when the kernel is loaded via EJTAG). The divider control is configured for a 32KHZ reference clock if necessary, and the SET bit of the RTC_CONTROL register is cleared if necessary without changing any other bits (this bit will be set when coming out of reset if the battery has been disconnected). Fixes: a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot") Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Paul Burton <paul.burton@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.14+ Patchwork: https://patchwork.linux-mips.org/patch/10739/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-17 08:54:41 -06:00
/* Set 32KHz time base if not already set */
freq = CMOS_READ(RTC_FREQ_SELECT);
if ((freq & RTC_DIV_CTL) != RTC_REF_CLCK_32KHZ)
CMOS_WRITE(RTC_REF_CLCK_32KHZ, RTC_FREQ_SELECT);
MIPS: Malta: Don't reinitialise RTC On Malta, since commit a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot"), the RTC is reinitialised and forced into binary coded decimal (BCD) mode during init, even if the bootloader has already initialised it, and may even have already put it into binary mode (as YAMON does). This corrupts the current time, can result in the RTC seconds being an invalid BCD (e.g. 0x1a..0x1f) for up to 6 seconds, as well as confusing YAMON for a while after reset, enough for it to report timeouts when attempting to load from TFTP (it actually uses the RTC in that code). Therefore only initialise the RTC to the extent that is necessary so that Linux avoids interfering with the bootloader setup, while also allowing it to estimate the CPU frequency without hanging, without a bootloader necessarily having done anything with the RTC (for example when the kernel is loaded via EJTAG). The divider control is configured for a 32KHZ reference clock if necessary, and the SET bit of the RTC_CONTROL register is cleared if necessary without changing any other bits (this bit will be set when coming out of reset if the battery has been disconnected). Fixes: a87ea88d8f6c ("MIPS: Malta: initialise the RTC at boot") Signed-off-by: James Hogan <james.hogan@imgtec.com> Reviewed-by: Paul Burton <paul.burton@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.14+ Patchwork: https://patchwork.linux-mips.org/patch/10739/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-17 08:54:41 -06:00
/* Ensure SET bit is clear so RTC can run */
ctrl = CMOS_READ(RTC_CONTROL);
if (ctrl & RTC_SET)
CMOS_WRITE(ctrl & ~RTC_SET, RTC_CONTROL);
}
#ifdef CONFIG_CLKSRC_MIPS_GIC
static u32 gic_frequency_dt;
static struct property gic_frequency_prop = {
.name = "clock-frequency",
.length = sizeof(u32),
.value = &gic_frequency_dt,
};
static void update_gic_frequency_dt(void)
{
struct device_node *node;
gic_frequency_dt = cpu_to_be32(gic_frequency);
node = of_find_compatible_node(NULL, NULL, "mti,gic-timer");
if (!node) {
pr_err("mti,gic-timer device node not found\n");
return;
}
if (of_update_property(node, &gic_frequency_prop) < 0)
pr_err("error updating gic frequency property\n");
}
#endif
void __init plat_time_init(void)
{
unsigned int prid = read_c0_prid() & (PRID_COMP_MASK | PRID_IMP_MASK);
unsigned int freq;
init_rtc();
estimate_frequencies();
freq = mips_hpt_frequency;
if ((prid != (PRID_COMP_MIPS | PRID_IMP_20KC)) &&
(prid != (PRID_COMP_MIPS | PRID_IMP_25KF)))
freq *= 2;
freq = freqround(freq, 5000);
printk("CPU frequency %d.%02d MHz\n", freq/1000000,
(freq%1000000)*100/1000000);
#ifdef CONFIG_I8253
/* Only Malta has a PIT. */
setup_pit_timer();
#endif
if (mips_gic_present()) {
freq = freqround(gic_frequency, 5000);
printk("GIC frequency %d.%02d MHz\n", freq/1000000,
(freq%1000000)*100/1000000);
#ifdef CONFIG_CLKSRC_MIPS_GIC
update_gic_frequency_dt();
timer_probe();
#endif
}
}