AW: b43: ac rev1 captured packets with ampdu

[andreas.wendleder]

Hi Alessio,

Three findings on the MacBookAir6,1 (2.4 GHz, ucode 832.127), all thanks to your code and captures:

1. RX level. Your rxgainctrl write 0x1726 = 0x000c is worth 26 dB here. With it my remaining PHY table replay is gone.
2. Second TX chain. The chipcontrol |= 0x8 at the end of your fem2_sub1_setup is what turns on TX on core 1. I had ported the two PHY writes but not that one: core 1 did not radiate and MCS 8–15 failed completely. The bit survives a module reload, so it only shows after a cold boot.
3. A-MPDU TX works, with the microcode building the aggregates as in your notes. What it needed beyond 0x45c0 and the cache info:
   - the frame's seq_ctrl in the header's sequence field;
   - cache info bytes 0–1 zero when encrypting in software. The stock 50 04 makes the microcode encrypt again: the AP acks the frame and drops it;
   - session frames reported to mac80211 with IEEE80211_TX_STAT_AMPDU, or minstrel_ht ignores them;
   - the attempt count of a status (word 2, bits 7:0) divided by its MPDU count;
   - a requeue in the driver for MPDUs the microcode reports unacked. It gives up after a few attempts, and without the requeue TCP collapses.

   Result: about 30 Mbit/s up at HT20 over 15 minutes, against 20 at legacy rates.

One question: my TX gain sits at index 64 of acphy_txgain_epa_2g_2069rev4 (the reset value), and going to index 96 collapses the link at 1 m from the AP. Have you seen what a healthy board transmits with on 2.4 GHz, or is there more to the PA/FEM setup than fem2_sub1_setup?

Thanks, Andreas