Linux only sets that field for non-ht, and leaves the field blank for ht. Linux expects lower level set it. This is realized after checking the mac80211 source code. After studying the duration/id field of COTS WiFi chip by wireshark, we calculate it in driver sdr.c gen_ht_duration_id(). The concrete logic/method of the calculation is in the comments of the function gen_ht_duration_id().
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.
- Manually issue Tx Quadrature calibration if frequency change is more than 100MHz
- Disable FPGA SPI module before calibration
- Add xpu reg 13 to disable control manually
- 2022-03-04 detailed test result:
- - bb_gain 290 work for 11a/g all mcs
- - bb_gain 290 work for 11n mcs 1~7 (aggr and non aggr)
- - bb_gain 290 destroy 11n mcs 0 long (MTU 1500) tx pkt due to high PAPR (Peak to Average Power Ratio)
- - bb_gain 250 work for 11n mcs 0
So, a conservative bb_gain 250 should be used
1. mixer/duc is not needed because we will not use offset tuning after the ad9361 tx lo control via FPGA is supported.
2. source selection register is not needed as well.
3. arbitrary IQ register is added.
Some client, like iPhone, always has frequent PS (Power Saving) state change like this:
sdr0: STA e2:72:49:82:a6:a0 aid 1 enters power save mode
sdr0: STA e2:72:49:82:a6:a0 aid 1 exits power save mode
sdr0: STA e2:72:49:82:a6:a0 aid 1 sending 0 filtered/0 PS frames since STA woke up
Now with these correct hw flag setting, the link is more stable
