⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 hostc_sd_requests.htm

📁 SDIO Linux documentation
💻 HTM
📖 第 1 页 / 共 2 页
字号:
<html><!-- InstanceBegin template="/Templates/helpnav.dwt" codeOutsideHTMLIsLocked="false" -->
<head>
<!-- InstanceBeginEditable name="doctitle" -->

<title>Host Driver SD Request Processing</title>
<!-- InstanceEndEditable -->
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- InstanceBeginEditable name="head" -->
<!-- InstanceEndEditable -->
<!-- InstanceParam name="HeaderColor" type="color" value="#0000FF" -->
<!-- InstanceParam name="FooterColor" type="color" value="#0000FF" -->
<!-- InstanceParam name="NavBackgroundColor" type="color" value="#FFFFFF" -->
<!-- InstanceParam name="BodyBackgroundColor" type="color" value="#FFFFFF" -->
<link href="CodeTHelp.css" rel="stylesheet" type="text/css">
</head><a name="TopTopic"></a>
<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0">
<table width="100%" border="0" cellspacing="0" cellpadding="4">
  <tr> 
    <td width="40%" rowspan="2" bgcolor="#0000FF"><a href="http://www.codetelligence.com"><img src="Images/codetelligence_lrg.gif" name="image" width="252" height="40" border="0"></a></td>
    <td width="60%" height="62" bgcolor="#0000FF">
     <font color="#FFFFFF" size="5" face="Arial, Helvetica, sans-serif"><strong>Embedded SDIO Driver Kit Help </strong></font></td>
  </tr>
</table>

<table width="100%" border="0" cellspacing="10" cellpadding="0">
  <tr>
    <td width="93%"><font face="Arial, Helvetica, sans-serif">
<p class="Topic"><!-- InstanceBeginEditable name="SubTemplate" -->Host&nbsp;Driver
		SD Request Processing <!-- InstanceEndEditable --> </p>
</font></td>
    <td><!-- InstanceBeginEditable name="NavBack" --><A href="hostc_callbacks.htm"><img
			src="Images/leftarrow.gif" width="27" height="32" border="0" alt=""></A>
		<!-- InstanceEndEditable --></td><td><!-- InstanceBeginEditable name="Nav" --><A href="hostc_configuration.htm"><img
			src="Images/rightarrow.gif" width="27" height="32" border="0" alt=""></A>
		<!-- InstanceEndEditable --></td>
  </tr>
