| created | 2022-08-28T03:01:49Z |
|---|---|
| begin | 2022-08-25T00:00:00Z |
| end | 2022-08-26T00:00:00Z |
| path | src/sys |
| commits | 10 |
| date | 2022-08-25T16:10:15Z | |||
|---|---|---|---|---|
| author | miod | |||
| files | src/sys/arch/octeon/conf/BOOT | log | diff | annotate |
| message | No need for wsmux in this kernel configuration; ok visa@ | |||
| date | 2022-08-25T17:25:25Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/arch/amd64/amd64/machdep.c | log | diff | annotate |
| src/sys/arch/amd64/include/cpu.h | log | diff | annotate | |
| src/sys/arch/i386/i386/machdep.c | log | diff | annotate | |
| src/sys/arch/i386/include/cpu.h | log | diff | annotate | |
| message |
amd64, i386: add delay_init(): basic delay(9) implementation management Because the clock situation on x86 and amd64 is a terminal clusterfuck, there are many different ways to delay(9). We need a rudimentary mechanism for gracefully switching to progressively better delay(9) implementations as they become available during boot without riddling the code with ifdefs and function pointer comparisons. This patch adds delay_init() to both amd64 and i386. If the quality value passed to delay_init() exceeds the quality value of the current delay_func, delay_init() changes delay_func to the given function pointer and updates the quality value. Both platforms start with delay_func set to i8254_delay() and a quality value of zero: all other delay(9) implementations are preferable. Idea and patch provided by jsg@. With tons of input, research, and advice from jsg@. Link: https://marc.info/?l=openbsd-tech&m=166053729104923&w=2 ok mlarkin@ jsg@ |
|||
| date | 2022-08-25T17:38:16Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/arch/amd64/amd64/lapic.c | log | diff | annotate |
| src/sys/arch/amd64/amd64/tsc.c | log | diff | annotate | |
| src/sys/arch/i386/i386/lapic.c | log | diff | annotate | |
| src/sys/dev/pv/pvbus.c | log | diff | annotate | |
| message |
amd64, i386: use delay_init() instead of writing delay_func by hand Now that we have delay_init(), use it in all the places where we currently set delay_func by hand. lapic_delay() is great: 3000. hv_delay() is needed before we set up lapic_delay() on Hyper-V guests: 4000. tsc_delay() is better than lapic_delay() and (probably?) hv_delay(): 5000. We may bump hv_delay's quality value up over that of tsc_delay() in a future patch. It's a little ambiguous whether hv_delay() causes a VM exit. Idea and patch from jsg@. With tons of input, research and advice from jsg@. Link: https://marc.info/?l=openbsd-tech&m=166053729104923&w=2 ok mlarkin@ jsg@ |
|||
| date | 2022-08-25T17:43:34Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/dev/acpi/acpitimer.c | log | diff | annotate |
| message |
acpitimer(4): add acpitimer_delay(), another delay(9) implementation When lapic_delay() is removed from the tree in the near future, older machines without a constant/invariant TSC will need a delay(9) implementation better than i8254_delay(). This patch adds acpitimer_delay(), a delay(9) implementation based on the ACPI PM timer. It is only preferable to i8254_delay(), so set its quality to 1000. With input from jsg@. Link: https://marc.info/?l=openbsd-tech&m=166053729104923&w=2 ok mlarkin@ jsg@ |
|||
| date | 2022-08-25T17:54:33Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/dev/acpi/acpihpet.c | log | diff | annotate |
| message |
acpihpet(4): add acpihpet_delay(), another delay(9) implementation When lapic_delay() is removed from the tree in the near future, older machines without a constant/invariant TSC will need a delay(9) implementation better than i8254_delay(). This patch adds acpihpet_delay(), a delay(9) implementation based on the ACPI HPET timer. It is preferable to i8254_delay() (0) and acpitimer_delay() (1000), so set its quality to 2000. On newer machines, the HPET is slower to read than the PMT on newer machines for reasons unknown, so _technically_ this quality hierarchy is not always accurate. However, we expect these newer machines to have a constant/invariant TSC available, so the inaccuracy is harmless because tsc_delay() will be available, which is better than both the PMT and the HPET. In general, on real hardware that predates wide availability of the constant/invariant TSC, the HPET is preferable to the PMT. With input from jsg@. Link: https://marc.info/?l=openbsd-tech&m=166053729104923&w=2 ok mlarkin@ jsg@ |
|||
| date | 2022-08-25T18:01:54Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/dev/acpi/acpihpet.c | log | diff | annotate |
| message |
acpihpet(4): don't truncate HPET frequency to 32-bit value timecounter.tc_frequency is a 64-bit value: this cast is unnecessary. Split off from the acpihpet_delay() commit at jsg@'s suggestion. Link1: https://marc.info/?l=openbsd-tech&m=166053729104923&w=2 Link2: https://marc.info/?l=openbsd-tech&m=166132727120528&w=2 probably ok jsg@ |
|||
| date | 2022-08-25T19:16:29Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/dev/aplcpu.c | log | diff | annotate |
| message |
The "Avalanche" performance cores on Apple's M2 SoC have more than 16 P-states. As a result the layout of the "state" register changed. Make the driver handle that. Also make sure we use the correct lowest state in case the lowest frequency of the performance cores is different from the lowest frequency of the efficiency cores. ok tobhe@ |
|||
| date | 2022-08-25T20:43:17Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/arch/amd64/amd64/lapic.c | log | diff | annotate |
| message | amd64/lapic.c: remove unused extern prototype for tsc_delay() | |||
| date | 2022-08-25T23:49:31Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/ttm/ttm_bo.c | log | diff | annotate |
| message |
drm/ttm: Fix dummy res NULL ptr deref bug From Arunpravin Paneer Selvam 76672cd326c146ded2c2712ff257b8908dcf23d8 in linux 5.15.y/5.15.63 cf4b7387c0a842d64bdd7c353e6d3298174a7740 in mainline linux |
|||
| date | 2022-08-25T23:52:56Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/amd/display/dc/dcn303/dcn303_resource.c | log | diff | annotate |
| message |
drm/amd/display: Check correct bounds for stream encoder instances for DCN303 From Aurabindo Pillai 82a27c1855445d48aacc67b0c0640f3dadebe52f in linux 5.15.y/5.15.63 89b008222c2bf21e50219725caed31590edfd9d1 in mainline linux |
|||