#
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 ...
|
#
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 ...
|
#
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 ...
|
#
8e3880d2 |
| 17-Jan-2023 |
cheloha <cheloha@openbsd.org> |
amptimer(4): switch to clockintr
- Strip out custom hardclock/statclock scheduling code. - Wire up amptimer_intrclock. - Remove debug evcounts. All interrupts are now counted with the evcount in
amptimer(4): switch to clockintr
- Strip out custom hardclock/statclock scheduling code. - Wire up amptimer_intrclock. - Remove debug evcounts. All interrupts are now counted with the evcount in the interrupt handler. - Remove apparently dead USE_GTIMER_CMP code.
Debugged with jca@. Tested by jca@.
Link: https://marc.info/?l=openbsd-tech&m=167060127825418&w=2
ok kettenis@ jca@
show more ...
|
#
e3ee5e84 |
| 12-Mar-2022 |
mpi <mpi@openbsd.org> |
Constify struct cfattach.
ok patrick@
|
#
37e35e27 |
| 16-May-2021 |
jsg <jsg@openbsd.org> |
ansi
|
#
a4a50d96 |
| 25-Mar-2021 |
jsg <jsg@openbsd.org> |
remove uneeded includes in md armv7 files
based on include-what-you-use suggestions
|
#
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 ...
|
#
2252d02c |
| 19-Jan-2021 |
kettenis <kettenis@openbsd.org> |
s/KHZ/kHz/ and reduce dmesg spam a bit
ok tb@, deraadt@
|
#
789e88a4 |
| 14-Jul-2020 |
patrick <patrick@openbsd.org> |
Extend the interrupt API on arm64 and armv7 to be able to pass around a struct cpu_info *. From a driver point of view the fdt_intr_establish_* API now also exist same functions with a *_cpu suffix.
Extend the interrupt API on arm64 and armv7 to be able to pass around a struct cpu_info *. From a driver point of view the fdt_intr_establish_* API now also exist same functions with a *_cpu suffix. Internally the "old" functions now call their *_cpu counterparts, passing NULL as ci. NULL will be interpreted as primary CPU in the interrupt controller code.
The internal framework for interrupt controllers has been changed so that the establish methods provided by an interrupt controller function always takes a struct cpu_info *.
Some drivers, like imxgpio(4) and rkgpio(4), only have a single interrupt line for multiple pins. On those we simply disallow trying to establish an interrupt on a non-primary CPU, returning NULL.
Since we do not have MP yet on armv7, all armv7 interrupt controllers do return NULL if an attempt is made to establish an interrupt on a different CPU. That said, so far there's no way this can happen. If we ever gain MP support, this is a reminder that the interrupt controller drivers have to be adjusted.
Prompted by dlg@ ok kettenis@
show more ...
|
#
439fbd73 |
| 12-Jul-2020 |
naddy <naddy@openbsd.org> |
Use the full 32 bits for the miscellaneous armv7 timecounters. Checked against * ARM Architecture Reference Manual (agtimer) * ARM Cortex-A9 MPCore Technical Reference Manual (amptimer) * OMAP35x App
Use the full 32 bits for the miscellaneous armv7 timecounters. Checked against * ARM Architecture Reference Manual (agtimer) * ARM Cortex-A9 MPCore Technical Reference Manual (amptimer) * OMAP35x Applications Processor Technical Reference Manual (gptimer)
Artturi Alm had independently suggested this in the past.
show more ...
|
#
d82e6535 |
| 06-Jul-2020 |
pirofti <pirofti@openbsd.org> |
Add support for timeconting in userland.
This diff exposes parts of clock_gettime(2) and gettimeofday(2) to userland via libc eliberating processes from the need for a context switch everytime they
Add support for timeconting in userland.
This diff exposes parts of clock_gettime(2) and gettimeofday(2) to userland via libc eliberating processes from the need for a context switch everytime they want to count the passage of time.
If a timecounter clock can be exposed to userland than it needs to set its tc_user member to a non-zero value. Tested with one or multiple counters per architecture.
The timing data is shared through a pointer found in the new ELF auxiliary vector AUX_openbsd_timekeep containing timehands information that is frequently updated by the kernel.
Timing differences between the last kernel update and the current time are adjusted in userland by the tc_get_timecount() function inside the MD usertc.c file.
This permits a much more responsive environment, quite visible in browsers, office programs and gaming (apparently one is are able to fly in Minecraft now).
Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others!
OK from at least kettenis@, cheloha@, naddy@, sthen@
show more ...
|
#
23a4b636 |
| 09-Jul-2018 |
patrick <patrick@openbsd.org> |
Implement ampintcmsi(4) in ampintc(4) to support MSI. The GICv2M is an extension to the GIC controller, which is represented as subnode in the device tree. There can be multiple GICv2Ms, so it make
Implement ampintcmsi(4) in ampintc(4) to support MSI. The GICv2M is an extension to the GIC controller, which is represented as subnode in the device tree. There can be multiple GICv2Ms, so it makes sense to attach those to ampintc(4) as some kind of simplebus. The GICv2M is simply an interrupt generator that can be used by PCIe devices to ring the door bell. There is no need for further configuration, we only need to find out which SPIs we are allowed to use for MSI and to register an edge triggered interrupt on a (randomly) allocated SPI.
Implement support for interrupt types. The GIC only seems to support level triggered active-high or egdge triggered low-to-high interrupts. We currently always configure them to be level triggered, which is a sane default for most controllers. Since MSI interupts on the GIC are edge triggered, we need to be able to parse the type information and to configure the interrupt correspondingly.
ok kettenis@
show more ...
|
#
e6a06f73 |
| 12-Dec-2015 |
mmcc <mmcc@openbsd.org> |
comment typo
|
#
bd6a20cf |
| 08-Aug-2013 |
rapha <rapha@openbsd.org> |
Remove duplicate loop.
ok patrick@
|
#
0e8af838 |
| 06-Aug-2013 |
patrick <patrick@openbsd.org> |
Attach amptimer only on Cortex-A9, as all Cortex-A8 doesn't have a generic timer and the newer Cortexes have another generic timer.
ok rapha@ jsg@
|
#
7e60210c |
| 09-May-2013 |
patrick <patrick@openbsd.org> |
Have the ARM MPCore Timer use the private timer, which will be very useful for SMP on the newer ARMv7 boards. From drahn at dalerahn.com.
ok bmercer@
|
#
027018ef |
| 01-May-2013 |
patrick <patrick@openbsd.org> |
Add a cortex bus which represents the ARM MPCore Complex. It will attach only to ARM Cortex A9 and A15 SoCs. The generic interrupt controller and timer will attach to this bus, later a secondary cach
Add a cortex bus which represents the ARM MPCore Complex. It will attach only to ARM Cortex A9 and A15 SoCs. The generic interrupt controller and timer will attach to this bus, later a secondary cache controller can be added. The base address for those controllers are figured out using the periphbase register.
ok bmercer@
show more ...
|