Difference between revisions of "Unit DWCOTG"

This Host Controller Driver implements this interface asynchronously, as intended. Furthermore, it uses a simplistic scheduling algorithm where it places requests into a single queue and executes them in the order they were submitted. Transfers that need to be retried, including periodic transfers that receive a NAK reply and split transactions that receive a NYET reply when doing the Complete Split transaction, are scheduled to be retried at an appropriate time by separate code that shortcuts the main queue when the timer expires
Caller must hold the device lock

Caller must hold the device lock

milliseconds to wait before the next poll.
To actually implement delaying a transfer, we associate each transfer with a thread created on-demand. Each such thread simply enters a loop where it calls sleep() for the appropriate number of milliseconds, then retries the transfer. A semaphore is needed to make the thread do nothing until the request has actually been resubmitted.
This code gets used to scheduling polling of IN interrupt endpoints, including those on hubs and HID devices. Thus, polling of these devices for status changes (in the case of hubs) or new input (in the case of HID devices) is done in software. This wakes up the CPU a lot and wastes time and energy. But with USB 2.0, there is no way around this, other than by suspending the USB device which we don't support.

- The AHB configuration register contains a mask bit used to enable/disable all interrupts whatsoever from the DWC hardware.
- The "Core" interrupt and interrupt mask registers control top-level interrupts. For example, a single bit in these registers corresponds to all channel interrupts.
- The "Host All Channels" interrupt and interrupt mask registers control all interrupts on each channel.
- The "Channel" interrupt and interrupt mask registers, of which one copy exists for each channel, control individual interrupt types on that channel.
We can assume that an interrupt only occurs if it is enabled in all the places listed above. Furthermore, it only seems to work to clear interrupts at the lowest level; for example, a channel interrupt must be cleared in its individual channel interrupt register rather than in one of the higher level interrupt registers.
The above just covers the DWC-specific interrupt registers. In addition to those, the system will have other ways to control interrupts. For example, on the BCM2835 (Raspberry Pi), the interrupt line going to the DWC is just one of many dozen and can be enabled/disabled using the interrupt controller. In the code below we enable this interrupt line and register a handler function so that we can actually get interrupts from the DWC.
And all that's in addition to the CPSR of the ARM processor itself, or the equivalent on other CPUs. So all in all, you literally have to enable interrupts in 6 different places to get an interrupt when a USB transfer has completed

Can be called by the interrupt handler

Can be called by the interrupt handler

Can be called by the interrupt handler

This is a very simplistic scheduler that does not take into account bandwidth requirements or which endpoint a transfer is for

This thread also receives requests that need to be resubmitted and resubmits them for later processing by another thread
Message contents are as follows:
Msg = Request to be completed
wParam = Channel that the request executed on (or INVALID_HANDLE_VALUE if no channel was allocated)
lParam = Status of the channel interrupt

Once the request has been resubmitted the thread waits for the semaphore to be signaled again. If the request is a periodic polling of an endpoint then it will be resubmitted continuously at the predetermined interval, otherwise the semaphore will be destroyed by the completion handler and the thread will terminate

Caller must hold the host lock

Caller must hold the host lock