aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
diff options
context:
space:
mode:
authorEmmanuel Grumbach <emmanuel.grumbach@intel.com>2017-05-07 15:00:31 +0300
committerLuca Coelho <luciano.coelho@intel.com>2017-06-23 12:07:04 +0300
commitdcfbd67b4b8d5223d5362aac9af267387a32f568 (patch)
treea4ec097c5ada5b733220ad9eafa3158a8f2ced34 /drivers/net/wireless/intel/iwlwifi/pcie/tx.c
parentiwlwifi: mvm: don't mark TIDs that are not idle wrt BA as inactive (diff)
downloadlinux-dev-dcfbd67b4b8d5223d5362aac9af267387a32f568.tar.xz
linux-dev-dcfbd67b4b8d5223d5362aac9af267387a32f568.zip
iwlwifi: add a W/A for a scheduler hardware bug
In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Diffstat (limited to 'drivers/net/wireless/intel/iwlwifi/pcie/tx.c')
-rw-r--r--drivers/net/wireless/intel/iwlwifi/pcie/tx.c22
1 files changed, 21 insertions, 1 deletions
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
index 6b19ccc0ae41..9087b1fccaee 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
@@ -1277,13 +1277,14 @@ static int iwl_pcie_txq_set_ratid_map(struct iwl_trans *trans, u16 ra_tid,
* combined with Traffic ID (QOS priority), in format used by Tx Scheduler */
#define BUILD_RAxTID(sta_id, tid) (((sta_id) << 4) + (tid))
-void iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, u16 ssn,
+bool iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, u16 ssn,
const struct iwl_trans_txq_scd_cfg *cfg,
unsigned int wdg_timeout)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
struct iwl_txq *txq = trans_pcie->txq[txq_id];
int fifo = -1;
+ bool scd_bug = false;
if (test_and_set_bit(txq_id, trans_pcie->queue_used))
WARN_ONCE(1, "queue %d already used - expect issues", txq_id);
@@ -1324,6 +1325,23 @@ void iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, u16 ssn,
ssn = txq->read_ptr;
}
+ } else {
+ /*
+ * If we need to move the SCD write pointer by steps of
+ * 0x40, 0x80 or 0xc0, it gets stuck. Avoids this and let
+ * the op_mode know by returning true later.
+ * Do this only in case cfg is NULL since this trick can
+ * be done only if we have DQA enabled which is true for mvm
+ * only. And mvm never sets a cfg pointer.
+ * This is really ugly, but this is the easiest way out for
+ * this sad hardware issue.
+ * This bug has been fixed on devices 9000 and up.
+ */
+ scd_bug = !trans->cfg->mq_rx_supported &&
+ !((ssn - txq->write_ptr) & 0x3f) &&
+ (ssn != txq->write_ptr);
+ if (scd_bug)
+ ssn++;
}
/* Place first TFD at index corresponding to start sequence number.
@@ -1367,6 +1385,8 @@ void iwl_trans_pcie_txq_enable(struct iwl_trans *trans, int txq_id, u16 ssn,
"Activate queue %d WrPtr: %d\n",
txq_id, ssn & 0xff);
}
+
+ return scd_bug;
}
void iwl_trans_pcie_txq_set_shared_mode(struct iwl_trans *trans, u32 txq_id,