On Mon, Jan 21, 2013 at 11:45:51AM +0200, Andy Shevchenko wrote: > > > + return 0; > > hmmm, why not use BLOCK_TS value. That way you dont need to look at > > direction > > and along with burst can easily calculate residue... > > Do you mean to read CTL hi/lo and do > > desc->len - ctlhi.block_ts * ctllo.src_tr_width? > Yes > I think it could be not precise when memory-to-peripheral transfer is > going on. In that case you probably will have src_tr_width like 32 bits, > meanwhile peripheral may receive only byte stream. Nope that is not the case. SAR/DAR is always incremented in src/dstn_tr_width granularity. For example if you are using MEM to DMA, then SAR will always increment in case of x86 in 4byte granularity as we will read bursts not singles.
Also if check the spec, it says "Once the transfer starts, the read-back value is the total number of data items already read from the source peripheral, regardless of what is the flow controller" So basically you get what is read from buffer in case of MEM->PER and get what is read from FIFO in case of PER->MEM which IMO gives you better or equal results than your calulation. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
