On Sunday 01 February 2009 00:35:01 Francesco Gringoli wrote: > On Jan 30, 2009, at 10:59 PM, Michael Buesch wrote: > > > On Friday 30 January 2009 14:22:35 Lorenzo Nava wrote: > >>> I think that's rather unlikely, however. The DMA code is basically > >>> unchanged > >>> for months and especially the slot handling hasn't changed in years. > >>> > >> > >> Yes, but I didn't mean that the code has some bug. Let's say, for > >> example, that all the DMA slots were filled; when the firmware will > >> try to report a tx status it will send the informations to the DMA. > >> The DMA won't have enough space to store it and so it will drop the > >> message. In your opinion is it possible that something like that > >> happened? > > > > No. TX status isn't passed through DMA in >=rev5 cores. > > It's passed through MMIO registers which access an internal hardware > > queue. > Michael, > > sorry, I have a question, there is a piece of code I do not > understand. I see from specs that this queue (that is filled by the > firmware to report status to host) _seems_ to be 16 positions long. I > would say that this value should be taken as an upper limit in the > number of frames sent on the dma and still not acked (positively or > not, depending on tx success) by the firmware. Is this correct? I did > some tests and I saw that the number of frames sent through > op32_poke_tx before corresponding status being reported greatly > exceeds 16.
The driver just puts the stuff into the DMA ring. It can put as much stuff into the ring as it wants, as it allocated the ring. The _firmware_ must make sure to accept new packets from dma _only_ if its buffers are not filled. That includes the tx status report buffer. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
