Re: port-sgimips/53520 (delay(9) is ineffective in early initialization phase sgimips kernel.)

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

The following reply was made to PR port-sgimips/53520; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-sgimips/53520 (delay(9) is ineffective in early initialization
	 phase sgimips kernel.)
Date: Sat, 8 Sep 2018 01:28:13 +0900

 > The basic analysis (temporary initialization of ci_divisor_delay for
 > early use of delay(9)) is reasonable. However it looks something wrong
 > around delay() implementation of sgimips. I will also investigate it.
 
 Quoted from port-sgimips@:
  http://mail-index.netbsd.org/port-sgimips/2018/09/02/msg000775.html
 
 > Notes for PR/53520:
 >  NetBSD/sgimips uses the ci_divisor_delay value for the 4.4BSD derived
 >  dumb delay loop. However ci_devisor_delay is designed for mips3_delay()
 >  in sys/arch/mips/mips/mips3_clock.c that uses MIPS3's internal CPU counter,
 >  i.e. "a number of CPU clock count per microsecond."
 >  (note ci_cycles_per_hz is also for common mips3_clockintr() in
 >   sys/arch/mips/mips/mips3_clockintr.c)
 > 
 >  For sgimips delay implementation (traditional 4.4BSD derived delay loop),
 >  the "cpuspeed" value (that represents "instructions per microsecond")
 >  should be used instead, as pmax and newsmips do.
 > 
 >  Anyway the cpuspeed value is not so precise as noted in
 >  sys/arch/mips/mips/mips_mcclock.c
 >   https://nxr.netbsd.org/xref/src/sys/arch/mips/mips/mips_mcclock.c?r=1.19#198
 >  so current ci_divisor_delay value is still acceptable, I think.
 
 The 'cpuspeed' values in mips_mcclock.c are similar with
 "(frequency [MHz]) / 2" for ci_divisor_delay so it seems
 acceptable for now to (ab)use it for traditional sgimips delay.
 
 I'll commit the fix in the PR soon. (with some proper comment)
 
 ---
 Izumi Tsutsui