Has anybody done any USB 3.0 work yet? USB 3.0 introduces the concept
of multiple “streams” on a bulk endpoint. Conceptually, this basically
allows a single bulk endpoint to support tens of thousands of pipes at
once, each of which is addressed and transferred separately. I’m
wondering how this is likely to be implemented. Stream number as
another field in the BULK_OR_INTERRUPT_TRANSFER URB?
Since we don’t have any public guidance from Microsoft, as far as I am
aware, the XHCI manufacturers must have invented their own structures.
I’m curious as to what they have invented.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
No specs yet from usb.org?
Mark Roddy
On Fri, Jul 23, 2010 at 2:19 PM, Tim Roberts wrote:
> Has anybody done any USB 3.0 work yet? USB 3.0 introduces the concept
> of multiple “streams” on a bulk endpoint. Conceptually, this basically
> allows a single bulk endpoint to support tens of thousands of pipes at
> once, each of which is addressed and transferred separately. I’m
> wondering how this is likely to be implemented. Stream number as
> another field in the BULK_OR_INTERRUPT_TRANSFER URB?
>
> Since we don’t have any public guidance from Microsoft, as far as I am
> aware, the XHCI manufacturers must have invented their own structures.
> I’m curious as to what they have invented.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
On 7/25/2010 2:00 AM, Mark Roddy wrote:
No specs yet from usb.org http:?
Mark, URBs are the OS way of handling USB requests. As it is out of
their scope, usb.org does not specify any OS-internal API for USB.
At WinHEC 2008, Microsoft announced support for xHCI (USB3), so I assume
they will eventually extend the API for USB3. Until then we will likely
have to live with several USB chip vendor specific implementations. :-(</http:>