![Intel IXP45X Скачать руководство пользователя страница 482](http://html1.mh-extra.com/html/intel/ixp45x/ixp45x_developers-manual_2073092482.webp)
Intel
®
IXP45X and Intel
®
IXP46X Product Line of Network Processors—USB 2.0 Host Controller
Intel
®
IXP45X and Intel
®
IXP46X Product Line of Network Processors
Developer’s Manual
August 2006
482
Order Number: 306262-004US
• Place all enabled root ports into the suspended state by setting the Suspend bit in
each appropriate PORTSC register to a one.
• Set the Run/Stop bit in the USBCMD register to a zero and wait for the HCHalted bit
in the USBSTS register, to transition to a one. Note that an EHCI host controller
implementation may optionally allow port testing with the Run/Stop bit set to a
one. However, all host controllers must support port testing with Run/Stop set to a
zero and HCHalted set to a one.
• Set the Port Test Control field in the port under test PORTSC register to the value
corresponding to the desired test mode. If the selected test is
Test_Force_Enable, then the Run/Stop bit in the USBCMD register must then be
transitioned back to one, in order to enable transmission of SOFs out of the port
under test.
• When the test is complete, system software must ensure the host controller is
halted (HCHalted bit is a one) then it terminates and exits test mode by setting
HCReset to a one.
9.14.15
Interrupts
The EHCI Host Controller hardware provides interrupt capability based on a number of
sources. There are several general groups of interrupt sources:
• Interrupts as a result of executing transactions from the schedule (success and
error conditions),
• Host controller events (Port change events, etc.), and
• Host Controller error events
All transaction-based sources are maskable through the Host Controller’s Interrupt
Enable register (USBINTR, see
Section 9.12.3, “USBINTR” on page 377
). Additionally,
individual transfer descriptors can be marked to generate an interrupt on completion.
This section describes each interrupt source and the processing that occurs in response
to the interrupt.
During normal operation, interrupts may be immediate or deferred until the next
interrupt threshold occurs. The interrupt threshold is a tunable parameter via the
Interrupt Threshold Control field in the USBCMD register. The value of this register
controls when the host controller will generate an interrupt on behalf of normal
transaction execution. When a transaction completes during an interrupt interval
period, the interrupt signaling the completion of the transfer will not occur until the
interrupt threshold occurs. For example, the default value is eight micro-frames. This
means that the host controller will not generate interrupts any more frequently than
once every eight micro-frames.
“Host System Error” on page 485
details effects of a host system error.
If an interrupt has been scheduled to be generated for the current interrupt threshold
interval, the interrupt is not signaled until after the status for the last complete
transaction in the interval has been written back to host memory. This may sometimes
result in the interrupt not being signaled until the next interrupt threshold.
Initial interrupt processing is the same, regardless of the reason for the interrupt.
When an interrupt is signaled by the hardware, CPU control is transferred to host
controller's USB interrupt handler. The precise mechanism to accomplish the transfer is
OS specific. For this discussion it is just assumed that control is received. When the
interrupt handler receives control, its first action is to reads the USBSTS (USB Status
Register). It then acknowledges the interrupt by clearing all of the interrupt status bits
by writing ones to these bit positions. The handler then determines whether the
interrupt is due to schedule processing or some other event. After acknowledging the
interrupt, the handler (via an OS-specific mechanism), schedules a deferred procedure