| created | 2020-12-20T00:42:03Z |
|---|---|
| begin | 2020-12-17T00:00:00Z |
| end | 2020-12-18T00:00:00Z |
| path | src/sys |
| commits | 8 |
| date | 2020-12-17T04:15:03Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/if_mcx.c | log | diff | annotate |
| message |
rework the maths used to set mbuf timestamps. there's a comment that explains how it works now, but the result is that i get much tighter and more consistent synchronisation between the kernel clock and the values derived from the mcx timestamps now. however, i only just worked out that there is still an unresolved problem where the kernel clock changes how fast it ticks. this happens when ntpd uses adjtime(2) or adjfreq(2) to try and make the kernel tick at the same rate as the rest of the universe (well, the small bit of it that it can observe). these adjustments to the kernel clock immediately skew the timestamps that mcx calculates, but then it also throws off the mcx calibration calculations that run every 30 seconds. the offsets calculated in the next calibration period are often (very) negative. eg, when things are synced up nicely and you do a read of the mcx timer and immediately follow it with a nanouptime(9) call, on this box it calculates that the time in between those two events is about 2600ns. in the calibration period after ntpd did a very small adjtime call, it now thinks the time between those two events is -700000ns. this is a pretty obvious problem in hindsight. i can't think of a simple solution to it at the moment though so i'm going to leave mcx timestamping disabled for now. |
|||
| date | 2020-12-17T15:37:09Z | |||
|---|---|---|---|---|
| author | jcs | |||
| files | src/sys/dev/ic/bwfm.c | log | diff | annotate |
| message |
bwfm: add a delay in bwfm_set_key_cb before talking to hardware This works around an issue on the BCM43602 where ieee80211 calls this too quickly during authentication and triggers "unexpected pairwise key update" errors. ok patrick |
|||
| date | 2020-12-17T17:57:19Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/acpi/acpi.c | log | diff | annotate |
| src/sys/dev/acpi/acpiprt.c | log | diff | annotate | |
| src/sys/dev/acpi/acpipwrres.c | log | diff | annotate | |
| src/sys/dev/acpi/acpitz.c | log | diff | annotate | |
| src/sys/dev/acpi/atk0110.c | log | diff | annotate | |
| src/sys/dev/acpi/dsdt.c | log | diff | annotate | |
| message |
Fix some issues with referencing named ACPI nodes from Packages. These references need to be resolved at runtime rather than when they're parsed such that they pick up the right values for those nodes which can be changed when for example _INI methods run. The current approach is to replace these reference with a string that names the node in question. The problem with that is that packages can also contain normal strings. Which means that we need special code that depends on the context where the package is used. This diff takes a different approach by retaining a reference when parsing. Code that uses a package will need to resolve this reference but there is no ambiguiety anymore. ok patrick@ |
|||
| date | 2020-12-17T19:43:32Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/fdt/amlpinctrl.c | log | diff | annotate |
| message | Add support for the "Always On" GPIOs. | |||
| date | 2020-12-17T19:50:06Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/fdt/if_dwge.c | log | diff | annotate |
| message |
Match on "amlogic,meson-g12a-dwmac" which is used by newer Linux mainline device trees. |
|||
| date | 2020-12-17T21:52:09Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/fdt/amlpinctrl.c | log | diff | annotate |
| message |
Reset pin 3 of the GPIOAO bank to input mode to work around a hardware bug in the Odroid C4/HC4 boards. |
|||
| date | 2020-12-17T22:39:45Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/fdt/amldwusb.c | log | diff | annotate |
| message | Only enable the USB 3.0 port and PHY if it is enabled on a board. | |||
| date | 2020-12-17T23:36:47Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/dev/pci/if_tht.c | log | diff | annotate |
| message |
tht(4): more tsleep(9) -> tsleep_nsec(9) The first wait-loop in tht_fw_load() can sleep for at least 10ms per iteration instead of up to 1 tick per iteration with no ill effects. The worst-case scenario is that we sleep a little longer than we do now while we wait. The second wait-loop can be simplified to sleep for at least 10ms per iteration for up to 2000ms instead of using a timeout. This method is less precise and less efficient but is far simpler to read and understand than using a timeout. We can then remove all the timeout-related stuff from if_tht.c. Discussed with mpi@. ok dlg@ |
|||