1. 16 1月, 2018 1 次提交
    • K
      ath10k: fix recently introduced checkpatch warnings · a3e712b7
      Kalle Valo 提交于
      Checkpatch found these issues:
      
      drivers/net/wireless/ath/ath10k/ce.h:324: Please use a blank line after function/struct/union/enum declarations
      drivers/net/wireless/ath/ath10k/core.c:1321: Please don't use multiple blank lines
      drivers/net/wireless/ath/ath10k/htt.h:1859: Please use a blank line after function/struct/union/enum declarations
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a3e712b7
  2. 09 1月, 2018 1 次提交
  3. 27 12月, 2017 7 次提交
  4. 14 12月, 2017 2 次提交
    • A
      ath10k: add per peer tx stats support for 10.2.4 · e8123bb7
      Anilkumar Kolli 提交于
      10.2.4 firmware branch (used in QCA988X) does not support
      HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide
      tranmission rate statistics to user space, instead it just shows
      hardcoded 6 Mbit/s. But pktlog firmware facility provides per peer tx
      statistics. The firmware sends one pktlog event for every four
      PPDUs per peer, which include:
      
      * successful number of packets and bytes transmitted
      * number of packets and bytes dropped
      * retried number of packets and bytes
      * rate info per ppdu
      
      Firmware supports WMI_SERVICE_PEER_STATS, pktlog is enabled through
      ATH10K_FLAG_PEER_STATS, which is nowadays enabled by default in ath10k.
      
      This patch does not impact throughput.
      
      Tested on QCA9880 with firmware version 10.2.4.70.48. This should also
      work with firmware branch 10.2.4-1.0-00029
      
      Parse peer stats from pktlog packets and update the tx rate information
      per STA. This way user space can query about transmit rate with iw:
      
      $iw wlan0 station dump
      Station 3c:a9:f4:72:bb:a4 (on wlan1)
              inactive time:  8210 ms
              rx bytes:       9166
              rx packets:     44
              tx bytes:       1105
              tx packets:     9
              tx retries:     0
              tx failed:      1
              rx drop misc:   3
              signal:         -75 [-75, -87, -88] dBm
              signal avg:     -75 [-75, -85, -88] dBm
              tx bitrate:     39.0 MBit/s MCS 10
              rx bitrate:     26.0 MBit/s MCS 3
              rx duration:    23250 us
              authorized:     yes
              authenticated:  yes
              associated:     yes
              preamble:       short
              WMM/WME:        yes
              MFP:            no
              TDLS peer:      no
              DTIM period:    2
              beacon interval:100
              short preamble: yes
              short slot time:yes
              connected time: 22 seconds
      Signed-off-by: NAnilkumar Kolli <akolli@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e8123bb7
    • R
      ath10k: unify rx processing in napi_poll · deba1b9e
      Rajkumar Manoharan 提交于
      With current NAPI implementation, NAPI poll can deliver more frames
      to net core than allotted budget. This may cause warning in napi_poll.
      Remaining quota is not accounted, while processing amsdus in
      rx_in_ord_ind and rx_ind queue. Adding num_msdus at last can not
      prevent delivering more frames to net core. With this change,
      all amdus from both in_ord_ind and rx_ind queues are processed and
      enqueued into common skb list instead of delivering into mac80211.
      Later msdus from common queue are dequeued and delivered depends on
      quota availability. This change also simplifies the rx processing in
      napi poll routine.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      deba1b9e
  5. 05 4月, 2017 1 次提交
  6. 07 2月, 2017 2 次提交
  7. 01 12月, 2016 1 次提交
    • M
      ath10k: fix Tx DMA alloc failure during continuous wifi down/up · 9ec34a86
      Mohammed Shafi Shajakhan 提交于
      With maximum number of vap's configured in a two radio supported
      systems of ~256 Mb RAM, doing a continuous wifi down/up and
      intermittent traffic streaming from the connected stations results
      in failure to allocate contiguous memory for tx buffers. This results
      in the disappearance of all VAP's and a manual reboot is needed as
      this is not a crash (or) OOM(for OOM killer to be invoked). To address
      this allocate contiguous memory for tx buffers one time and re-use them
      until the modules are unloaded but this results in a slight increase in
      memory footprint of ath10k when the wifi is down, but the modules are
      still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
      to keep track of the one time memory allocation, as we cannot come up
      with something like 'ath10k_tx_{register,unregister}' before
      'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
      memory allocation is dependent on the hw_param 'continuous_frag_desc'
      
      a) memory footprint of ath10k without the change
      
      lsmod | grep ath10k
      ath10k_core           414498  1 ath10k_pci
      ath10k_pci             38236  0
      
      b) memory footprint of ath10k with the change
      
      ath10k_core           414980  1 ath10k_pci
      ath10k_pci             38236  0
      
      Memory Failure Call trace:
      
      hostapd: page allocation failure: order:6, mode:0xd0
       [<c021f150>] (__dma_alloc_buffer.isra.23) from
      [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
      [<c021f23c>] (__alloc_remap_buffer.isra.26) from
      [<c021f664>] (__dma_alloc+0x224/0x2b8)
      [<c021f664>] (__dma_alloc) from [<c021f810>]
      (arm_dma_alloc+0x84/0x90)
      [<c021f810>] (arm_dma_alloc) from [<bf954764>]
      (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
      [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
      [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
      [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
      [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
      [<bf947eec>] (ath10k_start [ath10k_core]) from
      [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
      [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
      (ieee80211_do_open+0x170/0x82c [mac80211])
      [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
      [<c056afc8>] (__dev_open+0xa0/0xf4)
      [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
      126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
      0*1024kB 0*2048kB 0*4096kB = 95276kB
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      9ec34a86
  8. 24 11月, 2016 1 次提交
  9. 27 9月, 2016 1 次提交
  10. 09 9月, 2016 1 次提交
    • R
      ath10k: implement NAPI support · 3c97f5de
      Rajkumar Manoharan 提交于
      Add NAPI support for rx and tx completion. NAPI poll is scheduled
      from interrupt handler. The design is as below
      
       - on interrupt
           - schedule napi and mask interrupts
       - on poll
         - process all pipes (no actual Tx/Rx)
         - process Rx within budget
         - if quota exceeds budget reschedule napi poll by returning budget
         - process Tx completions and update budget if necessary
         - process Tx fetch indications (pull-push)
         - push any other pending Tx (if possible)
         - before resched or napi completion replenish htt rx ring buffer
         - if work done < budget, complete napi poll and unmask interrupts
      
      This change also get rid of two tasklets (intr_tq and txrx_compl_task).
      
      Measured peak throughput with NAPI on IPQ4019 platform in controlled
      environment. No noticeable reduction in throughput is seen and also
      observed improvements in CPU usage. Approx. 15% CPU usage got reduced
      in UDP uplink case.
      
      DL: AP DUT Tx
      UL: AP DUT Rx
      
      IPQ4019 (avg. cpu usage %)
      
      ========
                      TOT              +NAPI
                    ===========      =============
      TCP DL       644 Mbps (42%)    645 Mbps (36%)
      TCP UL       673 Mbps (30%)    675 Mbps (26%)
      UDP DL       682 Mbps (49%)    680 Mbps (49%)
      UDP UL       720 Mbps (28%)    717 Mbps (11%)
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      3c97f5de
  11. 14 6月, 2016 1 次提交
  12. 21 4月, 2016 1 次提交
  13. 14 4月, 2016 1 次提交
  14. 04 4月, 2016 4 次提交
  15. 18 3月, 2016 2 次提交
    • R
      ath10k: move mgmt descriptor limit handle under mgmt_tx · cac08552
      Rajkumar Manoharan 提交于
      Frames that are transmitted via MGMT_TX are using reserved descriptor
      slots in firmware. This limitation is for the htt_mgmt_tx path itself,
      not for mgmt frames per se. In 16 MBSSID scenario, these reserved slots
      will be easy exhausted due to frequent probe responses. So for 10.4
      based solutions, probe responses are limited by a threshold (24).
      
      management tx path is separate for all except tlv based solutions. Since
      tlv solutions (qca6174 & qca9377) do not support 16 AP interfaces, it is
      safe to move management descriptor limitation check under mgmt_tx
      function. Though CPU improvement is negligible, unlikely conditions or
      never hit conditions in hot path can be avoided on data transmission.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      cac08552
    • R
      ath10k: handle channel change htt event · 2ce9b25c
      Rajkumar Manoharan 提交于
      Whenever firmware is configuring operating channel during scan or
      home channel, channel change event will be indicated to host. In some
      cases (device probe/ last vdev down), target will be configured to
      default channel whereas host is unaware of target's operating channel.
      This leads to packet drop due to unknown channel and kernel log will be
      filled up with "no channel configured; ignoring frame(s)!". Fix that
      by handling HTT_T2H_MSG_TYPE_CHAN_CHANGE event.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      2ce9b25c
  16. 06 3月, 2016 4 次提交
    • M
      ath10k: implement push-pull tx · 426e10ea
      Michal Kazior 提交于
      The current/old tx path design was that host, at
      its own leisure, pushed tx frames to the device.
      For HTT there was ~1000-1400 msdu queue depth.
      
      After reaching that limit the driver would request
      mac80211 to stop queues. There was little control
      over what packets got in there as far as
      DA/RA was considered so it was rather easy to
      starve per-station traffic flows.
      
      With MU-MIMO this became a significant problem
      because the queue depth was insufficient to buffer
      frames from multiple clients (which could have
      different signal quality and capabilities) in an
      efficient fashion.
      
      Hence the new tx path in 10.4 was introduced: a
      pull-push mode.
      
      Firmware and host can share tx queue state via
      DMA. The state is logically a 2 dimensional array
      addressed via peer_id+tid pair. Each entry is a
      counter (either number of bytes or packets. Host
      keeps it updated and firmware uses it for
      scheduling Tx pull requests to host.
      
      This allows MU-MIMO to become a lot more effective
      with 10+ clients.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      426e10ea
    • M
      ath10k: implement updating shared htt txq state · c1a43d97
      Michal Kazior 提交于
      Firmware 10.4.3 onwards can support a pull-push Tx
      model where it shares a Tx queue state with the
      host.
      
      The host updates the DMA region it pointed to
      during HTT setup whenever number of software
      queued from (on host) changes. Based on this
      information firmware issues fetch requests to the
      host telling the host how many frames from a list
      of given stations/tids should be submitted to the
      firmware.
      
      The code won't be called because not all
      appropriate HTT events are processed yet.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c1a43d97
    • M
      ath10k: add new htt message generation/parsing logic · 839ae637
      Michal Kazior 提交于
      This merely adds some parsing, generation and
      sanity checks with placeholders for real
      code/functionality to be added later.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      839ae637
    • M
      ath10k: refactor tx pending management · 6421969f
      Michal Kazior 提交于
      Tx pending counter logic assumed that the sk_buff
      is already known and hence was performed in HTT
      functions themselves.
      
      However, for the sake of future wake_tx_queue()
      usage the driver must be able to tell whether it
      can submit more frames to firmware before it
      dequeues frame from ieee80211_txq (and thus long
      before HTT Tx functions are called) because once a
      frame is dequeued it cannot be requeud back to
      mac80211.
      
      This prepares the driver for future changes.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      6421969f
  17. 28 1月, 2016 3 次提交
  18. 23 11月, 2015 1 次提交
  19. 13 11月, 2015 1 次提交
    • V
      ath10k: fix peerid configuration in htt tx desc for htt version < 3.4 · d39de991
      Vasanthakumar Thiagarajan 提交于
      Of a word in struct htt_data_tx_desc htt version >= 3.4 firmware uses
      LSB 16-bit for frequency configuration which is used for offchannel tx
      and MSB 16-bit is for peerid. But other firmwares using version 2.X
      (10.1, 10.2.2, 10.2.4 and 10.4) are using 32-bit for peerid in htt tx
      desc. So far no issue is found with the existing code setting peerid and
      freq for HTT version 2.X, this could be mainly because of 0 as frequecy
      (home channel) is being always passed with those firmwares. There may be
      issues when non-zero freq is passed with firmware using < 3.4 htt version.
      To be safe use target_version_major and target_version_minor along with
      htt-op-version before configuring peer id and freq in htt tx desc. This
      patch extends ath10k_mac_tx_frm_has_freq() to check for htt_op_version_tlv
      and uses the helper while setting peerid in htt_tx_desc.
      
      Fixes: 8d6d3624 ("ath10k: fix offchan reliability")
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d39de991
  20. 05 11月, 2015 1 次提交
  21. 16 10月, 2015 1 次提交
  22. 06 10月, 2015 1 次提交
  23. 09 9月, 2015 1 次提交