Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
From: David Acker <hidden>
Date: 2007-05-24 12:42:59
Milton Miller wrote:
On May 23, 2007, at 4:32 PM, David Acker wrote:quoted
Milton Miller wrote:quoted
My current reading of the manual is that the C bit will not be set on an RFD that is size 0. It goes on to processes EL and S, and decides to stop and interrupt RNR or suspend, or just go to the next packet.I double checked this with a quick experiment and it appears you are correct. What about if we always did the following: set the size: sync(); clear el-bit sync() Then if the hardware sees just the size set, the packet completes but with the el-bit and we know we need to restart since it completed. If it sees the size == 0, and the el bit set, it stops and RNR interrupts.I think this is exposed to a hole and a race: we don't know if the hardware read the RFD before we set the size or after, just that it was before the EL bit was cleared. If it read it before the size was set, then it will not set the C bit. If it reads it after the size is set, it will complete it.
Yep...I too got sidetracked! My test time got lost to two 2 month old twins needing to be fed or else! :-)
For coherent DMA we can always observe the C bit. But for the incoherent DMA case, our store to clear the EL bit may overwrite the dma from the device to the beginning of the packet, or the write to EOF, F, and size, and/or the write to C, OK, and status bits to tell us its done. In the worst case, we would overwrite the beginning of the data but catch the C bit and even the actual size, and therefore would receive corrupted data. We can only detect the hardware went RNR when it does so or decide we won the race when it receives and completes the next frame.
Yes, I agree.
quoted
When we find a buffer that is not completed but has the el-bit set, we read the status byte of the status control block to see if the RU is in the no resources state. If it isn't, it means that we found that buffer before the hardware did and thus need to wait for it. We will either find it on the next poll or enable interrupts and get told about it by hardware. What do you think?I think the second part is good ...
Cool. That part seemed to work well in my tests. I will reply to your next mail to discuss your plan so that I get it all in one message. -Ack