History log of /openbsd/sys/arch/sparc64/sparc64/clock.c (Results 1 – 25 of 87)
Revision Date Author Comments
# e1f14dc3 08-Apr-2024 miod <miod@openbsd.org>

There is too much #ifdef DEBUG stuff cluttering locore, really. While some of
it had sense in the early days of the sparc64 port, this code has bitrotten
and is getting in the way. Time for a visit t

There is too much #ifdef DEBUG stuff cluttering locore, really. While some of
it had sense in the early days of the sparc64 port, this code has bitrotten
and is getting in the way. Time for a visit to the Attic.

This removes:
- interrupt handling debug code (forcing hz = 1, probably broken since years).
- unused or too invasive DEBUG code which noone will ever use in this state.
- #if 0 code blocks which have been this way since locore.s revision 1.1 and
will never get enabled.

ok kettenis@

show more ...


# 8a1e8cca 29-Mar-2024 miod <miod@openbsd.org>

Drop the first argument of intr_establish().

Instead, require all callers to put the right value in the ih_pil field, and
have intr_establish() trust them rather than assigning this field again from

Drop the first argument of intr_establish().

Instead, require all callers to put the right value in the ih_pil field, and
have intr_establish() trust them rather than assigning this field again from
its first argument.

ok claudio@ kettenis@

show more ...


# f635dc10 29-Mar-2024 miod <miod@openbsd.org>

Remove truly unneeded includes (not included indirectly).

ok claudio@ kettenis@


# bdd1b079 29-Mar-2024 miod <miod@openbsd.org>

send_softint() was designed as being able to target a particular cpu, but the
code for this was never written and all uses target the running cpu anyway,
so stop pretending it may do things it won't

send_softint() was designed as being able to target a particular cpu, but the
code for this was never written and all uses target the running cpu anyway,
so stop pretending it may do things it won't do and drop that cpu argument.

ok claudio@ kettenis@

show more ...


# e78c98cb 29-Mar-2024 miod <miod@openbsd.org>

Remove dead defines, prototypes and data, and duplicate or misleading comments.

ok claudio@ kettenis@


# 0ed1bf01 17-Sep-2023 cheloha <cheloha@openbsd.org>

clockintr: remove clockintr_init(), clockintr_flags

All the state initialization once done in clockintr_init() has been
moved to other parts of the kernel. It's a dead function. Remove it.

Likewi

clockintr: remove clockintr_init(), clockintr_flags

All the state initialization once done in clockintr_init() has been
moved to other parts of the kernel. It's a dead function. Remove it.

Likewise, the clockintr_flags variable no longer sports any meaningful
flags. Remove it. This frees up the CL_* flag namespace, which might
be useful to the clockintr frontend if we ever need to add behavior
flags to any of those functions.

show more ...


# b3ef18bd 14-Sep-2023 cheloha <cheloha@openbsd.org>

clockintr: replace CL_RNDSTAT with global variable statclock_is_randomized

In order to separate the statclock from the clock interrupt subsystem
we need to move all statclock state out into the broa

clockintr: replace CL_RNDSTAT with global variable statclock_is_randomized

In order to separate the statclock from the clock interrupt subsystem
we need to move all statclock state out into the broader kernel.

Start by replacing the CL_RNDSTAT flag with a new global variable,
"statclock_is_randomized", in kern_clock.c. Update all clockintr_init()
callers to set the boolean instead of passing the flag.

Thread: https://marc.info/?l=openbsd-tech&m=169428749720476&w=2

show more ...


# 11d1f9b2 23-Aug-2023 cheloha <cheloha@openbsd.org>

all platforms: separate cpu_initclocks() from cpu_startclock()

To give the primary CPU an opportunity to perform clock interrupt
preparation in a machine-independent manner we need to separate the
"

all platforms: separate cpu_initclocks() from cpu_startclock()

To give the primary CPU an opportunity to perform clock interrupt
preparation in a machine-independent manner we need to separate the
"initialization" parts of cpu_initclocks() from the "start the clock
interrupt" parts. Currently, cpu_initclocks() does everything all at
once, so there is no space for this MI setup.

Many platforms have more-or-less already done this separation by
implementing a separate routine named "cpu_startclock()". This patch
promotes cpu_startclock() from de facto standard to mandatory API.

