How to Enable DMA Transfer Mode on IDE DEVICE via USB ADAPTER/USBS

Discussion in 'Windows Vista Drivers' started by docjay, Jan 1, 2005.

  1. docjay

    docjay Guest

    I have an IDE device that works fine on a PCI IDE controller, and transfers
    at a high rate (ULTRA-DMA MODES).

    However, when I use it with a USB=>IDE adapter card, it slows down to PIO
    MODE (which I have verified with a scope). I know that with the PCI IDE
    adapter I had to go into the control panel to enable DMA Modes.

    There does not seem to be any such option in the USBSTOR device.

    If I attach a hard disk to the USB=>IDE adapter it goes at fast ata modes
    (better than 20 mbytes / second). I am using USB2.0.

    How can I enable DMA modes for an ultra-ata capable device via the USBSTOR
    interface? I have written a function (class) driver for my device, but still
    cannot find an API in the ddk or in the user application to enable dma modes
    (on SCSI_PASS_THROUGH operations).
     
    docjay, Jan 1, 2005
    #1
    1. Advertisements

  2. docjay

    Phil Barila Guest

    It would be a surprise if it didn't.
    Does the bridge attempt to set the DMA mode on the device?
    USBStor speaks CDB. It knows nothing of ATA, unless the bridge provides a
    vendor unique form of ATA translation.
    Are saying that the bridge translates the normal read/write commands to
    READ/WRITE SECTORS or READ/WRITE MULTIPLE? The opcode written into the
    command register determines the transfer mode.
    SCSI_PASS_THROUGH doesn't know anything about ATA transfer modes. The USB
    bridge is responsible for choosing the ATA opcode, which determines the
    transfer mode.

    Phil
    --
    Philip D. Barila Windows DDK MVP
    Seagate Technology LLC
    (720) 684-1842
    As if I need to say it: Not speaking for Seagate.
    E-mail address is pointed at a domain squatter. Use reply-to instead.
     
    Phil Barila, Jan 2, 2005
    #2
    1. Advertisements

  3. How can I enable DMA modes for an ultra-ata capable device via the USBSTOR
    No, just choose another USB-to-IDE adapter.
     
    Maxim S. Shatskih, Jan 2, 2005
    #3
  4. docjay

    docjay2003 Guest

    Thanks for the reply. In answer to your comments:

    A) I am certain that the device supports Ultra DMA transfers. I am the
    manufacturer and it definitely works in ultra modes on standard IDE devices.

    B) Does the bridge attempt to set the mode to ultra dma? APPARENTLY NOT,
    since it isnt doing dma transfers. The key question is HOW CAN I ASK THE
    BRIDGE to set the mode to ULTRA DMA?

    I have attached a standard hard disk to the bridge and it is clearly in
    ultra dma mode.

    I do not issue disk read or disk write to my device. It is NOT a disk. I
    do issue ATAPI packets to the device, via SCSI_PASS_ThROUGH. And for some
    odd reason the drivers involved do not want to enter dma mode.

    ON AN IDE controller, there is an option in the control panel to allow /
    disallow DMA mode for master and slave devices. There does not appear to be
    any such option for the usb bridge (USBSTOR), which is provided by microsoft,
    and which appears to be undocumented on its interface!!!

    Any other suggestions would be appreciated.
     
    docjay2003, Jan 2, 2005
    #4
  5. docjay

    docjay2003 Guest

    Thanks for the message, I can try another device, but doubt that this will
    help because I believe the problem is in the microsoft driver stack. After
    all, a hard disk on a standard PCI based ide controller by default tries dma
    modes (without having to enable the ultra dma options in the control panel),
    and a hard disk attached to this usb adapter goes into ultradma modes also.
    So it seems like microsoft just failed to expose the dma options for the
    usbstor driver.
     
    docjay2003, Jan 2, 2005
    #5
  6. docjay

    docjay2003 Guest

    Phil, as far as the bridge talking CDB language. That makes sense. If only
    microsoft documented the data structure to send a CDB, perhaps I could
    generate an IRP in my function driver to send a CDB to the device directly?

    The scsi_pass_through structure does not include any way to specify the
    transfer mode (or the registers for the transfer (to select dma versus pio
    modes)).

    Does anyone know if there is a definition of the IRPs that I can send to
    USBSTOR or to an ide device in general. Is there any documentation on
    microsofts interface.
     
    docjay2003, Jan 2, 2005
    #6
  7. docjay

    docjay2003 Guest

    Phil, as far as the bridge talking CDB language. That makes sense. If only
    microsoft documented the data structure to send a CDB, perhaps I could
    generate an IRP in my function driver to send a CDB to the device directly?

    The scsi_pass_through structure does not include any way to specify the
    transfer mode (or the registers for the transfer (to select dma versus pio
    modes)).

    Does anyone know if there is a definition of the IRPs that I can send to
    USBSTOR or to an ide device in general. Is there any documentation on
    microsofts interface.

    I am aware of an IDE_PASS_THROUGH ioctl which I dicussed with Microsoft
    several years ago, and they pretty much said that it did not work.
     
    docjay2003, Jan 2, 2005
    #7
  8. any such option for the usb bridge (USBSTOR), which is provided by microsoft,
    USB bridge is not provided by Microsoft, but by some vendor, usually Chinese.

    USBSTOR protocol knows nothing on PIO/DMA modes, so, the bridge must always
    choose the best drive's mode automatically. If it does not do this - it is
    broken.
     
    Maxim S. Shatskih, Jan 2, 2005
    #8
  9. Thanks for the message, I can try another device, but doubt that this will
    No. Microsoft driver stack follows the USB Storage Spec very closely, and this
    spec knows nothing on IDE-only things like PIO or DMA.

    Sorry. The bridge vendor must make this choice itself and no help from USB side
    can be provided to it.

    ATA passthrough over SCSI CDBs is not documented and thus not supported.

    P.S. Sarotech is a good bridge. Hard drive running fast when being placed there
    :)
    Ahhh! So the disk works in DMA and works fine?

    Then sorry. USB storage has no notions of "PIO" and "DMA". Neither is SCSI
    storage.

    For Microsoft to display this, there must be:
    a) a mapping of IDE PIO/DMA modes to SCSI CDBs - like some MODE SENSE or so.
    b) USBSTOR protocol must support this MODE SENSE.

    The main problem is for sure a). It must be stardatized by some body (T13
    probably or T10). There are some efforts on this, but sorry, they are not
    complete.

    Without these efforts, the USB->IDE bridge has 100% no means or reporting to
    host whether the drive is in DMA mode or not. No standard describe this.

    Microsoft has these setting for drives connected to usual stupid on-mobo IDE
    controllers only. I have doubts that even software RAIDs like HighPoint (which
    look SCSI for the OS) will allow you to set this. Probably the RAID-provided
    tool will allow this.

    Anyway forget this stuff. The DMA mode must be chosen by the PHY layer of the
    controller based on IDENTIFY data and cabling. No need for any software to
    meddle into it.

    I think SATA has no more PIO/DMA modes. That's good.
     
    Maxim S. Shatskih, Jan 2, 2005
    #9
  10. docjay

    docjay2003 Guest

    Thanks for the messages. I will try another bridge. But even if they all
    behave the same way I think you are right that the problem is in the bridge
    and I think you have answered my questions.

    Great
     
    docjay2003, Jan 3, 2005
    #10
  11. docjay

    Phil Barila Guest

    devices.

    You don't appear to have a very thorough understanding of the ATA spec to be
    manufacturing ATAPI devices.
    You CAN'T. The bridge will or won't do it depending on what the URB
    includes. The bridge selects DMA or PIO through BIT 0 of the Feature
    register. You have very little control over whether the bridge sets this
    bit from the host. You ***MAY*** have some control based on what you report
    in your response to IDENTIFY PACKET DEVICE.
    That's because the bridge understands an ATA (disk) device very well.
    It's not very odd at all. The SCSI_PASS_THROUGH packages up a CDB, the
    USBPORT driver stuffs it into a URB and sends it down to the USB device.
    That device sets up the ATAPI device for a packet, then puts the CDB on it.
    It has no requirement to ever set the DMA bit in the feature register.
    Yes, because the ATAPI.sys driver can set up the DMA directly. The USBPORT
    has little or no knowledge of the USB bridge to set it up for DMA on PACKET
    commands.

    Phil
    --
    Philip D. Barila Windows DDK MVP
    Seagate Technology LLC
    (720) 684-1842
    As if I need to say it: Not speaking for Seagate.
    E-mail address is pointed at a domain squatter. Use reply-to instead.
     
    Phil Barila, Jan 6, 2005
    #11
  12. docjay

    Phil Barila Guest

    directly?

    What kind of function driver are you writing? Is your device compliant with
    a SCSI device specification?
    There's no way for the USBPORT to enforce that.
    It's not Microsoft's interface, it's your device and the bridge. So I'll
    repeat my question from above, what is your device? Is there a SCSI spec
    that defines what one of those should be?
    You have an ATAPI device, which takes CDBs, not ATA task files. IDE or ATA
    command transports won't do you any good. But they only work on ATA HBAs,
    anyway. The USB bus driver could implement one, but it would need help from
    the bridge in the form of a CDB that describes the task file, but that's
    vendor-unique for now, and as I just noted, won't help you, anyway.

    Phil
    --
    Philip D. Barila Windows DDK MVP
    Seagate Technology LLC
    (720) 684-1842
    As if I need to say it: Not speaking for Seagate.
    E-mail address is pointed at a domain squatter. Use reply-to instead.
     
    Phil Barila, Jan 6, 2005
    #12
  13. docjay

    docjay2003 Guest

    Thanks for the feedback. You have been helpful.

    As far as our understanding of ATAPI goes, perhaps you are right. We based
    our design on the ATA-ATAPI-5 specification standard. WE WERE DISAPPOINTED
    that Microsoft did not seem to be following the specification but had to
    accept and work around what they were doing. NOWHERE in the atapi-5
    specification does it say that a device must implement any SPECIFIC packet
    commands (like mode and request sense), and our identify-packet-device
    response indicates that we are not a device with a standard packet set. The
    SCSI_PASS_THROUGH SHOULD HAVE passed our packets throught directly AND THE
    OPERATING SYSTEM SHOULD NEVER HAVE issued any of these pseudo-standard
    packets like mode-sense. Yet microsoft modifies the packets, wiping out the
    byte where the logical unit number is typically present and sending packets
    which we do not claim to support !!!

    It would have been nice if Microsoft had CORRECTLY implemented the ATAPI
    spec. Did you know that they do NOT get the device name (for plug and play
    purposes) from the IDENTIFY PACKET COMMAND structure!!!, but rather from a
    non-standard SCSI packet command. WOW.

    Any way, enought ranting and raving, thanks for your help.
     
    docjay2003, Jan 6, 2005
    #13
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.