* Looks like some error in atombios. AMD just
reversed the values instead of fixing the atom.h
defines in Linux.
Change-Id: I440682af5708ce0da1625e8f50e8cb77595c8397
* A first attempt at improving on #17377
* We haven't actually seen any cards using this
routing stuff yet pre-navi.
* We don't use the router information yet... but this might
improve things a bit on new cards.
Change-Id: I17962dfd8bb09e619a6084cd9571ccb9832fb19a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4697
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: If7feffafea4fc6d295d04f696127c8f0fbd8fb9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4704
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The previous round of this code unblocked after unset universally,
but that was incorrect in the case where the thread was not in
the "waiting" state before we unset. Yesterday I changed that to
just unblock before unset universally.
It seems, however, that thread_unblock is so time-consuming
that the other thread will wake up and begin doing things
before unblock returns for us, and then it will hit the timeout
before we have a chance to unset. So, now we unblock later
if it is possible to do so.
It seems very strange, though, that thread_unblock will
not return in a small but significant number of cases
before the unblocked thread actually starts running (note
that we are in interrupts-disabled mode here, so that is
not the problem.) That sounds like a problem for another day.
Should fix#17455, possibly in tandem with the previous commit.
This also fixes a leak of slots when initializing devices failed.
Fixes#16323, although there is some other underlying problem
which led to that error in the first place.
It is defined as a uint32:1, which apparently becomes an "int" on
newer GCC versions, which thus triggers a -Werror=format. So,
convert it explicitly in order to prevent the error.
In GCC 8 builds it is by default, in GCC 11 builds it is weakly
defined, which runtime_loader does not yet support properly,
so we force it to be included.
Unblocking after unsetting fVariable just causes too many headaches
and corner cases to deal with; the code as-is did not actually handle
all of them, as it missed the case where the entry thread had called
thread_prepare_to_block but had not yet actually blocked.
Hopefully the last fix for #17444.
* Removed i2c keyboard handler, as it was just a hid shared handler duplicate with kdl stuff removed
* I've created a new macro def for the kdl code, splitting generic kdl code from specific usb one
* I2C custom KDL code can be added in the future (I don't know if it is already possible)
I am not very happy with this solution, but imho it is better than having two keyboard handlers. In fact, they were already out of sync from last patch series
Change-Id: I36513e57a2ce4f004fc7e05ccff5a6b2517fc139
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4758
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If a thread executes a system call and meanwhile a different thread calls another one, then
the ongoing call is marked as unfinished. When the call returns it will be marked as resumed.
* remove PreSyscall, now unused.
Change-Id: Iea45b866be2c40568d766c2ed3cc73e34b9d1293
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4765
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
in the case of poll(), the events should be printed before the actual syscall,
and the revents after, while taking in account the return value.
thus B_DEBUGGER_MESSAGE_PRE_SYSCALL needs to be enabled and handled.
the attribute "preSyscall" is added to identify such syscalls, and the parameters
are identified with the attribute "inOut".
Change-Id: I390643ea176c720738c5ec4fc75a3a4c7125a3cd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4763
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
For now this is used on RISCV64 to indicate that interrupts will always
be on CPU 0. However, in the future, some architectures may want
or require interrupts to be "steered" in various ways, and this
also paves the way for that.
Change-Id: Iec79870cf5c4898d102d0e624de19602271ae772
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4721
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
