linux-kernel - Re: [PATCH 2/2] dw_dmac: return proper residue value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130121142205.GB26562@intel.com>
Date:	Mon, 21 Jan 2013 06:22:05 -0800
From:	Vinod Koul <vinod.koul@...el.com>
To:	Andy Shevchenko <andriy.shevchenko@...ux.jf.intel.com>
Cc:	Andy Shevchenko <andriy.shevchenko@...ux.jf.intel.com>,
	Viresh Kumar <viresh.linux@...il.com>,
	linux-kernel@...r.kernel.org, spear-devel <spear-devel@...t.st.com>
Subject: Re: [PATCH 2/2] dw_dmac: return proper residue value

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/