Previously, we would store the operating mode at interface up time,
but only update the PCU registers when the next reset happened.
The result is that if beacon configuration (ops->bss_info_changed)
happens before ops->config, we will program the wrong things into
the timer registers. Consequently, beacons won't work in AP mode
until after a reset (channel change, scan etc.).
This is fragile anyway so just program the opmode as soon as
mac80211 gives it to us.
Signed-off-by: Bob Copeland <[email protected]>
---
drivers/net/wireless/ath/ath5k/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 7db32ce..55ee976 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1117,6 +1117,8 @@ ath5k_mode_setup(struct ath5k_softc *sc)
struct ath5k_hw *ah = sc->ah;
u32 rfilt;
+ ah->ah_op_mode = sc->opmode;
+
/* configure rx filter */
rfilt = sc->filter_flags;
ath5k_hw_set_rx_filter(ah, rfilt);
@@ -2768,6 +2770,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
}
ath5k_hw_set_lladdr(sc->ah, conf->mac_addr);
+ ath5k_mode_setup(sc);
ret = 0;
end:
--
1.6.2.5
On Wed, Jul 29, 2009 at 4:06 PM, Nick Kossifidis<[email protected]> wrote:
> 2009/7/29 Bob Copeland <[email protected]>:
> 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 %% http://www.bobcopeland.com
We need to process tx descriptors for all queues (currently main tx
queue and cabq) which may have triggered the TX completion interrupt.
Otherwise, the queues can get stuck after sending a few frames.
Signed-off-by: Bob Copeland <[email protected]>
---
John, hand-edited this one to remove the queue config stuff for now.
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 55ee976..3a1c156 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2000,9 +2000,12 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
static void
ath5k_tasklet_tx(unsigned long data)
{
+ int i;
struct ath5k_softc *sc = (void *)data;
- ath5k_tx_processq(sc, sc->txq);
+ for (i=0; i < AR5K_NUM_TX_QUEUES; i++)
+ if (sc->txqs[i].setup && (sc->ah->ah_txq_isr & BIT(i)))
+ ath5k_tx_processq(sc, &sc->txqs[i]);
}
We need to process tx descriptors for all queues (currently main tx
queue and cabq) which may have triggered the TX completion interrupt.
Otherwise, the queues can get stuck after sending a few frames.
Also, the CAB queue does need to be DBA (DMA beacon alert) gated, as
in ath9k and madwifi, instead of beacon sent gated or the CAB frames
may not be sent at the right time.
Signed-off-by: Bob Copeland <[email protected]>
---
drivers/net/wireless/ath/ath5k/base.c | 5 ++++-
drivers/net/wireless/ath/ath5k/qcu.c | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 55ee976..3a1c156 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2000,9 +2000,12 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
static void
ath5k_tasklet_tx(unsigned long data)
{
+ int i;
struct ath5k_softc *sc = (void *)data;
- ath5k_tx_processq(sc, sc->txq);
+ for (i=0; i < AR5K_NUM_TX_QUEUES; i++)
+ if (sc->txqs[i].setup && (sc->ah->ah_txq_isr & BIT(i)))
+ ath5k_tx_processq(sc, &sc->txqs[i]);
}
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index 6d5aaf0..d7d5d11 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -409,7 +409,7 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
case AR5K_TX_QUEUE_CAB:
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
- AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
+ AR5K_QCU_MISC_FRSHED_DBA_GT |
AR5K_QCU_MISC_CBREXP_DIS |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
--
1.6.2.5
2009/7/29 Bob Copeland <[email protected]>:
> We need to process tx descriptors for all queues (currently main tx
> queue and cabq) which may have triggered the TX completion interrupt.
> Otherwise, the queues can get stuck after sending a few frames.
>
> Also, the CAB queue does need to be DBA (DMA beacon alert) gated, as
> in ath9k and madwifi, instead of beacon sent gated or the CAB frames
> may not be sent at the right time.
>
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).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick