Difference between revisions of "Unit DWCOTG"
Line 7: | Line 7: | ||
'''USB Host Controller Driver for the Synopsys DesignWare Hi-Speed USB 2.0 On-The-Go Controller unit''' | '''USB Host Controller Driver for the Synopsys DesignWare Hi-Speed USB 2.0 On-The-Go Controller unit''' | ||
− | This is a USB Host Controller Driver (HCD) that interfaces with the Synopsys DesignWare Hi-Speed USB 2.0 On-The-Go Controller, henceforth abbreviated as "DWC". | + | This is a USB Host Controller Driver (HCD) that interfaces with the Synopsys DesignWare Hi-Speed USB 2.0 On-The-Go Controller, henceforth abbreviated as "DWC". This is the USB Host Controller used on the BCM2835 SoC used on the Raspberry Pi. |
Please note that there is no publicly available official documentation for this particular piece of hardware, and it uses its own custom host controller interface rather than a standard one such as EHCI. Therefore, this driver was written on a best-effort basis using several sources to glean the necessary hardware details, including the extremely complicated and difficult to understand vendor provided Linux driver. | Please note that there is no publicly available official documentation for this particular piece of hardware, and it uses its own custom host controller interface rather than a standard one such as EHCI. Therefore, this driver was written on a best-effort basis using several sources to glean the necessary hardware details, including the extremely complicated and difficult to understand vendor provided Linux driver. | ||
Line 1,229: | Line 1,229: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,244: | Line 1,244: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| See usb.pas for the documentation of this interface of the Host Controller Driver | | See usb.pas for the documentation of this interface of the Host Controller Driver | ||
|- | |- | ||
Line 1,256: | Line 1,256: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| See usb.pas for the documentation of this interface of the Host Controller Driver | | See usb.pas for the documentation of this interface of the Host Controller Driver | ||
|- | |- | ||
Line 1,268: | Line 1,268: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,280: | Line 1,280: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,292: | Line 1,292: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| See usb.pas for the documentation of this interface of the Host Controller Driver | | See usb.pas for the documentation of this interface of the Host Controller Driver | ||
− | 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. | + | 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. |
<br />Caller must hold the device lock. | <br />Caller must hold the device lock. | ||
|- | |- | ||
Line 1,309: | Line 1,309: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| See usb.pas for the documentation of this interface of the Host Controller Driver | | See usb.pas for the documentation of this interface of the Host Controller Driver | ||
Caller must hold the device lock | Caller must hold the device lock | ||
Line 1,325: | Line 1,325: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Request |
| USB transfer to resubmit | | USB transfer to resubmit | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| For periodic transfers (e.g. polling an interrupt endpoint), the exact time at which the transfer must be retried is specified by the bInterval member of the endpoint descriptor. For low and full-speed devices, bInterval specifies the number of millisconds to wait before the next poll, while for high-speed devices it specifies the exponent (plus one) of a power-of-two number of milliseconds to wait before the next poll. | | For periodic transfers (e.g. polling an interrupt endpoint), the exact time at which the transfer must be retried is specified by the bInterval member of the endpoint descriptor. For low and full-speed devices, bInterval specifies the number of millisconds to wait before the next poll, while for high-speed devices it specifies the exponent (plus one) of a power-of-two number of 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. | + | 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. |
<br />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. | <br />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. | ||
|- | |- | ||
Line 1,345: | Line 1,345: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host to power on | | The DWCOTG host to power on | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
Line 1,360: | Line 1,360: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host to power off | | The DWCOTG host to power off | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
Line 1,375: | Line 1,375: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
Line 1,387: | Line 1,387: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
Line 1,399: | Line 1,399: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,411: | Line 1,411: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,423: | Line 1,423: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| The DWC contains several levels of interrupt registers, detailed in the following list. Note that for each level, each bit of the "interrupt" register contains the state of a pending interrupt (1 means interrupt pending; write 1 to clear), while the "interrupt mask" register has the same format but is used to turn the corresponding interrupt on or off (1 means on; write 1 to turn on; write 0 to turn off). | | The DWC contains several levels of interrupt registers, detailed in the following list. Note that for each level, each bit of the "interrupt" register contains the state of a pending interrupt (1 means interrupt pending; write 1 to clear), while the "interrupt mask" register has the same format but is used to turn the corresponding interrupt on or off (1 means on; write 1 to turn on; write 0 to turn off). | ||
- The AHB configuration register contains a mask bit used to enable/disable all interrupts whatsoever from the DWC hardware. | - The AHB configuration register contains a mask bit used to enable/disable all interrupts whatsoever from the DWC hardware. | ||
Line 1,429: | Line 1,429: | ||
<br />- The "Host All Channels" interrupt and interrupt mask registers control all interrupts on each channel. | <br />- The "Host All Channels" interrupt and interrupt mask registers control all interrupts on each channel. | ||
<br />- The "Channel" interrupt and interrupt mask registers, of which one copy exists for each channel, control individual interrupt types on that channel. | <br />- The "Channel" interrupt and interrupt mask registers, of which one copy exists for each channel, control individual interrupt types on that channel. | ||
− | <br />We can assume that an interrupt only occurs if it is enabled in all the places listed above. | + | <br />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. |
<br />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. | <br />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. | ||
<br />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 | <br />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 | ||
Line 1,442: | Line 1,442: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,454: | Line 1,454: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host to get available channel from | | The DWC host to get available channel from | ||
|- | |- | ||
− | ! | + | ! Return |
| Channel number of the next available channel | | Channel number of the next available channel | ||
|- | |- | ||
Line 1,469: | Line 1,469: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host to mark available channel on | | The DWC host to mark available channel on | ||
|- | |- | ||
− | ! | + | ! Channel |
| The channel number to mark as available | | The channel number to mark as available | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
Line 1,487: | Line 1,487: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host to start the request on | | The DWC host to start the request on | ||
|- | |- | ||
− | ! | + | ! Channel |
| The channel number to start the request on | | The channel number to start the request on | ||
|- | |- | ||
− | ! | + | ! Request |
| USB request to start | | USB request to start | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the host lock | | Caller must hold the host lock | ||
Can be called by the interrupt handler | Can be called by the interrupt handler | ||
Line 1,509: | Line 1,509: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host to start the transaction on | | The DWC host to start the transaction on | ||
|- | |- | ||
− | ! | + | ! Channel |
| The host channel number to start the transaction on | | The host channel number to start the transaction on | ||
|- | |- | ||
− | ! | + | ! Request |
| USB request set up for the next transaction | | USB request set up for the next transaction | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the host lock | | Caller must hold the host lock | ||
Can be called by the interrupt handler | Can be called by the interrupt handler | ||
Line 1,531: | Line 1,531: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,543: | Line 1,543: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,555: | Line 1,555: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,567: | Line 1,567: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,579: | Line 1,579: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,591: | Line 1,591: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host for the change request | | The DWCOTG host for the change request | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
Can be called by the interrupt handler | Can be called by the interrupt handler | ||
Line 1,607: | Line 1,607: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host for the request | | The DWCOTG host for the request | ||
|- | |- | ||
− | ! | + | ! Request |
| The USB request to perform | | The USB request to perform | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,628: | Line 1,628: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host for the request | | The DWCOTG host for the request | ||
|- | |- | ||
− | ! | + | ! Request |
| The USB request to perform | | The USB request to perform | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,649: | Line 1,649: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host for the request | | The DWCOTG host for the request | ||
|- | |- | ||
− | ! | + | ! Request |
| Hub specific request to the root hub | | Hub specific request to the root hub | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,670: | Line 1,670: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host for the request | | The DWCOTG host for the request | ||
|- | |- | ||
− | ! | + | ! Request |
| Standard request to the root hub | | Standard request to the root hub | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| Caller must hold the Host lock | | Caller must hold the Host lock | ||
|- | |- | ||
Line 1,691: | Line 1,691: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,703: | Line 1,703: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| USB host to service submitted requests for | | USB host to service submitted requests for | ||
|- | |- | ||
− | ! | + | ! Note |
| This thread receives requests that have been submitted and schedules them on the next available channel. | | This thread receives requests that have been submitted and schedules them on the next available channel. | ||
This is a very simplistic scheduler that does not take into account bandwidth requirements or which endpoint a transfer is for. | This is a very simplistic scheduler that does not take into account bandwidth requirements or which endpoint a transfer is for. | ||
Line 1,719: | Line 1,719: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| USB host to service completed requests for | | USB host to service completed requests for | ||
|- | |- | ||
− | ! | + | ! Note |
| This thread receives completed requests which have either succeeded or failed and calls the completion handler which will call the registered callback for the request. | | This thread receives completed requests which have either succeeded or failed and calls the completion handler which will call the registered callback for the request. | ||
This thread also receives requests that need to be resubmitted and resubmits them for later processing by another thread. | This thread also receives requests that need to be resubmitted and resubmits them for later processing by another thread. | ||
Line 1,739: | Line 1,739: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Request |
| USB request to resubmit | | USB request to resubmit | ||
|- | |- | ||
− | ! | + | ! Note |
| An instance of this thread is created for each request that needs to be resubmitted, this thread then either waits for a predetermined number of milliseconds before scheduling the request on the next available channel. | | An instance of this thread is created for each request that needs to be resubmitted, this thread then either waits for a predetermined number of milliseconds before scheduling the request on the next available channel. | ||
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. | 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. | ||
Line 1,755: | Line 1,755: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host where the interrupt occurred | | The DWC host where the interrupt occurred | ||
|- | |- | ||
Line 1,767: | Line 1,767: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host where the interrupt occurred | | The DWC host where the interrupt occurred | ||
|- | |- | ||
− | ! | + | ! Channel |
| DWC host channel where the channel interrupt occurred | | DWC host channel where the channel interrupt occurred | ||
|- | |- | ||
− | ! | + | ! Return |
| USB_STATUS_SUCCESS if completed or another error code on failure | | USB_STATUS_SUCCESS if completed or another error code on failure | ||
|- | |- | ||
− | ! | + | ! Note |
| Only called by DWCInterruptHandler | | Only called by DWCInterruptHandler | ||
Caller must hold the host lock | Caller must hold the host lock | ||
Line 1,789: | Line 1,789: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Request |
| The USB request currently scheduled on this channel | | The USB request currently scheduled on this channel | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWC host where the interrupt occurred | | The DWC host where the interrupt occurred | ||
|- | |- | ||
− | ! | + | ! Channel |
| DWC host channel where the channel interrupt occurred | | DWC host channel where the channel interrupt occurred | ||
|- | |- | ||
− | ! | + | ! Interrupts |
| The currently pending interrupts on this channel | | The currently pending interrupts on this channel | ||
|- | |- | ||
− | ! | + | ! Note |
| Only called by DWCChannelInterrupt | | Only called by DWCChannelInterrupt | ||
Caller must hold the host lock | Caller must hold the host lock | ||
Line 1,817: | Line 1,817: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Note |
| None documented | | None documented | ||
|- | |- | ||
Line 1,829: | Line 1,829: | ||
{| class="wikitable" style="font-size: 14px; background: white;" | {| class="wikitable" style="font-size: 14px; background: white;" | ||
|- | |- | ||
− | ! | + | ! Host |
| The DWCOTG host to calculate the interval for | | The DWCOTG host to calculate the interval for | ||
|- | |- | ||
− | ! | + | ! Note |
| The host frame interval register can only be modified when the port enabled bit is set in the host port control and status register | | The host frame interval register can only be modified when the port enabled bit is set in the host port control and status register | ||
Caller must hold the Host lock | Caller must hold the Host lock |
Revision as of 00:29, 24 April 2018
Return to Unit Reference
Contents
[hide]Description
USB Host Controller Driver for the Synopsys DesignWare Hi-Speed USB 2.0 On-The-Go Controller unit
This is a USB Host Controller Driver (HCD) that interfaces with the Synopsys DesignWare Hi-Speed USB 2.0 On-The-Go Controller, henceforth abbreviated as "DWC". This is the USB Host Controller used on the BCM2835 SoC used on the Raspberry Pi.
Please note that there is no publicly available official documentation for this particular piece of hardware, and it uses its own custom host controller interface rather than a standard one such as EHCI. Therefore, this driver was written on a best-effort basis using several sources to glean the necessary hardware details, including the extremely complicated and difficult to understand vendor provided Linux driver.
This file implements the Host Controller Driver Interface defined in TUSBHost. Most importantly, it implements a function to power on and start the host controller (HostStart) and a function to send and receive messages over the USB (HostSubmit).
The DWC is controlled by reading and writing to/from memory-mapped registers. The most important registers are the host channel registers. On this particular hardware, a "host channel", or simply "channel", is a set of registers to which software can read and write to cause transactions to take place on the USB. A fixed number of host channels exist, on the Raspberry Pi there are 8. From the software's perspective, transactions using different host channels can be executed at the same time.
Some of the host channel registers, as well as other registers, deal with interrupts. This driver makes heavy use of these and performs all USB transfers in an interrupt-driven manner. However, due to design flaws in this hardware and in USB 2.0 itself, "interrupt" and "isochronous" transfers still need to make use of software polling when checking for new data, even though each individual transfer is itself interrupt-driven. This means that, for example, if your USB mouse specifies a polling rate of 100 times per second, then it will, unfortunately, be polled 100 times per second in software. For more detail about how interrupts can be controlled on this particular hardware, see the comment above DWCSetupInterrupts. Another important concept is the idea of "packets", "transactions", and "transfers". A USB transfer, such as a single control message or bulk request, may need to be split into multiple packets if it exceeds the endpoint's maximum packet size. Unfortunately, this has to be dealt with explicitly in this code, as this hardware doesn't do it for us. But at least, from the viewpoint of this software, a "transaction" is essentially the same as a "packet".
The "On-The-Go" in the name of this hardware means that it supports the USB On-The-Go protocol, which allows it to act either as a host or a device. However, we only are concerned with it acting as a host, which simplifies our driver.
To simplify the USB core software, a useful design technique (as recommended by the USB 2.0 standard and used in other implementations such as Linux's) is to have the HCD present the root hub as a standard USB hub, even if the root hub is integrated with the host controller and does not appear as a standard hub at the hardware level. This is the case with the DWC, and we implement this design. Therefore, some code in this file deals with faking requests sent to the root hub.
Constants
DWC_*
DWC_USB_PID_*
DWC_RECEIVE_*
DWC_STATUS_*
DWC_COMPLETE_SPLIT_*
DWC_OTG_CTRL_*
DWC_AHB_*
DWC_USB_CFG_*
DWC_SOFT_RESET*
DWC_CORE_INTERRUPTS_*
DWC_VENDOR_ID_*
DWC_HWCFG2_*
DWC_HFIR_*
DWC_HFNUM_*
DWC_HOST_PORT_CTRLSTATUS_*
DWC_HOST_CHANNEL_CHARACTERISTICS_*
DWC_HOST_CHANNEL_SPLIT_CONTROL_*
DWC_HOST_CHANNEL_INTERRUPTS_*
DWC_HOST_CHANNEL_INTERRUPT_MASK_*
DWC_HOST_CHANNEL_TRANSFER_*
Type definitions
DWC host channel
DWC registers
DWC root hub configuration
PDWCRootHubConfiguration = ^TDWCRootHubConfiguration;
TDWCRootHubConfiguration = packed record
DWC USB transfer
DWC USB host
Public variables
None defined
Function declarations
Initialization functions
DWCOTG functions
function DWCHostStart(Host:PUSBHost):LongWord;
function DWCHostStop(Host:PUSBHost):LongWord;
function DWCHostReset(Host:PUSBHost):LongWord;
function DWCHostResetEx(Host:PDWCUSBHost):LongWord;
function DWCHostSubmit(Host:PUSBHost; Request:PUSBRequest):LongWord;
function DWCHostCancel(Host:PUSBHost; Request:PUSBRequest):LongWord;
function DWCHostResubmit(Host:PDWCUSBHost; Request:PUSBRequest):LongWord;
function DWCHostPowerOn(Host:PDWCUSBHost):LongWord;
function DWCHostPowerOff(Host:PDWCUSBHost):LongWord;
function DWCHostCheck(Host:PDWCUSBHost):LongWord;
function DWCHostInit(Host:PDWCUSBHost):LongWord;
function DWCHostSetup(Host:PDWCUSBHost):LongWord;
function DWCHostSetupDMA(Host:PDWCUSBHost):LongWord;
function DWCHostSetupInterrupts(Host:PDWCUSBHost):LongWord;
function DWCHostStartFrameInterrupt(Host:PDWCUSBHost; Enable:Boolean):LongWord;
function DWCAllocateChannel(Host:PDWCUSBHost):LongWord;
function DWCReleaseChannel(Host:PDWCUSBHost; Channel:LongWord):LongWord;
function DWCChannelStartTransfer(Host:PDWCUSBHost; Channel:LongWord; Request:PUSBRequest):LongWord;
function DWCChannelStartTransaction(Host:PDWCUSBHost; Channel:LongWord; Request:PUSBRequest):LongWord;
function DWCHostPortReset(Host:PDWCUSBHost):LongWord;
function DWCHostPortPowerOn(Host:PDWCUSBHost):LongWord;
function DWCHostPortGetStatus(Host:PDWCUSBHost):LongWord;
function DWCHostPortSetFeature(Host:PDWCUSBHost; Feature:Word):LongWord;
function DWCHostPortClearFeature(Host:PDWCUSBHost; Feature:Word):LongWord;
procedure DWCHostPortStatusChanged(Host:PDWCUSBHost);
function DWCRootHubRequest(Host:PDWCUSBHost; Request:PUSBRequest):LongWord;
function DWCRootHubControlRequest(Host:PDWCUSBHost; Request:PUSBRequest):LongWord;
function DWCRootHubClassRequest(Host:PDWCUSBHost; Request:PUSBRequest):LongWord;
function DWCRootHubStandardRequest(Host:PDWCUSBHost; Request:PUSBRequest):LongWord;
function DWCSchedulerStart(Host:PDWCUSBHost):LongWord;
function DWCSchedulerExecute(Host:PDWCUSBHost):PtrInt;
function DWCCompletionExecute(Host:PDWCUSBHost):PtrInt;
function DWCResubmitExecute(Request:PUSBRequest):PtrInt;
procedure DWCInterruptHandler(Host:PDWCUSBHost);
function DWCChannelInterrupt(Host:PDWCUSBHost; Channel:LongWord):LongWord;
function DWCChannelCompleted(Host:PDWCUSBHost; Request:PUSBRequest; Channel,Interrupts:LongWord):LongWord;
DWCOTG helper functions
function DWCDivRoundUp(Number,Denominator:LongWord):LongWord;
function DWCCalculateFrameInterval(Host:PDWCUSBHost):LongWord;
Return to Unit Reference