Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Dec 2014 10:31:47 +0100
From:      Hans Petter Selasky <hps@selasky.org>
To:        Ian Lepore <ian@freebsd.org>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: About XHCI_TD_PAGE_SIZE.
Message-ID:  <54993683.7010901@selasky.org>
In-Reply-To: <1419259745.1018.113.camel@freebsd.org>
References:  <549541BC.6070505@selasky.org>		<20141222.103833.2105768702793613386.okuno.kohji@jp.panasonic.com>		<5497E016.7020809@selasky.org>	 <20141222.183157.253796126986510571.okuno.kohji@jp.panasonic.com>	 <5497E8F2.5080800@selasky.org> <1419259745.1018.113.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54993683.7010901>