- Prototype cpu_startclock() in sys/systm.h alongside cpu_initclocks().
The separation of responsibility between the two routines is a bit
fuzzy but the basic guidelines are as follows:

+ cpu_initclocks() must initialize hz, stathz, and profhz, and call
clockintr_init().

+ cpu_startclock() must call clockintr_cpu_init() and start the clock
interrupt cycle on the calling CPU.

These guidelines will shift in the future, but that's the way things
stand as of *this* commit.

- In initclocks(): first call cpu_initclocks(), then do MI setup, and
last call cpu_startclock().

- On platforms where cpu_startclock() already exists: don't call
cpu_startclock() from cpu_initclocks() anymore.

- On platforms where cpu_startclock() doesn't yet exist: implement it.
Usually this is as simple as dividing cpu_initclocks() in two.

Tested on amd64 (i8254, lapic), arm64, i386 (i8254, lapic), macppc,
mips64/octeon, and sparc64. Tested on arm/armv7 (agtimer(4)) by
phessler@ and jmatthew@. Tested on m88k/luna88k by aoyama@. Tested
on powerpc64 by gkoehler@ and mlarkin@. Tested on riscv64 by
jmatthew@.

Thread: https://marc.info/?l=openbsd-tech&m=169195251322149&w=2

show more ...


# 3342c5b5 07-Aug-2023 miod <miod@openbsd.org>

Revert 1.43 and always make our own mapping of the Mostek chip. Trying to
reuse the prom mapping here is a bad idea because we alter its writeability
and the prom will not always expect this.

Repair

Revert 1.43 and always make our own mapping of the Mostek chip. Trying to
reuse the prom mapping here is a bad idea because we alter its writeability
and the prom will not always expect this.

Repairs powerdown on Tapdole Ultrabook IIe.

discussed with and ok kettenis@

show more ...


# 671537bf 25-Jul-2023 cheloha <cheloha@openbsd.org>

statclock: move profil(2), GPROF code to profclock(), gmonclock()

This patch isolates profil(2) and GPROF from statclock(). Currently,
statclock() implements both profil(2) and GPROF through a comp

statclock: move profil(2), GPROF code to profclock(), gmonclock()

This patch isolates profil(2) and GPROF from statclock(). Currently,
statclock() implements both profil(2) and GPROF through a complex
mechanism involving both platform code (setstatclockrate) and the
scheduler (pscnt, psdiv, and psratio). We have a machine-independent
interface to the clock interrupt hardware now, so we no longer need to
do it this way.

- Move profil(2)-specific code from statclock() to a new clock
interrupt callback, profclock(), in subr_prof.c. Each
schedstate_percpu has its own profclock handle. The profclock is
enabled/disabled for a given CPU when it is needed by the running
thread during mi_switch() and sched_exit().

- Move GPROF-specific code from statclock() to a new clock interrupt
callback, gmonclock(), in subr_prof.c. Where available, each cpu_info
has its own gmonclock handle . The gmonclock is enabled/disabled for
a given CPU via sysctl(2) in prof_state_toggle().

- Both profclock() and gmonclock() have a fixed period, profclock_period,
that is initialized during initclocks().

- Export clockintr_advance(), clockintr_cancel(), clockintr_establish(),
and clockintr_stagger() via <sys/clockintr.h>. They have external
callers now.

- Delete pscnt, psdiv, psratio. From schedstate_percpu, also delete
spc_pscnt and spc_psdiv. The statclock frequency is not dynamic
anymore so these variables are now useless.

- Delete code/state related to the dynamic statclock frequency from
kern_clockintr.c. The statclock frequency can still be pseudo-random,
so move the contents of clockintr_statvar_init() into clockintr_init().

With input from miod@, deraadt@, and claudio@. Early revisions
cleaned up by claudio. Early revisions tested by claudio@. Tested by
cheloha@ on amd64, arm64, macppc, octeon, and sparc64 (sun4v).
Compile- and boot- tested on i386 by mlarkin@. riscv64 compilation
bugs found by mlarkin@. Tested on riscv64 by jca@. Tested on
powerpc64 by gkoehler@.

show more ...


# d4028b06 28-Apr-2023 cheloha <cheloha@openbsd.org>

timer(4/sparc64): remove driver

