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.