contiguous memory allocation problem

Hans Petter Selasky hselasky at c2i.net
Sun Jul 2 12:33:28 UTC 2006


On Sunday 02 July 2006 14:05, Ian Dowse wrote:
> In message <200607021138.11945.hselasky at c2i.net>, Hans Petter Selasky 
writes:
> >But there is one problem, that has been overlooked, and that is High speed
> >isochronous transfers, which are not supported by the existing USB system.
> > I don't think that the EHCI specification was designed for scatter and
> > gather, when you consider this:
> >
> >8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to
> > work, and I am right, one page has to contain two transfers. (see page 43
> > of ehci-r10.pdf)
>
> I haven't looked into the details, but the text in section 3.3.3
> seems to suggest that EHCI is designed to not require physically
> contiguous allocations here either, so the same approach of using
> bus_dmamap_load() should work:
>
>   This data structure requires the associated data buffer to be
>   contiguous (relative to virtual memory), but allows the physical
>   memory pages to be non-contiguous. Seven page pointers are provided
>   to support the expression of 8 isochronous transfers. The seven
>   pointers allow for 3 (transactions) * 1024 (maximum packet size)
>   * 8 (transaction records) (24576 bytes) to be moved with this
>   data structure, regardless of the alignment offset of the first
>   page.

3 * 1024 bytes = 0xC00 bytes

8 * 0xC00 = 0x6000 bytes maximum

According to this you need "6" "EHCI pages", because "6 * 0x1000 = 0x6000". 
The seventh "EHCI page" is just there to allow one to start at any page 
offset. There is no eight "EHCI page".

The only solution I see, is to have a double layer ITD. The first layer have 
the 4 first transfers activated, and the second layer have the 4 last 
transfers activated.

A little more complicated, but not impossible.

--HPS


More information about the freebsd-hackers mailing list