1. 29 7月, 2015 1 次提交
  2. 24 7月, 2015 3 次提交
  3. 02 7月, 2015 1 次提交
    • R
      ath10k: configure frag desc memory to target for qca99X0 · d9156b5f
      Raja Mani 提交于
      Pre qca99X0 chipsets follows the model where dynamically allocate
      memory for frag desc on getting new skb for TX. But, this is not
      going to be the case in qca99X0. It expects frag desc memory to be
      allocated at boot time and let the driver to reuse allocated memory
      after every TX completion. So there won't be any dynamic frag memory
      memory allocation in qca99X0 during data transmission.
      
      qca99X0 hardware doesn't need fragment desc address to be programmed
      in msdu descriptor for every data transaction. It needs to know only
      starting address of fragment descriptor at the time of the boot.
      During data transmission, qca99X0 hardware can retrieve corresponding
      frag addr by adding programmed frag desc base addr + msdu id.
      
      Allocate continuous fragment descriptor memory (same size as number of
      descriptor) at the time of target initialization and configure allocated
      dma address to the target via HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG.
      
      How this is allocated continuous memory is going to be used is not
      covered in this patch. It just allocates memory and hand over to firmware.
      If we don't do it at init time, qca99X0 will stall when firmware tries
      to do TX.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d9156b5f
  4. 02 4月, 2015 1 次提交
  5. 30 3月, 2015 1 次提交
  6. 04 2月, 2015 1 次提交
  7. 27 1月, 2015 2 次提交
  8. 13 1月, 2015 1 次提交
  9. 08 12月, 2014 1 次提交
  10. 26 11月, 2014 1 次提交
  11. 17 11月, 2014 1 次提交
  12. 31 10月, 2014 1 次提交
    • M
      ath10k: speed up hw recovery · 7962b0d8
      Michal Kazior 提交于
      In some cases hw recovery was taking an absurdly
      long time due to ath10k waiting for things that
      would never really complete.
      
      Instead of waiting for inevitable timeouts poke
      all completions and wakequeues and check if it's
      still worth waiting.
      
      Reading/writing ar->state requires conf_mutex.
      Since waiters might be holding it introduce a new
      flag CRASH_FLUSH so it's possible to tell waiters
      to abort whatever they were waiting for.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7962b0d8
  13. 08 10月, 2014 1 次提交
  14. 07 10月, 2014 1 次提交
  15. 18 9月, 2014 2 次提交
  16. 27 8月, 2014 1 次提交
  17. 22 7月, 2014 1 次提交
    • M
      ath10k: prevent some tx flushing failures · 708b9bde
      Michal Kazior 提交于
      Firmware could request inspection of some
      submitted tx requests. Since the callback wasn't
      implemented it was possible to bleed tx msdu_ids
      which could translate to tx flushing timeouts.
      
      There's nothing ath10k can do to help firmware
      with tx processing now so just report all tx
      frames as already inspected to prevent firmware
      from sending up inspection events and force it to
      report regular tx completion indications with
      discard status.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      708b9bde
  18. 14 7月, 2014 1 次提交
  19. 23 5月, 2014 1 次提交
  20. 28 2月, 2014 3 次提交
    • M
      ath10k: reduce htt tx/rx spinlock overhead · 45967089
      Michal Kazior 提交于
      It is inefficient to grab irqsave spinlocks for
      skb lists for each queue/dequeue action.
      
      Using rx_ring.lock and tx_lock allows to use less
      heavy bh spinlock functions and moving locking
      upwards allows to toggle spinlocks less often.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      45967089
    • M
      ath10k: bypass htc for htt tx path · a16942e6
      Michal Kazior 提交于
      Going through full htc tx path for htt tx is a
      waste of resources. By skipping it it's possible
      to easily submit scatter-gather to the pci hif for
      reduced host cpu load and improved performance.
      
      The new approach uses dma pool to store the
      following metadata for each tx request:
       * msdu fragment list
       * htc header
       * htt tx command
      
      The htt tx command contains a msdu prefetch.
      Instead of copying it original mapped msdu address
      is used to submit a second scatter-gather item to
      hif to make a complete htt tx command.
      
      The htt tx command itself hands over dma mapped
      pointers to msdus and completion of the command
      itself doesn't mean the frame has been sent and
      can be unmapped/freed. This is why htc tx
      completion is skipped for htt tx as all tx related
      resources are freed upon htt tx completion
      indication event (which also implicitly means htt
      tx command itself was completed).
      
      Since now each htt tx request effectively consists
      of 2 copy engine items CE_HTT_H2T_MSG_SRC_NENTRIES
      is updated to allow maximum of
      TARGET_10X_NUM_MSDU_DESC msdus being queued. This
      keeps the tx path resource management simple.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a16942e6
    • M
      ath10k: remove DMA mapping wrappers · 767d34fc
      Michal Kazior 提交于
      There's no real benefit from using them. DMA-API
      already provides debugging. Some skbuffs are
      already mapped directly with DMA-API since wrapper
      arguments were insufficient and extending them
      would be pointless.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      767d34fc
  21. 13 2月, 2014 1 次提交
  22. 21 10月, 2013 1 次提交
  23. 27 9月, 2013 1 次提交
  24. 20 9月, 2013 4 次提交
  25. 12 9月, 2013 1 次提交
  26. 06 9月, 2013 1 次提交
  27. 15 8月, 2013 1 次提交
  28. 02 8月, 2013 1 次提交
  29. 30 7月, 2013 2 次提交
  30. 13 6月, 2013 1 次提交
    • K
      ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices · 5e3dd157
      Kalle Valo 提交于
      Here's a new mac80211 driver for Qualcomm Atheros 802.11ac QCA98xx devices.
      A major difference from ath9k is that there's now a firmware and
      that's why we had to implement a new driver.
      
      The wiki page for the driver is:
      
      http://wireless.kernel.org/en/users/Drivers/ath10k
      
      The driver has had many authors, they are listed here alphabetically:
      
      Bartosz Markowski <bartosz.markowski@tieto.com>
      Janusz Dziedzic <janusz.dziedzic@tieto.com>
      Kalle Valo <kvalo@qca.qualcomm.com>
      Marek Kwaczynski <marek.kwaczynski@tieto.com>
      Marek Puzyniak <marek.puzyniak@tieto.com>
      Michal Kazior <michal.kazior@tieto.com>
      Sujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5e3dd157