On Sun, Apr 24, 2022 at 12:46:23PM +0100, Maciej W. Rozycki wrote:
> Fix the discrepancy between the two places we check for the CP0 counter
> erratum in along with the incorrect comparison of the R4400 revision
> number against 0x30 which matches none and consistently consider all
> R4000 and R4400 processors affected, as documented in processor errata
> publications[1][2][3], following the mapping between CP0 PRId register
> values and processor models:
>
> PRId | Processor Model
> ---------+--------------------
> 00000422 | R4000 Revision 2.2
> 00000430 | R4000 Revision 3.0
> 00000440 | R4400 Revision 1.0
> 00000450 | R4400 Revision 2.0
> 00000460 | R4400 Revision 3.0
>
> No other revision of either processor has ever been spotted.
>
> Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume
> R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the
> CP0 counter as buggy does not preclude it from being used as either a
> clock event or a clock source device. It just cannot be used as both at
> a time, because in that case clock event interrupts will be occasionally
> lost, and the use as a clock event device takes precedence.
>
> Compare against 0x4ff in `can_use_mips_counter' so that a single machine
> instruction is produced.
>
> References:
>
> [1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS
> Technologies Inc., May 10, 1994, Erratum 53, p.13
>
> [2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies
> Inc., February 9, 1994, Erratum 21, p.4
>
> [3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS
> Technologies Inc., January 24, 1995, Erratum 14, p.3
>
> Signed-off-by: Maciej W. Rozycki <macro@xxxxxxxxxxx>
> Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug")
> Cc: stable@xxxxxxxxxxxxxxx # v2.6.24+
> ---
> Thomas,
>
> Please review the requirements for SNI platforms. In the case of an
> erratic CP0 timer we give precedence to the use as a clock event rather
> than clock source device; see `time_init' in arch/mips/kernel/time.c.
> Therefore if SNI systems have no alternative timer interrupt source, then
> the CP0 timer is supposed to still do regardless of the erratum.
>
> Conversely a system can do without a high-precision clock source, in
> which case jiffies will be used. Of course such a system will suffer if
> used for precision timekeeping, but such is the price for broken hardware.
> Don't SNI systems have any alternative timer available, not even the
> venerable 8254?
>
> Long-term I think this code should be factored out and rewritten so that
> it lives in one place and can take advantage of compile-time constants,
> which will be the case for the majority of platforms. For the time being
> fix the immediate breakage however.
>
> With the considerations above in mind, please apply.
>
> Maciej
> ---
> arch/mips/include/asm/timex.h | 8 ++++----
> arch/mips/kernel/time.c | 11 +++--------
> 2 files changed, 7 insertions(+), 12 deletions(-)
applied to mips-fixes.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