The timer(4/sparc64) driver was effectively disabled during the
previous release. Nobody has come forward asking for it to be adapted
to work with the new clockintr

timer(4/sparc64): remove driver

The timer(4/sparc64) driver was effectively disabled during the
previous release. Nobody has come forward asking for it to be adapted
to work with the new clockintr framework, so it's time to remove the
driver from the tree.

As of today, if you want to run OpenBSD on SPARC v9 hardware, that
hardware needs to sport either %tick and %tick_compare (%asr23), or
%stick (%asr24) and %stick_compare (%asr25).

All Sun/Oracle SPARC v9 hardware meets these conditions, from the
UltraSPARC I onward.

Most HAL/Fujitsu SPARC v9 hardware meets these conditions, from the
SPARC64 III onward. The only HAL/Fujitsu hardware that might not have
%tick_compare are the HAL SPARC64 I and SPARC64 II, for which I can
find no documentation. However, those processors are currently
unsupported by OpenBSD for other reasons, so their support status is
unchanged by the removal of this driver.

With help from miod@.

Link: https://marc.info/?l=openbsd-tech&m=167898759928206&w=2

"after unlock" deraadt@, ok mlarkin@ miod@

show more ...


# 24ee467d 04-Feb-2023 cheloha <cheloha@openbsd.org>

timecounting: remove incomplete PPS support

The timecounting code has had stubs for pulse-per-second (PPS) polling
since it was imported in 2004. At this point it seems unlikely that
anyone is goin

timecounting: remove incomplete PPS support

The timecounting code has had stubs for pulse-per-second (PPS) polling
since it was imported in 2004. At this point it seems unlikely that
anyone is going to finish adding PPS support, so let's remove the stubs:

- Delete the dead tc_poll_pps() call from tc_windup().
- Remove all tc_poll_pps symbols from the kernel.

Link: https://marc.info/?l=openbsd-tech&m=167519035723210&w=2

ok miod@

show more ...


# 573d576b 13-Jan-2023 cheloha <cheloha@openbsd.org>

sparc64: switch to clockintr

- Remove all use of timer(4/sparc64) from sparc64/clock.c.
- Don't map interrupts in timer_match(), effectively disabling
timer(4/sparc64). The driver will be complet

sparc64: switch to clockintr

- Remove all use of timer(4/sparc64) from sparc64/clock.c.
- Don't map interrupts in timer_match(), effectively disabling
timer(4/sparc64). The driver will be completely removed in a
later commit.
- Wire up tick_intrclock, stick_intrclock, and sys_tick_intrclock.
- All sparc64 machines now have a randomized statclock; stathz = hz,
profhz = stathz * 10.

Very special thanks to miod@, without whom this would have been impossible.

sun4v testing by kmos@, mlarkin@, and kn@. sun4u testing (%tick and the
oddball USIIe %stick) by miod@. With input from miod@, mlarkin@, and
kettenis@.

v1: https://marc.info/?l=openbsd-tech&m=166776418803680&w=2
v2: https://marc.info/?l=openbsd-tech&m=167287772220176&w=2
v3: https://marc.info/?l=openbsd-tech&m=167322011602530&w=2

ok mlarkin@ kettenis@ miod@

show more ...


# 4b28d16f 29-Dec-2022 cheloha <cheloha@openbsd.org>

sparc64: pull retry logic out of tickcmpr_set(), sys_tickcmpr_set()

Pull the retry logic out of tickcmpr_set() and sys_tickcmpr_set() into
C functions tick_rearm() and sys_tick_rearm(), respectively

sparc64: pull retry logic out of tickcmpr_set(), sys_tickcmpr_set()

Pull the retry logic out of tickcmpr_set() and sys_tickcmpr_set() into
C functions tick_rearm() and sys_tick_rearm(), respectively. There is
nothing wrong with the retry logic in these assembly functions, but
it's better to keep equivalent code similar and this change realigns
the %TICK and %SYS_TICK rearm code with that of the Hummingbird
%STICK.

Tested by miod@ on UltraSPARC I, UltraSPARC II, and UltraSPARC IIe.

Link: https://marc.info/?l=openbsd-tech&m=167175014315419&w=2

ok kettenis@

show more ...


