carl9170 firmware: per-vif tx sequence counter

[carl9170fw.git] / include / shared / wlan.h

diff --git a/include/shared/wlan.h b/include/shared/wlan.h
index 24d63b583b6b08459d657055d70836c621106177..9e1324b67e08e19cc0bea538b74ed9ab0b5fb924 100644 (file)
--- a/include/shared/wlan.h
+++ b/include/shared/wlan.h
@@ -251,7 +251,7 @@ struct carl9170_tx_superdesc {
        u8 ampdu_commit_factor:1;
        u8 ampdu_unused_bit:1;
        u8 queue:2;
-       u8 reserved:1;
+       u8 assign_seq:1;
        u8 vif_id:3;
        u8 fill_in_tsf:1;
        u8 cab:1;
@@ -299,6 +299,7 @@ struct _ar9170_tx_hwdesc {
 
 #define CARL9170_TX_SUPER_MISC_QUEUE                   0x3
 #define CARL9170_TX_SUPER_MISC_QUEUE_S                 0
+#define CARL9170_TX_SUPER_MISC_ASSIGN_SEQ              0x4
 #define        CARL9170_TX_SUPER_MISC_VIF_ID                   0x38
 #define        CARL9170_TX_SUPER_MISC_VIF_ID_S                 3
 #define        CARL9170_TX_SUPER_MISC_FILL_IN_TSF              0x40
@@ -413,6 +414,23 @@ enum ar9170_txq {
        __AR9170_NUM_TXQ,
 };
 
+/*
+ * This is an workaround for several undocumented bugs.
+ * Don't mess with the QoS/AC <-> HW Queue map, if you don't
+ * know what you are doing.
+ *
+ * Known problems [hardware]:
+ *  * The MAC does not aggregate frames on anything other
+ *    than the first HW queue.
+ *  * when an AMPDU is placed [in the first hw queue] and
+ *    additional frames are already queued on a different
+ *    hw queue, the MAC will ALWAYS freeze.
+ *
+ * In a nutshell: The hardware can either do QoS or
+ * Aggregation but not both at the same time. As a
+ * result, this makes the device pretty much useless
+ * for any serious 802.11n setup.
+ */
 static const u8 ar9170_qmap[__AR9170_NUM_TXQ] = { 2, 1, 0, 3 };
 
 #define        AR9170_TXQ_DEPTH                        32