From: Ralf Baechle Date: Thu, 12 Sep 2013 11:47:32 +0000 (+0200) Subject: MIPS: Reimplement get_cycles(). X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=9c9b415c50bc298ac61412dff856eae2f54889ee;p=GitHub%2Fexynos8895%2Fandroid_kernel_samsung_universal8895.git MIPS: Reimplement get_cycles(). This essentially reverts commit efb9ca08b5a2374b29938cdcab417ce4feb14b54 (kernel.org) / 58020a106879a8b372068741c81f0015c9b0b96dbv [[MIPS] Change get_cycles to always return 0.] Most users of get_cycles() invoke it as a timing interface. That's why in modern kernels it was never very much missed for. /dev/random however uses get_cycles() in the how the jitter in the interrupt timing contains some useful entropy. Signed-off-by: Ralf Baechle --- diff --git a/arch/mips/include/asm/timex.h b/arch/mips/include/asm/timex.h index 6529704aa73a..c5424757da65 100644 --- a/arch/mips/include/asm/timex.h +++ b/arch/mips/include/asm/timex.h @@ -10,7 +10,9 @@ #ifdef __KERNEL__ +#include #include +#include /* * This is the clock rate of the i8253 PIT. A MIPS system may not have @@ -33,9 +35,38 @@ typedef unsigned int cycles_t; +/* + * On R4000/R4400 before version 5.0 an erratum exists such that if the + * cycle counter is read in the exact moment that it is matching the + * compare register, no interrupt will be generated. + * + * There is a suggested workaround and also the erratum can't strike if + * the compare interrupt isn't being used as the clock source device. + * However for now the implementaton of this function doesn't get these + * fine details right. + */ static inline cycles_t get_cycles(void) { - return 0; + switch (boot_cpu_type()) { + case CPU_R4400PC: + case CPU_R4400SC: + case CPU_R4400MC: + if ((read_c0_prid() & 0xff) >= 0x0050) + return read_c0_count(); + break; + + case CPU_R4000PC: + case CPU_R4000SC: + case CPU_R4000MC: + break; + + default: + if (cpu_has_counter) + return read_c0_count(); + break; + } + + return 0; /* no usable counter */ } #endif /* __KERNEL__ */