Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

How Windows driver will manage USB DMA transfer after submit URB?

Hi,

Currently, I'm developing a custom USB device driver for FX3 USB 3.0 peripheral controller for both Windows and Linux. I know the driver for both the OS of FX3 is available but the reason behind the development of these drivers is to develop a cross-platform library on top of this driver to interact with my USB device. The IOCTLs in the library is common for both OS which is custom IOCTLs.


Now question is,

One of the IOCTL I need to provide is DMA buffer set by passing size as IOCTL argument.

For Linux I can do it easily, there is a facility in Linux to Submit URB with pre-allocated DMA buffer information.

https://www.kernel.org/doc/html/v4.16/driver-api/usb/dma.html


For implementing similar IOCTL in Windows for USB DMA buffer, I didn't find any perfect documentation like in Linux. Even https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/usb/ns-usb-_urb URB struct doesn't have a feature like in case of Linux URB struct http://www.hep.by/gnu/kernel/usb/API-struct-urb.html


URB is the base of USB communication and after submitting URB it will be queued inside host controller and when schedule time comes inside host controller it will write or read bytes on specified EP. So at the hardware level of the USB host controller, both the OS should perform a similar role, isn't it?


I have also go through https://www.osronline.com/showthread.cfm?link=243802 but experts said in this thread that host controller will do DMA transfer for client driver itself in Windows.


How can I manage if Linux have feature to perform USB DMA transfer but in WIndows I can't.



Regards,
Bhoomil C.



************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *************************************************************************************************************************************************************

Comments

  • DMA is a property of the host controller, not your device. All data transfers in USB are done via DMA.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Hi Peter,
    Thanks for your reply.

    So you mean, whenever we fill _URB_BULK_OR_INTERRUPT_TRANSFER.TransferBuffer(buffer pointer) of struct _URB for read operation and then submit that URB to host controller. So after receive data from device it will 1st place at host controller's DMA buffer and then perform some memcpy to _URB_BULK_OR_INTERRUPT_TRANSFER.TransferBuffer ?

    Regards,
    Bhoomil C.
  • <quote>
    So after receive
    data from device it will 1st place at host controller's DMA buffer and then
    perform some memcpy to _URB_BULK_OR_INTERRUPT_TRANSFER.TransferBuffer
    </quote>

    It depends on several things, including the host controller and how the host controller driver is written. MOST host controller drivers will ensure that large DMA operations are done directly in to or out of the supplied user data buffer. However, there may be alignment or length requirements.

    In any case, there's nothing you can do about it. The host controller driver will do whatever it does, and it SHOULD be trusted to "do what's best."

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Posts: 12,619
    xxxxx@einfochips.com wrote:
    > So you mean, whenever we fill _URB_BULK_OR_INTERRUPT_TRANSFER.TransferBuffer(buffer pointer) of struct _URB for read operation and then submit that URB to host controller. So after receive data from device it will 1st place at host controller's DMA buffer and then perform some memcpy to _URB_BULK_OR_INTERRUPT_TRANSFER.TransferBuffer ?

    The host controllers do scatter/gather DMA (extensively).  The host
    controller driver will add the pages of your transfer to the host
    controller's work queue, and the host controller will transfer directly
    into the buffer.  Linux works similarly.  I think the only reason you're
    seeing "DMA" in Linux USB driver code is so the memory is locked down. 
    In Windows, that's generally been done for you by the time you see the IRP.

    By the way, in virtually every case, you don't actually need a driver at
    all.  Both Windows and Linux provide generic USB kernel drivers that let
    you do all of your transfers directly from user-mode code.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • @Peter Viscarola

    Thanks for your reply. It looks like Windows host controller driver and host controller hardware itself doing this things for me.
  • @Tim Roberts

    > ? Linux works similarly.? I think the only reason you're
    > seeing "DMA" in Linux USB driver code is so the memory is locked down.?
    > In Windows, that's generally been done for you by the time you see the IRP.

    As Peter and you said that USB Host controller hardware chip and device driver of HCD do it for me in both Windows and Linux. I don't know why Linux have this explicit APIs for USB DMA transfer.

    I Know OSROnline is the forum related to Windows Driver and FS related questions.
    But if it is possible then can you please elaborate on below link as part of comparison between Linux and Windows

    https://www.kernel.org/doc/html/v4.16/driver-api/usb/dma.html
  • Doron_HolanDoron_Holan Posts: 10,360
    It looks like the Linux side just exposes finer grain control over allocating and locking dma buffers. Windows does expose this level of granularity. From the doc page, my first guess is that most Linux usb drivers wouldn?t use this functionality...it is used when you identify a performance issue related to dma mapping.

    d

    Bent from my phone

    ________________________________
    From: 30131673600n behalf of
    Sent: Friday, August 3, 2018 10:35 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] How Windows driver will manage USB DMA transfer after submit URB?

    @Tim Roberts

    > ? Linux works similarly.? I think the only reason you're
    > seeing "DMA" in Linux USB driver code is so the memory is locked down.?
    > In Windows, that's generally been done for you by the time you see the IRP.

    As Peter and you said that USB Host controller hardware chip and device driver of HCD do it for me in both Windows and Linux. I don't know why Linux have this explicit APIs for USB DMA transfer.

    I Know OSROnline is the forum related to Windows Driver and FS related questions.
    But if it is possible then can you please elaborate on below link as part of comparison between Linux and Windows

    https://na01.safelinks.protection.outlook.com/?url=https://www.kernel.org/doc/html/v4.16/driver-api/usb/dma.html&amp;data=02|01|[email protected]|72ec5889d3a04a38949008d5f9cc0eb4|72f988bf86f141af91ab2d7cd011db47|1|0|636689577171082468&amp;sdata=fsT6w41albrUyYCN4NkPAC1f1oNNX6zBP5LvA+mEPrc=&amp;reserved=0




    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!