On Thu, Feb 22, 2018 at 12:39:55PM +0100, Maxime Jayat wrote: > Despite the efforts made to correctly read the NDA and CUBC registers, > the order in which the registers are read could sometimes lead to an > inconsistent state. > > Re-using the timeline from the comments, this following timing of > registers reads could lead to reading NDA with value "@desc2" and > CUBC with value "MAX desc1": > > INITD -------- ------------ > |____________________| > _______________________ _______________ > NDA @desc2 \/ @desc3 > _______________________/\_______________ > __________ ___________ _______________ > CUBC 0 \/ MAX desc1 \/ MAX desc2 > __________/\___________/\_______________ > | | | | > Events:(1)(2) (3)(4) > > (1) check_nda = @desc2 > (2) initd = 1 > (3) cur_ubc = MAX desc1 > (4) cur_nda = @desc2 > > This is allowed by the condition ((check_nda == cur_nda) && initd), > despite cur_ubc and cur_nda being in the precise state we don't want. > > This error leads to incorrect residue computation. > > Fix it by inversing the order in which CUBC and INITD are read. This > makes sure that NDA and CUBC are always read together either _before_ > INITD goes to 0 or _after_ it is back at 1. > The case where NDA is read before INITD is at 0 and CUBC is read after > INITD is back at 1 will be rejected by check_nda and cur_nda being > different. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
