[PATCH] b43: use rx desc underrun interrupt

[Piotras]

On Sun, Apr 21, 2013 at 1:12 PM, Thommy Jakobsson <thommyj at gmail.com> wrote:
>
>
> On Sun, 21 Apr 2013, Michael Büsch wrote:
>
>> On Sun, 21 Apr 2013 11:01:11 +0200 (CEST)
>> Thommy Jakobsson <thommyj at 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