<div class="gmail_quote">On 24 January 2011 22:22, Russell King - ARM Linux <span dir="ltr"><<a href="mailto:linux@arm.linux.org.uk">linux@arm.linux.org.uk</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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. There shouldn't be any bursts from the DMA controller.<br></blockquote><div><br>Actually, drilling into the datasheet we have this statement for the version<br>used in U8500:<br><br>-------------------<br>
if data to be transferred in not multiple of 8 words, then:<br>* when Tx mode (DMAreqctl field of DCTRL register should be = 1),<br> MCIDMABREQ will be asserted until less 8 words remain. After this<br> SDI will assert MCIDMALBREQ for last words transfer to terminate<br>
the transfer.<br>* when Rx mode (DMAreqctl field of DCTRL register should be = 0),<br> MCIDMABREQ will be asserted until less 8 words remain. After<br> this SDI will assert MCIDMASREQ until 1 word remains and then<br>
it will assert MCIDMALSREQ to terminate the transfer.<br>-------------------<br>
<br>So the way I read it, the U8500 version of PL180 will do what you<br>describe for RX transfers (so as not to overwrite any memory)<br>but for TX it will simply read some extra bytes to make a<br>complete burst which is faster and then discard the remainder.<br>
<br>This wiring has consequences as we'll see later...<br><br>(I don't know if the original PL180 acually works the same, it may<br>just be some undocumented "feature"...)<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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. If your DMA<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>Here is another snippet:<br><br>-------------------<br>
For burst size = 1, if the data transfer is more than 7 words and the<br>
data to be transferred is a multiple of 8 words, a single burst transfer<br>
cannot be done, because when data transfer count reaches 8 words,<br>
MCIDMALBREQ is generated and 1 word will be transferred from<br>
memory to the SDI host FIFO. But as the DMA controller sees<br>
MCIDMALBREQ, it terminates the transfer and the remaining 7<br>
words are not be transferred to the Tx FIFO.<br>
-------------------<br>
<br>So we must use a burst size of 8 for anything exceeding and<br>including 8 words. Else it will break. (Follows logically from the<br>first snippet in some way, likely the VHDL code just checks<br>the higher bits.)<br>
<br>Yet, if it tried to issue a burst request size 8 for n<8, nothing<br>would be transfered, and that's due to limitations in the PL180<br>derivates way of issuing the request signals, not in the DMA<br>controller.<br>
<br>
So what the driver has to do is issue 1 word requests to avoid<br>issuing a single burst request when n<8, because of limitations<br>in the PL180 derivate.<br><br>It would require the same treatment no matter what DMA<br>
engine is used on the other side.<br>
<br>So right now I believe this code actually belongs in the mmci<br>driver albeit with the addition of vendor spec flag, like<br>.odd_st_bursts for the ST Micro versions.<br><br>We're looking into another parameter here: for some packet<br>
size say maybe < 512 DMA may just give overhead, and we may<br>want to resort to PIO. This would do away with the whole issue<br>in another way. But that's a separate issue that we need<br>to back up with measurements.<br>
<br>Yours,<br>Linus Walleij<br>