Create helper function ad9361_tx_calibration() and openwifi_rf_rx_update_after_tuning() for frequency tuning. No matter it is from Linux request or rf register 1 (Tx freq override MHz) and 5 (Rx freq override MHz)
1. Consider more corner cases: interrupt missing will cause a bd in the driver ring will never be cleaned. this need to be considered in the openwifi_tx()
2. Another corner case in openwifi_tx_interrupt: a packet is just sent and an interrupt calls the routine, but it finds that the bd in the driver ring has been cleared somehow
3. The driver ring and FPGA queue are always 1 on 1 mapping. User needs to map the higher level Linux priority to the driver ring idx instead of FPGA queue idx
4. Record the information about which FPGA queue (driver ring) has stopped which Linux priority before, and do exhausted search after a packet is sent (in the interrupt routine) to wake that Linux priority queue (in mac80211) up
5. Reserve more room before the FPGA queue full to adopt the last packet before we decide to stop the mac80211 queue. In this way, the last packet before the queue stop will still be put into FPGA and is expected to be sent (not lost/drop actively)
When pkt_cnt is 1, it is also possible the aggregation case (single packet aggregation). So the reporting type (non aggregation or aggregation) should be decided automatically based on a dedicated use_ht_aggr flag instead of pkt_cnt, otherwise the Linux minstrel_ht link adaptation can not get correct TX status report in the aggregation case and will keep using the lowest MCS0
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.