# 2f31c0f7 22-Dec-2022 cheloha <cheloha@openbsd.org>

sparc64: move retry logic out of stickcmpr_set()

In some cases, stickcmpr_set() fails to ensure that %STICK_CMPR leads
%STICK before returning to the caller. Rewriting the retry logic in C
triviall

sparc64: move retry logic out of stickcmpr_set()

In some cases, stickcmpr_set() fails to ensure that %STICK_CMPR leads
%STICK before returning to the caller. Rewriting the retry logic in C
trivially fixes the issue. So move the retry logic out into a new
function, stick_rearm().

Issue discovered by miod@, fix tested by miod@.

Link: https://marc.info/?l=openbsd-tech&m=167122933414238&w=2

ok kettenis@

show more ...


# 11e6c7e4 10-Nov-2022 jmatthew <jmatthew@openbsd.org>

Convert sparc64 clock event counter to per-cpu and increment using
evcount_inc() rather than atomic operations.

ok kettenis@ jca@ cheloha@


# eb7eaf8d 24-Oct-2021 mpi <mpi@openbsd.org>

Constify struct cfattach.

ok visa@ a long time ago


# 36fd90dc 11-Mar-2021 jsg <jsg@openbsd.org>

spelling


# 9ac6db98 23-Feb-2021 cheloha <cheloha@openbsd.org>

sparc64/clock.c: use ANSI-style function definitions

While here, zap a few ARGUSED linter comments.

Compile-tested by deraadt@.

ok deraadt@


# 8611d3cd 23-Feb-2021 cheloha <cheloha@openbsd.org>

timecounting: use C99-style initialization for all timecounter structs

The timecounter struct is large and I think it may change in the
future. Changing it later will be easier if we use C99-style

timecounting: use C99-style initialization for all timecounter structs

The timecounter struct is large and I think it may change in the
future. Changing it later will be easier if we use C99-style
initialization for all timecounter structs. It also makes reading the
code a bit easier.

For reasons I cannot explain, switching to C99-style initialization
sometimes changes the hash of the resulting object file, even though
the resulting struct should be the same. So there is a binary change
here, but only sometimes. No behavior should change in either case.

I can't compile-test this everywhere but I have been staring at the
diff for days now and I'm relatively confident this will not break
compilation. Fingers crossed.

ok gnezdo@

show more ...


# ee48eda3 20-Oct-2020 cheloha <cheloha@openbsd.org>

alpha, loongson, sh, sparc64: recompute tick, tick_nsec when hz(9) is reset

Normally we set hz(9) at compile-time in sys/conf/param.c to the value
of HZ. HZ is one of the fundamental compilation op

alpha, loongson, sh, sparc64: recompute tick, tick_nsec when hz(9) is reset

Normally we set hz(9) at compile-time in sys/conf/param.c to the value
of HZ. HZ is one of the fundamental compilation options(4). However,
sometimes we need to reset hz(9) at runtime.

Whenever we reset hz(9) we need to recompute tick and tick_nsec.
Otherwise a variety of "time stuff" in the kernel will not work
correctly. For example, most timeouts will expire "too slow" or "too
fast". There are a bunch of other places we use tick and tick_nsec
that will exhibit similar problems.

Test-compiled by deraadt@.

show more ...


# 42bbbbfd 31-Jul-2020 kettenis <kettenis@openbsd.org>

On sun4u systems that have the STICK register, clear the NPT bit of the
register such that it can be accessed from userland. With this change
we can unconditionally enabled the usertc code again.

o

On sun4u systems that have the STICK register, clear the NPT bit of the
register such that it can be accessed from userland. With this change
we can unconditionally enabled the usertc code again.

ok naddy@

show more ...


# 14c0d295 24-Jul-2020 kettenis <kettenis@openbsd.org>

Enable usertc if the NPT bit isn't set for %tick and %sys_tick.

ok naddy@


# 703c3386 19-Jul-2020 kettenis <kettenis@openbsd.org>

Disable userland timecounters for now. On some (all?) sun4u machines this
triggers an illegal instruction exception presumably because unpriviliged
access to the cycle counters is prohibited.


# de43b1a9 08-Jul-2020 kettenis <kettenis@openbsd.org>

Userland timecounter implementation for sparc64.

ok deraadt@, pirofti@


1234