On Sun, 5 May 2013, Michael B?sch wrote: > On Sun, 5 May 2013 21:50:33 +0200 > Rafa? Mi?ecki <zajec5@xxxxxxxxx> wrote: > > > 2013/5/5 Michael B?sch <m@xxxxxxx>: > > > On Sun, 5 May 2013 18:31:20 +0200 > > > Rafa? Mi?ecki <zajec5@xxxxxxxxx> wrote: > > > > > >> Still worth considering is my previous e-mail. Why writing (for > > >> example) 1 to RXSTOPINDEX doesn't stop firmware from using slot 1? > > > > > > What makes you think this register does not work? > > > > Take a look at this: > > > > [ 327.224976] [DBG] old current:5 new current:6 > > [ 327.224982] [DBG] reading slot 5 > > [ 327.224997] [DBG] writing stop slot 6 > > > > In above ring->slot was 5, but IRQ was generated, and we read new > > "current" using get_current_rxslot. It appeared to be 6. So we read > > packet from slot 5 and then called > > ops->set_current_rxslot(ring, 6); > > AFAIU hardware shouldn't use slot 6, right? But take a look at what > > happens next: > > > > [ 327.319582] [DBG] old current:6 new current:7 > > [ 327.319590] [DBG] reading slot 6 > > [ 327.319619] [DBG] writing stop slot 7 > > > > Hardware generated IRQ and we get_current_rxslot returned 7. It means > > we're allowed to read slots up to 7 (excluding). It other words it > > means firmware used slot 6... but 100ms earlier we forbid firmware to > > use slot 6! > > I'd rather say that this is a race condition between your testing code > and the firmware. If I understood Rafael this is the normal rx-code (with some printouts). When you use set_current_rxslot you dont forbid the hardware to use slot 6, you say that the last slot that you can use is 5.So the firmware actually checks if we step from 5 to 6, not if the slot is 6. //Thommy -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
