On 12/22/14 15:49, Ian Lepore wrote:
On Mon, 2014-12-22 at 10:48 +0100, Hans Petter Selasky wrote:
On 12/22/14 10:31, Kohji Okuno wrote:
In an optimisation, we should reduce the number of LINK_TRB, too.
I heard from a LSI engineer that,
Generally xhci controler has the cache of TRB array. But, LINK_TRB
may make the cache miss.
Hi,
One reason for the additional link TRB's is that I think there is
different behaviour among the XHCI implementations how and when they
generate a completion event. Any changes we make in that area needs to
be tested with different XHCI controllers.
Currently only the umass driver will use transfers greater than 64KBytes
in case of USB 3.0. Else the most common case is transfers below
64KBytes, except for custom apps.
I have another idea pending, which is related to performance, but not
the XHCI. I was thinking that the FreeBSD libusb could be extended to
allocate a data buffer in the kernel which then gets mmapped to
userspace, to save copying/copyout of USB transfer data. The problem
about mmap() is that the buffers cannot be freed afterwards, and must
remain in the kernel.
What do you think?
So you're going to be doing DMA directly in and out of buffers mapped
into userspace? I think that will fail on ARM and MIPS at least, and
maybe others (any platform that does cache maintenance based on virtual
addresses will be unable to do the maintenance reliably if the DMA
memory is mapped to multiple virtual addresses). The solution for that
is bounce buffers, which just gets you right back into copying the data.
-- Ian
Right, so there is no way to make coherent memory mappings into userspace?
--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
