Re: [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

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

interesting, where is this documented ? And it's quite funny that so far
everybody messed up revision printing for R4400 CPUs. 

>  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?

all SNI systems have a i8254 in their EISA/PCI chipsets. But they aren't
that nice for clock events as their interupts are connected via an i8259
addresses via ISA PIO. 

>  With the considerations above in mind, please apply.

will do later.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]