Since commit 760b3dffb0 ("qdl: Rework qdl_write to limit write sizes
to out_maxpktsize") outgoing transfers has been chunked into blocks of
wMaxPacketSize.
As reported by Wiktor Drewniak, Maksim Paimushkin, and Luca Weiss in [1]
there's huge benefits to be found in reverting this change, but out of
caution the limit was untouched.
With the transition to libusb, the throughput dropped another ~15% on my
machine. The numbers for HighSpeed and SuperSpeed are also in the same
ballpark.
With SuperSpeed, benchmarking of different chunk sizes in the megabyte
range shows improvement over these numbers in the range of 15-20x on the
same machine/board combination.
The bug report related to the reduction in size describes a host machine
running out of swiotlb, from the fact that we requested 1MB physically
contiguous memory. It's unclear if attempts was made to correct the
kernel's behavior. libusb does inquiry the capabilities of the kernel
and will split the buffer and submitting multiple URBs at once, as
needed. While no definitive guidance has been found, multiple sources
seems to recommend passing 1-2MB of buffer to libusb at a time. So,
let's move the default chunk size back up to 1MB and hope that libusb
resolves the reported problem.
Additionally, introduce a new option --out-chunk-size, which allow the
user to override the chunk size. This would allow any user to reduce the
size if needed, but also allow the value to be increased as needed.
[1] https://github.com/linux-msm/qdl/pull/39
Reported-by: Wiktor Drewniak
Reported-by: Maksim Paimushkin
Reported-by: Luca Weiss
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
The documentation for libusb_bulk_transfer() specifies that in the event
that the read or write request is split into multiple chunks, some of
these may still be transferred despite a LIBUSB_ERROR_TIMEOUT is
returned.
In the transition to libusb this detail was missed and completed
read transfers are sometimes considred to be timeouts and the data
discarded, obviously resulting in failure to continue.
Consider the "transferred" value in the event of timeout, to avoid this.
Although not yet spotted in testing, the same logic is introduced for
the write path.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
In the event that the kernel have some other driver attached to the
device the attempt claim of the interface will fail.
Lost in the libusb conversion was a call to USBDEVFS_DISCONNECT to first
detach any such drivers. Reintroduce this by invoking
libusb_detach_kernel_driver().
As with some other libusb functions there are multiple return values
denoting "success", so rely on libusb_claim_interface() to catch the
actual errors.
Reported-by: Maxim Akristiniy
Suggested-by: Maxim Akristiniy
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
libusb commit f0cce43f882d ("core: Fix definition and use of enum
libusb_transfer_type") split the types of split transfer type and
endpoint transfer, introducing LIBUSB_ENDPOINT_TRANSFER_TYPE_BULK.
The result is that when building with older libusb, such the one
available on Ubuntu 20.04 the build fails with the following error:
usb.c:84:16: error: ‘LIBUSB_ENDPOINT_TRANSFER_TYPE_BULK’ undeclared (first use in this function); did you mean ‘LIBUSB_TRANSFER_TYPE_BULK’?
Introduce an alias using the preprocessor to make available the new
define when building against the older version of libusb headers.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
When working on a host with multiple boards attached being able to
select a specific board by serial number becomes necessary.
In the EDL USB descriptors a device serial number is available as part
of the iProduct string, so this can be used for comparison.
As libusb requires a handle the libusb_open() needs to be moved into the
loop.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
In order to support selecting board based on serial number the iProduct
field needs to be inspected, with the hand-rolled parsing of the USB
descriptors this becomes cumbersome.
Furthermore the direct use of Linux's USBDEVFS creats an unnecessary
dependency on the host OS being Linux.
It's unclear why libusb wasn't choosen in the first place, perhaps it
relates to the faint memory of 0.1 vs 1.0 packaging issues?
Move to libusb-1.0 in order to resolve these issues, as well as clean up
the code a bit.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Expose the newly introduce Sahara implementation for ramdump support to
the user, by introducing the qdl-ramdump utility.
The -o option can be used to specify the output directory, where files
will be stored.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
In preparation for the introduction of a new ramdump utility, extract
out the USB functions.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
