| created | 2023-04-30T19:16:42Z |
|---|---|
| begin | 2023-04-23T00:00:00Z |
| end | 2023-04-24T00:00:00Z |
| path | src/sys |
| commits | 10 |
| date | 2023-04-23T00:01:40Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_clockintr.c | log | diff | annotate |
| message |
clockintr_advance: don't use cached uptime when called outside of dispatch When clockintr_advance() is eventually used by outside callers, there will be no way to know how fresh cq_uptime is. If we're not running in the dispatch loop, we need to call nsecuptime(9) to get a high-res uptime before advancing a clockintr. |
|||
| date | 2023-04-23T00:08:36Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_clockintr.c | log | diff | annotate |
| message |
clockintr_cpu_init: don't update cached uptime clockintr_advance() now calls nsecuptime(9) when called outside clockintr_dispatch(). There is no need for clockintr_cpu_init() to update the queue's cached uptime (cq->cq_uptime) to ensure it is fresh. |
|||
| date | 2023-04-23T00:20:26Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/conf/files | log | diff | annotate |
| src/sys/dev/acpi/files.acpi | log | diff | annotate | |
| src/sys/dev/acpi/iosf_acpi.c | log | diff | annotate | |
| src/sys/dev/ic/iosf.c | log | diff | annotate | |
| src/sys/dev/ic/iosfvar.h | log | diff | annotate | |
| src/sys/dev/pci/files.pci | log | diff | annotate | |
| src/sys/dev/pci/iosf_pci.c | log | diff | annotate | |
| message |
add iosf(4), a driver for the Intel OnChip System Fabric The OnChip System Fabric is mostly an implementation detail on a bunch of Intel SoC platforms we usually don't care about, except on some of these machines there are devices shared between the kernel and the platform that need to coordinate. The iosf(4) driver allows the kernel to talk via a mailbox interface to take and release a semaphore that the hardware also uses to lock around accesses to some components. There are two ways to talk to the mailbox interface, one via mmio ops on an INT33BD acpi device. The other is via magic pci conf space operations on the pci host device. This provides a generic iosf driver with attachment glue for both acpi and pci so either can be used. According to linux, the pci ops are a lot more reliable and less buggy, so if both acpi and pci are available we will prefer the pci ops after they attach. I found this because I got a Dell Wyse 3040, which is a cherry trail/braswell system that has an acpitz(4) which talks to a tipmic(4) device attached to dwiic(4) on acpi. This box almost always locked up by the time it got to showing the console login prompt, and it turns out one of the reasons for this is because acpitz was touching the tipmic device at the same time the powerunit on the platform was also trying to use it. The tipmic device lists the iosf mailbox as a dependency, and the dwiic controller has a _SEM property, both of which indicate we should use an iosf device to coordinate iic ops when talking to the tipmic. This adds the code, but doesn't wire it into dwiic or the build yet. help from patrick@ jsg@ kettenis@ ok kettenis@ patrick@ |
|||
| date | 2023-04-23T00:33:02Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/acpi/dwiic_acpi.c | log | diff | annotate |
| message |
add support for coordinating i2c bus access with iosf(4) if the acpi node has a _SEM property, add wrappers around the i2c bus acquire and release handlers to try and call the iosf provided hardware semaphore ops. this means bus accesses can be coordinate with other parts of the platform such as the punit. this stops my Dell Wyse 3040 from locking up. ok kettenis@ patrick@ |
|||
| date | 2023-04-23T00:49:04Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/drm/include/asm/iosf_mbi.h | log | diff | annotate |
| message | iosf(4) implements functionality that was stubbed out in drm | |||
| date | 2023-04-23T00:50:29Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/arch/amd64/conf/GENERIC | log | diff | annotate |
| message |
enable iosf(4) this should help some braswell and bay trail machines. it definitely helps my dell wyse 3040 avoid locking up. ok kettenis@ patrick@ |
|||
| date | 2023-04-23T06:22:15Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/ic/dwqe.c | log | diff | annotate |
| src/sys/dev/ic/dwqevar.h | log | diff | annotate | |
| message | rename sc_tick to sc_phy_tick. no functional change. | |||
| date | 2023-04-23T10:29:35Z | |||
|---|---|---|---|---|
| author | patrick | |||
| files | src/sys/dev/pv/viogpu.c | log | diff | annotate |
| message |
Stop setting ri->ri_bs to prevent a panic caused by rasops accessing its uninitialized content. When we rasops_init() with RI_VCONS, a new screen is allocated. If ri->ri_bs is set, this will be copied. Otherwise a new one will be allocated and filled with ASCII spaces. Copying the ri->ri_bs is useful in case we have an early console which contents we want to keep. As we do not have an early console here, there's no point in setting it at the moment. With this my Hetzner arm64 VM doesn't panic anymore. ok jcs@ kettenis@ |
|||
| date | 2023-04-23T22:48:03Z | |||
|---|---|---|---|---|
| author | jmatthew | |||
| files | src/sys/dev/pci/if_aq_pci.c | log | diff | annotate |
| message |
Prepare for adding Atlantic 2 support by renaming functions and defines specific to Atlantic 1, shuffling some of the setup code, and adding get_mac_addr to the firmware ops struct. ok dlg@ |
|||
| date | 2023-04-23T22:57:23Z | |||
|---|---|---|---|---|
| author | jmatthew | |||
| files | src/sys/dev/pci/if_aq_pci.c | log | diff | annotate |
| message |
Adjust some printfs in the attach code path to make more sense, and include the mac address of the interface on the attach line. ok dlg@ |
|||