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