On Sun, Apr 21, 2013 at 1:12 PM, Thommy Jakobsson <thom...@gmail.com> wrote: > > > On Sun, 21 Apr 2013, Michael Büsch wrote: > >> On Sun, 21 Apr 2013 11:01:11 +0200 (CEST) >> Thommy Jakobsson <thom...@gmail.com> wrote: >> >> > Why is it set to to beyond the ring when it is initilised? >> >> That's what broadcom does in their implementation. I guess that's the only >> reason. >> > Check, I'll give index-1 a go. It should be quite obvious if it works or > not.
Thommy, I had the same thought, but notice that you also need to update ring->current_slot in b43_dma_rx_discard. When ring->current_slot update is missing (as in your original patch), you will introduce the same problem I hit by removing ops->set_current_rxslot(ring, slot) from b43_dma_rx (disabling RX underflow detection). Basically we break assumptions about ownership of descriptors (which descriptors are exclusively used by host and which can be written by DMA processor). So next time b43_dma_rx is called it may process descriptors that are updated by DMA processor at the same time (race condition). I guess the following could be used to mark all descriptors for DMA use from RX underflow interrupt or whenever we decide that number of free descriptors is too low (not tested): slot = prev_slot(ring, ops->get_current_rxslot(ring)); wmb(); ops->set_current_rxslot(ring, slot); ring->current_slot = slot; The above code simply puts back all the already filled descriptors back for DMA processor to be overwritten with new data. I'm still concerned about FIFO overruns. When descriptor underflow condition occurs while CPU is busy with b43_dma_rx, we still wait for b43_dma_rx to finish processing all received packets before any descriptors become available for DMA to use. Depending on FIFO size and CPU load we may still hit fatal receive FIFO underflow error. This should cause driver to reset (possible explanation of why "discards" and "slot_usage" files disappeared when Richlv tested your patch in https://dev.openwrt.org/ticket/7552#comment:94). I suspect that driver reset after FIFO underflow interrupt triggers is not handled correctly, but not sure why. Possibly this is not expected by hostapd, so it needs restart? Not sure if FIFO overruns are really an issue and how to prevent them. Maybe RX underflow should be handled in top half and reprogram device to suspend receives (is this possible)? Or maybe we could clean and set B43_DMA32_RXENABLE bit in B43_DMA32_RXCTL to reset DMA channel without resetting the driver? Ideas? Piotr > > //thommy _______________________________________________ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
