1. 14 Jun, 2010 16 commits
  2. 08 Jun, 2010 8 commits
  3. 07 Jun, 2010 9 commits
  4. 06 Jun, 2010 7 commits
    • Daniel Halperin's avatar
      iwlwifi: fix wrapping when handling aggregated batches · f668da2f
      Daniel Halperin authored
      Fairly complex code in iwlagn_tx_status_reply_tx handle the status reports for
      aggregated packet batches sent by the NIC. This code aims to handle the case
      where the NIC retransmits failed packets from a previous batch; the status
      information for these packets can sometimes be inserted in the middle of a
      batch and are actually not in order by sequence number! (I verified this can
      happen with printk's in the function.)
      
      The code in question adaptively identifies the "first" frame of the batch,
      taking into account that it may not be the one corresponding to the first agg
      status report, and also handles the case when the set of sent packets wraps the
      256-character entry buffer. It generates the agg->bitmap field of sent packets
      which is later compared to the BlockAck response from the receiver to see which
      frames of those sent in this batch were ACKed. A small logic error (wrapping by
      0xff==255 instead of 0x100==256) was causing the agg->bitmap to be set
      incorrectly.
      
      Fix this wrapping code, and add extensive comments to clarify what is going on.
      Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      f668da2f
    • Daniel Halperin's avatar
      iwlwifi: parse block ack responses correctly · 02cd8dee
      Daniel Halperin authored
      Compressed BlockAck frames store the ACKs/NACKs in a 64-bit bitmap that starts
      at the sequence number of the first frame sent in the aggregated batch. Note
      that this is a selective ACKnowledgement following selective retransmission;
      e.g., if frames 1,4-5 in a batch are ACKed then the next transmission will
      include frames 2-3,6-10 (7 frames). In this latter case, the Compressed
      BlockAck will not have all meaningful information in the low order bits -- the
      semantically meaningful bits of the BA will be 0x1f3 (where the low-order frame
      is seq 2).
      
      The driver code originally just looked at the lower (in this case, 7) bits of
      the BlockAck. In this case, the lower 7 bits of 0x1f3 => only 5 packets,
      maximum, could ever be ACKed. In reality it should be looking at all of the
      bits, filtered by those corresponding to packets that were actually sent. This
      flaw meant that the number of correctly ACked packets could be significantly
      underreported and might result in asynchronous state between TX and RX sides as
      well as driver and uCode.
      
      Fix this and also add a shortcut that doesn't require the code to loop through
      all 64 bits of the bitmap but rather stops when no higher packets are ACKed.
      
      In my experiments this fix greatly reduces throughput swing, making throughput
      stable and high. It is also likely related to some of the stalls observed in
      aggregation mode and maybe some of the buffer underruns observed, e.g.,
      
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1968
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2098
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2018Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      02cd8dee
    • Wey-Yi Guy's avatar
      iwlwifi: remove unused parameter · 18ab9f1e
      Wey-Yi Guy authored
      framecnt_to_us is not used, remove it
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      18ab9f1e
    • Johannes Berg's avatar
      iwlwifi: queue user-initiated scan when doing internal scan · f84b29ec
      Johannes Berg authored
      The internal scanning created a problem where
      when userspace tries to scan, the scan gets
      rejected. Instead of doing that, queue up the
      user-initiated scan when doing an internal
      scan.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      f84b29ec
    • Johannes Berg's avatar
      iwlwifi: generic scan TX antenna forcing · 0e1654fa
      Johannes Berg authored
      In "iwlwifi: make scan antenna forcing more generic"
      I introduced generic scan RX antenna forcing, which
      here I rename to make it more evident. Also add scan
      TX antenna forcing, since I will need that as well.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      0e1654fa
    • Wey-Yi Guy's avatar
      iwlwifi: do not use huge command buffer for channel switch · 3839f7ce
      Wey-Yi Guy authored
      Channel switch host command do not need to allocate huge command buffer
      since its size is already included in the iwl_device_cmd structure.
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      3839f7ce
    • Johannes Berg's avatar
      iwlwifi: reduce memory allocation · ff0d91c3
      Johannes Berg authored
      Currently, the driver allocates up to 19 skb pointers
      for each TFD, of which we have 256 per queue. This
      means that for each TX queue, we allocate 19k/38k
      (an order 4 or 5 allocation on 32/64 bit respectively)
      just for each queue's "txb" array, which contains only
      the SKB pointers.
      
      However, due to the way we use these pointers only the
      first one can ever be assigned. When the driver was
      initially written, the idea was that it could be
      passed multiple SKBs for each TFD and attach all
      those to implement gather DMA. However, due to
      constraints in the userspace API and lack of TCP/IP
      level checksumming in the device, this is in fact not
      possible. And even if it were, the SKBs would be
      chained, and we wouldn't need to keep pointers to
      each anyway.
      
      Change this to only keep track of one SKB per TFD,
      and thereby reduce memory consumption to just one
      pointer per TFD, which is an order 0 allocation per
      transmit queue.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      ff0d91c3