Multi-TRB xhci transfers should use event data
While testing, we discovered that QEMU has an odd peculiarity where it doesn't honor a series of chained TRBs with some set with interrupt on short and the final entry set to generate an interrupt on completion. Instead, we should refactor things such that when we have a multi-trb transfer in a single TD we instead use event data to be notified of the completion. The use of event data also has the benefit of always telling us the exact amount of data that was transferred. This means we don't have to count and add up the residual bytes along the way.
At this time, only bulk transfers use multiple TRBs. Therefore this only applies to them. However, as we later go through and change how things are mapped, we should come back and apply this to other transfer types rather than the existing games.
As a side effect of this, we no longer set interrupt on short packet (ISP) on most blocks. As items that have interrupt on completion (IOC), will still always get the short packet. This is done mostly to simplify and make the few cases where we need ISP in control transfers much more obvious.
To test this change, I did the following:
- Tested plugging in USB keyboards and verifying that we saw them.
- Tested an audio class device and successfully played an mp3 converted to a .au file out, thus testing isochronous transfers.
- Tested bulk transfers by creating a ZFS file system on a device and then using dd to create several different streams from /dev/urandom to the device. While that was being done, we eventually scrubbed while in progress and at the end to verify that all the data was correct. This was how we were able to discover 9818.
This change and 9817 were also tested by Alex Wilson in Linux KVM which is how we discovered several of these problems to begin with. With this in place, the bulk CCID transfers that he was making were verified.
As part of evaluating whether or not this made sense, we did some research to see who else was using the event data systems. Most notably, it is highly suggested that Microsoft does use them. This is a major consideration as we don't want to be the only ones using an esoteric hardware feature.