[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-sgimips/53520 (delay(9) is ineffective in early initialization phase sgimips kernel.)
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>
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@:
> 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
> 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
> 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)
Main Index |
Thread Index |