* Drop ArchUART8260 layer to reduce complexity. It's whole
existance in life was to adjust the mmio alignment.
* Fold architecture mmio alignment into DebugUart
* We could potentially pass a Init(int mmioAlignment)
arg in the future if the macros get too messy.
* Move Barrier code back a layer into DebugUART
* Fixes the arm uart and EFI build
Change-Id: I0f127d902993e9f6e6a03cac8c7c37c0363134bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4422
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We have a number of "actions" blocks in our Jam rules with more than
one command, and so without -e, the actions will only fail if the last
command does. This is clearly not what was intended in virtually all
cases, so we should pass -e to the shell to ensure any command failing
causes the whole actions to fail.
I am kind of surprised that nobody noticed this before now, even
in the original Jamrules going back to the Perforce days. I only
noticed it because I experimented with making "rm" fail to find
places where it was invoked instead of $(RM)...
Change-Id: Id83a1aeb9736be1d08ba10bb52ab81f2cab11625
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4426
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Some logs are emitted even when nothing at all is happening, constantly
spamming the syslog. Log them only the first time they happen.
Change-Id: I81511a7ce245c2141fa3dcd141b2f3732d9b51ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4424
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
In some cases, we don't need the full tracking of every byte received at
the PS2 level, but higher level traces from specific devices will be
enough.
Change-Id: I31984e6b7784b5d033b457f43f3793f772213f4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4423
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* Get rid of fPacketSize and use fSamplesCount in GetBuffers instead.
* Clarify logic in _TransferCallback.
* Properly multiply in kSamplesBufferCount to fAreaSize
(this should be the only functional change in here.)
The larger buffers (now similarly sized to HDA at least in the
default cases of 44100 or 48000) seem to help with jittering
and discontinuities, which are significantly reduced now,
at least under emulation.
In hrev55048, checks were added to bail on initialization if invalid
audio formats were present either in inputs or outputs, which broke
any audio nodes that supported only one or the other. Now, instead,
we check channels first, and even then do not bail on invalid formats,
but simply do not declare support for inputs or outputs respectively.
This solves the initial cause of #17235. However, that ticket refers to
an unrelated problem this bug merely exposed, and so it should remain
open until that is resolved.
Stalls cause "HALTED" conditions on endpoints, so use B_DEV_STALLED.
Also clarify the comment referencing the specification, and add a
missing linebreak to the error message.
* Allocate the descriptors array separately from the data area.
* Clone the data area for kernel use separately from userland use.
Fixes the remaining SMAP problems with this driver.
An "Input" terminal in USB audio terms refers to any stream of audio
going "in" to the USB device, whether that be from the outside world
(e.g. a line in jack) or from the computer (e.g. via USB OUT endpoints.)
So we cannot rely on the terminal type to tell us whether it is an in
or an out for our purposes, we have to check the stream type, and then
use that to declare to multi_audio what kind of stream we have.
Fixes USB audio mixing up inputs and outputs, especially on devices
that only have one or the other and not both. (QEMU manifested
this problem.)
This may help fixing lgtm build failure "There is not enough space on the disk".
Change-Id: I5db5748b73e611ec6b66a8effdf5ad39969f9bde
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4415
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The USB Kit uses it, so this allows the USB Kit to stop including
USB3.h.
Change-Id: Ifde025ec41bef92013fda0440d60b7216cfdbe4a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4413
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It seems this has been broken since I originally wrote it in 2019,
but it only gets called in two scenarios: on device unplug (where
it does not really matter), and on interface changes (where it does.)
Apparently very few people tried to use devices that depend on interface
changes, because those would have been totally broken by this.
There were actually two bugs here:
1. ConfigureEndpoint should not be called with the Deconfigure bit set.
(See inline comment.)
2. The first bit must be set in the context add flags.
Fixes#14971 at least, and possibly others as well.
...to usb_endpoint_superspeed_companion_descriptor, as it is
really SuperSpeed-specific (there are more companion descriptors
introduced in SuperSpeedPlus.)
No functional change, and this is a private struct at present.
* We really should get out of the habbit of making up
our own architecture defines.
* __riscv with an additional __riscv_xlen is the
standard that developed... let's just roll with it.
Change-Id: Ieb777d48340ae25a6d66f66133afa0ec5c6da9b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4402
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Including thread.h brings a massive array of things with it from
the kernel thread arch headers, team and thread definitions,
hash tables, linked lists, Referenceable, etc. that the vast majority
of AutoLock.h consumers neither want nor need.
So, put these in a separate header, and adjust all consumers of these
lockers to include the new file.
This change exposes the fact that a lot of files were inadvertently
making use of headers included indirectly through thread.h. Those
will be fixed in the next commit.
* Set driver module name of device_node.
* Set device module name and path for published devices.
This helps to understand what driver is used, and it's /dev path in the
Devices app.
Change-Id: Ibd902a322da7e4276052bd4429a7b869a56a592b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3390
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Previously these were just using the raw function name, which led
to markers like "Slab_begin". Now we prefix RANGE_MARKER_ so there
is absolutely no chance of confusion, and the symbols are clearly
visible in dumps.
Also add a note that the kernel must be built with -fno-toplevel-reorder
for these to work. (It seems when this was implemented, GCC had not yet
implemented top-level reordering.)
They are only used for debugging with the tracing system in a handful
of places, and -ftoplevel-reorder is enabled with optimizations for
a reason, so it makes more sense just to note this and not to enable
that option by default (i.e. in the off chance someone will want to
use these in non-debug builds, like I did.)
Will allow USB3, 64vCPU, NVME, etc. Versions below 13 are only for vmware products currently EOL.
Change-Id: I83303ab985f615852267e2539b350f72f05231e7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4410
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unfortunately it does not work, I get this when invoking
allocations_per_caller at the kdebug prompt:
92513 9162096 0x0000000000000000 <NULL> + 0x0 (commpage) (nearest)
12602 2108408 0xffffffff80132a50 _Z23add_alloc_tracing_entryP11ObjectCachejPv + 0x70 (kernel_x86_64)
The stack tracing system must be broken, or maybe it has never been
properly adjusted for x86_64.
If the timeout is already >= B_INFINITE_TIMEOUT, we do not need
to do any of the following math (which would usually overflow anyway)
and can leave the timeout alone.
Spotted by kernel undefined behavior sanitizer.
For the kernel team, we now assign it in team_init instead of having
a special case in Team::Team(), making things more similar to the
userland team creation.
Should not change any real functionality as Team::Create calls
almost nothing outside of this file.
This translator only supports still images for now, and supports both
decoding and encoding.
Encoding support has been tested only with aom, rav1e doesn’t build on
Haiku yet, see https://github.com/haikuports/haikuports/pull/5534 for
one of the missing dependencies.
Change-Id: I716f4b862ed316b89b227bfed38072d72074201f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3040
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The "update dependency versions" step automatically adds the requisite
versions to this file during the build based on whatever the build
system is actually using, so this is not necessary; and it seems
that some architectures besides GCC2 are still on a version of ICU
less than 66.
... so that you can see the extension.
Change-Id: I0c3cdcede912f6ccc7dfb8360bfd82599c8117c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4323
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
