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>
<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>
<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>
<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>
<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't be any bursts from the DMA controller.<br>
<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>
<br>
> What it does is to emulate single requests below a certain<br>
> threshold by requesting one-word bursts. I think this is<br>
> primarily for SDIO, not card transfers.<br>
<br>
This should be handled in hardware, if not it's DMA controller specific=
<br>
as it shouldn't burst past the remainder of the transfer. =A0If your DM=
A<br>
controller does burst past the number of bytes in the transfer, surely<br>
that'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;">
> > + =A0 =A0 =A0 /* Check for weird stuff in the sg list */<br>
> > + =A0 =A0 =A0 /* shouldn't this be in the DMA engine driver? =
*/<br>
> > + =A0 =A0 =A0 for_each_sg(data->sg, sg, data->sg_len, i) {<=
br>
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_vdbg(mmc_dev(host->mmc), &qu=
ot;MMCI SGlist %d dir %d: length: %08<br>
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0i, conf.directio=
n, sg->length);<br>
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (sg->offset & 3 || sg->=
;length & 3)<br>
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;<br>
> > + =A0 =A0 =A0 }<br>
><br>
> This one is just overcautious and for SDIO we don't even want to d=
o<br>
> such things, so it should be dropped altogether.<br>
><br>
> The original intent was to avoid writing anything than 32bit words<br>
> into the register, and with the SDIO-modified versions you can<br>
> actually do that.<br>
<br>
Surely that'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;">
> So I'll drop it for the next iteration.<br>
<br>
Given that I've already heavily modified the code, it's probably be=
tter if<br>
you just let me know the answer... ;)<br>
</blockquote></div><br>In any case I'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>
--0016e649c71adca677049aa790e5--
More information about the linux-arm-kernel
mailing list