This question is regarding the 5-Series Chipset Platform Controller Hub (PCH), although I suspect the same answer would apply to the 7-, 8-, and 100-Series chipsets as well. The datasheet for the 5-Series Chipset is here:
Section 5.18 describes the USB EHCI Host Controller; Section 5.18.3 describes the priority order that the PCH USB 2.0 Enhanced Host Controller (EHC) uses for processing USB Transfer Descriptors (TDs):
1.The USB 2.0 Debug Port (see Section USB 2.0 Based Debug Port),
2.The Periodic DMA engine, and
3.The Asynchronous DMA engine.
My question is specifically related to the 3rd option there, the Asynchronous DMA engine dedicated to Control and Bulk transfers. Once the Periodic transfers have been processed, any remaining time in the 125us microframe is dedicated to the Asynchronous transfers.
If an Asynchronous transfer from the USB Host is NAK'ed by the downstream USB Device, the associated Transfer Descriptor remains in the Asynchronous DMA Schedule.
Assume there are no Debug or Periodic USB transfers. The particular case I am concerned with is where there is a single Function-to-Host (IN) Transfer Descriptor in the Asynchronous Schedule. If the targeted USB Device takes some time to build the appropriate DATA response, it will NAK the received IN packets (which will remain in the Asynchronous Schedule).
1) Will the NAK'ed IN packet in the Asynchronous Schedule be retried immediately during the same microframe, using the min Inter Packet Delay from the USB spec (or something close to that) to determine when to resend the next IN packet to the USB Device?
2) Is there some way to program the 5-Series PCH or a Queue Head or Transfer Descriptor setting that would cause the next retry of the IN packet to occur in the next microframe (~120us later) or in the next Frame (~1ms later)? This would give the USB Device more time to build its response before having to service the IN packet again.
Thank you,
Mike