On Feb 1, 2009, at 12:49 AM, Michael Buesch wrote: > On Sunday 01 February 2009 00:47:35 Michael Buesch wrote: >> 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. > > The tx-status-queue-full condition most likely is an external > condition > in the firmware. Don't ask me which one, however. Ok, this could be a problem. Will check next days how to solve. I suppose now that the length of that report_tx_status queue is very device dependent as mine can grow it more than one hundred elements and status continues to be correctly reported.
Cheers, -FG > > > -- > Greetings, Michael. ------- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
