From 39be7dc384e0dd45dc36b4b517fd9fae874b06f0 Mon Sep 17 00:00:00 2001 From: Christian Lamparter Date: Fri, 17 Dec 2010 18:56:35 +0100 Subject: [PATCH] carl9170 firmware: clarify aggregation vs. qos situation Signed-off-by: Christian Lamparter --- include/shared/wlan.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/include/shared/wlan.h b/include/shared/wlan.h index 24d63b5..ff3b917 100644 --- a/include/shared/wlan.h +++ b/include/shared/wlan.h @@ -413,6 +413,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 -- 2.31.1