From b96c234d091381528cad1d2ee59e2474cd439501 Mon Sep 17 00:00:00 2001 From: Xianjun Jiao Date: Tue, 29 Mar 2022 10:04:25 +0200 Subject: [PATCH 1/5] Remove unnecessary ht aggr related flag reset: Don't need to reset _prev variables every time when it is not ht aggr qos data. Reason: 1. In 99.9999% cases, the ht always use qos data and goes to prio/queue_idx 2. By not resetting the variable to -1, we can have continuous aggregation packet operation in FPGA queue 2. 2. In other words, the aggregation operation for queue 2 in FPGA won't be interrupted by other non aggregation packets (control/management/beacon/etc.) that go to queue 0 (or other queues than 2). 3. From wired domain and upper level ( DSCP, AC (0~3), WMM management, 802.11D service classes and user priority (UP) ) to chip/FPGA queue index, thre should be some (complicated) mapping relationship. 4. More decent design is setting these aggregation flags (ht_aggr_start) per queue/prio here in driver. But since now only queue 2 and 0 are used (data goes to queue 2, others go to queue 0) in normal (most) cases, let's not go to the decent (complicated) solution immediately. --- driver/sdr.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/driver/sdr.c b/driver/sdr.c index 4acc641..8852dd4 100644 --- a/driver/sdr.c +++ b/driver/sdr.c @@ -911,15 +911,20 @@ static void openwifi_tx(struct ieee80211_hw *dev, { // psdu = [ MPDU ] len_psdu = len_mpdu; - - addr1_low32_prev = -1; - addr1_high16_prev = -1; - duration_id_prev = -1; - use_short_gi_prev = -1; - rate_hw_value_prev = -1; - prio_prev = -1; - retry_limit_raw_prev = -1; - pkt_need_ack_prev = -1; + + // // Don't need to reset _prev variables every time when it is not ht aggr qos data. Reason: + // // 1. In 99.9999% cases, the ht always use qos data and goes to prio/queue_idx 2. By not resetting the variable to -1, we can have continuous aggregation packet operation in FPGA queue 2. + // // 2. In other words, the aggregation operation for queue 2 in FPGA won't be interrupted by other non aggregation packets (control/management/beacon/etc.) that go to queue 0 (or other queues than 2). + // // 3. From wired domain and upper level ( DSCP, AC (0~3), WMM management, 802.11D service classes and user priority (UP) ) to chip/FPGA queue index, thre should be some (complicated) mapping relationship. + // // 4. More decent design is setting these aggregation flags (ht_aggr_start) per queue/prio here in driver. But since now only queue 2 and 0 are used (data goes to queue 2, others go to queue 0) in normal (most) cases, let's not go to the decent (complicated) solution immediately. + // addr1_low32_prev = -1; + // addr1_high16_prev = -1; + // duration_id_prev = -1; + // use_short_gi_prev = -1; + // rate_hw_value_prev = -1; + // prio_prev = -1; + // retry_limit_raw_prev = -1; + // pkt_need_ack_prev = -1; } num_dma_symbol = (len_psdu>>TX_INTF_NUM_BYTE_PER_DMA_SYMBOL_IN_BITS) + ((len_psdu&(TX_INTF_NUM_BYTE_PER_DMA_SYMBOL-1))!=0); From e3fb22a4b36efa3f72ffecdd4ac1c95361d38d17 Mon Sep 17 00:00:00 2001 From: Xianjun Jiao Date: Tue, 29 Mar 2022 10:05:33 +0200 Subject: [PATCH 2/5] gpio gain delay and rssi: Fine tune the rssi calculation sync with gpio gain (add the same gpio gain smoothing like iq_rssi in FPGA) --- driver/xpu/xpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/driver/xpu/xpu.c b/driver/xpu/xpu.c index b3603f4..7eef660 100644 --- a/driver/xpu/xpu.c +++ b/driver/xpu/xpu.c @@ -416,7 +416,7 @@ static inline u32 hw_init(enum xpu_mode mode){ } xpu_api->XPU_REG_BAND_CHANNEL_write((false<<24)|(BAND_5_8GHZ<<16)|44);//use_short_slot==false; 5.8GHz; channel 44 -- default setting to sync with priv->band/channel/use_short_slot - agc_gain_delay = 50; //samples + agc_gain_delay = 39; //samples rssi_half_db_offset = 75<<1; xpu_api->XPU_REG_RSSI_DB_CFG_write(0x80000000|((rssi_half_db_offset<<16)|agc_gain_delay) ); xpu_api->XPU_REG_RSSI_DB_CFG_write((~0x80000000)&((rssi_half_db_offset<<16)|agc_gain_delay) ); From 066dd1bba2da228e81b7943b30fbfea58dc13658 Mon Sep 17 00:00:00 2001 From: Xianjun Jiao Date: Tue, 29 Mar 2022 10:06:27 +0200 Subject: [PATCH 3/5] fine tuning of ack tx wait time for new design --- driver/xpu/xpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/driver/xpu/xpu.c b/driver/xpu/xpu.c index 7eef660..ae4c779 100644 --- a/driver/xpu/xpu.c +++ b/driver/xpu/xpu.c @@ -433,7 +433,7 @@ static inline u32 hw_init(enum xpu_mode mode){ // xpu_api->XPU_REG_CSMA_CFG_write(268435459); // Linux will do config for each queue via openwifi_conf_tx // xpu_api->XPU_REG_CSMA_CFG_write(0xe0000000); // Linux will do config for each queue via openwifi_conf_tx - xpu_api->XPU_REG_SEND_ACK_WAIT_TOP_write( ((51)<<16)|0 );//now our tx send out I/Q immediately + xpu_api->XPU_REG_SEND_ACK_WAIT_TOP_write( ((16+23)<<16)|(0+23) ); xpu_api->XPU_REG_RECV_ACK_COUNT_TOP0_write( (((45+2+2)*10 + 15)<<16) | 10 );//2.4GHz. extra 300 clocks are needed when rx core fall into fake ht detection phase (rx mcs 6M) xpu_api->XPU_REG_RECV_ACK_COUNT_TOP1_write( (((51+2+2)*10 + 15)<<16) | 10 );//5GHz. extra 300 clocks are needed when rx core fall into fake ht detection phase (rx mcs 6M) From b597510ce37484f09fb7941c91dfeb3c45676c9d Mon Sep 17 00:00:00 2001 From: Xianjun Jiao Date: Tue, 29 Mar 2022 10:11:14 +0200 Subject: [PATCH 4/5] Relax the ACK waiting condition for non block ACK case: If the packet type/sub-type is ACK and the length field is 14, we believe it is ACK. No matter the fcs is valid or not --- driver/xpu/xpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/driver/xpu/xpu.c b/driver/xpu/xpu.c index ae4c779..87463f0 100644 --- a/driver/xpu/xpu.c +++ b/driver/xpu/xpu.c @@ -435,8 +435,8 @@ static inline u32 hw_init(enum xpu_mode mode){ xpu_api->XPU_REG_SEND_ACK_WAIT_TOP_write( ((16+23)<<16)|(0+23) ); - xpu_api->XPU_REG_RECV_ACK_COUNT_TOP0_write( (((45+2+2)*10 + 15)<<16) | 10 );//2.4GHz. extra 300 clocks are needed when rx core fall into fake ht detection phase (rx mcs 6M) - xpu_api->XPU_REG_RECV_ACK_COUNT_TOP1_write( (((51+2+2)*10 + 15)<<16) | 10 );//5GHz. extra 300 clocks are needed when rx core fall into fake ht detection phase (rx mcs 6M) + xpu_api->XPU_REG_RECV_ACK_COUNT_TOP0_write( (1<<31) | (((45+2+2)*10 + 15)<<16) | 10 );//2.4GHz. extra 300 clocks are needed when rx core fall into fake ht detection phase (rx mcs 6M) + xpu_api->XPU_REG_RECV_ACK_COUNT_TOP1_write( (1<<31) | (((51+2+2)*10 + 15)<<16) | 10 );//5GHz. extra 300 clocks are needed when rx core fall into fake ht detection phase (rx mcs 6M) xpu_api->XPU_REG_DIFS_ADVANCE_write((OPENWIFI_MAX_SIGNAL_LEN_TH<<16)|2); //us. bit31~16 max pkt length threshold From 4bdc210e861d67483517f169618380d248a347ee Mon Sep 17 00:00:00 2001 From: Xianjun Jiao Date: Tue, 29 Mar 2022 10:13:16 +0200 Subject: [PATCH 5/5] Open the 4 queue gates all the time during xpu initialization --- driver/xpu/xpu.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/driver/xpu/xpu.c b/driver/xpu/xpu.c index 87463f0..00636b7 100644 --- a/driver/xpu/xpu.c +++ b/driver/xpu/xpu.c @@ -440,6 +440,36 @@ static inline u32 hw_init(enum xpu_mode mode){ xpu_api->XPU_REG_DIFS_ADVANCE_write((OPENWIFI_MAX_SIGNAL_LEN_TH<<16)|2); //us. bit31~16 max pkt length threshold + // setup time schedule of 4 slices + // slice 0 + xpu_api->XPU_REG_SLICE_COUNT_TOTAL_write(50000-1); // total 50ms + xpu_api->XPU_REG_SLICE_COUNT_START_write(0); //start 0ms + xpu_api->XPU_REG_SLICE_COUNT_END_write(50000-1); //end 50ms + + // slice 1 + xpu_api->XPU_REG_SLICE_COUNT_TOTAL_write((1<<20)|(50000-1)); // total 50ms + xpu_api->XPU_REG_SLICE_COUNT_START_write((1<<20)|(0)); //start 0ms + //xpu_api->XPU_REG_SLICE_COUNT_END_write((1<<20)|(20000-1)); //end 20ms + xpu_api->XPU_REG_SLICE_COUNT_END_write((1<<20)|(50000-1)); //end 20ms + + // slice 2 + xpu_api->XPU_REG_SLICE_COUNT_TOTAL_write((2<<20)|(50000-1)); // total 50ms + //xpu_api->XPU_REG_SLICE_COUNT_START_write((2<<20)|(20000)); //start 20ms + xpu_api->XPU_REG_SLICE_COUNT_START_write((2<<20)|(0)); //start 20ms + //xpu_api->XPU_REG_SLICE_COUNT_END_write((2<<20)|(40000-1)); //end 20ms + xpu_api->XPU_REG_SLICE_COUNT_END_write((2<<20)|(50000-1)); //end 20ms + + // slice 3 + xpu_api->XPU_REG_SLICE_COUNT_TOTAL_write((3<<20)|(50000-1)); // total 50ms + //xpu_api->XPU_REG_SLICE_COUNT_START_write((3<<20)|(40000)); //start 40ms + xpu_api->XPU_REG_SLICE_COUNT_START_write((3<<20)|(0)); //start 40ms + //xpu_api->XPU_REG_SLICE_COUNT_END_write((3<<20)|(50000-1)); //end 20ms + xpu_api->XPU_REG_SLICE_COUNT_END_write((3<<20)|(50000-1)); //end 20ms + + // all slice sync rest + xpu_api->XPU_REG_MULTI_RST_write(1<<7); //bit7 reset the counter for all queues at the same time + xpu_api->XPU_REG_MULTI_RST_write(0<<7); + printk("%s hw_init err %d\n", xpu_compatible_str, err); return(err); }