c-periph.html

linux2.4.20下的针对三星公司的s3c2410的usb模块驱动代码

    UINT32 isochOutMaxPacketSize;    /* max packet size in isoch OUT mode */ 
    UINT32 isochInOutMaxPacketSize;  /* max packet size in isoch I/O mode */ 
 
    UINT16 endpointNum;              /* currently assigned endpoint num */ 
    UINT16 configuration;            /* current configuration */ 
    UINT16 interface;                /* current interface */ 
    UINT16 transferType;             /* current transfer type */ 
    UINT16 direction;                /* current direction */ 
 
    UINT16 maxPacketSize;            /* max packet size as configured */ 
 
    } USB_TARG_ENDPOINT_INFO, *pUSB_TARG_ENDPOINT_INFO; 
</pre>
</font>
</dl>

<dl class="margin">

<dd><p class="Body"><a name="87470"></a>The purpose of this structure is to give TCDs, and thus <b class="library">usbTargLib</b>, a way to describe the endpoint capabilities of a particular TCD and target controller in a hardware-independent manner. The target application should treat this structure as read-only. Its fields are defined as follows:</p>
</dl>

<dl class="margin">

<dd><div class="Item"><a name="87471"></a><i class="textVariable">endpointId</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87472"></a>An arbitrary endpoint ID number assigned by the TCD to a particular endpoint. </div><br>
</dl>

<dd><div class="Item"><a name="87473"></a><i class="textVariable">flags</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87474"></a>A description of the capabilities of the endpoint, as follows:</div><br>
</dl>

</dl>

<dl class="margin">

<dd><font color="0000a0">
<pre class="Code"><a name="87475"></a>&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_IN_OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;host-&gt;device capable 
&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_OUT_OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;device-&gt;host capable 
&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_CTRL_OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capable of control xfr 
&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_BULK_OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capable of bulk xfr 
&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_INT_OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capable of interrupt xfr 
&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_ISOCH_OK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capable of isoch xfr 
&nbsp;&nbsp;&nbsp;&nbsp;TCD_ENDPOINT_IN_USE&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;endpoint has pipe 
</pre>
</font>
</dl>

<dl class="margin">

<dd><div class="Item"><a name="87476"></a><i class="textVariable">endpointNumMask</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87477"></a>A bit-vector identifying the endpoint numbers that can be supported by the endpoint. For example, if bit 0 is "1", the endpoint can be endpoint 0. If bit 1 is "1", the endpoint can be endpoint 1. And so on.</div><br>
</dl>

<dd><div class="Item"><a name="87478"></a>xxx<i class="textVariable">MaxPacketSize</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87479"></a>These fields define the maximum packet size supported by the endpoint when enabled as a control, bulk, interrupt, or isochronous endpoint. </div><br>
</dl>

<dd><div class="Item"><a name="87480"></a><i class="textVariable">endpointNum</i> </div>
<dl class="margin">

<dd><div class="Follow"><a name="87481"></a>The endpoint number currently assigned to this endpoint.</div><br>
</dl>

<dd><div class="Item"><a name="87482"></a><i class="textVariable">configuration <br>
interface</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87483"></a>The configuration and interface with which this endpoint is currently configured. </div><br>
</dl>

<dd><div class="Item"><a name="87484"></a><i class="textVariable">transferType <br>
direction</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87485"></a>Similar to <i class="textVariable">configuration</i> and <i class="textVariable">interface</i>, the endpoints transfer type and direction, as <b class="symbol_UC">USB_XFRTYPE_</b><i class="textVariable">xxxx</i> and <b class="symbol_UC">USB_DIR_</b>xxxx.</div><br>
</dl>

<dd><div class="Item"><a name="87486"></a><i class="textVariable">maxPacketSize</i></div>
<dl class="margin">

<dd><div class="Follow"><a name="87487"></a>The maximum packet size as currently configured.</div><br>
</dl>

</dl>

<dl class="margin">

