About XHCI_TD_PAGE_SIZE.

[Hans Petter Selasky]

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