This went through review way too fast once again. I did warn that these
changes were completely untested, and indeed this one was broken. Be
very careful when pressing the submit button, please!
Change-Id: I6e0230efe94830033f5427451f67fe6ce29a28e6
Reviewed-on: https://review.haiku-os.org/c/1184
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Check "endpoint == NULL" instead of the ID for this pipe; as
_InsertEndpointForPipe will have already done the check for us.
* Store the endpoint's ID (our internal ID) in the structure, and
then move the doorbell-ring into _LinkDescriptorForPipe. Now all
variables named "id" are actually that, and not the endpoint number
(which is "id + 1".)
* Return actual statuses in NotifyPipeChange, among other tweaks.
* All things which set the usb_request_data structure also set data,
so we can just use ReadDescriptor to do copies like normal, simplifying
the finish-transfers code.
No (major) functional change intended.
This behaves mostly like a pointer, but pointer maths works in bytes,
not the native object size.
It avoids casting to char* and back when doing byte-based pointer math,
making the code easier to read.
Change-Id: I6a8681a398345f0c7d419a2cfe7244d972ffa62f
Reviewed-on: https://review.haiku-os.org/c/1086
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Remove code duplication.
* Make _mutex_trylock work in non-KDEBUG kernels. This should fix
spurious failures to lock in drivers compiled for KDEBUG kernels
running under non-KDEBUG kernels.
* the spec requires 521us, 1000us is generally used.
* also only uninit streams, corb and rirb when a codec reset is in progress (seen in zircon).
linux instead clears HDAC_STATE_STATUS.
This requires a bit of massaging around the locking code. Probably
we shouldn't be able to do this, and there should be a "mutex_unlock_etc"
for use in interrupt contexts, but at present there is not.
This makes it possible to use XHCI-attached keyboards from within KDL!
This is not so important now (though it is a mild performance improvement
when running transfers during commands), but it will be when the debug
transfer hooks are implemented, as we will need to use these to determine
if it is safe to queue and poll for transfers or not.
The code as it was before was very hard to follow and incorrect in
a number of corner cases, as well as not being very clear about what
the TODOs were.
It now follows the spec much more closely (especially in interval
computation) and contains more details on where it is still lacking.
This probably does not fix much (if anything) as is, but it paves the
way for future isochronous support.
non standard extension, but widely available to obtain attributes for a thread.
also provides an alias for pthread_getattr_np which is the bsd equivalent.
Change-Id: I26ef8245ed2537186f48c8b8bdf3e42b03e70892
Reviewed-on: https://review.haiku-os.org/c/1172
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Replace do...while(false) loop with while(true)... loop,
so that 'continue' at line 1968 can continue loop.
Change-Id: I4d64ff2699ad0837f29d49c63b683b134c4ccc1e
Reviewed-on: https://review.haiku-os.org/c/1149
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Barrett17 <b.vitruvio@gmail.com>
See inline comments. At least in brief testing I couldn't cause the
USB-HID stalls anymore, but they were very intermittent for me anyway.
But it was doubtless the case that the logic as it was before was
very much incorrect.
Besides calling the allocator fewer times, this also helps break up
the size classes we are allocating chunks from, reducing memory pressure.
As most transfers are smaller than 128KB, this is a major performance
optimization for them.
See inline comment. This is very subtle stuff...
I didn't manage to trigger this in my brief testing, and the USB-HID
stall during USB Disk access is still not very difficult to reproduce.
So, this doesn't seem to have been the issue.
This is essentially a complete rewrite of the way TDs work, and a
significant change to how "normal" requests are submitted. In summation:
* There is now no such thing as a "descriptor chain". This was a concept
mostly carried over from EHCI and previous controllers that does not
really map to XHCI properly, as one "transfer descriptor" can contain
as many TRBs as are necessary to complete the transfer.
What we were really doing before was setting up multiple TRB sequences
owned by our xhci_td structure, and then linking them together with the
CHAIN bit set on each TRB, which in XHCI terms is *one* descriptor,
not multiple ones as we had it, and we were allocating the same amount
of memory anyway, so we might as well do it all in one structure.
So now xhci_td does not have a fixed size of TRBs, but rather a dynamic
one, and thus also a dynamic number of buffers. As part of this refactor,
xhci_td is now a data structure for our own use only, and so it is allocated
from the normal heap instead of as physical memory, and TRBs separately.
* Removing the distinction between "descriptor" and "descriptor chain" greatly
simplifies quite a lot of logic related to transfer handling, especially
in WriteDescriptor and ReadDescriptor, which no longer need to handle
writing to buffers across xhci_td boundaries.
* There is now a proper split between "trb_count" and "trb_used". The former
is the actual number of TRBs allocated in the data structure; the latter
is the number presently used in said data structure. This clarifies
quite a lot of code.
As part of this refactor, a number of other related issues were also cleaned up:
* TRB buffer sizes are now hard-coded to be 4x the Max Packet Size for the
given pipe. Previously they were 64KB, which is much larger than the spec
suggests. As we now size them exactly this way, we can set the endpoint's
Average TRB Length to this value also, which allows the controller to
better schedule transfers for us. This logic can probably be cleaned up
further in the future, even.
* We now write the "TD Size" field of Normal transfers (i.e. packet count,
not TRB count) properly, as it is now much easier to compute based on
our new TRB sizing logic.
* We now record the Max Packet Size for the endpoint in the endpoint
structure. (This will probably be more useful when we are dealing
with isochronous transfers later on.)
* Write the last cycle bit in _LinkDescriptorForPipe after everything else
has been written. This probably does not affect anything too seriously,
but it is technically more correct.
* Added section & page references to the specification in various comments.
* Added more error checking where applicable.
Some things still to be done that I noticed while working on this change:
* When we use a single large buffer and manually segment it rather than
calling AllocateChunk() for each one, there is a massive performance
gain (I saw 50MB/s -> 95MB/s in testing on some USB devices.) However,
we can't do this unconditionally, as the stack doesn't allocate physical
chunks larger than 32 * B_PAGE_SIZE, which is a problem for some filesystems
which can read/write in chunks of 1MB. I'll implement this in a later commit.
* Setting the IOC bit on the last TRB in a transfer is acceptable to find
out when the transfer is finished, but it isn't enough to get a proper
tally of how much data was transfered. This is what Event Status TRBs
are for; we should implement them.
* _LinkDescriptorForPipe has an overflow condition. I'll fix that in the
next commit.
Tested on a ThinkPad E550 (Intel Broadwell) with usb_disk and usb_hid.
Previously we were sending the hardware completely garbage values,
as CreateDescriptorChain clobbered the trbCount value it had set
by using it to determine how many more TRBs it needed to allocate,
and so it usually returned with the value set to 0.
Then SubmitNormalRequest() would immediately subtract 1, causing it
to become negative, and the loop would continue doing this, which also
violated the spec's notice that the field should be 31 if its "true
value" was >= 31, and of course 0 for the last TRB in the transfer.
The spec also says this should be the number of packets remaining, not
the number of TRBs remaining, which we also do not obey; but that
will be a problem for another time, so just add a TODO.
This clears out the area_ids, the pointers to them, and a variety
of other state information that will be invalid following the
deletion of the device.
Turns #12929 from a use-after-free into a NULL dereference panic.
It was removed before because bold text rendering was partially
broken. Now that Terminal uses fractional widths for character
sizes, we can restore it by default.
This matches the behavior of virtually all Linux terminal emulators
(they also appear to make bold text brighter.)
Suggested by korli in #11019. We pass this struct directly to the
BIOS, so pack it while we are here.
Checked against GRUB (it also does not have this field.)
Change-Id: I9a2708c44ff48fd702175053f2889443d6f7a003
Reviewed-on: https://review.haiku-os.org/c/1145
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
These are simple structs, so hopefully GCC8 will be OK with us
memsetting them. We can't use the standard = {} route because
GCC2 does not support that.
Initialize each class members instead of memset()
for clearing PackageInfoAttributeValue.
Pointed out by gcc8.
Change-Id: I8bdb328e2271e49e840b1294dba9cca544805e72
Reviewed-on: https://review.haiku-os.org/c/1114
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
So that I can more easily import sparc headers from it.
NO_UNDERSCORES is gone and is now always the default.
Some previously arch-specific defines are now valid for all platforms.
Change-Id: If9876b241719559bdcb5cd9d8b1dc97e5e3d96b3
Reviewed-on: https://review.haiku-os.org/c/1141
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