<dd><p class="Body"><a name="87488"></a>While this abstract endpoint structure permits target applications to be written without prior knowledge of the capabilities of the underlying TCD and target controller, many target application developers are likely to bypass this abstraction and code their target applications to use specific endpoints based on their knowledge of the underlying hardware's capability.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="87491"></a>2.2.6  &nbsp;&nbsp;Data Transfer</i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="87492"></a>All data transfers on a USB are initiated by the USB host. In general, a host creates a pipe--in other words, a connection--to a specific endpoint on a given peripheral. In addition to the address of the peripheral and the endpoint number, the pipe has other characteristics, such as the data type (control, bulk, interrupt, or isochronous), direction, and perhaps information describing the bandwidth required by the pipe. Having created a pipe, the USB host application requests data transfers by formatting IRPs (I/O request packets) and submitting them to the USB driver (called the USBD in the Wind River USB host stack). </p>
<dd><p class="Body"><a name="87493"></a>The Wind River USB peripheral stack functions similarly. A target application creates pipes and attaches them to specific endpoints supported by the TCD and target controller. Pipes are created and destroyed using the routines <b class="routine">usbTargPipeCreate</b><b>(&nbsp;)</b> and <b class="routine">usbTargPipeDestroy</b><b>(&nbsp;)</b>. As described further in <a href="c-periph.html#87512"><i class="title">Control Pipe Data Transfers</i></a>, <b class="library">usbTargLib</b> automatically creates the pipe for the default control endpoint (endpoint #0); so the target application itself omits the pipe creation step for the default control pipe.</p>
</dl>

</dl>

<dl class="margin">
<dd>
<p class="table">
<table border="0" cellpadding="2" cellspacing="0">
<tr valign="top">
<td colspan=1 rowspan=1></td><td><hr></td></tr>
<tr valign="top"><td>
<img border="0" alt="*" src="icons/note.gif">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</td>
<td colspan=1 rowspan=1><div class="CalloutCell"><a name="87501"></a>
<b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE:  </font></b>
By convention, the direction of a particular pipe is always viewed from the USB host's perspective; so, a pipe that transfers data from the host to the peripheral has a direction of <b class="symbol_UC">USB_DIR_OUT</b> (even though the peripheral sees the data as incoming). Similarly, a pipe that transfers data from the peripheral to the host has a direction of <b class="symbol_UC">USB_DIR_IN</b>.</div>
</td>
</tr>
<tr valign="top">
<td colspan=1 rowspan=1></td>
<td colspan=1 rowspan=1><hr>
</td>
</tr>

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p>



<dl class="margin">

<dd><p class="Body"><a name="87507"></a>After creating the necessary pipes, the target application formats <b class="symbol_UC">USB_ERP</b>s (USB endpoint request packets) which describe data to be transferred. When the USB host requests a transfer to or from a specific target endpoint, the USB peripheral stack responds by transferring data to or from <b class="symbol_UC">USB_ERP</b>s provided by the target application. <b class="symbol_UC">USB_ERP</b>s take the following form:</p>
</dl>

<dl class="margin">

<dd><font color="0000a0">
<pre class="Code"><a name="87508"></a>typedef struct usb_erp 
&nbsp;&nbsp;&nbsp;&nbsp;{ 
&nbsp;&nbsp;&nbsp;&nbsp;LINK targLink;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* link field used internally by usbTargLib */ 
&nbsp;&nbsp;&nbsp;&nbsp;pVOID targPtr;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* ptr field for use by usbTargLib */ 
&nbsp;&nbsp;&nbsp;&nbsp;LINK tcdLink;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* link field used internally by USB TCD */ 
&nbsp;&nbsp;&nbsp;&nbsp;pVOID tcdPtr;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* ptr field for use by USB TCD */ 
&nbsp;&nbsp;&nbsp;&nbsp;pVOID userPtr;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* ptr field for use by client */ 
&nbsp;&nbsp;&nbsp;&nbsp;UINT16 erpLen;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* total length of ERP structure */ 
&nbsp;&nbsp;&nbsp;&nbsp;int result;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* ERP completion result: S_usbTcdLib_xxxx */ 
&nbsp;&nbsp;&nbsp;&nbsp;ERP_CALLBACK targCallback;&nbsp;/* usbTargLib completion callback routine */ 
&nbsp;&nbsp;&nbsp;&nbsp;ERP_CALLBACK userCallback;&nbsp;/* client's completion callback routine */ 
&nbsp;&nbsp;&nbsp;&nbsp;UINT16 endpointId;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* device endpoint */ 
&nbsp;&nbsp;&nbsp;&nbsp;UINT16 transferType;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* type of ERP: control, bulk, etc. */ 
&nbsp;&nbsp;&nbsp;&nbsp;UINT16 dataToggle;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* ERP should start with DATA0/DATA1. */ 
&nbsp;&nbsp;&nbsp;&nbsp;UINT16 bfrCount;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* indicates count of buffers in BfrList */ 
&nbsp;&nbsp;&nbsp;&nbsp;USB_BFR_LIST bfrList [1]; 
&nbsp;&nbsp;&nbsp;&nbsp;} USB_ERP, *pUSB_ERP; 
</pre>
</font>
</dl>

<dl class="margin">

<dd><p class="Body"><a name="87509"></a>There are numerous similarities between this data structure and the <b class="symbol_UC">USB_IRP</b> used by the Wind River USB host stack. The <b class="symbol_UC">USB_BFR_LIST</b> structure in the <b class="symbol_UC">USB_ERP</b> is identical to the one included as part of the <b class="symbol_UC">USB_IRP</b>.</p>
<dd><p class="Body"><a name="87510"></a>As with the USB host stack, the USB peripheral stack automatically manages the <i class="textVariable">dataToggle</i> for ERPs; thus, the target application is not required to keep track of the current state of DAT0 and DATA1 for each pipe.</p>
</dl>

</dl>
<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="87512"></a>Control Pipe Data Transfers</i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="87513"></a>The <b class="library">usbTargLib</b> driver automatically manages communication on the default control pipe (endpoint #0), making it unnecessary for the target application to create a pipe for this particular endpoint. However, this also means that the target application has no direct access to the default control pipe. For this reason, <b class="library">usbTargLib</b> provides two routines that allow the target application to transfer data through the default control pipe: </p>
<dl class="margin">

<dd><div class="Item2"><a name="87514"></a><b class="routine">usbTargControlResponseSend</b><b>(&nbsp;)</b></div>
<dl class="margin">

<dd><div class="Follow2"><a name="87515"></a>Send control pipe responses to the USB host.</div><br>
</dl>

<dd><div class="Item2"><a name="87516"></a><b class="routine">usbTargControlPayloadRcv</b><b>(&nbsp;)</b></div>
<dl class="margin">

<dd><div class="Follow2"><a name="87517"></a>Receive additional control pipe payloads from the USB host.</div><br>
</dl>

</dl>

<dd><p class="Body"><a name="87521"></a>Unlike the general data transfer routines (see <a href="c-periph.html#87524"><i class="tit