</table>
<hr>
<table width="100%" border="0" cellspacing="0" cellpadding="15">
<tr><td>
<!-- InstanceBeginEditable name="Help Content" --> <OBJECT
			type="application/x-oleobject"
			classid="clsid:1e2a7bd0-dab9-11d0-b93a-00c04fc99f9e">
			<PARAM name="Keyword" value="Host Driver SD Request Processing"
				name="">
		</OBJECT>

		<p class="BODYTEXT">The SDIO core and peripheral drivers allocate,
		assemble and issue <font face="Courier New">SDREQUEST</font>
		structures to host controller drivers. Each request provides
		information for all phases of an SD/SDIO bus transaction.&nbsp; This
		includes the command, response and data transfer phases&nbsp; The
		content of a bus request is card/function specific&nbsp;and can
		consist of any&nbsp; combination of command code, command
		argument,&nbsp;standard response types and the presence of data (read
		or write).&nbsp; The HCD is unaware of the purpose and nature of each
		command.&nbsp; An HCD is only concerned by the value of the command
		code,&nbsp;the 32-bit value of the&nbsp;argument, the expected
		response type and the block transfer parameters (number of blocks,
		bytes per block).&nbsp;&nbsp; The HCD relies on upper layer software
		to properly assemble the request that is appropriate (or
		legal)&nbsp;for the card.&nbsp; The HCD is only concerned about the
		basic parameters of the&nbsp;request and not whether the response
		and/or argument is appropriate for the command.&nbsp; This is left for
		upper layer software.&nbsp; This technique of breaking down a bus
		request into it's&nbsp;basic&nbsp;parameters allow the stack to
		handle&nbsp;future&nbsp;commands&nbsp;without a change in the host
		controller driver. A quick reference to the key fields of a bus request
		can be found here: <a href="periph_io_requests.htm#KeyBusRequestFields">Function Driver I/O Request</a>.</p>

		<p class="BODYTEXT"><strong>Command and Responses:</strong></p>

		<p class="BODYTEXT">All bus requests consist of a command and response
		phase.&nbsp; Each bus request contains the command code and 32-bit
		command argument to be issued.&nbsp; The response type is also encoded
		in each bus request structure.&nbsp; The HCD should decode the
		response type and setup hardware appropriately.&nbsp; The HCD should
		start the command/response transaction in hardware and wait for
		completion.&nbsp; An HCD request callback typically enables a &quot;command
		done&quot; interrupt
		and immediately returns <font face="Courier New, Courier, mono">SDIO_STATUS_PENDING</font>.
		At	some point in the future the interrupt will signal and the ISR will
		process the results. Most	HCDs	can	poll	for	command/response
		completion	as	the	SD/SDIO	specifications	defines	a maximum	timeout
		period	which	is relatively short compared to typical interrupt processing
		overhead.&nbsp; Polling however, should only be used when the clock
		rate is high.&nbsp; At lower clock rates (low speed devices) the
		polling operation can affect system responsiveness.&nbsp; When completing a
		request	without interrupts, the HCD can return from the request callback
		with	the completion status of the request. There are however restrictions
		on returning a non-pending status (see <A href="#CompleteRequest">Completing
		Requests Immediately</A>). </p>
		<p class="BODYTEXT">On	successful transmission of the command and reception
		of	a response, the HCD	should	move	the	response	data	into
		the <font face="Courier New">Response[]</font> array of bytes in the <font face="Courier New">SDREQUEST</font> structure.&nbsp; The&nbsp;HCD must also set&nbsp;the completion status
		in the <font face="Courier New">Status</font> field. The following
		code demonstrates this:</p>
		<pre> 
        if (!(hwStatus &amp; HW_ERRORS)) { 
            pReq-&gt;Status = SDIO_STATUS_SUCCESS; 
		    // move data from FIFO into read buffer, this
		    // aligns the data correctly
           for (ii = 0; ii &lt; dwordCount; ii++)  { 
                   readBuffer[ii] = READ_HOST_REG32(pDevice, HOST_REG_RESPONSE+(ii*4));  
           } 
               // copy to response 
           memcpy(&amp;pReq-&gt;Response[1],readBuffer,byteCount); 
        } else {
		       // set appropriate status 
           pRequest->Status = SDIO_STATUS_xxxx;    
        }
        </pre>


		<p class="BODYTEXT">The response data should be copied into the
		response buffer starting at byte index 1.&nbsp; Byte index 0 is a
		place holder for the CRC and not used.&nbsp; SPI mode requires a
		different response format.&nbsp; Response bytes received in SPI mode
		are stored into the response buffer at byte 0.&nbsp; The SDIO stack
		converts SPI responses to SD/SDIO responses allowing most peripheral
		drivers to operate in 1/4 bit mode or SPI mode&nbsp;without
		modification.&nbsp; Under SPI mode, the HCD must submit the bus
		request to the <font face="Courier New"><a href="HD_Reference.htm#FUNC_SDIO_CheckResponse">SDIO_CheckResponse()</a></font>
		API , using the <font face="Courier New, Courier, mono">SDHCD_CHECK_SPI_TOKEN</font> option
		to determine the appropriate	completion	status.&nbsp; This
		function filters the SPI mode response and returns <font
			face="Courier New">SDIO_STATUS_TIMEOUT</font> for SPI responses that
		have the illegal cmd bit set.&nbsp; This will simulate SD 1/4 bit
		behavior for commands that are not allowed for a card type.&nbsp;</p>

		<p class="BODYTEXT">A non-data transfer bus request that completes
		with failure or success can be completed using the <font
			face="Courier New"><a href="HD_Reference.htm#FUNC_SDIO_HandleHcdEvent">SDIO_HandleHcdEvent()</a></font> API
		with the event	code of <font face="Courier New">EVENT_HCD_TRANSFER_DONE</font>.&nbsp;
		Under most operating systems this should NOT be called from an interrupt
		service routine (ISR). The ISR should queue a deferred procedure or work
		item that makes the actual indication. The <font face="Courier New">EVENT_HCD_TRANSFER_DONE</font> indication
		should not be made	under	any circumstances	from	within	the <font face="Courier New, Courier, mono">pRequest</font>		callback. </p>
		<p class="BODYTEXT"><font
			face="Courier New">SDIO_HandleHcdEvent()</font> will	remove	the	current
		request	and start	the	next	request	in	the	queue.&nbsp; The
		bus	request	callback	may	be	called	in	the same	context as the
		call	to <font face="Courier New">SDIO_HandleHcdEvent</font> .&nbsp;See <a href="hostc_events.htm">Host Driver Events</a> for
		more	information on transfer completion events.</p>
		<p class="HEADING3">Data Transfers:</p>

		<p class="BODYTEXT">A bus request contains data if the <font
			face="Courier New">Flags</font> field of the request has the <font
			face="Courier New">SDREQ_FLAGS_DATA_TRANS</font> bit set.&nbsp; The
		data transfer is a write operation if <font face="Courier New">SDREQ_FLAGS_DATA_WRITE</font>
		bit is set, otherwise it is a read operation.&nbsp; The HCD should
		submit the bus request (with received response) to the <font
			face="Courier New"><a href="HD_Reference.htm#FUNC_SDIO_CheckResponse">SDIO_CheckResponse()</a></font> API&nbsp;&nbsp;to
		determine whether the card status indicates that the data transfer can
		proceed.&nbsp; This API filters the request for certain command codes
		and responses and returns <font face="Courier New">SDIO_STATUS_SUCCESS</font>
		if the data transaction can start.&nbsp; The function filters all
		SD/MMC memory read/write commands and SDIO CMD53 responses.</p>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -