On Wed, Jul 29, 2009 at 4:06 PM, Nick Kossifidis<mickflemm@xxxxxxxxx> wrote: > 2009/7/29 Bob Copeland <me@xxxxxxxxxxxxxxx>: > I think we are doing the wrong thing, CAB queue is supposed to fire > after beacon queue. Ath9k fires up cab queue and beacon queue at the > same time and uses ready time to hold cab queue for a fixed interval. > Try to remove the readytime stuff from cab queue and i guess it'll > work fine (now we fire it after the beacon queue AND wait for a beacon > transmition period). Yeah I was getting almost no delivery of buffered frames without that change, but I didn't check the delivery time to see if they were too late, which they probably are. So you are saying keep BCN_SENT_GT, but remove this: ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL - (AR5K_TUNE_SW_BEACON_RESP - AR5K_TUNE_DMA_BEACON_RESP) - AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) | AR5K_QCU_RDYTIMECFG_ENABLE, AR5K_QUEUE_RDYTIMECFG(queue)); I'll give it ago. Maybe split that part out because the process tx queue fix is obvious enough. (Now I see that the similar-to-above-stuff from madwifi is only compat code and also uses a readyTime like ath9k. Ah.) -- Bob Copeland %% www.bobcopeland.com -- 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
