No subject

Fri Oct 22 17:57:35 EDT 2010

For SREQ:<br>
 =A0 =A0 =A0 =A0For receive: Asserted if data counter is<br>
 =A0 =A0 =A0 =A0zero and receive FIFO contains more than<br>
 =A0 =A0 =A0 =A0one and fewer than eight words.<br>
 =A0 =A0 =A0 =A0For transmit: Asserted if fewer than eight<br>
 =A0 =A0 =A0 =A0and more than one word remain for<br>
 =A0 =A0 =A0 =A0transfer to FIFO.<br>
For BREQ:<br>
 =A0 =A0 =A0 =A0For receive: Asserted if FIFO contains<br>
 =A0 =A0 =A0 =A0eight words and data counter is not zero,<br>
 =A0 =A0 =A0 =A0or if FIFO contains more than eight words.<br>
 =A0 =A0 =A0 =A0For transmit: Asserted if more than eight<br>
 =A0 =A0 =A0 =A0words remain for transfer to FIFO.<br>
For LSREQ:<br>
 =A0 =A0 =A0 =A0For receive: Asserted if data counter is<br>
 =A0 =A0 =A0 =A0zero and FIFO contains only one word.<br>
 =A0 =A0 =A0 =A0For transmit: Asserted if only one word<br>
 =A0 =A0 =A0 =A0remains for transfer to FIFO.<br>
For LBREQ:<br>
 =A0 =A0 =A0 =A0For receive: Asserted if data counter is<br>
 =A0 =A0 =A0 =A0zero and FIFO contains eight words.<br>
 =A0 =A0 =A0 =A0For transmit: Asserted if only eight words<br>
 =A0 =A0 =A0 =A0remain for transfer to FIFO.<br>
So, for small transfers (less than half the FIFO depth), SREQ will be<br>
asserted to transfer a single word at a time, and LSREQ for the last<br>
word. =A0There shouldn&#39;t be any bursts from the DMA controller.<br>
The second argument is that if you have a burst size of, say, 8 words<br>
and you program the DMA to transfer 4 words, it should _not_ transfer<br>
8 words to the peripheral.<br>
&gt; What it does is to emulate single requests below a certain<br>
&gt; threshold by requesting one-word bursts. I think this is<br>
&gt; primarily for SDIO, not card transfers.<br>
This should be handled in hardware, if not it&#39;s DMA controller specific=
as it shouldn&#39;t burst past the remainder of the transfer. =A0If your DM=
controller does burst past the number of bytes in the transfer, surely<br>
that&#39;s something that your DMA controller code needs to work around?<br=
></blockquote><div><br>Yes that indeed seems resonable. With the COH901318 =
DMA engine<br>it worked just fine without the burst threshold. Just want to=
 give my<br>
colleagues a chance to have a second opinion on this.<br>=A0<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
&gt; &gt; + =A0 =A0 =A0 /* Check for weird stuff in the sg list */<br>
&gt; &gt; + =A0 =A0 =A0 /* shouldn&#39;t this be in the DMA engine driver? =
&gt; &gt; + =A0 =A0 =A0 for_each_sg(data-&gt;sg, sg, data-&gt;sg_len, i) {<=
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_vdbg(mmc_dev(host-&gt;mmc), &qu=
ot;MMCI SGlist %d dir %d: length: %08<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i, conf.directio=
n, sg-&gt;length);<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (sg-&gt;offset &amp; 3 || sg-&gt=
;length &amp; 3)<br>
&gt; &gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;<br>
&gt; &gt; + =A0 =A0 =A0 }<br>
&gt; This one is just overcautious and for SDIO we don&#39;t even want to d=
&gt; such things, so it should be dropped altogether.<br>
&gt; The original intent was to avoid writing anything than 32bit words<br>
&gt; into the register, and with the SDIO-modified versions you can<br>
&gt; actually do that.<br>
Surely that&#39;s to do with the DMA controller though?<br></blockquote><di=
v><br>Absolutely.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">

&gt; So I&#39;ll drop it for the next iteration.<br>
Given that I&#39;ve already heavily modified the code, it&#39;s probably be=
tter if<br>
you just let me know the answer... ;)<br>
</blockquote></div><br>In any case I&#39;m happy if you post/commit the MMC=
I support<br>you have, if there are problems we can certainly sort it out l=
ater<br>in any case.<br><br>Hm, does this mean you got it working with one =
of the<br>
reference boards eventually?<br><br>Yours,<br>Linus Walleij<br>


More information about the linux-arm-kernel mailing list