Share via


EHCI-specific Code (Windows Embedded CE 6.0)

1/6/2010

The USB 2.0 implementation includes some code that is specific to the host controller. The EHCI-specific module, EHCI.dll, implements CPipeAbs for all USB pipes and implements the pure virtual functions declared in CHcd. CEhcd contains hardware properties and includes all data structures that it shares with the hardware. The CIsochronousPipe, CInterruptPipe and CControlPipe classes manage various USB transactions.

The following list shows what performs, composes, and manages transfers to the host controller:

  • Pipes perform transfers.
  • Multiple transfer descriptors compose transfers.
  • Transfer classes and transfer descriptors manage transfers.
  • Transfer classes and transfer descriptors compose transfers.

The hardware and the queue header use the transfer descriptor. Hardware and software share the transfer descriptor and the queue header.

CHW is the hardware abstract class for the EHCI hardware registers and its structure. CHW includes the host controller operation register, periodic frame-list handling, and the asynchronous list.

EHCI-specific Pipe Classes

Depending on the endpoint type, USB transactions use the CIsochronousPipe, CInterruptPipe and CControlPipe classes. Each instance of the CControlPipe, CBulkPipe and CInterrupt classes has an endpoint descriptor structure that is used to create the instance. For interrupt, bulk, and control transfers that are queued, the pipe creates a queue header instance that is inserted either into an asynchronous schedule queue or into a periodic schedule queue. An instance of the HCD hardware class manages the asynchronous schedule queue and the periodic schedule queue, which a separate class defines.

The CQH class implements the queue header structure functionality. The next qTD pointer inside the queue header structure references the transfer descriptor structure list that is associated with this queue header.

CTransfer creates and owns the transfer descriptor list. CTransfer queues or dequeues those transfer descriptors to or from the queue header using CPipe. Both the EHCI hardware and the CQueuePipe class reference the queue header that CQueuePipe uses. For more information, see CQueuePipe Class and CTransfer Class Relationship.

All pipes support accepting more than one transfer. The CQueuePipe member m_pUnQueuedTransfer holds the outstanding queue transfer.

For information about the relationship between the periodic table, the isochronous transfer descriptor, and the interrupt endpoint descriptor, see CIsochronousPipe Class and CIsochTransfer Class Relationship.

The hardware register class, CHW, creates the periodic table, which the hardware references. Each entry represents a frame, not a micro-frame. All transfer descriptors that send within this frame are horizontally linked. For more information, see CIsochronousPipe Class and CIsochTransfer Class Relationship. In addition, software vertical links are created to link those transfer descriptors that belong to a transfer. Members of the CIsochTransfer class reference the header of this vertical list. CTransfer and CIsochTransfer create and own these transfer descriptors. The queue header for interrupt transfers also queues horizontally after isochronous transfer descriptors.

The following table shows the hierarchy of the pipe classes in EHCI-specific code.

Class Description and hierarchy

CPipeAbs

The CPipeAbs abstract class connects to the CPipe abstract class.

CPipeAbs is at the top of the class hierarchy.

CPipe

The cPipe abstract class implements the common code between the queue pipe and the isochronous pipe. This class includes a split mask and a complete mask for a full speed endpoint. It also holds the transaction translation address and the speed of the pipe.

The CPipe abstract class is below and connects to the CPipeAbs abstract class.

The CPipe abstract class is above and connects to the CQueuedPipe abstract class.

The CPipe abstract class is above and connects to the CIsochronousPipe class.

CQueuedPipe

The CQueuedPipe abstract class is used for queue-type pipes, control, bulk, and interrupt common code. It holds the queue header class instance it used. It also holds the currently processing transfer instance and the outstanding queued transfer instance. A transfer class such as CIoschTransfer and CQTransfer manage the transfer.

CQueuedPipe handles queued transfers to the queue header. It also handles transfers to the queue header that are not queued. It also controls the state of the queue header through an instance of CQH, the queue header class.

CQueuedPipe abstract class is below and connects to the CPipe abstract class.

The CQueuedPipe abstract class is above and connects to the CControlPipe, CInterruptPipe, and CBulkPipe classes.

CIsochronousPipe

The CIsochronousPipe class is below and connects to the CPipe abstract class.

CIsochronousPipe cannot use CQueuePipe because CIsochronousPipe is not a queue based transfer. Instead, CQueuePipe extends CPipe. CQueuePipe has multiple transfers queued into the periodic schedule table to support the continuation of a transfer. CIsochronousPipe references only the header of those transfer lists. Those transfers might all have transfer descriptors inserted into the periodic schedule list table.

CControlPipe

The CControlPipe abstract class extends CQueuePipe for control pipes. It sets up the queue header according to the control type and it queues this queue header into the hardware asynchronous queue header list. It provides parameters and the ability to change the packet size at least once for this queue header.

The CControlPipe class is below and connects to the CQueuedPipe abstract class.

CInterruptPipe

The CInterruptPipe abstract class calls AllocateBusTime in the USB20 library for this endpoint and uses GetSMASK and GetCMASK with the bus bandwidth information as parameters to get the split and complete mask. This class processes high-speed and full-speed interrupt endpoints. It also queues this queue header into the periodic schedule list table.

CInterruptPipe extends CQueuePipe for interrupt pipes. It sets up the queue header according to the interrupt type. It also sets up the split and complete mask for its queue header.

The CInterruptPipe class is below and connects to the CQueuedPipe abstract class.

CBulkPipe

The CBulkPipe abstract class extends CQueuePipe for bulk pipes. It sets up the queue header according to the bulk type, and it queues this queue header into the hardware asynchronous queue header list. It also provides parameter checking functions for IssueTransfer.

The CBulkPipe class is below and connects to the CQueuedPipe abstract class.

EHCI-specific Transfer Classes

Pipes use transfers to carry out transactions initiated by the user. A pipe carries the transfer parameter and status. It also contains the transfer descriptor class instance that it used. When there is a hardware interrupt, an active transfer that potentially connects the transfer descriptor to the hardware data structure calls the DoneTransfer class member. For queued endpoints, the transfer referenced by m_pQueuedTransfer in CQueuedPipe is the active transfer. For more information, see CQueuePipe Class and CTransfer Class Relationship.

For isochronous endpoints, all of the queued transfers are potentially active transfers. For more information, see CIsochronousPipe Class and CIsochTransfer Class Relationship.

The following table shows the hierarchy of the transfer classes in host controller-specific code.

Class Description and hierarchy

CTransfer

The CTransfer abstract class allocates memory for the client, initializes transfer buffers for the client, and performs a callback when it is finished.

CTransfer is above CQTransfer and CIsochTransfer and connects to both.

CQTransfer

The CQTransfer abstract class implements the transfer descriptor list initialization with AddTransfer. It also implements checking for completion and transfer descriptor completion actions, and implements aborting actions if a transfer must terminate.

CQueuedPipe uses CQTransfer for queued pipe endpoints, control transfers, and bulk interrupt transfers. CQTransfer manages the queue transfer descriptor list and references it with the m_pCQTDList member.

CQTransfer is below and connects to CTransfer. CQTransfer is parallel to CIsochTransfer.

CIsochTransfer

The CIsochTransfer abstract class is the common interface between CITransfer and CSITransfer. With few exceptions, the CIsochronous class interfaces only with CIsochTransfer. CITransfer handles high-speed USB isochronous transfers. CSITransfer, which handles split isochronous transfers, handles full-speed isochronous transfers. CITransfer creates the isochronous transfer descriptors and CSITransfer creates the split isochronous transfer descriptors.

CIsochTransfer is below and connects to CTransfer. CIsochTransfer is above CITransfer and CSITransfer. CIsochTransfer is parallel to CQTransfer.

CITransfer

The CITransfer abstract class manages isochronous transfers.

The CITransfer abstract class is below and connects to CIsochTransfer. CITransfer is parallel to CSITransfer.

CSITransfer

The CSITransfer abstract class manages high-speed isochronous transfers.

CSITransfer abstract class is below and connects to CIsochTransfer. CSITransfer is parallel to CITransfer.

EHCI-specific Transfer Descriptors and Queued Headers

The EHCI hardware and the EHCI driver share the queue header and use it for queued transfers. Each pipe or endpoint has one queue header that the asynchronous list or periodic frame list can reference.

The following list shows the queue header objects in EHCI-specific code:

  • The CQH object is an extended queue header structure that simplifies queue header management.
    It contains a pointer that references the pipe class that owns this instance of the class. It also contains a virtual address reference to the next CQH to which the next physical queue address points. This allows access to the next CQH without converting the physical address.
  • The CQTD object is an extended queued transfer descriptor structure that manages queued transfer descriptors.
    It contains references to the instance transfer class, CQTransfer, and to CQH, which simplifies the driver architecture.
  • The CITD object is an extended isochronous transfer descriptor structure that manages transfer descriptors.
    It contains a reference to the transfer that owns this instance. CITD has extended reference pointers that point to the next transfer descriptors that transfer to the next frame within the same transfer.
  • The CSITD object is an extended split isochronous transfer descriptor structure that facilitates managing split transfers.
    It contains a reference to the transfer that created and owns this instance. It also contains a reference to the previous CSITD in the list. You can use the reference to the previous CSITD for initialization or to navigate backwards through the list. CSITD has extended reference pointers that point to the next transfer descriptors that transfer to the next frame within the same transfer.

For more information about the relationship between these classes, see CIsochronousPipe Class and CIsochTransfer Class Relationship.

EHCI-specific Code and USB 2.0 Common Code Interface

USB 2.0 common code requires all host controller specific code to implement the virtual functions exposed by the HCD class. The following table shows the components used to implement the host controller functionality.

Component Description and hierarchy

HCD

HCD implements the host controller driver interface. This abstract class passes requests to other objects.

Above CHW and connects to CHW.

CHW

CHW implements all of the HCD virtual functions and interfaces with the hardware. There are two reference pointers in hardware that point to the structure to manage.

Below HCD and connects to HCD.

Above CEhcd and connects to CEhcd.

USB2lib

USB2lib handles scheduling of USB transactions.

Parallel to CHW and connects to CEhcd.

CEhcd

CEhcd contains USB2lib code that the pipe class utilizes.

Below CHW and connects to CHW.

Below USB2lib and connects to USB2lib.

The following table shows a comparison between periodic scheduling and asynchronous scheduling.

Scheduling method Description

Periodic

The periodic list base hardware register references this scheduling structure. The CPeriodicMgr class manages the referenced structures.

CPeriodicMgr creates the periodic list table during initialization. It also initializes the dummy periodic queue header and links the list table and queue header according to the polling rate. This avoids complications when inserting a periodic queue header requested from CPipeInterrupt that has a different polling rate.

CPeriodicMgr exposes a public interface for pipes and transfers to use. The public interface includes functions to insert CITD, CSITD, and CQH objects, and functions to delete CITD, CSITD, and CQH objects.

Asynchronous

The asynchronous list address hardware register references this scheduling structure. The CAsyncMgr class manages the referenced structures.

CAsyncMgr creates the dummy periodic queue header that serves as the head of the list. This header has the reclamation flag set and it is not deleted until its class instance is deleted. It does not have to move the reclamation flag when a queue header is inserted or deleted.

CAsyncMgr exposes a public interface that pipes use to insert and delete asynchronous queue headers.

See Also

Concepts

The Enhanced Host Controller Interface (EHCI) Driver